Displaying 20 results from an estimated 1000 matches similar to: "[PATCH v2 0/3] drm/nouveau: Support NVIDIA format modifiers"
2020 Feb 05
3
[PATCH v3 0/3] drm/nouveau: Support NVIDIA format modifiers
This series modifies the NV5x+ nouveau display backends to advertise
appropriate format modifiers on their display planes in atomic mode
setting blobs.
Corresponding modifications to Mesa/userspace are available on the
Mesa-dev mailing list as the series:
nouveau: Improved format modifier support
I've tested this on Tesla, Kepler, Pascal, and Turing-class hardware
using various formats
2020 Feb 07
3
[PATCH v4 0/3] drm/nouveau: Support NVIDIA format modifiers
This series modifies the NV5x+ nouveau display backends to advertise
appropriate format modifiers on their display planes in atomic mode
setting blobs.
Corresponding modifications to Mesa/userspace are available on the
Mesa-dev gitlab merge request 3724:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3724
I've tested this on Tesla, Kepler, Pascal, and Turing-class hardware
using
2020 Feb 10
3
[PATCH v5 0/3] drm/nouveau: Support NVIDIA format modifiers
This series modifies the NV5x+ nouveau display backends to advertise
appropriate format modifiers on their display planes in atomic mode
setting blobs.
Corresponding modifications to Mesa/userspace are available on the
Mesa-dev gitlab merge request 3724:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3724
I've tested this on Tesla, Kepler, Pascal, and Turing-class hardware
using
2019 Dec 11
5
[PATCH 0/3] drm/nouveau: Support NVIDIA format modifiers
This series modifies the NV5x+ nouveau display backends to advertise
appropriate format modifiers on their display planes in atomic mode
setting blobs.
Corresponding modifications to Mesa/userspace are available here:
https://gitlab.freedesktop.org/cubanismo/mesa/tree/nouveau_work
But those need a bit of cleanup before they're ready to submit.
I've tested this on Tesla, Kepler, Pascal,
2020 Jan 06
1
[PATCH v2 2/3] drm/nouveau: Check framebuffer size against bo
On Tue, 17 Dec 2019 at 10:45, James Jones <jajones at nvidia.com> wrote:
>
> Make sure framebuffer dimensions and tiling
> parameters will not result in accesses beyond the
> end of the GEM buffer they are bound to.
>
> Signed-off-by: James Jones <jajones at nvidia.com>
> ---
> drivers/gpu/drm/nouveau/nouveau_display.c | 93 +++++++++++++++++++++++
> 1 file
2019 Dec 11
2
[PATCH 3/3] drm/nouveau: Support NVIDIA format modifiers
On Wed, Dec 11, 2019 at 4:04 PM James Jones <jajones at nvidia.com> wrote:
>
> Allow setting the block layout of a nouveau FB
> object using DRM format modifiers. When
> specified, the format modifier block layout and
> kind overrides the GEM buffer's implicit layout
> and kind. The specified format modifier is
> validated against he list of modifiers supported
2020 Feb 06
5
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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 simpler and likely less error-prone with the wrapper
struct.
Thanks,
-James
On 2/6/20
2020 Feb 06
2
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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
>> "drm/nouveau: Support NVIDIA format modifiers."?
2020 Feb 10
2
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
On Sat, 8 Feb 2020 at 07:10, James Jones <jajones at nvidia.com> wrote:
>
> I've sent out a v4 version of the format modifier patches which avoid
> caching values in the nouveau_framebuffer struct. It will have a few
> trivial conflicts with your series, but should make them structurally
> compatible.
>
> I'm fine with either v3 or v4 of my series personally,
2020 Feb 10
2
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
On 2/10/20 12:25 AM, Thomas Zimmermann wrote:
> Hi
>
> Am 10.02.20 um 09:20 schrieb Ben Skeggs:
>> On Sat, 8 Feb 2020 at 07:10, James Jones <jajones at nvidia.com> wrote:
>>>
>>> I've sent out a v4 version of the format modifier patches which avoid
>>> caching values in the nouveau_framebuffer struct. It will have a few
>>> trivial
2020 Feb 06
5
[PATCH 0/4] drm/nouveau: Remove struct nouveau_framebuffer
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 relevant for fbdev emulation, and as such he field is
only used there.
Patch 3 removes nvbo from struct
2020 Feb 06
2
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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 meaningful, so I suspect those fields will be effectively
deprecated in favor of the
2019 Dec 17
0
[PATCH v2 2/3] drm/nouveau: Check framebuffer size against bo
Make sure framebuffer dimensions and tiling
parameters will not result in accesses beyond the
end of the GEM buffer they are bound to.
Signed-off-by: James Jones <jajones at nvidia.com>
---
drivers/gpu/drm/nouveau/nouveau_display.c | 93 +++++++++++++++++++++++
1 file changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
2020 Jan 06
2
[PATCH v2 0/3] drm/nouveau: Support NVIDIA format modifiers
On 1/5/20 5:30 PM, Ben Skeggs wrote:
> On Tue, 17 Dec 2019 at 10:44, James Jones <jajones at nvidia.com> wrote:
>>
>> This series modifies the NV5x+ nouveau display backends to advertise
>> appropriate format modifiers on their display planes in atomic mode
>> setting blobs.
>>
>> Corresponding modifications to Mesa/userspace are available here:
2020 Nov 06
4
[PATCH 0/3] drm/nouveau: extend the lifetime of nouveau_drm
Hi folks,
Currently, when the device is removed (or the driver is unbound) the
nouveau_drm structure de-allocated. However, it's still accessible from
and used by some DRM layer callbacks. For example, file handles can be
closed after the device has been removed (physically or otherwise). This
series converts the Nouveau device structure to be allocated and
de-allocated with the
2017 Aug 08
5
[PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".
Because all drivers currently use gem objects for framebuffer planes,
the virtual create_handle() is not required. This change adds a
struct drm_gem_object *gems[4] field to drm_framebuffer and removes
create_handle() function pointer from drm_framebuffer_funcs. The
corresponding *_create_handle() function is removed from each driver.
In many cases this change eliminates a struct *_framebuffer
2017 Aug 08
5
[PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".
Because all drivers currently use gem objects for framebuffer planes,
the virtual create_handle() is not required. This change adds a
struct drm_gem_object *gems[4] field to drm_framebuffer and removes
create_handle() function pointer from drm_framebuffer_funcs. The
corresponding *_create_handle() function is removed from each driver.
In many cases this change eliminates a struct *_framebuffer
2017 Aug 08
5
[PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".
Because all drivers currently use gem objects for framebuffer planes,
the virtual create_handle() is not required. This change adds a
struct drm_gem_object *gems[4] field to drm_framebuffer and removes
create_handle() function pointer from drm_framebuffer_funcs. The
corresponding *_create_handle() function is removed from each driver.
In many cases this change eliminates a struct *_framebuffer
2020 Apr 17
9
[RFC v3 00/11] drm/nouveau: Introduce CRC support for gf119+
Nvidia released some documentation on how CRC support works on their
GPUs, hooray!
So: this patch series implements said CRC support in nouveau, along with
adding some special debugfs interfaces for some relevant igt-gpu-tools
tests that we'll be sending in just a short bit.
This additionally adds a feature that Ville Syrj?l? came up with: vblank
works. Basically, this is just a generic DRM
2020 Feb 10
2
[PATCH] drm/nouveau: Fix NULL ptr access in nv50_wndw_prepare_fb()
This fixes a kernel oops when loading the nouveau
module with fb console enabled after the change:
drm/nouveau: Remove field nvbo from struct nouveau_framebuffer
state->fb may be NULL in nv50_wndw_prepare_fb(),
so defer initializing nvbo from its obj[] array
until after the NULL check.
Signed-off-by: James Jones <jajones at nvidia.com>
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 3