Freedreno Graphics Driver Reaches Version 1.0

[phoronix]

Phoronix: Freedreno Graphics Driver Reaches Version 1.0

The xf86-video-freedreno X.Org driver for providing support for Qualcomm's Adreno/Snapdragon graphics hardware has reached version 1.0 in its first stable release...

http://www.phoronix.com/vr.php?view=MTUxNjg

[89c51]

The question is how it compares to the closed driver in performance and most importantly in features that save battery.

[amehaye]

A Freedreno-supported hardware is the best way right now to ensure getting future versions of Android through CyanogenMod or Omni. Also, Linux/Wayland.

Even OMAP-based phones are getting the finger right now. Think about that the next time you buy a phone...

[robclark]

small note.. the XA support isn't merged yet. Early on I had some slight corruption/mis-rendering issues with it so it stayed on a branch. But I think I've figured out the gallium issue (seems there is a workaround needed for hw bug in a320), so I should revisit XA when I have time.

As far as performance, for desktop stuff it should be as good or better than blob driver. (Well, that is a slightly artificial statement, because blob driver doesn't support gl and blob driver doesn't support linux, so essentially freedreno is infinite times faster.) I implement some scissor related optimizations that the blob driver does not, which really help for gnome-shell/compiz type workloads. For things like xbmc which are not vertex heavy, and simple shaders, it should be comparable (although, without non android drivers there is really no way to compare). For stuff with high vertex loads and complex shaders, the blob driver is almost certainly better at this stage (if it existed for linux)... for this I need two things: (a) compiler optimizing pass(es) and (b) hw binning support. I have an experimental branch with the former, which gives >10% boost in fps in xonotic, and gives me what I need to generate vertex shaders for hw binning pass (which is the next step). I can't quite say what the fps boost for hw binning support will be, but from some rough expirements I'm guestimating >20% at 1024x768 and more at higher resolutions.

That all said, the focus so far has not been performance. It has been getting something that works at all. (See again comment about no linux blob driver.) Certainly there are known optimizations that will come with time, but you have to walk before you can run. But the nice thing is we don't have those pesky reclocking issues, so it shouldn't be >10x differences from blob driver.

[robclark]

small note.. the XA support isn't merged yet. Early on I had some slight corruption/mis-rendering issues with it so it stayed on a branch. But I think I've figured out the gallium issue (seems there is a workaround needed for hw bug in a320), so I should revisit XA when I have time.

As far as performance, for desktop stuff it should be as good or better than blob driver. (Well, that is a slightly artificial statement, because blob driver doesn't support gl and blob driver doesn't support linux, so essentially freedreno is infinite times faster.) I implement some scissor related optimizations that the blob driver does not, which really help for gnome-shell/compiz type workloads. For things like xbmc which are not vertex heavy, and simple shaders, it should be comparable (although, without non android drivers there is really no way to compare). For stuff with high vertex loads and complex shaders, the blob driver is almost certainly better at this stage (if it existed for linux)... for this I need two things: (a) compiler optimizing pass(es) and (b) hw binning support. I have an experimental branch with the former, which gives >10% boost in fps in xonotic, and gives me what I need to generate vertex shaders for hw binning pass (which is the next step). I can't quite say what the fps boost for hw binning support will be, but from some rough expirements I'm guestimating >20% at 1024x768 and more at higher resolutions.

That all said, the focus so far has not been performance. It has been getting something that works at all. (See again comment about no linux blob driver.) Certainly there are known optimizations that will come with time, but you have to walk before you can run. But the nice thing is we don't have those pesky reclocking issues, so it shouldn't be >10x differences from blob driver.

oh, and in case you haven't seen it, there is some status about performance and what is known to work/not-work at:
https://github.com/freedreno/freedreno/wiki#status

(needs some update.. I plan to spend a bit of time on wiki updates in near future, but I've been busy getting a new board working)

[bemerk]

A Freedreno-supported hardware is the best way right now to ensure getting future versions of Android through CyanogenMod or Omni. Also, Linux/Wayland.

Even OMAP-based phones are getting the finger right now. Think about that the next time you buy a phone...

As far as i see, all that was mentioned is linux support, the driver developer never lost a word about linux , so why are you having such high hopes?

[bemerk]

A Freedreno-supported hardware is the best way right now to ensure getting future versions of Android through CyanogenMod or Omni. Also, Linux/Wayland.

Even OMAP-based phones are getting the finger right now. Think about that the next time you buy a phone...

Where did they mention Android support? I only read so far about running linux on those devices.

[robclark]

As far as i see, all that was mentioned is linux support, the driver developer never lost a word about linux , so why are you having such high hopes?

Just fwiw, while my personal interest is "traditional" linux (xorg, wayland), there is nothing about the libdrm or gallium parts of freedreno that are window system specific. If someone wants to figure out how to build and use freedreno on android (or webos or mir or whatever), that should be completely possible. Obviously you won't need xf86-video-freedreno on android or others which directly use GL(ES) for compositor. And it is possible that different environements trigger some bug that I haven't seen yet (although at least according to piglit freedreno is getting much more solid). I'll certainly help try to help debug and fix issues in other environments as best I can (it helps for rendering bugs if you can get an apitrace or a test program the reproduces the issue on an environement that I have, ie. wayland/xorg).

Of course freedreno won't help with other aspects of getting new android running on old device (ie. porting newer kernel to older device, or somehow making other subsystems like camera work on older kernel). It would be nice if this was a less painful process, but I've yet to see a vendor android kernel that isn't a mess.

But graphics has traditionally been the biggest stumbling block, and at least now that is not so much of an issue.

[Awesomeness]

The question is how it compares to the closed driver in performance and most importantly in features that save battery.

No idea about battery but this independent comparison of a pre-1.0 version already declared it ?Good? while the blob is ?Horrible? regarding standards support.
https://de.dolphin-emu.org/blog/2013...meshame/?cr=de

[Awesomeness]

Where did they mention Android support? I only read so far about running linux on those devices.

A) Android is Linux and B) Mesa in general works with Android, although the port is AFAIK mainly maintained by Intel for Android on Intel's own hardware.