From: Daniel Vetter <daniel@ffwll.ch>
To: "Thomas Hellström (VMware)" <thomas@shipmail.org>
Cc: ckoenig.leichtzumerken@gmail.com,
Gerd Hoffmann <kraxel@redhat.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 00/18] drm/ttm: make ttm bo a gem bo subclass
Date: Fri, 21 Jun 2019 17:57:37 +0200 [thread overview]
Message-ID: <20190621155737.GH12905@phenom.ffwll.local> (raw)
In-Reply-To: <8e022cff-604c-457a-7b85-c1233ac3a2fe@shipmail.org>
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-06-21 15:57 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-21 11:57 [PATCH v2 00/18] drm/ttm: make ttm bo a gem bo subclass Gerd Hoffmann
2019-06-21 11:57 ` [PATCH v2 01/18] drm/ttm: add gem base object Gerd Hoffmann
2019-06-21 11:57 ` [PATCH v2 02/18] drm/vram: use embedded gem object Gerd Hoffmann
2019-06-28 7:29 ` Thomas Zimmermann
2019-06-28 7:50 ` Daniel Vetter
2019-06-21 11:57 ` [PATCH v2 03/18] drm/qxl: " Gerd Hoffmann
[not found] ` <20190621115755.8481-1-kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-06-21 11:57 ` [PATCH v2 04/18] drm/radeon: " Gerd Hoffmann
2019-06-21 11:57 ` [PATCH v2 05/18] drm/amdgpu: " Gerd Hoffmann
2019-06-21 11:57 ` [PATCH v2 06/18] drm/nouveau: " Gerd Hoffmann
2019-06-21 11:57 ` [PATCH v2 12/18] drm/radeon: switch driver from bo->resv to bo->base.resv Gerd Hoffmann
2019-06-21 11:57 ` [PATCH v2 07/18] drm/ttm: use gem reservation object Gerd Hoffmann
2019-06-21 11:57 ` [PATCH v2 08/18] drm/ttm: use gem vma_node Gerd Hoffmann
2019-06-21 11:57 ` [PATCH v2 09/18] drm/vram: drop drm_gem_vram_driver_gem_prime_mmap Gerd Hoffmann
2019-06-28 7:30 ` Thomas Zimmermann
2019-06-21 11:57 ` [PATCH v2 10/18] drm/ttm: set both resv and base.resv pointers Gerd Hoffmann
2019-06-21 11:57 ` [PATCH v2 11/18] drm/ttm: switch ttm core from bo->resv to bo->base.resv Gerd Hoffmann
2019-06-21 11:57 ` [PATCH v2 13/18] drm/vmwgfx: switch driver " Gerd Hoffmann
2019-06-21 11:57 ` [PATCH v2 14/18] drm/amdgpu: " Gerd Hoffmann
2019-06-21 11:57 ` [PATCH v2 15/18] drm/nouveau: " Gerd Hoffmann
2019-06-21 11:57 ` [PATCH v2 16/18] drm/qxl: " Gerd Hoffmann
2019-06-21 11:57 ` [PATCH v2 17/18] drm/virtio: " Gerd Hoffmann
2019-06-21 11:57 ` [PATCH v2 18/18] drm/ttm: drop ttm_buffer_object->resv Gerd Hoffmann
2019-06-21 13:48 ` [PATCH v2 00/18] drm/ttm: make ttm bo a gem bo subclass Christian König
2019-06-21 16:31 ` Daniel Vetter
2019-06-21 15:12 ` Thomas Hellström (VMware)
2019-06-21 15:57 ` Daniel Vetter [this message]
2019-06-21 22:52 ` Thomas Hellstrom
2019-06-22 9:18 ` Daniel Vetter
2019-06-22 19:14 ` Thomas Hellstrom
2019-06-24 6:32 ` Gerd Hoffmann
2019-06-26 7:17 ` Christian König
2019-06-24 8:39 ` Daniel Vetter
2019-06-27 7:32 ` Daniel Vetter
2019-06-27 12:22 ` Gerd Hoffmann
2019-06-27 15:57 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190621155737.GH12905@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kraxel@redhat.com \
--cc=thomas@shipmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox