On Fri, Jun 21, 2019 at 05:12:19PM +0200, Thomas Hellström (VMware) wrote: > > > On 6/21/19 1:57 PM, Gerd Hoffmann wrote: > > Aargh. Please don't do this. Multiple reasons: > > 1) I think It's bad to dump all buffer object functionality we can possibly > think of in a single struct and force that on all (well at least most) > users. It's better to isolate functionality in structs, have utility > functions for those and let the drivers derive their buffer objects from > whatever functionality they actually need. > 2) vmwgfx is not using gem and we don't want to carry that extra payload in > the buffer object. > 3) TTM historically hasn't been using the various drm layers except for > later when common helpers have been used, (like the vma manager and the > cache utilities). It's desirable to keep that layer distinction. (which is > really what I'm saying in 1.) > > Now if more and more functionality that originated in TTM is moving into GEM > we need to find a better way to do that without duplicating functionality. I > suggest adding pointers in the TTM structs and defaulting those pointers to > the member in the TTM struct. Optionally to to the member in the GEM struct. > If we need to migrate those members out of the TTM struct, vmwgfx would have > to provide them in its own buffer class. > > NAK from the vmwgfx side. It's 59 DRIVER_GEM vs 1 which is not. I think the verdict is clear what the reasonable thing to do is here, and this will allow us to substantially improve code and concept sharing across drm drivers. 10 years ago it was indeed not clear whether everyone doing the same is a bright idea, but that's no more. If you want I guess you can keep a private copy of ttm in vmwgfx, but not sure that's really worth it long-term. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
