oldnpastit
Posts: 34
Joined: Wed Dec 04, 2013 7:57 am

fbturbo - dma hardly ever gets used?

Thu Jan 02, 2014 12:18 am

I thought I would have a quick look to see if I could get the DMA support in the bcm2708 framebuffer driver to use interrupts rather than busy waiting as it looks quite easy (or I just don't know enough to know why it's hard :-)

But first I wanted to check that DMA is being used at all. I added some statistics into the kernel driver, but DMA seems to hardly ever get used. The fbturbo X11 driver is definitely being used, and I can see the message about copyarea being detected. But DMA never actually happens (it seems to happen once at startup but that's it).

I've tried display depths of 16 bits and 32 bits.

What am I missing? Is there something I need to do to make it happen more often?

Looking at the code in the x11 fbturbo driver, it's very particular about when it will decide it's able to use the ioctl(). I'm wondering whether it actually can't ever be used unless both the source and destination are onscreen.

Kernel is 3.10.25. x11 fbturbo driver is 1.20131208-1.

Thanks

oldnpastit
Posts: 34
Joined: Wed Dec 04, 2013 7:57 am

Re: fbturbo - dma hardly ever gets used?

Thu Jan 02, 2014 9:22 am

Looks like if you switch back from the X display to the virtual console then it starts doing DMA lots.

Now to work out why my DMA interrupt never completes....

User avatar
joan
Posts: 14369
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: fbturbo - dma hardly ever gets used?

Thu Jan 02, 2014 9:52 am

oldnpastit wrote:Looks like if you switch back from the X display to the virtual console then it starts doing DMA lots.

Now to work out why my DMA interrupt never completes....
I don't understand that. Why would it DMA if nothing from X is visible. Have I misunderstood?

oldnpastit
Posts: 34
Joined: Wed Dec 04, 2013 7:57 am

Re: fbturbo - dma hardly ever gets used?

Thu Jan 02, 2014 10:05 am

I don't understand that. Why would it DMA if nothing from X is visible. Have I misunderstood?
The kernel also makes use of the copyarea ioctl() for doing console scrolling. That seems to be the easiest and most consistent way to get it to be used. It *seemed* to also start using it in X after I switched back but I didn't spend time investigating that.
Last edited by oldnpastit on Thu Jan 02, 2014 10:12 am, edited 1 time in total.

oldnpastit
Posts: 34
Joined: Wed Dec 04, 2013 7:57 am

Re: fbturbo - dma hardly ever gets used?

Thu Jan 02, 2014 10:12 am

Initial first cut at a patch for waiting for the DMA to complete using an interrupt:

https://github.com/luked99/linux/tree/fb_dma_irqs

This has a threshold (pixel area) to decide whether to use an IRQ or to busywait (which will be more efficient for smaller sizes).

I find that below about 16k pixels, it's not worth using the IRQ. And I also find that, at least for console scrolling, it never goes above this value anyway. It seems to be almost impossible to persuade the X server to use the copyarea extension (it detects it, just never uses it) so I'm not sure how much of a win this actually is.

Anyway, the threshold can be adjusted by changed /sys/module/bcm2708_fb/parameters/dma_busy_wait_threshold. There are stats on copyarea usage in /sys/kernel/debug/bcm2708_fb/stats (assuming you have debugfs mounted).

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23893
Joined: Sat Jul 30, 2011 7:41 pm

Re: fbturbo - dma hardly ever gets used?

Thu Jan 02, 2014 12:16 pm

Is this DMA stuff the stuff that make moving windows so much quicker when running X? Because there is a noticeable improvement there - is that not using copyarea?
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

oldnpastit
Posts: 34
Joined: Wed Dec 04, 2013 7:57 am

Re: fbturbo - dma hardly ever gets used?

Thu Jan 02, 2014 12:33 pm

Well, that's a good question.

There are several things that have made X go a bit quicker:
  1. 1. ARM optimizations in the X11 xorg fbturbo driver (user-side), by hglm This now uses some nifty VFP code to do blitting. This is nothing to do with DMA but has a big effect.
  • 2. The DMA copyarea() support in the kernel framebuffer driver itself (from ssvb). By itself this makes console scrolling go faster, but it should also make X go faster because of...
  • 3. the support added in the X11 xorg fbturbo driver
I have so far not really managed to persuade X to make use of the DMA though, so any speedup I get in X is likely a result of (1). I thought I _did_ see DMA/copyarea being used by X at one point, but then I upgraded X to the latest version and I've not seen it since. Possibly I'm just missing something obvious, or maybe the newer version of X somehow stops this working anymore.

The suggestion was that the busy-waiting for DMA completion could be improved upon by using an interrupt instead, which is what my patch does. If someone has a setup where X does make use of copyarea then it would be interesting to see if this makes things any better (or worse).

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23893
Joined: Sat Jul 30, 2011 7:41 pm

Re: fbturbo - dma hardly ever gets used?

Thu Jan 02, 2014 12:56 pm

Just read that thread - there's a comment in there that says that adding the IRQ for completion (this thread?) should dramatically reduce the CPU load over the non-IRQ implementation when window dragging - has that happened?
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5341
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: fbturbo - dma hardly ever gets used?

Thu Jan 02, 2014 3:00 pm

oldnpastit wrote:The suggestion was that the busy-waiting for DMA completion could be improved upon by using an interrupt instead, which is what my patch does. If someone has a setup where X does make use of copyarea then it would be interesting to see if this makes things any better (or worse).
I'll test your patch and see if I can see dma/irqs happening in X.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23893
Joined: Sat Jul 30, 2011 7:41 pm

Re: fbturbo - dma hardly ever gets used?

Thu Jan 02, 2014 3:55 pm

Having to spoken to OP, this may be related to the version of xserver being used - it would be interesting to know if people with 1.14 (?) see any regressions.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5341
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: fbturbo - dma hardly ever gets used?

Thu Jan 02, 2014 6:41 pm

So after launching X and opening a few windows and dragging around I get:

Code: Select all

dma_copies = 0x00000001
dma_irqs = 0x00000000
Opening a console (e.g. ALT-F3) and holding down enter:

Code: Select all

dma_copies = 0x0002738b
dma_irqs = 0x00000000
So, when do we get copies without an IRQ?
catting a big (binary) file from this console:

Code: Select all

dma_copies = 0x00063ac6
dma_irqs = 0x00002070
So now we're getting some irqs.

I did do the "Web" browser install which has possibly put my X into an unusual state.
I've now done the "apt-get" to revert libwebkitgtk (http://www.raspberrypi.org/phpBB3/viewt ... ra#p475037)

and I am seeing dma/irqs when dragging midori window:

Code: Select all

dma_copies = 0x0006503d
dma_irqs = 0x000025a4
and if I drag window as fast as possible, the CPU stays at around 28%. I imagine that was 100% without the IRQ.

Strangely dragging LXTerminal doesn't cause any DMA/IRQs so perhaps not everything possible is using the DMA path.

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: fbturbo - dma hardly ever gets used?

Thu Jan 02, 2014 7:30 pm

dom wrote:Strangely dragging LXTerminal doesn't cause any DMA/IRQs so perhaps not everything possible is using the DMA path.
That's because LXTerminal enforces RGBA visual (for potentially enabling translucency effects in the compositing window managers), which causes window redirection into a backing pixmap. And when moving the window, the pixels are simply copied from this backing pixmap to the framebuffer, also doing RGBA32->RGB565 conversion in the case of 16bpp desktop. Basically, a lot of awful things are happening and the performance suffers.

I would suggest using either XTerm (a very simplistic and fast terminal) or gnome-terminal (it specifically checks whether it was really launched under the compositing manager to decide whether to set RGBA visual or not). Both of these terminals have better performance than LXTerminal.

oldnpastit
Posts: 34
Joined: Wed Dec 04, 2013 7:57 am

Re: fbturbo - dma hardly ever gets used?

Thu Jan 02, 2014 9:57 pm

Thanks! Using xterm gives much more believable results.

I find a get a small but noticeable improvement with the threshold set at 32k.

Just constantly moving a large xterm, I was seeing around 50% CPU load from Xorg with DMA IRQs enabled, which went up to about 67% with the threshold high enough to prevent it ever being used. I'd be interested in other reports.

oldnpastit
Posts: 34
Joined: Wed Dec 04, 2013 7:57 am

Re: fbturbo - dma hardly ever gets used?

Thu Jan 02, 2014 10:54 pm

So, assuming this is working, what's the next easy thing to do to make X go faster?

The experience of previous work in this area suggests it's not easy. It might be interesting to see how far one can get by adding EXA support for GPU memory allocation: pixmaps allocated from the GPU memory ought to be easily fillable/blittable using the DMA (pixel formats allowing).

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: fbturbo - dma hardly ever gets used?

Thu Jan 09, 2014 8:19 am

oldnpastit wrote:So, assuming this is working, what's the next easy thing to do to make X go faster?
I'll add a more detailed comment later today or tomorrow.

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: fbturbo - dma hardly ever gets used?

Sun Jan 12, 2014 7:56 pm

oldnpastit wrote:The experience of previous work in this area suggests it's not easy.
Do you actually mean the Simon's work from the Accelerated X driver testing thread? This was indeed quite an interesting R&D project. Though unfortunately the critical parts of that work were never available as the open source code, which basically ensured that it has no chances to evolve into something of practical value :( By the critical parts I mean making use of the reverse engineered VideoCore bits for implementing the low level 2D graphics primitives.

There is another interesting MicroXwin- High performance X Windows thread. It tries to remove the interprocess communication overhead by replacing xlib with a lightweight shim, which talks directly to the kernel. Unfortunately MicroXwin developers also opted to take the closed source route, which diminishes the value of their efforts.
It might be interesting to see how far one can get by adding EXA support
I have thoroughly evaluated EXA approximately half a year ago and came to a conclusion that EXA simply is not fit for the job. EXA is a mid-layer convenience framework, which makes hooking the hardware accelerated operations really easy in the xorg drivers. But unfortunately this simplicity is not free and the internal EXA bookkeeping logic has a rather significant CPU overhead. That's why the DMA accelerated CopyArea code in fbturbo specifically avoids relying on EXA. It makes no sense to accelerate a single type of operation, but introduce a noticeable slowdown for everything else.
for GPU memory allocation: pixmaps allocated from the GPU memory ought to be easily fillable/blittable using the DMA (pixel formats allowing).
Accelerating just copy/fill is not enough. Because they would become bubbles in the middle of the sequence of 2D operations, causing CPU / GPU migration (cache flushing) of pixmap memory buffers. And for simple copy/fill it is clearly not worth it. The CPU can do copy/fill in the cached memory buffers reasonably fast.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23893
Joined: Sat Jul 30, 2011 7:41 pm

Re: fbturbo - dma hardly ever gets used?

Sun Jan 12, 2014 8:25 pm

ssvb wrote:
oldnpastit wrote:The experience of previous work in this area suggests it's not easy.
Do you actually mean the Simon's work from the Accelerated X driver testing thread? This was indeed quite an interesting R&D project. Though unfortunately the critical parts of that work were never available as the open source code, which basically ensured that it has no chances to evolve into something of practical value :( By the critical parts I mean making use of the reverse engineered VideoCore bits for implementing the low level 2D graphics primitives.
I'd be interested to know what you are referring to here, specifically what the problem is with closed source code, and stuff being of limited value because of it. Reason being that if we (Brcm people) know what might be needed to make things faster, we may be able to implement stuff, albeit closed source, running on the GPU, to make X acceleration easier. If work time allows of course.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: fbturbo - dma hardly ever gets used?

Sun Jan 12, 2014 8:46 pm

oldnpastit wrote:what's the next easy thing to do to make X go faster?
That's actually a good question.

One of the things to try would be disabling L2 cache for the framebuffer. The CPU accesses to the framebuffer memory have rather poor locality and are just writing there most of the time, not reading. I wonder if the framebuffer scanout (reading it 60 times per second for screen refresh) is constantly competing for the L2 cache access with the CPU in the current setup. I tried to experiment with tweaking this a really long time ago, but only got bugs and memory corruption. Still it could be revisited now.

Another interesting thing to try is the use of huge pages. Huge pages demonstrated a nice performance improvement for software rendered 2D graphics in my benchmarks on other ARM hardware. I even have a test branch with hugetlb support for rpi. And I also mentioned about this in the pixman mailing list to the person who works (or worked) on improving pixman optimizations for ARMv6 and Raspberry Pi, but unfortunately that discussion has died off. In any case, the 4KiB page size was for the i386 computers with only 4MiB of RAM total. Nowadays Raspberry Pi has a lot more RAM and using larger pages may reduce TLB misses, improving performance as a result ;)

More pixman optimizations are always going to be useful.

And finally, it makes sense to also focus on the X11 applications. For example, LXTerminal is particularly poorly behaved (as mentioned in this thread earlier). No matter what we do in the X drivers, the performance is going to be bad for it if the application itself decides to drag data through multiple intermediate buffers. It is just easier to fix this application or replace it with some better alternative. Modern X11 applications are typically developed for modern desktop computers. That's why some of them have a lot of redundant overhead and nobody notices.

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: fbturbo - dma hardly ever gets used?

Mon Jan 13, 2014 12:10 am

jamesh wrote:
ssvb wrote: Do you actually mean the Simon's work from the Accelerated X driver testing thread? This was indeed quite an interesting R&D project. Though unfortunately the critical parts of that work were never available as the open source code, which basically ensured that it has no chances to evolve into something of practical value :( By the critical parts I mean making use of the reverse engineered VideoCore bits for implementing the low level 2D graphics primitives.
I'd be interested to know what you are referring to here, specifically what the problem is with closed source code, and stuff being of limited value because of it.
I understand that Broadcom has reasons to keep the sources of the VideoCore firmware closed and I respect this choice.

But I'm talking about the Simon's source code of the "VPU binary" mentioned at http://elinux.org/RPi_Xorg_rpi_Driver with a comment "This makes use of information derived through reverse engineering and should not be used in countries where this is prohibited". What we have now is a somewhat messy repository on github, with the sources which just do not build out of the box and have the most interesting VPU parts omitted. There is simply nothing useful to scavenge there. Even the DMA settings originally used by the Simon's fbdev_exa turned out to be not reliable.

The Simon's work has limited value because now nobody can pick it up and continue. And this is rather sad. I just don't see any justification for this decision, unless Simon has an NDA with Broadcom. Hope this makes it clear.
Reason being that if we (Brcm people) know what might be needed to make things faster, we may be able to implement stuff, albeit closed source, running on the GPU, to make X acceleration easier. If work time allows of course.
Yes, as far as I know, Broadcom is actually the least "evil" of all ARM GPU closed source blob driver vendors. And I really appreciate this.

About the possible 2D acceleration in X. Potentially it may make sense to have some kind of low level 2D acceleration API with asynchronous completion. But at this point I don't know how well it can map to VideoCore hardware and whether it would be effective in practice. I have plans to try making a better use of 2D hardware accelerators in different ARM devices (Allwinner, Rockchip, Exynos). And Raspberry Pi may be revisited after this is done. But 2D acceleration is really tough in X11. Even the desktop video cards are having difficulties when trying to beat software rendering via either EXA or GLAMOR.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23893
Joined: Sat Jul 30, 2011 7:41 pm

Re: fbturbo - dma hardly ever gets used?

Mon Jan 13, 2014 9:45 am

ssvb wrote:
I understand that Broadcom has reasons to keep the sources of the VideoCore firmware closed and I respect this choice.

But I'm talking about the Simon's source code of the "VPU binary" mentioned at http://elinux.org/RPi_Xorg_rpi_Driver with a comment "This makes use of information derived through reverse engineering and should not be used in countries where this is prohibited". What we have now is a somewhat messy repository on github, with the sources which just do not build out of the box and have the most interesting VPU parts omitted. There is simply nothing useful to scavenge there. Even the DMA settings originally used by the Simon's fbdev_exa turned out to be not reliable.

The Simon's work has limited value because now nobody can pick it up and continue. And this is rather sad. I just don't see any justification for this decision, unless Simon has an NDA with Broadcom. Hope this makes it clear.
Reason being that if we (Brcm people) know what might be needed to make things faster, we may be able to implement stuff, albeit closed source, running on the GPU, to make X acceleration easier. If work time allows of course.
Yes, as far as I know, Broadcom is actually the least "evil" of all ARM GPU closed source blob driver vendors. And I really appreciate this.

About the possible 2D acceleration in X. Potentially it may make sense to have some kind of low level 2D acceleration API with asynchronous completion. But at this point I don't know how well it can map to VideoCore hardware and whether it would be effective in practice. I have plans to try making a better use of 2D hardware accelerators in different ARM devices (Allwinner, Rockchip, Exynos). And Raspberry Pi may be revisited after this is done. But 2D acceleration is really tough in X11. Even the desktop video cards are having difficulties when trying to beat software rendering via either EXA or GLAMOR.
I'm still a bit unclear about what Simon did using the VPU that is problematic. If it's something that could be official put in to the GPU, or rather, a technique or API or whatever that helps (ie is worthwhile doing), that might be possible to put in (we would not be able to use Simon's code as I assume its GPL, but we could write equivalent code to achieve the same results).

As to the general problems of 2D acceleration of X - yes, it does seem a pretty difficult things to improve on! I'm no expert on X or, actually, the 2D HW in the VC4, so it's difficult to judge what would be possible.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5341
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: fbturbo - dma hardly ever gets used?

Mon Jan 13, 2014 11:40 am

ssvb wrote: But I'm talking about the Simon's source code of the "VPU binary" mentioned at http://elinux.org/RPi_Xorg_rpi_Driver with a comment "This makes use of information derived through reverse engineering and should not be used in countries where this is prohibited". What we have now is a somewhat messy repository on github, with the sources which just do not build out of the box and have the most interesting VPU parts omitted. There is simply nothing useful to scavenge there. Even the DMA settings originally used by the Simon's fbdev_exa turned out to be not reliable.

The Simon's work has limited value because now nobody can pick it up and continue. And this is rather sad. I just don't see any justification for this decision, unless Simon has an NDA with Broadcom. Hope this makes it clear.
There's no NDA and I don't believe we (either raspberry pi or Broadcom) have any objection to anyone publishing VPU code (either binary blobs, or assembly using reverse engineered tools).

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: fbturbo - dma hardly ever gets used?

Tue Jan 14, 2014 10:02 pm

dom wrote:There's no NDA and I don't believe we (either raspberry pi or Broadcom) have any objection to anyone publishing VPU code (either binary blobs, or assembly using reverse engineered tools).
OK, that's good to know. In any case, the choice to open source something or keep it closed is always up to its authors. But the discussion seems to have sidetracked, and it would be nice to get it back to the technical stuff.

hermanhermitage
Posts: 65
Joined: Sat Jul 07, 2012 11:21 pm
Location: Zero Page

Re: fbturbo - dma hardly ever gets used?

Wed Jan 15, 2014 1:20 am

I'm all for pitching in with some VPU code.

I've glanced at X11 in the past but it felt like too steep a mountain to climb with rather limited time here. Are there some bulk asynchronous commands we can implement? I got the feeling most X applications had devolved over the years into client side rendering (lots of data fences and small operations, relying on a fast CPU) and that going forward on the RPi all compositing will be taken over by dispmanx surfaces with the work being done on Wayland/Weston.

Any pointers?

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: fbturbo - dma hardly ever gets used?

Thu Jan 16, 2014 9:19 am

hermanhermitage wrote:I'm all for pitching in with some VPU code.

I've glanced at X11 in the past but it felt like too steep a mountain to climb with rather limited time here. Are there some bulk asynchronous commands we can implement?
I can't provide a good example or a guide for implementing the accelerated 2D operations this point. EXA is not really useful because it has a heavy CPU overhead by itself. And also adding support for individual accelerated functions one at a time via EXA will just result in pingpong between the CPU and GPU, which is a major performance problem.

But in a nutshell, the possible solution is to make sure that the transition from the CPU to GPU/DMA happens only once on the way to the display. Kind of like http://en.wikipedia.org/wiki/Multistage_rocket where the first stage is the CPU and the second stage is the GPU/VPU/DMA ;) Right now everything in fbturbo is done by the CPU, except for the very last DMA accelerated copyarea operations within the framebuffer itself. Looks exactly like an initial rudimentary implementation of this principle, right? The major advantage here is that we get a clear improvement over the original fbdev driver in xorg without any regressions.

The next step in the evolution of the fbturbo driver is to move more of the late operations to the GPU/DMA. The obvious targets are XRENDER based compositing window managers. If we can make sure that the window backing pixmaps are migrated to the GPU memory and all the desktop eye candy effects provided by the compositing window manager can be handled by the GPU, then we can have this stuff nicely accelerated. The important requirement (the CPU->GPU transition happening only once on the way to screen) is satisfied in this case.

However the practical usefulness of accelerating XRENDER compositing managers is questionable. Because compositing is better to be implemented via DispmanX layers in any case. But it's still a nice training exercise and should unlock further optimization opportunities.
I got the feeling most X applications had devolved over the years into client side rendering (lots of data fences and small operations, relying on a fast CPU)
You are making a good point about the applications. Everything basically boils down to the selection of applications. If the user mostly has GTK2 applications originating from a decade ago (and developed/optimized for single core low mhz desktop hardware of that time), then system is going to be generally usable on the Raspberry Pi. If the user prefers more modern applications developed for modern desktops, then the Raspberry Pi is going to struggle handling them. There are always exceptions of course. And not all the modern applications are poorly designed to abuse the abundance of the modern processing power, but the trend is rather disturbing.

As for the client side rendering, it's mostly the Qt based applications that are the worst offenders. The good old GTK2 applications are still enjoying the proper X11 network transparency and are better suited for 2D acceleration done by Xorg.
and that going forward on the RPi all compositing will be taken over by dispmanx surfaces with the work being done on Wayland/Weston.
I'm also very curious and keep an eye on the progress in this area.
Any pointers?
I hope to provide some update soonish.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23893
Joined: Sat Jul 30, 2011 7:41 pm

Re: fbturbo - dma hardly ever gets used?

Thu Jan 16, 2014 4:59 pm

HI ssvb,

any hints on getting fbturbo to compile?

I've tried on the Pi and am missing two packages during configure

xf86driproto
libdrm

But apt-get install xf86driproto libdrm

doesn't find either, and I haven't yet found which packages they are actually in (still looking).

Also trying to cross compile. But the .configure is saying cross compiler not being used - been adding a --target and --prefix, but no go. Do you cross compile, and if so which .configure line do you use?

James
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

Return to “Graphics programming”