On Mon, Dec 20, 2010 at 12:41 PM, Matt Sealey <m...@genesi-usa.com> wrote: > On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse <j.gli...@gmail.com> wrote: >> On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey <m...@genesi-usa.com> wrote: >>> On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann <a...@arndb.de> wrote: >>>> On Monday 13 December 2010, Jammy Zhou wrote: >>>>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij >>>>> <linus.wall...@linaro.org>wrote: >>>>> >>>>> > On 11 December 2010 22:41, Arnd Bergmann <a...@arndb.de> wrote: >>>>> > >>>>> > * amd-gpu -- a single but huge driver for the GPU. As is normally the >>>>> >> case with GPU drivers, we can expect long discussions >>>>> >> before it will get considered for mainline >>>>> >> 4 patches >>>>> >> 98 files changed, 278321 insertions(+), 0 deletions(-) >>>>> >> >>>>> > >>>>> > Just out of curiosity, following the discussion between Dave Airlie >>>>> > and Codeaurora this summer re GPU driver shims. >>>>> > >>>>> > Is the AMD GPU exposing all functionality in its kernel driver or >>>>> > is there some userspace blob somewhere with lots of e.g. GL >>>>> > goodies? >>>>> > >>>>> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now >>>>> belongs to Qualcom) is exposed. But we need accompanied userspace library >>>>> to >>>>> call these functionality (buffer management, command submission, ...). >>>> >>>> Who owns these components? If it's closed source, the only options we >>>> have are lobbying for complete release of the specs for a reimplementation >>>> or reverse-engineering the drivers, which may at least get easier with >>>> a user space driver than it would be with a kernel driver. >>>> >>>> Until there is a solution with an open source user space part, I would >>>> suggest that the driver better be dropped from the Freescale BSP and >>>> we should at least not waste time reviewing it. >>> >>> The concerns about host memory access via the GPU driver are valid but >>> unnecessary. The GPU MMU directly intervenes on memory access and can >>> only modify memory space allocated to the GPU resource - getting data >>> into this memory requires some extreme manual intervention if not done >>> by the kernel driver itself; this memory area is set internally by the >>> platform device resource.. As such (on the i.MX515 at least) the top >>> 64MB of memory reserved for the GPU is the only memory you need to >>> worry about, and any "corruption" will be limited to invalid API usage >>> which is also checked with assertions and other protection mechanisms. >>> Any other "unsecured" memory location such as system RAM cannot be >>> affected as the GPU MMU will not write or read any other memory than >>> the defined resource. It is not an outside possibility that you may >>> abuse the GPU to corrupt graphics RAM... but you can do that with any >>> GPU even with security checks. >> >> Security check of radeon GPU are advance enough to even catch and >> forbid overwriting other process video memory (this is more or less >> true depending on the generation you are looking at). >> >>> Ownership of the code is dependent on who licensed it. I do not think >>> Linaro need be so concerned over opensourcing or reimplementing >>> drivers. The fact that the kernel driver is open source as it is, and >>> this is by far the most important part. The userspace library is >>> closed because it is proprietary; and I think it is well outside >>> Linaro's remit to lobby for opensourcing of proprietary code simply to >>> meet an esoteric and needless demand for source code access (as it >>> stands, you can get source code access by signing the usual plethora >>> of NDAs with the appropriate vendor, as Genesi has done). It is my >>> understanding that Freescale/AMD and Qualcomm maintain seperate forks >>> of the driver and do not cooperate on development, and in any case, >>> Linaro does not include Qualcomm anyway, therefore it is also to my >>> understanding that this discussion is also beyond Linaro's remit. >>> >>> Can't we all just be happy that we actually have 3D drivers? >> >> So here you are advocating that we should accept any open source code >> inside the kernel just because it's open source and we love open >> source ? This is not how i understand the linux kernel project, we >> should not accept any open source driver that just add new api that we >> can't audit, test or understand. From my point of view any driver & >> new API should be introduced to support open source userspace. If GPU >> manufacturer don't want to open source their stack that's their issue >> but they should live with the pain of not having upstream kernel >> either. I believe, here i am just reformulating Dave point. > > The code may need improvement but that's no reason to run around > saying everything needs to be open sourced, and that the solution is > in fact to reverse engineer the thing rather than accept it as the > current solution. Given how long nouveau and later Radeon card support > has taken in real life, even with full documentation from AMD, I > seriously doubt Linaro are going to be the ones to somehow make the > world change for OpenSource embedded GPU graphics. Linaro doesn't > exist just to spend all their time undermining the status quo for the > sake of it. > > I also do not think that it is at all kernel policy to disallow kernel > drivers which do not have opensource userspace components. In fact, > Linus Torvalds begs to differ on this matter. The fact of the matter > is that the driver lives now, Qualcomm have it in their upstream, > Freescale have it in their upstream, Linaro are going to fetch from > that. It doesn't need to go all the way to stable, because people can > compile their own kernels if they want (and Linaro is there provide > the source to do that with the best interoperability with the silicon > vendors' chips as possible).
I was just expressing my opinion on upstream, if i see this driver showing up on lkml i will reply with a nak and explain why (pretty much same argument as here). I don't have any authority on linux kernel but as far as i understand it, it's about reviewing what's gets in, so i hope my review opinion would matter (what ever the out come is). > Well, good luck reverse engineering the GPU in the next 5 years, > because I suspect that is how long it is going to take. It's not that hard, it's time consuming and painfull. The time needed depends on how much people are working on it and how much time those people have to work on it. > I would love to see someone actually, physically prove that using the > libraries provided by vendors (Freescale's BSP, or from Genesi or so) > and the kernel driver committed, that you CAN actually cause rampant, > unsecured graphical corruption, before a discussion goes around to > those vendors about spending the next 6 months mired in legal work > trying to find all the potential IP sources and seek approval to > publish that code as opensource or perform rewrites. So far I don't > see that, just a "I'm fairly sure" from a trusted person. This is not > peer review, it's pure opinion. Go see how well you can break it, > submit a bug report, the vendors might fix it in the closed source > libraries or publish a kernel driver update to suit your needs. > The point here is that we can't prove it or be confidant that it's very unlikely or even impossible without the specifications, so before we can have any certainty about this we would either need the specification or reverse engineer it. Note that i haven't even bothered looking at that driver, i only looked at other qualcom gpu and voiced my concern on them (i was given reasonable technical answer on those concern by the way). For me, no kernel open source driver should be accepted upstream without open source userspace. So if a company want to push upstream an open source kernel driver they have to consider either waiting 5 years for reverse engineering (taking your estimation and assuming some one reverse engineer). Or actually try to look at those IP and see what they can do. Some GPU company (AMD, Intel) have proven that you can actually review IP and do open source driver, they likely won't disclose how much it cost them but it seems they think it's worth it. I hope others GPU company will starts thinking about that. Cheers, Jerome Glisse Cheers, Jerome Glisse _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
