GPU accelerated X driver for RPi


18 posts
by factoid » Fri Oct 05, 2012 6:46 am
I'm officially forking the discussion from "Simon's Accelerated X" thread as we're working on different approaches to improving render performance and it's starting to become confusing.

*ahem* Hi! Like many others, I'm attempting to write an xfree86 DDX driver which will leverage OpenGLES2 and OpenVG to offload most of the xserver's operation to the GPU. At the moment I'm in over my head, but that's never stopped me before, and it's been an illuminating process thus far learning about DDX driver development.

As yet I'm not even at the point where I'm incorporating the videocore libraries to actually render anything, but as I get a "does nothing" driver skeleton in place I'm hoping that perhaps some of the more experienced graphics hackers will want to pitch in, or at least help answer my questions.

My git hub is here https://github.com/Factoid/xf86-video-rpi and I have plans to add a supplementary git of odds and ends that are either prerequisites for the driver, or simply assist in debugging. Just stuff to help cut through the hassle of getting setup, since there are few things more frustrating than a project that doesn't just build and run out of the box.

Hope to find some collaborators, or at least a cheering squad in here. Thanks for your time!
Posts: 45
Joined: Tue Jul 17, 2012 5:35 am
by mister_wavey » Fri Oct 05, 2012 7:09 am
Woop! *cheer!*
User avatar
Posts: 98
Joined: Sun Sep 02, 2012 8:23 am
Location: Abergavenny, Wales, UK
by Synthetic_Darkness » Sat Oct 06, 2012 8:25 pm
*cheer* I think the more the better. I'll be closely following this thread.

Good luck soldier.
http://codefridge.com/ - where cool code comes to chill.
Posts: 30
Joined: Sun Sep 23, 2012 12:22 pm
Location: JHB, South Africa
by factoid » Mon Oct 08, 2012 5:48 am
First milestone achieved. I have a skeleton driver that can correctly startup/shutdown, and respond to device input and VT switching. Next step is to implement cursor rendering, as it seems like it would be the simplest thing to follow up with.
Posts: 45
Joined: Tue Jul 17, 2012 5:35 am
by Synthetic_Darkness » Mon Oct 08, 2012 7:32 am
Awesome stuff.
http://codefridge.com/ - where cool code comes to chill.
Posts: 30
Joined: Sun Sep 23, 2012 12:22 pm
Location: JHB, South Africa
by masterluke » Mon Oct 08, 2012 3:20 pm
Sorry I don't have skills in any area that would be helpful - but if you get it working nicely I'll give you a go on the wife :P
Posts: 193
Joined: Tue Apr 17, 2012 4:10 pm
by factoid » Mon Oct 08, 2012 3:30 pm
I'll settle for a pint if I'm ever in your area, but thanks for the enthusiasm.
Posts: 45
Joined: Tue Jul 17, 2012 5:35 am
by Synthetic_Darkness » Wed Oct 10, 2012 8:36 am
Ha ha imagine if he took you up on your offer :D
http://codefridge.com/ - where cool code comes to chill.
Posts: 30
Joined: Sun Sep 23, 2012 12:22 pm
Location: JHB, South Africa
by factoid » Tue Oct 16, 2012 5:12 am
Progress has been a little slower this week. I was able to get the driver to not crash running xeyes, but xeyes didn't get what it wanted from the server and shut down. In an effort to better understand what's going on I started writing a simple client program in xcb to output server state values. This makes it easier to compare how the fb driver looks to a client vs. the rpi driver.

Currently the rpi driver will crash if you run the client application too many times. It's related to colour mapping, which is also somehow interfereing with the screen's white pixel value. If any X hackers can jump in and help me understand what's going on that'd be grand. As it stands there is still no GL code in, I want to make sure everythings good at the basic protocol level before I move on, so even if you're not used to GL, but used to X, you should be able to find your way around the source.

xcb test client repo is in my github https://github.com/Factoid/xserver-client-test, so feel free to poke around there too.
Posts: 45
Joined: Tue Jul 17, 2012 5:35 am
by factoid » Wed Oct 24, 2012 6:33 pm
Some significant progress this time around. The xf86-video-rpi driver now runs against xeyes, xedit, xlogo, and a few others I think. xclock returns that trapezoid rendering is not supported.

Nothing visually interesting is happening yet, of course, but the main point is that the driver is stable as far as the device independent parts of X are concerned. Next step is to start implementing the actual graphics context calls in GL so that things render to the screen.

Next update should have something to actually show.
Posts: 45
Joined: Tue Jul 17, 2012 5:35 am
by Nr90 » Wed Oct 24, 2012 10:52 pm
That sounds very promising! :D
Posts: 213
Joined: Sat Nov 26, 2011 12:39 pm
by Synthetic_Darkness » Thu Oct 25, 2012 6:34 pm
Dude thats a massive amount of progress.
http://codefridge.com/ - where cool code comes to chill.
Posts: 30
Joined: Sun Sep 23, 2012 12:22 pm
Location: JHB, South Africa
by factoid » Mon Oct 29, 2012 7:01 pm
Interim update. Screen blanking via GL is supported, so you can watch X transition between a black screen and a VT if you want (or alter the fill color in the source to suit your mood!). I'm working on implementing the FillPoly GC command so that xeyes will work, and hopefully that'll be done before the end of the week. The nice thing is that the GC operations are all really primitive, so there's a lot of stuff that will just 'magically' work once the basic drawing functions are in. But after that I fully expect there to be a litany of special cases and fixes before an actual desktop is properly supported. Then optimization...
Posts: 45
Joined: Tue Jul 17, 2012 5:35 am
by Synthetic_Darkness » Tue Oct 30, 2012 11:09 am
Jeez dude. Is this a part time thing for you or are you sitting at home just coding :D
http://codefridge.com/ - where cool code comes to chill.
Posts: 30
Joined: Sun Sep 23, 2012 12:22 pm
Location: JHB, South Africa
by rymate1234 » Tue Oct 30, 2012 11:32 am
Been watching this post for a while. Progress seems really good! :D

Keep at it, we all want accelerated Xorg! :!:
Posts: 22
Joined: Wed Oct 03, 2012 8:22 pm
by factoid » Tue Oct 30, 2012 12:27 pm
It's a part time thing. I'm flattered, but the rate of progress isn't that significant. I'm able to spend maybe an hour or two a day on this. My professional life is closely tied to this kind of work, so if I was actually able to commit 8 hours a day, then you'd see some real progress. I'm just trying to keep my personal momentum, so that I don't drop the ball en lieu of playing XCom or something. :)
Posts: 45
Joined: Tue Jul 17, 2012 5:35 am
by factoid » Thu Nov 01, 2012 6:58 pm
Been working on some rendering code suitable for the PolyFillArc command (used by xeyes to draw ovals). Just got it roughly ported in to the driver, but it's got a host of issues, stuff that I didn't expect to work, plus other things that fail for other reasons, mostly due to my poor understanding of X client-server workflow. Still, if you want to see a server that does something, you can run the driver, and run xeyes. Though you need to be on the X VT when it runs to see anything, and brace yourself; You'll be thoroughly underwhelmed.

Also has anyone actually tried compiling/installing the driver from my github? I'd like any feedback if the build system is causing problems on stock environments.
Posts: 45
Joined: Tue Jul 17, 2012 5:35 am
by Synthetic_Darkness » Sat Nov 03, 2012 6:03 pm
I currently have no time for this. But give it about 2 weeks and I'll give it a go.
http://codefridge.com/ - where cool code comes to chill.
Posts: 30
Joined: Sun Sep 23, 2012 12:22 pm
Location: JHB, South Africa