GPU accelerated X driver for RPi

[factoid]

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!

[mister_wavey]

Woop! *cheer!*

[Synthetic_Darkness]

*cheer* I think the more the better. I'll be closely following this thread.

Good luck soldier.

[factoid]

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.

[Synthetic_Darkness]

Awesome stuff.

[masterluke]

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

[factoid]

I'll settle for a pint if I'm ever in your area, but thanks for the enthusiasm.

[Synthetic_Darkness]

Ha ha imagine if he took you up on your offer

[factoid]

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.

[factoid]

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.

[Nr90]

That sounds very promising!

[Synthetic_Darkness]

Dude thats a massive amount of progress.

[factoid]

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

[Synthetic_Darkness]

Jeez dude. Is this a part time thing for you or are you sitting at home just coding

[rymate1234]

Been watching this post for a while. Progress seems really good!

Keep at it, we all want accelerated Xorg!

[factoid]

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.

[factoid]

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.

[Synthetic_Darkness]

I currently have no time for this. But give it about 2 weeks and I'll give it a go.