On Sun, Aug 22, 2010 at 08:13:45PM +0200, Marek Olšák wrote: > On Sun, Aug 22, 2010 at 6:58 PM, Corbin Simpson > <mostawesomed...@gmail.com>wrote: > > > > I'm not so sure about this series, because (a) it should be possible > > to come up with something that works for both EGL backends (b) we > > haven't decided yet how much code r300g and r600g get to share. > > > > (a) I agree. > > (b) So far it seems to me that the strategy is to copy-paste useful pieces > of code from r300g to r600g and reinventing the wheel elsewhere, instead of > code sharing. My idea is that r300_xxx and r600_xxx structures should > inherit yet-non-existent structures radeon_xxx which should be used by > common code, and these in turn should inherit pipe_xxx. This way we don't > have to redirect all entrypoints to a driver like in galahad, only the ones > we want to override. At least all buffer management and texture transfer > code could be shared. Then, the drivers would not need to implement > entrypoints like user_buffer_create and transfers and some other resource > entrypoints, and an alternate low-level bufmgr interface would be provided > the drivers must implement instead. > > The idea of sharing winsys is pretty much dead, as you probably already > know. I think Jerome wants to move some of the r600g winsys code into > kernel. > > Marek
My feeling is that only some of the buffer management for avoiding to allocate too frequently bo would be usefull. I think this buffer management can be moved to util at some point as i believe other driver can benefit from similar things. It would be target for allocation of small buffer and the logic would be come one (couple of callback to allow driver to plug its low level allocation would be enough like bo_open,bo_decref,bo_incref,bo_is_idle,bo_wait_idle) The rest of the winsys is too different, i am going to simplify the r600 winsys state/context over the next few days but it will still be different from atom+prediction all over the place. Cheers, Jerome _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev