Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FBG – Lightweight C Linux framebuffer graphics with parallelism

github.com

Post reply on HN
Print view View original

41–50 of 50 posts

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#41

Post by Vendan »

raverbashing wrote: post #24
codedokode wrote: post #8

It 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…

> 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 No, it is as fast as it gets and it's the correct way of doing it (in fb at least).

Linux frame buffer is perfectly capable of doing 2 pages and "flipping" without memcpy. Just have it initialize a double height virtual screen, and then use a panDisplay IOCTL to swap between them.

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#42

Post by raverbashing »

Vendan wrote: post #41
raverbashing wrote: post #24

Earlier quoted context omitted.

> 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 No, it is as fast as it gets and it's the correct way of doing it (in fb at least).

Linux frame buffer is perfectly capable of doing 2 pages and "flipping" without memcpy. Just have it initialize a double height virtual screen, and then use a panDisplay IOCTL to swap between them.

I see your point. You still need to copy the data to the buffer.

But yeah, don't expect smooth animations without a dual buffer.

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#43

Post by v_lisivka »

Vendan wrote: post #17
ajross wrote: post #9

Earlier 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.

With CRT monitors, it was possible to swap buffer in the middle of the frame, to display different buffers in different areas of the screen. It was used on 16bit systems for fast scrolling and to display status line.

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#44

Post by zlynx »

smallstepforman wrote: post #20
codedokode wrote: post #8

It 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.

Haiku is also one of the best performers in a virtual Spice display. It feels faster and more responsive than a virtualized Fedora or Ubuntu.

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#45

Post by onirom »

quadcore wrote: post #11

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.

Did a simple clearing test with a 4 cores Raspberry PI 3B and 1280x768 resolution, i get 30 FPS.

However a single core memset (still RPI 3B) for this case is fast : 235 FPS

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#46

Post by quadcore »

yason wrote: post #34
quadcore wrote: post #11

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.

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 hundre…

I was intentionally keeping 'for y for x' loops.

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#47

Post by waddlesplash »

smallstepforman wrote: post #20
codedokode wrote: post #8

It 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.

Honestly we haven't spent a massive amount of time on VESA, or really much optimization in general. It's not like there are a ton of magic tricks in there to make it fast or something. Somehow everyone else still manages to be slower than we are, though...

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#48

Post by onirom »

Vendan wrote: post #41
raverbashing wrote: post #24

Earlier quoted context omitted.

> 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 No, it is as fast as it gets and it's the correct way of doing it (in fb at least).

Linux frame buffer is perfectly capable of doing 2 pages and "flipping" without memcpy. Just have it initialize a double height virtual screen, and then use a panDisplay IOCTL to swap between them.

Tried to implement page flipping today and performances are terribly low on the Raspberry PI due to direct draw calls to the video mapped memory... so you need to do a single memcpy to avoid multiple write to the video mapped memory, this result in the initial behavior.

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#49

Post by Vendan »

onirom wrote: post #48
Vendan wrote: post #41

Earlier quoted context omitted.

Linux frame buffer is perfectly capable of doing 2 pages and "flipping" without memcpy. Just have it initialize a double height virtual screen, and then use a panDisplay IOCTL to swap between them.

Tried to implement page flipping today and performances are terribly low on the Raspberry PI due to direct draw calls to the video mapped memory... so you need to do a single memcpy to avoid multiple write to the video mapped memory, this result in the initial behavior.

Generate single frame, copy to "off page", flip. This prevents tearing.

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#50

Post by onirom »

Vendan wrote: post #49
onirom wrote: post #48

Earlier quoted context omitted.

Tried to implement page flipping today and performances are terribly low on the Raspberry PI due to direct draw calls to the video mapped memory... so you need to do a single memcpy to avoid multiple write to the video mapped memory, this result in the initial behavior.

Generate single frame, copy to "off page", flip. This prevents tearing.

Yes, this is actually how it work however page flipping mechanism require a memcpy, as such it is as effective as not using page flipping and just memcpy a front buffer to display and doing software flipping through pointers exchange, the only advantage of using page flipping is that it require much less operations and prevent tearing but performance wise, it is roughly the same.
Post reply on HN