A suggestion for the benchmarks: add one where the screen is filled with a solid color. I was getting 175fps on 1280x768 with a 1.5Ghz AMD back in 2003.
FBG – Lightweight C Linux framebuffer graphics with parallelism
11–20 of 50 posts
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#12I would have thought the vector capabilities of ARM and Intel architectures would have been useful here, in addition to any multi-threadedness. They can be used to add fast GPU like functions, e.g. alpha blending.
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#13Raspberry Pi is a good example of where this would be quite useful (as per the readme). Nice work.
The Raspberry Pi has a GPU. Why wouldn't you use accelerated graphics?
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#14Hmm.. 1. This is being announced on GitHub, a Microsoft entity; 2. there are typos everywhere in the documentation; 3. the code is generally undocumented.
This is a single author's work to write a demonstration piece. Odd that is made the top five items on HackerNews.
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#15It looks very ineffective. For example, in fbg_draw() they have this code: https://github.com/grz0zrg/fbg/blob/master/src/fbgraphics.c#... > memcpy(fbg->buffer, fbg->disp_buffer, fbg->size); So they don't flip buffers, and don't even use video memory for them, they just copy data from buffer in main memory into a memory-mapped framebuffer. This must be slow. Also it doesn't check for vblank and therefore doesn't prot…
Without proprietary video card driver both Windows and Linux had troubles even scrolling a window, it was very laggy. Why was unaccelerated VGA (or VESA?) mode so slow, I wonder?
I haven't looked into the details on Linux but on Windows the "default" VESA/VGA mode uses the VGA BIOS, whose code is run in 16-bit VM86 mode:
https://wiki.osdev.org/Virtual_8086_Mode#Usage
http://nuclear.mutantstargoat.com/articles/pcmetal/pcmetal04...
The 16-bit code is not optimised for speed (is your framebuffer more than 64K? It's probably doing bankswitching and only copying 64K at a time), and the video BIOS itself may reside behind a slow serial interface on the GPU[1] --- so executing from it is very slow.
[1] https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bu...
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#16Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#17It looks very ineffective. For example, in fbg_draw() they have this code: https://github.com/grz0zrg/fbg/blob/master/src/fbgraphics.c#... > memcpy(fbg->buffer, fbg->disp_buffer, fbg->size); So they don't flip buffers, and don't even use video memory for them, they just copy data from buffer in main memory into a memory-mapped framebuffer. This must be slow. Also it doesn't check for vblank and therefore doesn't prot…
The memory mapped frame buffer is video memory, that's why you have to use a driver API to map it. Though obviously on many systems it ends up just being system dram with different caching settings anyway. And this isn't something you'd code a game with, but you'd be surprised at how high modern memory bandwidth is.
Yeah, but linux framebuffer can do a very optimal swap... Just make the "virtual buffer" twice as tall, and then swap which "half" is "active" with a panDisplay IOCTL... That's why memcpy is such a bad idea, cause there is a very cheap method that can prevent tearing and such.
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#18Raspberry Pi is a good example of where this would be quite useful (as per the readme). Nice work.
The Raspberry Pi has a GPU. Why wouldn't you use accelerated graphics?
Because you need to use proprietary graphics drivers for acceleration. Another reason could be that you want to write more portable code that can run in your RPi during the early stages of development and on a board with no GPU later on.
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#19I would have thought the vector capabilities of ARM and Intel architectures would have been useful here, in addition to any multi-threadedness. They can be used to add fast GPU like functions, e.g. alpha blending.
handmade hero did a software renderer using SIMD instructions with very good results:
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#20It looks very ineffective. For example, in fbg_draw() they have this code: https://github.com/grz0zrg/fbg/blob/master/src/fbgraphics.c#... > memcpy(fbg->buffer, fbg->disp_buffer, fbg->size); So they don't flip buffers, and don't even use video memory for them, they just copy data from buffer in main memory into a memory-mapped framebuffer. This must be slow. Also it doesn't check for vblank and therefore doesn't prot…
VESA is suprisingly good with Haiku. Since most GPU manufacturers have ignored Haiku, the community has spent some time getting the VESA driver as good as it can get, and it is very respectable. Most users will not be aware that they are running VESA, since Haiku still less laggy than it's contemporaries.