Prev: [patch 006/164] oprofile: remove double ring buffering
Next: serial: fix rs485 for atmel_serial on avr32
From: Dave Airlie on 2 Jul 2010 06:30
>
> Yes, this a mess indeed.
>
> But i fear that this a mess that cannot be fixed, in its entirety, in a single shot.
>
> Qualcomm making this code available already clearly shows the will and determination of
> some people inside qualcomm to do The Right Thing.
>
> This is Qualcomms first big step on the graphics side, where IP is always amongst the
> heaviest. I am certain that Qualcomm wants to go further, but since Qualcomm most
> likely licenses some parts of their graphics, Qualcomm can only open up those bits that
> they truly own, and then use mainly market/sales-volume driven pressure to get the
> original IP owner to play along.

They own quite a lot of the IP in the 3D core, having bought it from
AMD, you can see the CP packets and PM4 stuff just like in radeon.

>
> You should also take into account who Jordan is. He is one of the guys who worked the
> Geode before AMD decided to drop that, which is when he got hired by Qualcomm. He worked on
> both the graphics drivers and on (then still) LinuxBIOS. I know that redhat has no
> intention of going near coreboot, but in my world one cannot become more free, hardware
> wise, than supporting coreboot. This gives me very good hopes that this is a serious
> attempt by qualcomm to go somewhere, and that this is not some lame attempt to grab
> marketing attention.

I know who Jordan is well from AMD, and I've stated this isn't a
Qualcomm only thing, but companies need to understand that putting
stuff into the kernel is part of a bargain, where you get the benefits
of all the work everyone has done on the kernel and they get the
benefits of being able to do stuff with the code you provide, only
giving us a half arsed interface to the hw and hiding all the good
stuff in userspace isn't accepting this bargain. You can say what you
like about liceneses and legalese but Linus picked the GPL for this
sort of everyone gives what they get.

> Now that you slammed the door on these guys (and on others in the process), what do you
> think the response would be? Where will this get us to in the end?

They'll keep shipping closed stuff, just like they are now. Are you
going to reverse engineer the userspace drivers, so people who care
about open and free software platforms can use these drivers? (or have
you already signed NDAs saying you can't). Why should we maintain a
bunch of kernel code, when they are hiding away all the really useful
stuff that people could improve.

>> b) verifying the sanity of the userspace API.
>> 1. Security: GPUs can do a lot of damage if left at home alone, since
>> mostly you are submitting command streams unverified into the GPU and
>> won't tell us what they mean, there is little way we can work out if
>> the GPU is going to over-write my passwd file to get 5 fps more in
>> quake. Now newer GPUs have at least started having MMUs, but again
>> we've no idea if that is the only way they work without docs or a lot
>> of trust.
>
> This makes me wonder: Why do you even care?
>
> If redhat was working with qualcomm, you would not have taken this stance here at all.

I would, some points
(a) Red Hat is the company I work for.
(b) Red Hat doesn't really care about this stuff at all.
(c) I'm the kernel maintainer for far longer that I worked for Red
Hat, I also work a lot with Intel at Red Hat and I've told them the
same thing, and VIA and now I'm stating it so I don't have to restate
individually to every company again.

> If so, why couldn't you have stated "please guys, have fun with what you are doing, but
> i will not be responsible for it" in a different way.

You don't understand what being a kernel maintainer is do you? at all?

> Now, it is interesting how you now are demanding documentation. When did recent and
> relevant hw documentation happen for ATI? This pretty much died together when the
> ATI<->SuSE relationship died, as the cooperation of SuSE and AMD is how documentation
> was forced out of ATI in the first place, and ATI more and more found ways to get rid
> of this responsibility, or overhead as bridgman would most likely name it.

Wierd I'm still seeing new docs being produced and old docs being
updated, not as fast as I'd like but I understand how many people
there is working on it and I'd rather we also got fixes for all the
current stuff done as well.


> If you are backing this reasoning for ATI, what is wrong with this code being the
> documentation for Qualcomm?

The code doesn't exist, there is no userspace code to be the
documents, if you read what I said, documents would be a good start in
lieu of code, but code is perfectly fine.

> Heh, in some of these cases, not having looked at this code in detail yet, such code
> predates kms, and drm might not have provided what was needed. Not wanting to
> completely diminish the responsibility of qualcomm (or the other companies who are
> working or are forced to work like this), you might want to think about providing
> stable and fitting infrastructure, not just stating that something is how _you_ are
> doing it and declaring that the law.
>
> Next to that, the IP heavy part that cannot be released (yet?) might be some blob that
> is used on both linux, windows, ximbian, etc. The concept of talking to some os
> independent blob through some painful and ever-shifting layer is not that alien even to
> you, with your staunch defending of ATIs AtomBIOS over more direct modesetting.
>
> Also, from where i sit, you complaining about people reinventing the wheel does bring
> me some bitter amusement.
>
> As a conclusion: With you having sent this mail, guess what the guys at qualcomm, and
> most likely imagination technologies and ARM as well (i think we can already discount
> nvidia -- they are far too adept at producing solid closed source drivers -- to
> desktop users satisfaction too), will do next?

Imagintaion technologies seriously? they've never ever taken one step
towards opening anything, I don't think this statement is suddenly
going to jumpstart them.

>
> We already squandered the free software desktop (on x86), and part of the
> responsibility for that is with the graphics hw support (and the radeon versus radeonhd
> story shows nicely how to go about squandering such things). What i see here is that
> you clearly want to go down a similar street with the now blossoming ARM market.
>

Maybe you should disclose what NDAs you currently are under and who
pays your bills, since you accuse me of Red Hat mind-control.

I'm not sure how the ARM market would benefit from having no userspace
3D drivers just like the x86 market, if you actually were normal you'd
realise the ARM people are trying to screw the market just like the
desktop people, to save themselves some money, but maybe working on
closed drivers has twisted you.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dave Airlie on 2 Jul 2010 07:30
On Fri, Jul 2, 2010 at 9:12 PM, Luc Verhaegen <libv(a)skynet.be> wrote:
> On Fri, Jul 02, 2010 at 06:15:35AM -0400, Christoph Hellwig wrote:
>> Luc, can you please take your corporate bullshit out of this? �I can
>> assume you know Dave personally and should be clearly aware that he's
>> everything but a corporate drone.
>
> Yes, with mails like this he clearly shows that he isn't a corporate drone.
>

Luc, this isn't phoronix forums, the adults are talking here, run along now.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dave Airlie on 2 Jul 2010 08:00
> Sure, but you still slammed, and this affected in first order mostly Qualcomm, instead
> of stating that you simply do not want to be involved.

I have no choice but to be involved, again you seem to misunderstand
what my position is.

>
>> They'll keep shipping closed stuff, just like they are now. Are you
>> going to reverse engineer the userspace drivers, so people who care
>> about open and free software platforms can use these drivers? (or have
>> you already signed NDAs saying you can't). Why should we maintain a
>> bunch of kernel code, when they are hiding away all the really useful
>> stuff that people could improve.
>
> Maintaining this exact code is not _your_ job, and you should've stated just that.

Maintaining kernel graphics drivers is my responsibility, a lot of
days i wish it wasn't, and I'm sure some day it won't be, but until
then I have to provide guidance on how things should work. Again you
should look at what being a kernel maintainer is.

>
> You will need to restate this every time anyway, unless you somehow manage to get your
> rather daunting and loud statement to be the first thing such corporations management
> people at linux.com, which is what people type in their browser first.

I'm sure I will, but now I can just point people at this rather public
statement as opposed to private emails.
>
> Heh, i could make a really nasty statement here, but i wont.

Please do, since you've proved you are clueless about this position entails.

> Hrm, i only see _very_ old docs getting updated, and none produced.
>
> I still have docs which are pretty ready to be shipped (from 2007), under uncertain
> legal status (the ati game was fun!), which were never made public. I am sure that
> bridgman, gave you these docs too, but under even more shady circumstances.

Shady circumstances? you might want to ask your lawyer before making
statements like that on a public mailing list.

>> The code doesn't exist, there is no userspace code to be the
>> documents, if you read what I said, documents would be a good start in
>> lieu of code, but code is perfectly fine.
>
>> Imagintaion technologies seriously? they've never ever taken one step
>> towards opening anything, I don't think this statement is suddenly
>> going to jumpstart them.
>
>> Maybe you should disclose what NDAs you currently are under and who
>> pays your bills, since you accuse me of Red Hat mind-control.
>
> Oh, i now work for basysKom, a contractor for, amongst others, nokia, which i'm sure
> you knew.

So you honestly think if I allow Nokia and/or Intel to push a poulsbo
driver into the kernel the magic fairies will come along and open the
userspace because they've seen the light?

What incentive does letting someone like Qualcomm etc put all their
kernel code upstream, and ignoring the userspace components do you
think it provides to open the userspace component, for once I'm
interested in your opinion since you seem to have the ARM players all
worked out. Previous experience with most companies has shown they'll
do as little as possible to ensure they can ship as many things as
possible, and this is fine, they need real incentives to follow the
open source rules.

>
>> I'm not sure how the ARM market would benefit from having no userspace
>> 3D drivers just like the x86 market, if you actually were normal you'd
>> realise the ARM people are trying to screw the market just like the
>> desktop people, to save themselves some money, but maybe working on
>> closed drivers has twisted you.
>
> Ah, so you did know.
>
> As a free software graphics driver developer there is little option left but to go
> straight to the ARM world, at least things have potential to move there still.

What potential? there are maybe 6 players on the ARM graphics scene

Imagination Technologies SGX, used in TI and poulsbo/mrst(x86) - no
hope of opening userspace
ARM Mali - not sure what is going on there, I;m going to go with no
hope but would be nice to be proved wrong
Qualcomm SnapDragon - imageon by another name, from what I can and
from talking to Jordan on irc, they don't seem to have much incentive
to bother working on an open userspace
Marvell - maybe OLPC can make them open a userspace for millions of
sales, it doesn't seem to have worked with VIA for 10s of thousands of
persumable sales
Samsung - also holding out hope for something maybe, they seemed to
have some interest once, but not sure what happening now.
Nvidia - well we know their position will never change.

So we should have six completely separate stacks shipping in the
kernel not using drm or kms, but all standalone, all with closed
userspace drivers, with no maintainer, thanks that is not a future I'm
interested in, and generally from experience in Linux it isn't
something we've had much luck with before, wireless, networking, sw
raid, etc all have this sort of vendor demands and it took independent
maintainer pushback to achieve some cooperation and get what we have
today.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: C. Bergström on 2 Jul 2010 08:10
Dave Airlie wrote:
> What potential? there are maybe 6 players on the ARM graphics scene
>
> ...
> Nvidia - well we know their position will never change.
>
Never say never. I have every reason to believe that Nvidia would
respond to market demand.

*fingers crossed*

../C

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Tim HRM on 15 Jul 2010 20:50
On Wed, Jul 14, 2010 at 9:24 AM, Pavel Machek <pavel(a)ucw.cz> wrote:
> Hi!
>
>> >There is no point supporting companies that give you a little bit of
>> >information in exchange they want the support that being in a mainline
>> >kernel gives. Its an unfair exchange of knowledge and time, and if they
>> >claim they have to make a profit then its even more unfair.
>>
>> also, they seem to do it quite wrong way. i.e. much simpler would be
>> to just implement regular, open driver , and implement additional
>> crypto
>> mechanism in chipset itself, allowing to use simple userspace program
>> sending certified keys allowing GPU to operate.
>
> What is going on there? Does msm actually use crypto to prevent you
> from use hardware you bought?
>
> Are the keys device-specific? What prevents me from
> reverse-engineering their binary and publishing them?
> � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>

Hi Pavel. No I think that was meant to be theoretical/hypothetical.
There's no crypto or device key as such, this hardware is much like
any other that requires firmware to function.

I think the issue is broader than that. The question seems to be
whether an open API/ABI can be specified between an open kernel driver
and a closed userspace driver that is required to perform a subset of
the total functionality, in this case, certain GL and 3D primitives.
The other functions, 2d, the ability to bind a texture to a simple
poly, etc. can be potentially accomplished with an open source driver
and development of a radeonhd or avivo based driver in parallel. But
that would require developers to agree on an API that can be stablised
and standardized between Android Xorg 2d driver and any potential 3d
driver, where the developers of closed source components must ensure
they remain compatible with whatever direction the open driver takes.

--
Timothy Meade
tmzt #htc-linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2
Prev: [patch 006/164] oprofile: remove double ring buffering
Next: serial: fix rs485 for atmel_serial on avr32