Simon's accelerated X development thread

[teh_orph]

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.

Sorry for the delay - I've been away.
You need some modifications to the Xorg source itself, so make sure you can build that too.

The cpp stuff is a PITA, since the original build system did not seem geared for it. Also, the compiler will not emit (useful) ARMv6 SIMD instructions, so I've had to go via an intermediate asm step. There's a makefile target for it in Makefile.in. You'll need clang installed. Just to clarify, we compile the cpp+inl with Clang to assembly, tack on an asm macro and then recompile the code with GCC using one of the inbuilt rules.

I'm developing the whole thing in Arch (the April distro) anyway, so should be able to guide you along.

[atarian88]

OK, thanks for you reply. I am able to build the Xorg server, as I've downloaded the source before. I'm a complete newbie when it comes to clang as well. A set of patches against the xorg-server source would be nice, if applicable.

It's exciting that you're almost finished. What do you plan to do with regards to the official effort to bring EXA to the Pi?

[teh_orph]

Yeah I really need to compile some patches against X - the driver won't work as-is. You also need to compile the Linux kernel, if you haven't done already and download my dma module from github. Github is getting DDOS'd right now, so I don't have a link to hand!

Besides not being able to check in some new stuff, proper successful evening today.
- the X people have fixed the bug I found in the Xorg server https://bugs.freedesktop.org/show_bug.cgi?id=55723 and I can confirm it works...even a rare corruption bug I've been seeing in Midori for six months has gone away!
- I've finally gotten a handle on the AXI burst value that can freeze your Pi or turn off the screen(!), and also being able to use the AXI burst in addition to source/destination burst. That's a 5x increase in window dragging/upload/download performance...
- I've spent the last few days with a test kernel in VirtualBox messing around with 'reserved' memory. I really need this in order to get a piece of memory that's not chopped up into 4k pages. I wrote the code for the Pi this evening and have X running with it. This can theoretically give up to 3x increase in said dragging.
- since I'm now not (always) bound by 4k pages, I can use the 2D DMA operations! That will lower the CPU load and also greatly reduce the DMA start-up cost. Wup wup.

I just now need to do a tidy up on this 4k page stuff (which will probably take all weekend), implement a few more composite operations (easy), and also try and bump up the composite code gen performance by 20%. And...that's it??!

NB: this reserved memory stuff should work really well I think n the 512MB Pis.

[portets]

Wow, exciting stuff. Is there any collaboration going on with this and http://www.raspberrypi.org/phpBB3/viewt ... 00#p194400

[hojnikb]

This is really great to finally see X has come this far.
What would be the minimum mem. split for accelaration to work ?
Would be 16MBs be enough ?

[teh_orph]

This is really great to finally see X has come this far.
What would be the minimum mem. split for accelaration to work ?
Would be 16MBs be enough ?

Yep. This is what I'm actually targetting. And also in 32-bit colour mode; I've not put in much effort for 15/16-bit colour.

[hojnikb]

Thats great for us with 256MB boards
Lots of free ram and less arm usage is what what Pi really needs for desktop use.

[teh_orph]

If you could stick this at the end of config.txt

framebuffer_depth=32
framebuffer_ignore_alpha=1

and get used to 32-bit X for a bit that'll help me out! (makes a better impression )

[lb]

16 bit has horrible color banding, I'm glad the focus is on 24/32 bits.

[teh_orph]

I just now need to do a tidy up on this 4k page stuff (which will probably take all weekend), implement a few more composite operations (easy), and also try and bump up the composite code gen performance by 20%. And...that's it??!

All done!

There's still lots of stuff that I'd like to do to handle large composition ops (which are still too slow) but that'll be another month or two of work. The stuff that EXA appears geared for - window dragging and scrolling, font rendering - are now where I'd like them.

Code's going to testers now.

[dliloch]

this is fantastic.. how does one become a "tester" ?? I would like to try it ...

[hojnikb]

Yeah, i would like to test awell

[Hexxeh]

+1, especially if there's some EGL goodness!

[hojnikb]

hmmm what about color issues with 24/32bit, is that fixed or is it still present ?
(looking at the wiki, haven't tried myself)

[teh_orph]

I'm afraid there is not an ounce of EGL in this code. There are some key things I'm planning on doing for the next version, which I'd imagine would be good to go in a number of months. I figured that if I just kept adding to the code, I'd never get anything out!

Now that I have full control over the graphics library I can choose to CPU+DMA some things and GPU some other things. The commands sent by applications need to have a low latency and if I'd done all the work with the GPU then it'd probably be slower than the stock X.

When I write this code (which is what I'm doing next) EGL interop should be much easier.

hmmm what about color issues with 24/32bit, is that fixed or is it still present ?
(looking at the wiki, haven't tried myself)

Which issue in particular? Just bust in the config.txt settings that enable 32-bit and you're good to go! As long as your binary blob is recent-ish.

[ghans]

Just a little question : Do you know anything about the engineering
resource the foundation has put on X acceleration ? Perhaps it would be better if you
worked together ?


ghans

[factoid]

I emailed them regarding my project, since I wondered if it was worth continuing my approach, didn't discuss Simon's stuff, but I haven't heard back either way. Hopefully we can all benefit from each other's work in the end, though I'm still playing catch up.

[masterluke]

Any word on how the testing is going? Would LOVE to see this in action.

Thanks for all your hard work

[cave]

UPDATE

http://www.raspberrypi.org/archives/2221

We've (with Broadcom's help) open sourced the ARM userland. More at http://www.raspberrypi.org/archives/2221 - hurrah!

It’s not going to have an immediate impact on X acceleration, though as I say does make it possible to provide the necessary Wayland EGL support for hardware compositing. There’s still the problem of optimising client-side rendering of each window. Simon Hall has done some interesting work on XOrg that we’re working with him to package up.

[cave]

Hi

I have found this:


VideoCore IV Programmers Manual

https://github.com/hermanhermitage/vide ... ers-Manual

Disclaimer:
This is a independent documentation project based on a combination of static analysis and trial and error on
real hardware. This work is 100% independent from and not sanctioned by or connected with Broadcom or its agents.
No Broadcom documents or materials were used beyond those publically available.
This work was undertaken and the information provided for non commercial use on the expectation that hobbyists of
all ages will find the details useful for understanding and working with their Raspberry Pi hardware.
The hope is that Broadcom will be flattered by the interest in the device and understand the benefits of opening up
understanding to a larger audience of potential customers and developers.
Broadcom should be commended with making their SoC available for a project as exciting as the Raspberry Pi.
No copyrighted materials are contained in this repository.

[teh_orph]

Although this does not help me with the Xorg driver project, it should make it pretty easy for me to write an EGL thingy for Hexxeh (but I don't think it would have been too tricky in the first place...famous last words!)

[Hexxeh]

Although this does not help me with the Xorg driver project, it should make it pretty easy for me to write an EGL thingy for Hexxeh (but I don't think it would have been too tricky in the first place...famous last words!)

"pretty easy"

I'm liking the sound of this. I can smell the Chromium OS images cooking already..!

[teh_orph]

So just to clarify, do you want existing EGL code that expects to render into an X window "to just work"?
Not a full-screen EGL application that runs sans-X (like Android)?

[Hexxeh]

So just to clarify, do you want existing EGL code that expects to render into an X window "to just work"?
Not a full-screen EGL application that runs sans-X (like Android)?

Yeah, you can test by passing --use_gl=egl to Chromium if I remember rightly.

[teh_orph]

Like Chromium that works in Raspbian?
I have noticed that Chromium (and Iceweasel) are dog slow on Rpi. Netsurf is super fast on my machine! (I don't overclock)