Freedreno Is Providing Good Adreno A4xx Graphics Acceleration

[robclark]

Ah OK, in about:config:


layers.offmainthreadcomposition enable
layout.frame_rate 1000
MOZ_USE_OMTC=1 firefox


Now got 100+ fps on 10+sharks

hmm, it does seem like it is capped, or maybe bottleneck in the js/browser stuff somehow.. it at least doesn't react to window size quite as much as I would expect. I was enabling layers.offmainthreadcomposition and using MOZ_USE_OMTC=1 in both cases. I'd missed the layout.frame_rate (and also layers.offmainthreadcomposition.frame-rate), which were both defaulting to -1 (disabled?.. setting both to 1000 doesn't seem to change things on my laptop..)

[syrjala]

hmm, it does seem like it is capped, or maybe bottleneck in the js/browser stuff somehow.. it at least doesn't react to window size quite as much as I would expect. I was enabling layers.offmainthreadcomposition and using MOZ_USE_OMTC=1 in both cases. I'd missed the layout.frame_rate (and also layers.offmainthreadcomposition.frame-rate), which were both defaulting to -1 (disabled?.. setting both to 1000 doesn't seem to change things on my laptop..)

layers.acceleration.force-enabled seems to be the key, at least with the version of firefox I have. With the -1 frame_rate option it seems to cap at 60fps with layers acceleration forced, and that drops to 40-45 without layers acceleration.

[kruger]

How does it compare to Qualcomm's blobs? Would these drivers work with Android (replace the blob on my CyanogenMod with freedreno)?

[droidhacker]

See the thing is,

Most phones are built for the kernel version they're shipped with, along with the proprietary drivers. The stock Android is then tweaked around that. So when you boot up to a stock linux kernel on most phones the most you can get to is a bash shell through ssh and that's only if the wifi and/or usb hardware is supported.. A bunch of hardware doesn't have OSS drivers already included in the stock kernel.

That's exactly why it's no nice to see drivers like this come in and start supporting those devices.

Wow! You have NO IDEA what you're talking about. Please do not try to "teach" anybody about this any more.

[duby229]

Wow! You have NO IDEA what you're talking about. Please do not try to "teach" anybody about this any more.

I've put gentoo linux on at least a dozen phones. I know what I've experienced. The fact is that on every single one of them the only kernel that works is the kernel that the phone shipped with and only with the stock android. Even if you pull the factory kernel out along with all the factory drivers and firmwares, usually it still will only work on the factory android.

Vanilla kernel sources -DON'T- have OSS drivers for a lot of common hardware in android phones. It's a fact.

Personally I welcome OSS driver development. This is a good thing whether you like it or not.

[mcirsta]

he's right

Wow! You have NO IDEA what you're talking about. Please do not try to "teach" anybody about this any more.

The man's actually quite correct and this is the way things currently are. Manufacturers seldom care about mainlining their drivers for their SOCs and usually all you get is kernel 3.4 + custom drivers strictly for that version of the kernel.
I would love to run a mainline kernel on my LG Optimus phone, just as I do on my x86 desktop but I doubt it will happen anytime soon.

[robclark]

How does it compare to Qualcomm's blobs?

well, blob on android is approaching 60fps.. but otoh it doesn't actually render correctly:

http://youtu.be/Gy6ZH79x4TU

Probably you can't really infer much from that... android has a more efficient path to screen than gnome-shell. And I'm starting to suspect that something is capping things ~45fps for firefox on linux.

Would these drivers work with Android (replace the blob on my CyanogenMod with freedreno)?

There would be some hacking required.

Mesa has a drm/kms based gralloc/etc for android support. No idea if it that would need some updates to work with current versions of android. But that is (at the moment) really only useful for devices like ifc6540/ifc6410 where your display is over hdmi. I think soon we should have initial DSI support in the upstream driver, at which point for phones/tablets it becomes a matter of backporting the upstream kernel to your device (or getting an upstream kernel to run on your device) and writing a corresponding DSI panel driver for whatever screen you have on your device.

The other option, it might be possible to make a hacked up gralloc/hwcomp based on qcom's android kernel drivers (fbdev/kgsl), but modify it to talk to mesa instead of blob driver..

It would be nice to see, but I think requires someone with more interest in android than me ;-)

[Drago]

Probably you can't really infer much from that... android has a more efficient path to screen than gnome-shell.

Hi Rob, can you elaborate a little more on that subject. When things start running on Wayland, how it will compare then?

[robclark]

Hi Rob, can you elaborate a little more on that subject. When things start running on Wayland, how it will compare then?

Wayland should allow for similar efficiencies (ie. using hw overlays or composition engines to bypass gpu)..

How quickly the window mgrs which have their roots in x11/desktop start taking advantage of those features will be a good question. It could possibly take a while for some of the DE wayland compositors to catch up with weston, in that regard. I expect some of that would get easier when you don't have to care about being a traditional window manager for x11 and being a wayland compositor from the same codebase. The sooner they can start dropping x11 cruft the better.

[Drago]

Wayland should allow for similar efficiencies (ie. using hw overlays or composition engines to bypass gpu)..

How quickly the window mgrs which have their roots in x11/desktop start taking advantage of those features will be a good question. It could possibly take a while for some of the DE wayland compositors to catch up with weston, in that regard. I expect some of that would get easier when you don't have to care about being a traditional window manager for x11 and being a wayland compositor from the same codebase. The sooner they can start dropping x11 cruft the better.

Thanks! I believe the first DE compositor for mass use, to be Mutter. I guess we will have it in less than a year in Fedora 23. Exciting times indeed.