So with all this ongoing Linus crap I'm going to be brave and ask for reasons why 0.0.16 kernel API can't become 1.0.0. Pros: All old userspace compatibility is gone. No more UMS cruft to support. Something can be shipped on distros at last, people get to use the driver. 3D drivers exist and use the interface, there is an investment in these already. Reasons against: (I'm making these up, feel free ack/nack/flesh out/add more etc). We haven't finished 3D drivers yet so the interface may still need changes? TTM sucks? Userspace command-submission for ever? I don't like versioning anything ever? So my current answers to my list of cons is: Adding new faster interfaces for 3D drivers shouldn't be a major problem, if its just a matter of making the current APIs saner. If you are going to write a UCS/non-TTM driver you are going to have to do major changes all over the stack, in theory a kernel CONFIG option to enable version 2 of the interface and drop version 1 would be an option at that time. Or even a boot option to select between which one you want. I would forsee a UCS/non-TTM driver needing to rewrite quite a lot of userspace, in fact probably all of it. I haven't seen anyone actually start or commit to working on such a beast, and I'd reckon its probably a 1-2 year job, GEM took over a year and it was arguably simpler. I'm not seeing the point of sitting in a holding pattern for that length of time just in case its better. The future is always going to be better. As for the I don't like versioning argument, well that really doesn't need addressing, you have to do version stuff to ship it, if the project as a whole decides they don't see a need to ever ship the code, then so be it. Dave.
On Thu, Mar 4, 2010 at 17:23, Dave Airlie <airlied at gmail.com> wrote:> So with all this ongoing Linus crap I'm going to be brave and ask for > reasons why > 0.0.16 kernel API can't become 1.0.0. > > Pros: > All old userspace compatibility is gone. > No more UMS cruft to support. > Something can be shipped on distros at last, people get to use the driver. > 3D drivers exist and use the interface, there is an investment in these already. > > Reasons against: (I'm making these up, feel free ack/nack/flesh > out/add more etc). > We haven't finished 3D drivers yet so the interface may still need changes? > TTM sucks? > Userspace command-submission for ever? > I don't like versioning anything ever? >Yeah, we definitely need more performance tuning on the 3D driver and video playback side. Otherwise we could end up shipping something that has no chance of sanely evolving into a fast enough driver. The issue is right now we are only barely scratching the surface of the performance issues.> So my current answers to my list of cons is: > > Adding new faster interfaces for 3D drivers shouldn't be a major problem, if its > just a matter of making the current APIs saner.You quickly handware this, but the problem is there is no way to be sure about it. If it was that simple we could have made a "stable" release many moons ago. Maybe the problem stems from some TTM bit, maybe it's a user space interface which is too heavy. There is no way to know right now.> > If you are going to write a UCS/non-TTM driver you are going to have to do > major changes all over the stack, in theory a kernel CONFIG option to enable > version 2 of the interface and drop version 1 would be an option at that time. > Or even a boot option to select between which one you want. I would > forsee a UCS/non-TTM driver needing to rewrite quite a lot of userspace, > in fact probably all of it. I haven't seen anyone actually start or > commit to working > on such a beast, and I'd reckon its probably a 1-2 year job, GEM took over a > year and it was arguably simpler. I'm not seeing the point of sitting > in a holding > pattern for that length of time just in case its better. The future is > always going > to be better. >Yes for a full GEM replacement that is probably true, but I think we should aim for something TTM based with decent performance. And we're really not remotely there yet. Having each driver carry the same suballocator? Come on... Stephane
On Fri, Mar 5, 2010 at 2:23 AM, Dave Airlie <airlied at gmail.com> wrote:> So with all this ongoing Linus crap I'm going to be brave and ask for > reasons why > 0.0.16 kernel API can't become 1.0.0. > > Pros: > All old userspace compatibility is gone. > No more UMS cruft to support. > Something can be shipped on distros at last, people get to use the driver. > 3D drivers exist and use the interface, there is an investment in these already. > > Reasons against: (I'm making these up, feel free ack/nack/flesh > out/add more etc). > We haven't finished 3D drivers yet so the interface may still need changes? > TTM sucks? > Userspace command-submission for ever? > I don't like versioning anything ever? > > So my current answers to my list of cons is: > > Adding new faster interfaces for 3D drivers shouldn't be a major problem, if its > just a matter of making the current APIs saner. > > If you are going to write a UCS/non-TTM driver you are going to have to do > major changes all over the stack, in theory a kernel CONFIG option to enable > version 2 of the interface and drop version 1 would be an option at that time. > Or even a boot option to select between which one you want. I would > forsee a UCS/non-TTM driver needing to rewrite quite a lot of userspace, > in fact probably all of it. I haven't seen anyone actually start or > commit to working > on such a beast, and I'd reckon its probably a 1-2 year job, GEM took over a > year and it was arguably simpler. I'm not seeing the point of sitting > in a holding > pattern for that length of time just in case its better. The future is > always going > to be better. > > As for the I don't like versioning argument, well that really doesn't > need addressing, > you have to do version stuff to ship it, if the project as a whole > decides they don't > see a need to ever ship the code, then so be it. > > Dave. > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau >I think at least the notifier/dma handle stuff should be looked at. I think there is opportunity for generalizing here and i believe at least one of the mesa drivers wants/needs it. Page based memory backend for nv50 could be done without breaking api (i think). IMO, we should declare 1.0 once our mesa drivers are running well and with decent performance. Then we can go forward. Maarten.
On Thu, Mar 4, 2010 at 8:23 PM, Dave Airlie <airlied at gmail.com> wrote:> So with all this ongoing Linus crap I'm going to be brave and ask for > reasons why > 0.0.16 kernel API can't become 1.0.0. > > Pros: > All old userspace compatibility is gone. > No more UMS cruft to support. > Something can be shipped on distros at last, people get to use the driver. > 3D drivers exist and use the interface, there is an investment in these already. > > Reasons against: (I'm making these up, feel free ack/nack/flesh > out/add more etc). > We haven't finished 3D drivers yet so the interface may still need changes? > TTM sucks? > Userspace command-submission for ever? > I don't like versioning anything ever? > > So my current answers to my list of cons is: > > Adding new faster interfaces for 3D drivers shouldn't be a major problem, if its > just a matter of making the current APIs saner. > > If you are going to write a UCS/non-TTM driver you are going to have to do > major changes all over the stack, in theory a kernel CONFIG option to enable > version 2 of the interface and drop version 1 would be an option at that time. > Or even a boot option to select between which one you want. I would > forsee a UCS/non-TTM driver needing to rewrite quite a lot of userspace, > in fact probably all of it. I haven't seen anyone actually start or > commit to working > on such a beast, and I'd reckon its probably a 1-2 year job, GEM took over a > year and it was arguably simpler. I'm not seeing the point of sitting > in a holding > pattern for that length of time just in case its better. The future is > always going > to be better. > > As for the I don't like versioning argument, well that really doesn't > need addressing, > you have to do version stuff to ship it, if the project as a whole > decides they don't > see a need to ever ship the code, then so be it. > > Dave.Whatever the decision is I suggest it not be made too hastily because of a Linus rant. We already know roughly where that leads. :)
So, after discussion on irc, here is an idea/proposal. We could flag the upcoming couple of months (two months sounds like enough?) as the "nouveau DRM stabilizing timeframe". Everything that we think should go into the DRM (basically everything which we want to go in and can be achieved in that timeframe) goes in. And then we declare that our first stable API ever. And then we party. So, does that sound like a plan? Stephane