On Fri, Mar 25, 2011 at 6:25 AM, Ben Skeggs <skeggsb at gmail.com> wrote: > On 25/03/2011, at 10:55, Jerome Glisse <j.glisse at gmail.com> wrote: > >> On Thu, Mar 24, 2011 at 8:17 PM, Linus Torvalds >> <torvalds at linux-foundation.org> wrote: >>> On Thu, Mar 24, 2011 at 5:07 PM, Dave Airlie <airlied at gmail.com> wrote: >>>> >>>> Like seriously you really think VFS locking rework wasn't under >>>> development or discussion when you merged it? I'm sure Al would have >>>> something to say about it considering the number of times he cursed in >>>> irc about that code after you merged it. >>> >>> Umm. That code was basically over a year old by the time it was merged. >>> >>> How old was the code we're talking about now? Seriously? >>> >>> And your argument that this case is something you'd have pushed even >>> outside the merge window - I think that sounds like more of the same >>> problem. You say it fixes a problem - but does it fix a REGRESSION? >>> >>> Do you see the difference? Every single commit I get "fixes a >>> problem". But our rules for these things are much stricter than that. >>> >>>> This isn't even close to the level of the usual type of fuckups you >>>> get in a merge window, it just happens you were cc'ed on the >>>> discusson, otherwise I'm betting you'd never even notice. I'm betting >>>> something much worse landed in this merge window that you should be >>>> giving a fuck about, but this isn't the droid you are lookin for. >>> >>> Maybe not. But why is it always the DRM tree that has these issues? >>> Why is it that the DRM tree is the one that gets relatively _huge_ >>> patches after -rc1 is out? >>> >>> I really REALLY wish that you graphics people would at some point >>> admit that you guys have a problem. I am hoping that the intel side is >>> being worked on. >>> >>> Instead, I see what seems to be you being in a hurry, and arguments >>> why uncooked code should be merged even outside the merge window. >>> >>> Do you see what I'm aiming at here? >>> >>> If this was a one-time event, we wouldn't be having this discussion. >>> But the DRM tree is one of the BIGGEST issues after the merge window >>> has closed. And it's EVERY SINGLE RELEASE. >>> >>> Why? Some introspection please. You don't even have to answer me. I >>> ask you to answer that to yourself. >>> >>> ? ? ? ? ? ? ? ?Linus >> >> Below are my feeling and likely don't reflect any others people feeling. >> >> DRM have been trying to play catchup for years, GPU are likely the >> most complex piece of hardware you can find in a computer (from memory >> management, to complex modesetting with all kind of tweaks to the >> utterly crazy 3d engine and everythings that comes with it) Unlike >> others piece of hardware, when it comes to fully use a GPU >> acceleration, there is no common denominator that we would be able to >> put in the kernel (like a tcp stack or filesystem). I am sure very few >> people would like to see a full GL stack into the kernel. >> >> This results in various non common API that each driver expose to the >> userspace and it's all half cooked, because we have a tendency to >> release early (which is not necessarily wrong in my eyes). If i were >> to do it cleanly for one device i wouldn't freeze the API before i got >> a full fast stack (ie fast GL driver, video decompression, dual GPU, >> efficient power management) this is exactly what nouveau is doing, >> they are in the experimental for good reasons, they have the freedom >> to fix their API and they keep improving it each time their userspace >> progress. > Oh, I wish this were actually the case. ?The last time we attempted such a > thing we were blasted by Linus. ?It does make me wonder at why we're even > bothering being in staging. > > This is where the binary drivers have a huge advantage, they package all the > pieces of their driver together and can modify things as necessary. > > Part of me does think such an approach with the open source graphics drivers > would be better. ?The current model doesn't really fit too well in my > opinion. ?Though, admittedly, there's different problems to going other ways. > > Ben.
Well i think being able to evolve the API would help a lot, it should still be possible to keep supporting old API over a year or so. But my feeling is some of the current API for some of the device, needs heavy lifting if we ever want to improve things. Cheers, Jerome
