Shared publicly  - 
Nice, one more down! This leaves only Mali T6xx/T7xx and ImgTec SGX/G6xxx as the main GPUs without a free driver, while Adreno, Tegra5/Kepler, VideoCoreIV, Vivante and Mali 4xx are all on their way to proper open source GPU support.
I guess this tips the balance from "you must be crazy to show the source code for your GPU and risk getting sued" to "how do you expect to stay in business without a free driver".
Alexandre Courbot's profile photoRob Clark's profile photoDaniel Stone's profile photoRussell King's profile photo
I looked at the source code and can confirm that it does include a shader compiler.
But are these doing the same mistakes as ever - keeping the physical addresses in userspace?

I suspect they all are, because I hear nothing of any of these doing a DRM port - and DRM is the only graphics interfacing subsystem we have which doesn't involve the massive security hole of physical addresses in userspace.

This stuff might as well remain closed source if people aren't willing to fix that problem.
I think it doesn't matter how crappy their code is. Now that it's open, people can work on fixing it, which mean involve rewriting large chunks of it.
wait what? i thought the RPi propaganda machine released this last year? hmm it was just another wrapper.... is thiss more of the same?
+David Anders ignore the RPi crap in the article. The important news is that Broadcom now has a vendor supported open source user space side for their GPU drivers. Yes, it does include the interesting bits that the last time were just wrappers for code running on the GPU.
+Arnd Bergmann It's no good if people rewrite it using the same mistakes wrt physical addresses.

Everyone has been showing off etnaviv recently too.  Oh yes, it's being rewritten as open source, which is really great, but... even the new code is riddled with physical addresses all over the place.

So even if you use etnaviv to get rid of the closed source layer, you're still stuck with something which is a gigantic security hole, which will let you overwrite the kernel as any user which has GPU access.
What I find interesting if we'll see any evidence of patent fallout or other IP mess in the next few months. Was it really the secret sauce where all the speedups vs competition were implemented? Or was it all because of PATENT PENDING algorithms from other companies.
Most of it is fear of patent trolls, as far as I've understood. And we won't really see much of that from the outside, if it happens -- since by far most of those situations are handled outside of the courts by settlements, etc.
Full disclosure - the adreno driver is third party.  Qualcomm is still solidly in the evil pile.
it's because that is the only business model they know and understand... +Arnd Bergmann we'll see if it is as advertised... if it is legit i'll be the first to applaud, but broadcom + RPi haven't exactlty been honest in the past with their 'open source efforts'...
+Jordan Crouse the same is true for Mali 400 and Vivante, and for the most part Tegra. I think it's just a matter of time until AOSP or perhaps Cyanogenmod switches over to free GPU drivers.
Free drivers on mobile doesn't seem realistic yet. I don't think any of then do power management yet?
+Olof Johansson I think for the most part they just use the same kernel drivers as the proprietary user space blobs, so there is power management support, but there is no upstream kernel support (except for freedreno), which leads to the problem that +Russell King mentioned: the kernel/user ABI is just as screwed as it was before, and presumably the code quality of the user space is initially much lower than it is in the blob that was written by people with access to the documentation.
+Olof Johansson Power management (from what I've seen) is quite straight forward on PowerVR 535 / 545. Just On/Off/Auto clockgating and stick with the same core freq and wait for the engines to power up/down. I'm looking at the VideoCore IV source now and it got off/min/max/run/hibernate and abilities to adjust core freq on the fly. Probably pretty straight forward from what Nvidia is doing.
+Russell King well, etnaviv on existing vivante kernel driver won't solve any security issues, of course.  But before we had an open userspace, there was no point in writing a proper kernel driver.  Now we can fix this ;-)
+Daniel Stone Yes and no.

On CMA, I'm not using the generic helper because it forces the use of CMA for everything.  It's an everything CMA or nothing CMA solution, there's no middle ground.

On the use of dma-buf / prime, I've switched the driver over to it and dropped the phys addresses - I do agree with David that phys addresses exposed to userspace /can/ be a security issue.  In this case, I don't believe they were ever a security problem within the confines of the driver.

However, switching to dma-buf has allowed the driver to be merged.  That's great.  However, I think as a result of this, I'm the sole user of this driver - because anyone else who uses it is then faced with having to do some pretty major rewriting of all the community work which has gone before to support the GPU and video decoder.  It's almost not worth having the driver merged into mainline.

I'm talking there of the big projects like Geexbox and similar.

So, I think the merging of the driver has actually turned into a net-loss - I think my efforts would have been better spent trying to sort out the fbdev mess so that it actually worked properly with hotplug.

I don't see the situation concerning armada-drm changing much - the community who used to have a primary interest in this has now moved on to i.MX6 hardware, and I doubt there's going to be much looking back to the Dove-based hardware.

This is the biggest painful thing about mainline kernel stuff - it's virtually impossible to get full support in mainline before a product becomes EOL and has been superseded.
Add a comment...