On 2/10/20 3:35 PM, Ben Skeggs wrote:
On Tue, 11 Feb 2020 at 09:17, James Jones wrote:
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 wrote:
I've sent out a v4 version of the format modifier patches
On Tue, 11 Feb 2020 at 09:17, James Jones wrote:
>
> 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 wrote:
> >>>
> >>> I've sent out a v4 version of the format modifier patches which avoid
> >>>
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 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
Hi
Am 10.02.20 um 09:20 schrieb Ben Skeggs:
> On Sat, 8 Feb 2020 at 07:10, James Jones 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
On Sat, 8 Feb 2020 at 07:10, James Jones 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
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, but if these
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
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
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
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
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 ++--
15 matches
Mail list logo
