Setting VBE before switching to protected mode is a better solution, but I want to keep my bootloader minimal. I might also have to call VBE in the kernel proper (unless no? I'm not too familiar with VBE..)
What would you recommend?
Thanks

Isn't emulation very troublesome to implement? Parsing and executing x86 instructions sounds like a lot of pain..nullplan wrote:You could also just emulate x86. For me, I have a long mode OS. So emulation is the only way I would ever be able to use VBE. However, for now, my OS just wants a framebuffer, to be provided by the bootloader. And then I don't have to care if it is a VBE or GOP or native framebuffer. This does mean that there is currently no resolution changing. The only way I see to change that is to attempt to get a native driver for my hardware working (I highly doubt my OS will ever be used by anyone but myself, and as far as I know, even nVidia has pledged to release enough documentation to get a frame buffer going). It also means no 2D acceleration, no 3D acceleration, so neither videos nor games will work without burning up the CPU, but all that can follow after I make it to userspace. Build the house from the bottom, not the top.
I will do that thennexos wrote:As nullplan said, emulation is your best route. Emulating isn't the easiest, especially since some VESA BIOSes are known for entering into protected mode. Also, I would bet that some VESA BIOSes make use of CPU extensions, meaning that you should emulate a Pentium Pro or something newert. Also, VBE is very simple, so doing it in your bootloader would be an easier route then all out emulation. In UEFI, you must do it in your bootloader (since GOP can only be called from UEFI boot services).
x86 is a big pain because of its variable sized instructions, real mode, segmentation, etc. Emulation can be a pretty fun project, but if you don't want to do it, then you should implement in the bootloaderIsn't emulation very troublesome to implement? Parsing and executing x86 instructions sounds like a lot of pain..
Yes, but at least Intel's documentation is rather horrible from what I understandAnd AMD & Intel release documentation for their graphics card
There are already finished libraries for it, but of course you are welcome to tackle it yourself. Doesn't seem like that big of an issue. For VBE you probably won't even need protected mode to work correctly (if BIOS does switch, then usually only to go to flat address space), and mostly it will only be in, out, and a few calculation instructions.angods wrote:Isn't emulation very troublesome to implement? Parsing and executing x86 instructions sounds like a lot of pain..
Yeah, that's what I do, and it has served me well so far.angods wrote:If I'll never have to call any VBE functions, having a linear framebuffer set up by the bootloader is fine
I can't, actually. I had only heard that they wanted to, and a cursory search revealed the nVidia documentation hub. Sadly it seems to want to bury me in inconsequential documents until I give up. A search for "framebuffer" turned up 84 pages of results, but most of them for some Linux driver. If someone ever does find out how to make a framebuffer on an nVidia card, it would be a good thing to tutorialize.angods wrote:Can you send the NVidia documentation link, please?
Set the video mode in the bootloader. That way, the kernel doesn't need separate code to handle BIOS/VBE and UEFI/GOP.angods wrote:What would you recommend?
This... Is a very debatable point. Especially considering the fact that every OS uses embedded font rendering in one way or another. I'd say the slowdown isn't even remotely significant, maybe a few hundred ns extra latency, maybe 1-2 us.rdos wrote:The downside of setting up a fixed mode is that you can no longer use text mode, which is a very fast interface for displaying text. Instead, text mode needs to be emulated with a fixed font, which is much less efficient.
I don't think that's correct. Linux for example will happily run text mode still (as long as you compile the kernel with appropriate support) and that means it's not rendering fonts itself. The whole point of text mode is that you don't have to do font rendering in software.Ethin wrote:Especially considering the fact that every OS uses embedded font rendering in one way or another.
Latency is not the issue, throughput is. Writing a text mode character requires writing 2 bytes. Writing a character in graphics mode will typically be more than 256 bytes (and a generally more complex operation). In any circumstance where text output is your bottleneck, that's a huge difference.Ethin wrote: I'd say the slowdown isn't even remotely significant, maybe a few hundred ns extra latency, maybe 1-2 us.
I wasn't saying that text mode is (not) more efficient, just that saying that its faster than an LFB is a pretty hard claim to prove. As for Linux still using text mode, sure it will, but only if your not on UEFI (or maybe it reconfigures the GPU). The point I was getting at regarding practically all OSes not using text mode is that in the end, when your in userland and running GUI apps, your doing font rendering all the time. It may be slightly slower than text mode but most likely not remotely significantly enough to be anything to worry about or even notice. Your not using text mode if you've got Wayland running a desktop, for example, and Windows most likely doesn't use it anymore either (though it probably does retain support). UEFI outright ditched it, and you're going to have to do font rendering in-kernel because of that unless you write a GPU driver that's capable of reconfiguring the GPU to operate in text mode.davmac314 wrote:I don't think that's correct. Linux for example will happily run text mode still (as long as you compile the kernel with appropriate support) and that means it's not rendering fonts itself. The whole point of text mode is that you don't have to do font rendering in software.Ethin wrote:Especially considering the fact that every OS uses embedded font rendering in one way or another.
Latency is not the issue, throughput is. Writing a text mode character requires writing 2 bytes. Writing a character in graphics mode will typically be more than 256 bytes (and a generally more complex operation). In any circumstance where text output is your bottleneck, that's a huge difference.Ethin wrote: I'd say the slowdown isn't even remotely significant, maybe a few hundred ns extra latency, maybe 1-2 us.
There are other trade-offs, and I don't think optimising text output is necessarily worth worrying too hard over, but I completely disagree with your assessment that text mode is not more efficient (for displaying text).
Writing 2 bytes per character is going to be significantly faster than writing 256 bytes. Unless you are disputing that claim, what more proof do you need?Ethin wrote:I wasn't saying that text mode is (not) more efficient, just that saying that its faster than an LFB is a pretty hard claim to prove.
I agree with you on this part, not because it won't be a lot slower, but because text output isn't usually a bottleneck (and if it is, you probably can avoid it).Ethin wrote:It may be slightly slower than text mode but most likely not remotely significantly enough to be anything to worry about
Not wrong, but also does not mean that text mode, if you can use it, is not more efficient and faster.Ethin wrote:UEFI outright ditched it, and you're going to have to do font rendering in-kernel because of that unless you write a GPU driver that's capable of reconfiguring the GPU to operate in text mode.
You could just have text mode be one of the available preset options. Obviously if you're writing your own bootloader, you can present that as a config file option, keyboard shortcut, menu entry... Even Grub has a way to do this, which is useful for Multiboot payloads that request a graphics mode - you can "set gfxpayload=text" and it'll start you up in text mode instead.rdos wrote:The downside of setting up a fixed mode is that you can no longer use text mode, which is a very fast interface for displaying text. Instead, text mode needs to be emulated with a fixed font, which is much less efficient.
It can be a lot more than that. In a command window, you will typically scroll the text too, which is the major bottleneck with font rendering. In text mode, you can scroll the screen by copying 2 bytes per character, while with font rendering it might be 256. If you want to scroll a 80x24 screen once, that becomes 3840 bytes vs 491520, something that is VERY noticable. I will typically implement the graphical "text mode" by regularly rendering the complete screen instead of doing it in real time. This avoids getting into "scroll loops", but also looks "slow". With text-mode, the characters will be printed directly and scrolling will be done in real-time.davmac314 wrote:Writing 2 bytes per character is going to be significantly faster than writing 256 bytes. Unless you are disputing that claim, what more proof do you need?Ethin wrote:I wasn't saying that text mode is (not) more efficient, just that saying that its faster than an LFB is a pretty hard claim to prove.
(and incidentally if you agree that it is "more efficient" but not that it is "faster", what do you mean precisely?)