Hi,
in last weeks I was working with UEFI. I succesfully wrote a 64 bit bootloader that gives the control to my 32 bit loader.
In a legacy BIOS system I used to print character on screen by vga text mode, now I'm going to use one of the graphic mode I can set by UEFI boot service.
I wrote a print function that works fine but I have problems with scroll text function.
I just want right now using graphic mode like text mode, I mean printing debug or any kind of string. But obviously if I scroll the text by a simple memmove the process is extremely slow (I am using for example a 1024x768 with 32bpp).
I'm completely newbie in graphic mode so maybe someone could suggest me a fast way to do that (without using any graphic card optimization).
Obviously I can split the screen in "windows" but it's not the point of my question.
Thank you,
Daniele
Scroll text in graphic mode
-
- Member
- Posts: 307
- Joined: Wed Oct 30, 2013 1:57 pm
- Libera.chat IRC: no92
- Location: Germany
- Contact:
Re: Scroll text in graphic mode
All the information about the buffer is provided in the GOP. Scrolling down is as simple as you said it is; copy every line one line upwards. For speed, there's not much to say; double-buffering and optimized memory functions are your friends.
Graphic Card acceleration is not provided by the GOP (take a look at the typedefs of whatever lib you use).
Graphic Card acceleration is not provided by the GOP (take a look at the typedefs of whatever lib you use).
Re: Scroll text in graphic mode
Yes I know all these information.
I just wondered if some faster technique was available in the community
You said "no", thanks anyway!
I just wondered if some faster technique was available in the community
You said "no", thanks anyway!
no92 wrote:All the information about the buffer is provided in the GOP. Scrolling down is as simple as you said it is; copy every line one line upwards. For speed, there's not much to say; double-buffering and optimized memory functions are your friends.
Graphic Card acceleration is not provided by the GOP (take a look at the typedefs of whatever lib you use).
- BrightLight
- Member
- Posts: 901
- Joined: Sat Dec 27, 2014 9:11 am
- Location: Maadi, Cairo, Egypt
- Contact:
Re: Scroll text in graphic mode
Try using SSE instructions to speed up moving memory. See this article: SSE.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
-
- Member
- Posts: 307
- Joined: Wed Oct 30, 2013 1:57 pm
- Libera.chat IRC: no92
- Location: Germany
- Contact:
Re: Scroll text in graphic mode
I didn't say no, I just said that I'm not aware of any optimizations except for the obvious memset/memmov/memchr/memcpy optimizations. As omarrx024 said, SSE would be a possibility to speed things up.matute81 wrote:You said "no", thanks anyway!
Just out of interest, what UEFI implementation ("kit") are you using?
Re: Scroll text in graphic mode
Hi,
When scrolling text most of the pixels actually remain the same. For example, there'll be space at the ends of lines and space between lines, and space between characters. Even when characters (that aren't white space) change, half of the character's pixels can still be the same - e.g. the upper part of most lower case characters (e.g. "acegmnopqrsuvw") is empty, few characters use the lower part of the character (only lower case "gjpqy"), maybe the middle part of 'a' and 'd' and 'q' are identical, etc.
For blitting to display memory, the largest bottleneck is often PCI bus bandwidth. If half the pixels don't actually change when you scroll, you'd be able to blit twice as fast by avoiding half the writes to display memory.
However, it's not quite that simple. There's 2 types of transfers over PCI - small transfers (which are like "address, size, data" and might add up to ~34 bytes of traffic just to write one byte) and "burst transfers" where the address is sent once for a longer sequence of bytes (e.g. "address + 64 bytes"). With this in mind, you don't really want to work on individual pixels, and (e.g.) if 11 bytes were changed and 5 weren't then you'd want to write all 16 bytes to avoid the small transfers.
Also note that RAM is typically a lot faster than the PCI bus, so (e.g.) if it takes several reads/writes to normal RAM just to avoid a similar sized write to display memory then it's usually worth doing.
With all of this in mind; I'd use 2 buffers in RAM. The first would contain the pixel data for the new frame, and the second would contain the pixel data for the previous frame. You'd compare data in the first buffer to the data in the second buffer (likely working on 8 bytes at a time to avoid/reduce those small transfers) and see if its different; and only if that group of pixels actually are different you'd write them to display memory.
Cheers,
Brendan
When scrolling text most of the pixels actually remain the same. For example, there'll be space at the ends of lines and space between lines, and space between characters. Even when characters (that aren't white space) change, half of the character's pixels can still be the same - e.g. the upper part of most lower case characters (e.g. "acegmnopqrsuvw") is empty, few characters use the lower part of the character (only lower case "gjpqy"), maybe the middle part of 'a' and 'd' and 'q' are identical, etc.
For blitting to display memory, the largest bottleneck is often PCI bus bandwidth. If half the pixels don't actually change when you scroll, you'd be able to blit twice as fast by avoiding half the writes to display memory.
However, it's not quite that simple. There's 2 types of transfers over PCI - small transfers (which are like "address, size, data" and might add up to ~34 bytes of traffic just to write one byte) and "burst transfers" where the address is sent once for a longer sequence of bytes (e.g. "address + 64 bytes"). With this in mind, you don't really want to work on individual pixels, and (e.g.) if 11 bytes were changed and 5 weren't then you'd want to write all 16 bytes to avoid the small transfers.
Also note that RAM is typically a lot faster than the PCI bus, so (e.g.) if it takes several reads/writes to normal RAM just to avoid a similar sized write to display memory then it's usually worth doing.
With all of this in mind; I'd use 2 buffers in RAM. The first would contain the pixel data for the new frame, and the second would contain the pixel data for the previous frame. You'd compare data in the first buffer to the data in the second buffer (likely working on 8 bytes at a time to avoid/reduce those small transfers) and see if its different; and only if that group of pixels actually are different you'd write them to display memory.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: Scroll text in graphic mode
Thank you for the good tips!
PS: I'm using UEFI implemented by PHOENIX, if I understand your question.
PS: I'm using UEFI implemented by PHOENIX, if I understand your question.