Hexxeh
Posts: 91
Joined: Thu Apr 05, 2012 3:07 pm
Contact: Website

Re: Simon's accelerated X development thread

Wed Oct 03, 2012 12:31 pm

I want to run Chromium with Aura in some fashion on the Pi without using software rendering.

factoid
Posts: 45
Joined: Tue Jul 17, 2012 5:35 am

Re: Simon's accelerated X development thread

Wed Oct 03, 2012 12:32 pm

Simon, it's not so bad once you get your head around it. The way I've been doing it isn't optimal but it's letting me discover a lot about the internals of X while I do it, which is important for me. If my code's built on something I don't at all understand it's going to be painful when it breaks. The ddx development guide and the Xserver porting layer are fairly helpful resources, and the fbdev driver is their reference implementation, so there's more to learn from that as well.

Mostly it just comes down to having your ScreenPtr, and dependant structures, properly initialized. Just about everything in the structs need to be touched or passed off to the mi* or fb* implmentations. I think I'm probably very close to a "doesn't crash, but doesn't do anything either" point, and from there my experience with 3D graphics programming should start to kick in as I actually implmenent the rendering calls for the GC. Just been a very steep learning curve and a few false starts.

Also, glamor is out for the time being, just due to the "I don't understand enough of what's going on". I suspect once I reach a certain point it'll be faster/easier to replace sections of my dummy functions with glamour calls, rather than re-writing from scratch. All the extra indirection was causing the EGL functions to fail as well, so that was one last reason to tear it back to the studs and build from the ground up.

I'll fork my updates into it's own thread now, probably in the graphics subsection, as I'm going to probably need assistance with the bcm_host and associated libraries at some point.

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Wed Oct 03, 2012 2:24 pm

Yeah I'm thinking about sacking off the EXA layer that sits on top of the driver (and connects the bits in ScreenPtr) as I'm convinced I'm hitting bugs in it. Also it does not appear to be able to handle unifed memory, so my initial version has to double-up memory usage (plus copies back and forth).

I also found a nice bug the other day where memory was allocated with one system (the base screen pixmap is allocated as an actual pixmap) and then freed with another. libc does not know how to free my special memory ;)
Hexxeh wrote:I want to run Chromium with Aura in some fashion on the Pi without using software rendering.
What kind of functions would you want to be calling? My example months ago of getting an EGL sample in a window only needed a few extra calls compared to the original EGL code. Are you suggesting not having any extra calls at all?

Hexxeh
Posts: 91
Joined: Thu Apr 05, 2012 3:07 pm
Contact: Website

Re: Simon's accelerated X development thread

Wed Oct 03, 2012 2:36 pm

Yep, no extra calls at all.

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Wed Oct 03, 2012 3:13 pm

What if you could link to a special libegl (or whatever it's called) that did all the work for you?

Hexxeh
Posts: 91
Joined: Thu Apr 05, 2012 3:07 pm
Contact: Website

Re: Simon's accelerated X development thread

Wed Oct 03, 2012 3:14 pm

Just a replacement for the current libEGL, then? That'd work for me.

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Wed Oct 03, 2012 8:48 pm

Right I'll stick it on the list! Not on the v1 list mind you, else I'll literally never get anything out the door.
(unless I can knock it up this weekend of course ;))

User avatar
Jade
Posts: 17
Joined: Wed Dec 28, 2011 12:49 am
Location: Russia

Re: Simon's accelerated X development thread

Thu Oct 04, 2012 1:51 am

that does sound like a good idea, far better than what we have right ow

benjsc
Posts: 3
Joined: Wed Oct 03, 2012 4:36 am

Re: Simon's accelerated X development thread

Thu Oct 04, 2012 1:31 pm

I started looking at what would be involved in using glamor and exa/uxa in a driver, and came across: http://cgit.freedesktop.org/~wjt/xf86-video-videocore/
With the description being: "A work-in-progress X driver for Raspberry Pi"

Seems to be quite well progressed.

User avatar
cave
Posts: 161
Joined: Fri Aug 03, 2012 6:26 am
Location: europe/austria
Contact: Website

Re: Simon's accelerated X development thread

Thu Oct 04, 2012 2:06 pm

Maybe we can ask him whats happend with his freedesktop repro, if it is still alive and some inputs and hints for factoid, teh_orph and hexxeh

http://willthompson.co.uk/
https://github.com/wjt
http://cavebeat.blogspot.co.at

benjsc
Posts: 3
Joined: Wed Oct 03, 2012 4:36 am

Re: Simon's accelerated X development thread

Thu Oct 04, 2012 3:11 pm

I'm taking a look at the state of the xorg repo driver now.. compiling and getting the debug infrastructure in place takes a while on the pi.


factoid
Posts: 45
Joined: Tue Jul 17, 2012 5:35 am

Re: Simon's accelerated X development thread

Fri Oct 05, 2012 7:05 am

Split the xf86-video-rpi discussion into its own thead http://www.raspberrypi.org/phpBB3/viewt ... 67&t=19263

User avatar
wjt
Posts: 1
Joined: Fri Oct 05, 2012 1:39 pm
Contact: Website

Re: Simon's accelerated X development thread

Fri Oct 05, 2012 3:29 pm

Hey folks. Nice detective work. :)

So my approach with that driver was to back X pixmaps by EGLImages created using the BRCM_global_image extension, which would allow clients to draw directly to a texture and have it sent to the screen without a further copy. I didn't get all that far with it, and in retrospect I don't think it's really the right starting point. It's quite a boil-the-ocean scheme, in that it helps if and only if all drawing everywhere is done with GL.

I'm working on other things at the moment. Some of my coworkers have been looking into getting Weston (the reference Wayland compositor) working atop OpenWF on Pi to get an accelerated desktop, and then improving XWayland for the benefit of non-Wayland apps. I'll point them at this thread… :)

(If anything from my xf86-video-videocore is useful, great!)

ubergeek72
Posts: 12
Joined: Tue Aug 28, 2012 2:58 am

Re: Simon's accelerated X development thread

Fri Oct 05, 2012 5:36 pm

I've been watching this thread with considerable interest, and from the sound of things, a great deal has gotten accomplished. Awesome work, folks. Not being an expert programmer myself, and being rather rusty at unix driver installation, I wonder if I could get a couple questions answered?

1. Is the driver working now?
a. reliable enough for day to day use
b. acceleration is working
c. reduced memory footprint? (Last numbers I saw were 79 megs for the compositor.)
2. Is there any specific memory split I need to use it?
3. For those of us unaccustomed to grabbing stuff off of git and installing it into the guts of the OS, could there be a quick explanation on how that's done?

Thank you, and thanks again for all your hard work.

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Fri Oct 05, 2012 5:55 pm

With regards to my driver,
ubergeek72 wrote:I wonder if I could get a couple questions answered?
1. Is the driver working now?
Yep, it's been working for many months. Debugging tiny issues can waste a weekend though :(
a. reliable enough for day to day use
If you have any doubt then I would say no, however if you're not running mission critical code then it's probably fine!
b. acceleration is working
Yes. However in the process of writing this, I've discovered that X is rarely the bottleneck. Since I doubt people will believe me I've added a mode where X runs as absolutely fast as possible (the display is completely corrupt) but you can still make out how slow the actual applications are functioning through the corruption. It'll make sense when you try it ;)
I have not bothered with most composite acceleration in 16-bit colour mode. Only 24 and 32 bits.
c. reduced memory footprint? (Last numbers I saw were 79 megs for the compositor.)
Sorry I must have given the wrong impression - that was the GNU assembler assembling the compositor. Normally assembling is a fast and low-memory event; it was more of a demonstration of how nuts I'd gone with the compositor's permutations!
With regards to the driver's run-time memory allocation, it does need more memory compared to vanilla X. I would like to fix this (to use the exact same amount) but that'll take quite some time. At the moment the amount of extra memory is completely controlled by you. I've given a finger-in-the-air default of 12 MB.
2. Is there any specific memory split I need to use it?
The most possible allocated to the ARM.
3. For those of us unaccustomed to grabbing stuff off of git and installing it into the guts of the OS, could there be a quick explanation on how that's done?
I don't know yet. I am hoping some kind soul will make a Debian package for me!
If I get lucky with my final corruption bug I'll be sending said packagers some code this weekend!
EDIT: oh and it'll require a kernel module that I've written. Not sure how that bit's gonna work...

mat80c
Posts: 15
Joined: Wed Aug 17, 2011 2:32 pm

Re: Simon's accelerated X development thread

Fri Oct 05, 2012 6:55 pm

What kind of speed up can we expect from the initial implementation of your x driver. Thanks in advance.

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Sun Oct 07, 2012 2:14 am

So I've spent the last five hours tracing this corruption bug (3am...) and it appears I've found my first genuine Xorg bug!
I can clearly see where it goes wrong in the code (not my code) and this tracker - that's been running for seven months - looks like what I've got.
https://bugs.freedesktop.org/show_bug.cgi?id=47266

Fixing this may be tricky.
NB: I'm seeing basically the same behaviour as the users get in the thread.

ubergeek72
Posts: 12
Joined: Tue Aug 28, 2012 2:58 am

Re: Simon's accelerated X development thread

Sun Oct 07, 2012 2:24 am

teh_orph wrote:With regards to my driver,
**snip**
If I get lucky with my final corruption bug I'll be sending said packagers some code this weekend!
EDIT: oh and it'll require a kernel module that I've written. Not sure how that bit's gonna work...
Awesome. Thanks for answering all my questions here. :)

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Sun Oct 07, 2012 10:40 am

Haha, fixed it! (well not properly anyway)
I think I'm gonna submit this to the Xorg peeps.

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Sun Oct 07, 2012 11:47 am

For those who care, I've stuck this in as a bug with the Xorg people. Includes two exciting screen shots!
https://bugs.freedesktop.org/show_bug.cgi?id=55723

atarian88
Posts: 6
Joined: Mon Jul 09, 2012 5:51 pm

Re: Simon's accelerated X development thread

Tue Oct 09, 2012 10:36 pm

Simon, which steps would one take to build this code of yours? I sort of managed by throwing the source into a xf86-video-fbdev source directory and modifying the Makefile.am to add the new source files, but since you added that big cpp file I have no clue how to build this.

Some friendly pointers would be appreciated. I'm on Arch Linux ARM (armv6h) if that helps. I'm sorry if I'm missing something obvious, but I'm new to X.org development.

SkinnyClient
Posts: 3
Joined: Thu Oct 11, 2012 8:55 pm

Re: Simon's accelerated X development thread

Thu Oct 11, 2012 9:58 pm

Agreed with Above, if you need beta testers or just some people to help out with grunt work. Please let me know. I've never done installation of X drivers so I'd need a very basic tutorial though.

User avatar
cave
Posts: 161
Joined: Fri Aug 03, 2012 6:26 am
Location: europe/austria
Contact: Website

Re: Simon's accelerated X development thread

Tue Oct 16, 2012 12:26 pm

please check the post from Liz :

http://www.raspberrypi.org/phpBB3/viewt ... 00#p194400
Liz wrote:Accelerated X will be a solved problem soon; we've put engineering resource on it, and it's actively being worked on.
http://cavebeat.blogspot.co.at

User avatar
malakai
Posts: 1382
Joined: Sat Sep 15, 2012 10:35 am
Contact: Website

Re: Simon's accelerated X development thread

Tue Oct 16, 2012 1:15 pm

Code: Select all

So you gonna be done by Tuesday..

Well maybe I don't know, maybe if I stop sleeping.

Well good. Because I just told a few million people it wouldn't be a problem.

Oh.... O.K. Then.

:D Bosses - got to love them sometimes. Just wanted to stop and say thanks for you hard work. Looks like you've got it under control. Can't wait to see what you've come up with.
http://www.raspians.com - always looking for content feel free to ask to have it posted. Or sign up and message me to become a contributor to the site. Raspians is not affiliated with the Raspberry Pi Foundation. (RPi's + You = Raspians)

Return to “General discussion”