How does it compare to llvmpipe, for instance? I expect llvmpipe to be able to use neon (vector extension on ARM) instructions, as well as similar SIMD mechanisms on other platforms.
FBG – Lightweight C Linux framebuffer graphics with parallelism
31–40 of 50 posts
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#32Sadly linux framebuffer is still inferior in comparison to Windows framebuffer I'm running Windows 7 with a 14 yo gfx card (ATI Radeon 9250 - DirectX 8.1) along with Windows 2000 drivers in compatibility mode and if you exclude some minor tearing everything else is perfect. Same configuration but this time in linux, on various distros, from the lightest to the heaviest and the results are the opposite. heavy screen t…
My experience is the exact same, I so want to be able to have a snappy low latency desktop experience in Linux and it is just not happening. Today I run a "lightweight" Ubuntu Mate workstation with an i7 + dedicated GPU and it's still worse latency wise than my Windows XP PC was more than 15 years ago. Not good. Really not good.
It even appears to have gotten worse with time.
My only Linux system is a netbook with an AMD APU DX11 class, it used to work quite well, however after the AMD driver split performance was never as good and having back video hardware decoding required me to force enable it.
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#33It 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…
>As a side note, I remember that framebuffer was very slow on a computer I had. 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?
FB on modern computers work surprisingly well except for playing video or 3d graphics. Sometimes on BSD systems it is the only option.
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#34A 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.
So, such a microbenchmark marks the baseline for how fast you could get via framebuffer.
That's like 6 ms per frame. If you spend a bit less than two thirds of the time in rendering you could still get 60 fps. But that's still just crazy slow.
The 175 fps at that resolution comes down to about 20-60 MB/s depending on display depth. Memory peak transfer rates were worst like that during the 1990's, then several hundreds of MB/s for regular speeds in the 2000's and are measured in GB/s these days.
As long as we can reduce framebuffer access to shared memory (to eliminate legacy transfer methods of pixels, if any) there's no reason we couldn't do significantly better. Basically the display controller is reading the memory and the cpu is writing it so we must share some of the bandwidth but still the speeds should be so high that there's absolutely no reason we should ever see visual jerkiness on framebuffer graphics, due to hardware.
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#35Earlier quoted context omitted.
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.
I am aware of those, this might land in a future update.
The library initial focus was just to get multiple cores to work for graphics task...
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#36Sadly linux framebuffer is still inferior in comparison to Windows framebuffer I'm running Windows 7 with a 14 yo gfx card (ATI Radeon 9250 - DirectX 8.1) along with Windows 2000 drivers in compatibility mode and if you exclude some minor tearing everything else is perfect. Same configuration but this time in linux, on various distros, from the lightest to the heaviest and the results are the opposite. heavy screen t…
My experience is the exact same, I so want to be able to have a snappy low latency desktop experience in Linux and it is just not happening. Today I run a "lightweight" Ubuntu Mate workstation with an i7 + dedicated GPU and it's still worse latency wise than my Windows XP PC was more than 15 years ago. Not good. Really not good.
This is not the experience I'm getting. I'm running XUbuntu Bionic with i3, and the experience is butter smooth; makes Windows feel laggy and MacOS slow as molasses
on the other hand, there are no nice animations, transitions and 3D effects like shadowing; just pixels on the screen; however everything updates instantly.
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#37Earlier quoted context omitted.
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.
"Because you need to use proprietary graphics drivers for acceleration."
Is there some specific scenario where this would be a problem?
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#38Wait, is 320×240 at 42 fps supposed to be impressive?
Yeah that is actually extremely slow unless the time goes into calculating buffer contents and in that case it isn't really a benchmark of an FB implementation but something else.
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#39Wait, is 320×240 at 42 fps supposed to be impressive?
Yeah that is actually extremely slow unless the time goes into calculating buffer contents and in that case it isn't really a benchmark of an FB implementation but something else.
The time goes into calculating a fullscreen pixels-based effect (so yeah; buffer contents), the point of this library is not the FB implementation which is a simple / bare-metal one.
The point is to render graphics content in a consistent way across multiple CPU cores but still remain lightweight enough to be used with your own implementation, this might change but that was the initial goal.
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#40Earlier quoted context omitted.
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.
Actually, you don't. Raspberry Pi is still a proprietary platform (you need a closed firmware blob on your SD card for it to boot), but open GPU driver is now in Mesa and in some cases works better than the old proprietary one.