On Thu, 2010-01-07 at 09:56 +0100, Maarten Maathuis wrote: > It's going to get ripped out at some point, the question is how long > do you expect to need it? It's not like the code is going anywhere too, it's in git :) It wouldn't be difficult to keep a branch from, say, now, and cherry pick the changes to the accel code across if there are any.
Ben. > > Depending on that estimate you can determine if it's worth it to keep > (there's no point in letting it bitrot all the way). > > And for testing, you do know that you can write test applications that > can test various features to see if everything works as intended, > without having to make X work first. > > Maarten. > > On Thu, Jan 7, 2010 at 2:59 AM, Robert Noland <[email protected]> wrote: > > On Thu, 2010-01-07 at 00:58 +0200, Pekka Paalanen wrote: > >> On Wed, 06 Jan 2010 15:32:30 +1000 > >> Ben Skeggs <[email protected]> wrote: > >> > >> > I did a very quick pass at removing all the non-KMS support from > >> > the DDX. It's tested on G80 but nowhere else currently, I > >> > thought some discussion would be a good idea rather than just > >> > ripping it out :) > >> > > >> > The non-KMS paths are messy, and lets face it, rotting badly. > >> > IMO the KMS code is stable enough now that we can continue > >> > without the UMS crutch, and indeed, the KMS code supports a lot > >> > more chipsets (particularly on GF8 and up) than the UMS code ever > >> > will. > >> > >> Considering that any BSD will not have KMS for quite some time > >> (do they?), this sounds very cruel. Is it really such a big > >> pain to keep the code around? > >> > >> OTOH, BSDs are stuck with pre-TTM Nouveau until they port GEM > >> and TTM to BSDs. How much more will it cost to BSDs to add KMS > >> to the list of mandatory kernel features... rnoland and others, > >> any comments? > > > > Well, I would prefer that this not get ripped out, honestly. My current > > big project queue is GEM, TTM and finally KMS. I think that I finally > > have a handle on how I'm going to finish implementing GEM now. TTM, I > > have started on, but mostly what I have now is stubs, so until I'm > > deeper into porting/re-writing the code I don't have a clear plan. I > > think that it will likely be handled in much the same way as GEM, but > > I'm sure there will be new things to sort out. > > > > I've looked at KMS less than any of the other stuff so far really, but > > the API is designed around linux and while much of the code to interact > > with the hardware should be fairly easy to port I think, I'm really not > > clear how the current API can/will tie into our (BSD) console code. So, > > basically what I'm saying here is that I don't currently have a plan for > > how I'm going to deal with KMS, where I do at least have fairly clear > > plans for GEM and hopefully TTM. > > > > Unfortunately, the amount of time that I have available to work on stuff > > has just been dramatically reduced, at least for the time being. > > > > robert. > > > > -- > > Robert Noland <[email protected]> > > 2Hip Networks > > > > _______________________________________________ > > Nouveau mailing list > > [email protected] > > http://lists.freedesktop.org/mailman/listinfo/nouveau > > > _______________________________________________ > Nouveau mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/nouveau _______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
