All fields in struct nouveau_framebuffer appear to be obsolete. The
data structure can be replaced by struct drm_framebuffer entirely.
Patch 1 removes several unused fields from struct nouveau_framebuffer.
Patch 2 moves the field vma to struct nouveau_fbdev. The information
in vma is only
After its cleanup, struct nouveau_framebuffer is only a wrapper around
struct drm_framebuffer. Use the latter directly.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 26 +++
drivers/gpu/drm/nouveau/nouveau_display.c | 14 ++--
The buffer object stored in nvbo is also available GEM object in obj[0]
of struct drm_framebuffer. Therefore remove nvbo in favor obj[0] and
replace all references accordingly. This may require an additional cast.
With this change we can already replace nouveau_user_framebuffer_destroy()
and
The vma field of struct nouveau_framebuffer is a special field for the
the accelerated fbdev console. Hence there's at most one single instance
for the active console. Moving it into struct nouveau_fbdev makes struct
nouveau_framebuffer slightly smaller and brings it closer to struct
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/nouveau_display.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.h
b/drivers/gpu/drm/nouveau/nouveau_display.h
index 6e8e66882e45..e397b3d246e5 100644
---
Note I'm adding some fields to nouveau_framebuffer in the series
"drm/nouveau: Support NVIDIA format modifiers." I sent out v3 of that
yesterday. It would probably still be possible to avoid them by
re-extracting the relevant data from the format modifier on the fly when
needed, but it is
So ... for Vulkan, the API requires allocating VA before declaring
what goes into that VA (e.g. an image or data). I believe our plan for
that was to move all this into userspace, which would allocate VA and
then just tell the kernel "make VA range X have memtype Y". At that
point, nouveau_bo
The format modifiers, when present, override the equivalent field in the
BO. Right now, that's probably not particularly useful. However, as
nouveau interfaces evolve towards the HW capabilities and add support
for newer graphics APIs, saying an entire BO has a singular layout
becomes less
(Re-sending to list rather than just to James)
Is this format modifier information not stored, or otherwise worth
storing, directly in the nouveau_bo object associated with the
framebuffer? I'm not particularly knowledgeable on the topic, but there
already seem to exist some fields with very
What object would ultimately provide the physical backing for the VA you
described below? I assumed it would be a bo. E.g., a Vulkan
application creates or imports some image backed by some memory that
gets represented as a bo in the kernel, then creates a framebuffer on
that bo with a
Hi James
Am 06.02.20 um 16:17 schrieb James Jones:
> Note I'm adding some fields to nouveau_framebuffer in the series
> "drm/nouveau: Support NVIDIA format modifiers." I sent out v3 of that
> yesterday. It would probably still be possible to avoid them by
> re-extracting the relevant data from
Yes, that's certainly viable. If that's the general preference in
direction, I'll rework that patches to do so.
Thanks,
-James
On 2/6/20 7:49 AM, Thomas Zimmermann wrote:
Hi James
Am 06.02.20 um 16:17 schrieb James Jones:
Note I'm adding some fields to nouveau_framebuffer in the series
Yes, that's certainly viable. If that's the general preference in
direction, I'll rework that patches to do so.
Thanks,
-James
On 2/6/20 7:49 AM, Thomas Zimmermann wrote:
Hi James
Am 06.02.20 um 16:17 schrieb James Jones:
Note I'm adding some fields to nouveau_framebuffer in the series
13 matches
Mail list logo
