Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Michel Dänzer]

On 28/10/16 07:15 PM, Marek Olšák wrote:
> On Oct 28, 2016 3:30 AM, "Michel Dänzer"  > wrote:
>>
>> On 28/10/16 03:08 AM, Marek Olšák wrote:
>> > On Thu, Oct 27, 2016 at 5:23 PM, Emil Velikov
> > wrote:
>> >> On 17 October 2016 at 10:37, Marek Olšák  > wrote:
>> >>> Reverting the whole commit is too much. You can just remove the
> PIPE BIND
>> >>> SHARED usage if you need to.
>> >>>
>> >> I'd imagine that one wants to check if radeon(s) behave OK with the
>> >> flag dropped ? Thus it might be better for someone with radeon HW to
>> >> give it a bash.
>> >> Can we have a volunteer please :-)
>> >
>> > r600-radeonsi ignore PIPE_BIND_SHARED on textures.
>>
>> That doesn't mean the state tracker can just drop PIPE_BIND_SHARED.
> 
> Actually, the flag should be removed from Gallium completely, because it
> serves no purpose. All textures can be shared. Always.

Fine with me, but that'd make things more complicated again for Ilia. :)


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Marek Olšák]

On Oct 28, 2016 3:30 AM, "Michel Dänzer"  wrote:
>
> On 28/10/16 03:08 AM, Marek Olšák wrote:
> > On Thu, Oct 27, 2016 at 5:23 PM, Emil Velikov 
wrote:
> >> On 17 October 2016 at 10:37, Marek Olšák  wrote:
> >>> Reverting the whole commit is too much. You can just remove the PIPE
BIND
> >>> SHARED usage if you need to.
> >>>
> >> I'd imagine that one wants to check if radeon(s) behave OK with the
> >> flag dropped ? Thus it might be better for someone with radeon HW to
> >> give it a bash.
> >> Can we have a volunteer please :-)
> >
> > r600-radeonsi ignore PIPE_BIND_SHARED on textures.
>
> That doesn't mean the state tracker can just drop PIPE_BIND_SHARED.

Actually, the flag should be removed from Gallium completely, because it
serves no purpose. All textures can be shared. Always.

Marek

>
> https://patchwork.freedesktop.org/patch/110569/ seems the best candidate
> for resolving the nouveau issue, but I suspect as is it might break DRI3
> PRIME. Nayan, can you check this and fix it up as necessary? Basically,
> PIPE_BIND_LINEAR is only really necessary for buffers which are sent to
> the X server for presentation on a different GPU.
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Nayan Deshmukh]

On Fri, Oct 28, 2016 at 2:43 PM, Michel Dänzer  wrote:

> On 28/10/16 06:04 PM, Nayan Deshmukh wrote:
> > On Fri, Oct 28, 2016 at 2:14 PM, Michel Dänzer  > > wrote:
> >
> > On 28/10/16 03:58 PM, Nayan Deshmukh wrote:
> > > On Fri, Oct 28, 2016 at 7:00 AM, Michel Dänzer  
> > > >> wrote:
> > >
> > > On 28/10/16 03:08 AM, Marek Olšák wrote:
> > > > On Thu, Oct 27, 2016 at 5:23 PM, Emil Velikov
> > 
> > >>
> > wrote:
> > > >> On 17 October 2016 at 10:37, Marek Olšák    > >> wrote:
> > > >>> Reverting the whole commit is too much. You can just
> remove the PIPE BIND
> > > >>> SHARED usage if you need to.
> > > >>>
> > > >> I'd imagine that one wants to check if radeon(s) behave OK
> with the
> > > >> flag dropped ? Thus it might be better for someone with
> radeon HW to
> > > >> give it a bash.
> > > >> Can we have a volunteer please :-)
> > > >
> > > > r600-radeonsi ignore PIPE_BIND_SHARED on textures.
> > >
> > > That doesn't mean the state tracker can just drop
> PIPE_BIND_SHARED.
> > >
> > > https://patchwork.freedesktop.org/patch/110569/
> > 
> > >  > > seems the best
> > > candidate
> > > for resolving the nouveau issue, but I suspect as is it might
> break DRI3
> > > PRIME. Nayan, can you check this and fix it up as necessary?
> Basically,
> > > PIPE_BIND_LINEAR is only really necessary for buffers which
> are sent to
> > > the X server for presentation on a different GPU.
> > >
> > > It works fine with DRI3 Prime with my I+A system, but I think it
> won't
> > > work with a I+N system as it uses PIPE_BIND_SHARE and
> PIPE_BIND_LINEAR
> > > together for one buffer.
> >
> > The patch above removes PIPE_BIND_LINEAR. Which case are you
> > thinking of?
> >
> >
> > We also use PIPE_BIND_LINEAR and PIPE_BIND_SHARED when allocating a
> > buffer in vl_winsys_dri3.c, so do we also need to change that?
>
> No, that's for sharing between different GPUs, in which case both flags
> are required (even with nouveau).
>
> Then DRI3 works fine with this change.

Regards,
Nayan.

>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Michel Dänzer]

On 28/10/16 06:04 PM, Nayan Deshmukh wrote:
> On Fri, Oct 28, 2016 at 2:14 PM, Michel Dänzer  > wrote:
> 
> On 28/10/16 03:58 PM, Nayan Deshmukh wrote:
> > On Fri, Oct 28, 2016 at 7:00 AM, Michel Dänzer  
> > >> wrote:
> >
> > On 28/10/16 03:08 AM, Marek Olšák wrote:
> > > On Thu, Oct 27, 2016 at 5:23 PM, Emil Velikov
> 
> >>
> wrote:
> > >> On 17 October 2016 at 10:37, Marek Olšák    >> wrote:
> > >>> Reverting the whole commit is too much. You can just remove the 
> PIPE BIND
> > >>> SHARED usage if you need to.
> > >>>
> > >> I'd imagine that one wants to check if radeon(s) behave OK with 
> the
> > >> flag dropped ? Thus it might be better for someone with radeon 
> HW to
> > >> give it a bash.
> > >> Can we have a volunteer please :-)
> > >
> > > r600-radeonsi ignore PIPE_BIND_SHARED on textures.
> >
> > That doesn't mean the state tracker can just drop PIPE_BIND_SHARED.
> >
> > https://patchwork.freedesktop.org/patch/110569/
> 
> >  > seems the best
> > candidate
> > for resolving the nouveau issue, but I suspect as is it might break 
> DRI3
> > PRIME. Nayan, can you check this and fix it up as necessary? 
> Basically,
> > PIPE_BIND_LINEAR is only really necessary for buffers which are 
> sent to
> > the X server for presentation on a different GPU.
> >
> > It works fine with DRI3 Prime with my I+A system, but I think it won't
> > work with a I+N system as it uses PIPE_BIND_SHARE and PIPE_BIND_LINEAR
> > together for one buffer.
> 
> The patch above removes PIPE_BIND_LINEAR. Which case are you
> thinking of?
> 
>  
> We also use PIPE_BIND_LINEAR and PIPE_BIND_SHARED when allocating a
> buffer in vl_winsys_dri3.c, so do we also need to change that? 

No, that's for sharing between different GPUs, in which case both flags
are required (even with nouveau).


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Nayan Deshmukh]

On Fri, Oct 28, 2016 at 2:14 PM, Michel Dänzer  wrote:

> On 28/10/16 03:58 PM, Nayan Deshmukh wrote:
> > On Fri, Oct 28, 2016 at 7:00 AM, Michel Dänzer  > > wrote:
> >
> > On 28/10/16 03:08 AM, Marek Olšák wrote:
> > > On Thu, Oct 27, 2016 at 5:23 PM, Emil Velikov <
> emil.l.veli...@gmail.com > wrote:
> > >> On 17 October 2016 at 10:37, Marek Olšák  > wrote:
> > >>> Reverting the whole commit is too much. You can just remove the
> PIPE BIND
> > >>> SHARED usage if you need to.
> > >>>
> > >> I'd imagine that one wants to check if radeon(s) behave OK with
> the
> > >> flag dropped ? Thus it might be better for someone with radeon HW
> to
> > >> give it a bash.
> > >> Can we have a volunteer please :-)
> > >
> > > r600-radeonsi ignore PIPE_BIND_SHARED on textures.
> >
> > That doesn't mean the state tracker can just drop PIPE_BIND_SHARED.
> >
> > https://patchwork.freedesktop.org/patch/110569/
> >  seems the best
> > candidate
> > for resolving the nouveau issue, but I suspect as is it might break
> DRI3
> > PRIME. Nayan, can you check this and fix it up as necessary?
> Basically,
> > PIPE_BIND_LINEAR is only really necessary for buffers which are sent
> to
> > the X server for presentation on a different GPU.
> >
> > It works fine with DRI3 Prime with my I+A system, but I think it won't
> > work with a I+N system as it uses PIPE_BIND_SHARE and PIPE_BIND_LINEAR
> > together for one buffer.
>
> The patch above removes PIPE_BIND_LINEAR. Which case are you thinking of?
>

We also use PIPE_BIND_LINEAR and PIPE_BIND_SHARED when allocating a
buffer in vl_winsys_dri3.c, so do we also need to change that?

>
>
> > Since this buffer is being sent to X we need to have a PIPE_BIND_LINEAR,
> > so should I send a patch removing SHARED flag, it is working fine on
> > my system without the shared flag.
>
> PIPE_BIND_LINEAR is only required for buffers which are shared between
> different GPUs. Note that in that case it's required with nouveau as well.
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Michel Dänzer]

On 28/10/16 03:58 PM, Nayan Deshmukh wrote:
> On Fri, Oct 28, 2016 at 7:00 AM, Michel Dänzer  > wrote:
> 
> On 28/10/16 03:08 AM, Marek Olšák wrote:
> > On Thu, Oct 27, 2016 at 5:23 PM, Emil Velikov  > wrote:
> >> On 17 October 2016 at 10:37, Marek Olšák  > wrote:
> >>> Reverting the whole commit is too much. You can just remove the PIPE 
> BIND
> >>> SHARED usage if you need to.
> >>>
> >> I'd imagine that one wants to check if radeon(s) behave OK with the
> >> flag dropped ? Thus it might be better for someone with radeon HW to
> >> give it a bash.
> >> Can we have a volunteer please :-)
> >
> > r600-radeonsi ignore PIPE_BIND_SHARED on textures.
> 
> That doesn't mean the state tracker can just drop PIPE_BIND_SHARED.
> 
> https://patchwork.freedesktop.org/patch/110569/
>  seems the best
> candidate
> for resolving the nouveau issue, but I suspect as is it might break DRI3
> PRIME. Nayan, can you check this and fix it up as necessary? Basically,
> PIPE_BIND_LINEAR is only really necessary for buffers which are sent to
> the X server for presentation on a different GPU.
> 
> It works fine with DRI3 Prime with my I+A system, but I think it won't
> work with a I+N system as it uses PIPE_BIND_SHARE and PIPE_BIND_LINEAR
> together for one buffer.

The patch above removes PIPE_BIND_LINEAR. Which case are you thinking of?


> Since this buffer is being sent to X we need to have a PIPE_BIND_LINEAR,
> so should I send a patch removing SHARED flag, it is working fine on
> my system without the shared flag. 

PIPE_BIND_LINEAR is only required for buffers which are shared between
different GPUs. Note that in that case it's required with nouveau as well.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Nayan Deshmukh]

On Fri, Oct 28, 2016 at 7:00 AM, Michel Dänzer  wrote:

> On 28/10/16 03:08 AM, Marek Olšák wrote:
> > On Thu, Oct 27, 2016 at 5:23 PM, Emil Velikov 
> wrote:
> >> On 17 October 2016 at 10:37, Marek Olšák  wrote:
> >>> Reverting the whole commit is too much. You can just remove the PIPE
> BIND
> >>> SHARED usage if you need to.
> >>>
> >> I'd imagine that one wants to check if radeon(s) behave OK with the
> >> flag dropped ? Thus it might be better for someone with radeon HW to
> >> give it a bash.
> >> Can we have a volunteer please :-)
> >
> > r600-radeonsi ignore PIPE_BIND_SHARED on textures.
>
> That doesn't mean the state tracker can just drop PIPE_BIND_SHARED.
>
> https://patchwork.freedesktop.org/patch/110569/ seems the best candidate
> for resolving the nouveau issue, but I suspect as is it might break DRI3
> PRIME. Nayan, can you check this and fix it up as necessary? Basically,
> PIPE_BIND_LINEAR is only really necessary for buffers which are sent to
> the X server for presentation on a different GPU.
>
> It works fine with DRI3 Prime with my I+A system, but I think it won't
work with a I+N
system as it uses PIPE_BIND_SHARE and PIPE_BIND_LINEAR together for one
buffer.
Since this buffer is being sent to X we need to have a PIPE_BIND_LINEAR, so
should I send
a patch removing SHARED flag, it is working fine on my system without the
shared flag.

Regards,
Nayan.

>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Michel Dänzer]

On 28/10/16 03:08 AM, Marek Olšák wrote:
> On Thu, Oct 27, 2016 at 5:23 PM, Emil Velikov  
> wrote:
>> On 17 October 2016 at 10:37, Marek Olšák  wrote:
>>> Reverting the whole commit is too much. You can just remove the PIPE BIND
>>> SHARED usage if you need to.
>>>
>> I'd imagine that one wants to check if radeon(s) behave OK with the
>> flag dropped ? Thus it might be better for someone with radeon HW to
>> give it a bash.
>> Can we have a volunteer please :-)
> 
> r600-radeonsi ignore PIPE_BIND_SHARED on textures.

That doesn't mean the state tracker can just drop PIPE_BIND_SHARED.

https://patchwork.freedesktop.org/patch/110569/ seems the best candidate
for resolving the nouveau issue, but I suspect as is it might break DRI3
PRIME. Nayan, can you check this and fix it up as necessary? Basically,
PIPE_BIND_LINEAR is only really necessary for buffers which are sent to
the X server for presentation on a different GPU.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Marek Olšák]

On Thu, Oct 27, 2016 at 5:23 PM, Emil Velikov  wrote:
> On 17 October 2016 at 10:37, Marek Olšák  wrote:
>> Reverting the whole commit is too much. You can just remove the PIPE BIND
>> SHARED usage if you need to.
>>
> I'd imagine that one wants to check if radeon(s) behave OK with the
> flag dropped ? Thus it might be better for someone with radeon HW to
> give it a bash.
> Can we have a volunteer please :-)

r600-radeonsi ignore PIPE_BIND_SHARED on textures.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Emil Velikov]

On 17 October 2016 at 10:37, Marek Olšák  wrote:
> Reverting the whole commit is too much. You can just remove the PIPE BIND
> SHARED usage if you need to.
>
I'd imagine that one wants to check if radeon(s) behave OK with the
flag dropped ? Thus it might be better for someone with radeon HW to
give it a bash.
Can we have a volunteer please :-)

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Marek Olšák]

Reverting the whole commit is too much. You can just remove the PIPE BIND
SHARED usage if you need to.

Marek

On Oct 17, 2016 6:43 AM, "Ilia Mirkin"  wrote:

> On Thu, Sep 15, 2016 at 4:54 PM, Marek Olšák  wrote:
> > On Thu, Sep 15, 2016 at 5:14 AM, Dave Airlie  wrote:
> >> On 15 September 2016 at 13:03, Ilia Mirkin 
> wrote:
> >>> On Wed, Sep 14, 2016 at 10:15 PM, Michel Dänzer 
> wrote:
> > No, the current impl is pretty radeon-specific (note - it doesn't
> work
> > on nouveau, and no other drivers support the interfaces, so ... it's
> > radeon-specific).
> 
>  We're getting into semantics here, but since the reason it doesn't
> work
>  well with nouveau is a fundamental issue in nouveau (which should also
>  affect at least DRI3 in general), while you may call it "de facto
> radeon
>  specific" if you're so inclined, that doesn't make the implementation
>  actually radeon specific.
> >>>
> >>> No one's reported any issues with DRI3, I use it on my home desktop
> >>> every day. And VDPAU used to work great until these changes to
> >>> st/vdpau went in. Prior to those changes in st/vdpau, saying that
> >>> "shared == gart" was a perfectly reasonable thing to say, since no one
> >>> tried blending/readback on those surfaces (or at least not enough for
> >>> it to matter). But now ... poof ... it doesn't work [actually, worse -
> >>> it works - but can't come close to keeping up with 24fps video].
> >>>
> >>> Anyways, I realize this is a losing argument. Interfaces and usages
> >>> move forward and change over time. This happens to be a change that
> >>> leaves nouveau behind. As a spare-time contributor, I can't keep up
> >>> with multiple full timers. I had hoped that there'd be some way to
> >>> make it all still work, but that doesn't seem to be the case.
> >>> Unfortunately end users are going to lose out on functionality as a
> >>> result.
> >>
> >> So (a) this is a regression, regressions aren't allowed, so it would
> >> be good to back the change out until it can be fixed.
> >>
> >> The problem is the combo of LINEAR and SHARED means that
> >> GART placement is most likely, radeon should be doing the same
> >> in most circumstances.
> >>
> >> We should possible introduced SHARED_OTHER_GPU maybe
> >> and use that throughout the stack where it matters.
> >
> > The main problem is that nouveau lacks a proper memory management and
> > buffers are pinned after allocation forever.
> >
> > The workaround is to add PIPE_BIND_something, which would do what you
> > need it to do, and use it where you need to use it. I don't care about
> > the name as long as it works for nouveau. Does that sound reasonable?
>
> I don't really care how it's resolved, but the current situation is
> unacceptable.
>
>  - Reverting definitely works.
>  - Dropping libvdpau_nouveau definitely works.
>  - Adding a new flag may work, depends on details, would require a
> bunch of testing.
>
> Dave sent a patch for the first, I've sent a patch for the second. I
> don't think a patch for the third has materialized.
>
>   -ilia
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Ilia Mirkin]

On Thu, Sep 15, 2016 at 4:54 PM, Marek Olšák  wrote:
> On Thu, Sep 15, 2016 at 5:14 AM, Dave Airlie  wrote:
>> On 15 September 2016 at 13:03, Ilia Mirkin  wrote:
>>> On Wed, Sep 14, 2016 at 10:15 PM, Michel Dänzer  wrote:
> No, the current impl is pretty radeon-specific (note - it doesn't work
> on nouveau, and no other drivers support the interfaces, so ... it's
> radeon-specific).

 We're getting into semantics here, but since the reason it doesn't work
 well with nouveau is a fundamental issue in nouveau (which should also
 affect at least DRI3 in general), while you may call it "de facto radeon
 specific" if you're so inclined, that doesn't make the implementation
 actually radeon specific.
>>>
>>> No one's reported any issues with DRI3, I use it on my home desktop
>>> every day. And VDPAU used to work great until these changes to
>>> st/vdpau went in. Prior to those changes in st/vdpau, saying that
>>> "shared == gart" was a perfectly reasonable thing to say, since no one
>>> tried blending/readback on those surfaces (or at least not enough for
>>> it to matter). But now ... poof ... it doesn't work [actually, worse -
>>> it works - but can't come close to keeping up with 24fps video].
>>>
>>> Anyways, I realize this is a losing argument. Interfaces and usages
>>> move forward and change over time. This happens to be a change that
>>> leaves nouveau behind. As a spare-time contributor, I can't keep up
>>> with multiple full timers. I had hoped that there'd be some way to
>>> make it all still work, but that doesn't seem to be the case.
>>> Unfortunately end users are going to lose out on functionality as a
>>> result.
>>
>> So (a) this is a regression, regressions aren't allowed, so it would
>> be good to back the change out until it can be fixed.
>>
>> The problem is the combo of LINEAR and SHARED means that
>> GART placement is most likely, radeon should be doing the same
>> in most circumstances.
>>
>> We should possible introduced SHARED_OTHER_GPU maybe
>> and use that throughout the stack where it matters.
>
> The main problem is that nouveau lacks a proper memory management and
> buffers are pinned after allocation forever.
>
> The workaround is to add PIPE_BIND_something, which would do what you
> need it to do, and use it where you need to use it. I don't care about
> the name as long as it works for nouveau. Does that sound reasonable?

I don't really care how it's resolved, but the current situation is
unacceptable.

 - Reverting definitely works.
 - Dropping libvdpau_nouveau definitely works.
 - Adding a new flag may work, depends on details, would require a
bunch of testing.

Dave sent a patch for the first, I've sent a patch for the second. I
don't think a patch for the third has materialized.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Marek Olšák]

On Thu, Sep 15, 2016 at 5:14 AM, Dave Airlie  wrote:
> On 15 September 2016 at 13:03, Ilia Mirkin  wrote:
>> On Wed, Sep 14, 2016 at 10:15 PM, Michel Dänzer  wrote:
 No, the current impl is pretty radeon-specific (note - it doesn't work
 on nouveau, and no other drivers support the interfaces, so ... it's
 radeon-specific).
>>>
>>> We're getting into semantics here, but since the reason it doesn't work
>>> well with nouveau is a fundamental issue in nouveau (which should also
>>> affect at least DRI3 in general), while you may call it "de facto radeon
>>> specific" if you're so inclined, that doesn't make the implementation
>>> actually radeon specific.
>>
>> No one's reported any issues with DRI3, I use it on my home desktop
>> every day. And VDPAU used to work great until these changes to
>> st/vdpau went in. Prior to those changes in st/vdpau, saying that
>> "shared == gart" was a perfectly reasonable thing to say, since no one
>> tried blending/readback on those surfaces (or at least not enough for
>> it to matter). But now ... poof ... it doesn't work [actually, worse -
>> it works - but can't come close to keeping up with 24fps video].
>>
>> Anyways, I realize this is a losing argument. Interfaces and usages
>> move forward and change over time. This happens to be a change that
>> leaves nouveau behind. As a spare-time contributor, I can't keep up
>> with multiple full timers. I had hoped that there'd be some way to
>> make it all still work, but that doesn't seem to be the case.
>> Unfortunately end users are going to lose out on functionality as a
>> result.
>
> So (a) this is a regression, regressions aren't allowed, so it would
> be good to back the change out until it can be fixed.
>
> The problem is the combo of LINEAR and SHARED means that
> GART placement is most likely, radeon should be doing the same
> in most circumstances.
>
> We should possible introduced SHARED_OTHER_GPU maybe
> and use that throughout the stack where it matters.

The main problem is that nouveau lacks a proper memory management and
buffers are pinned after allocation forever.

The workaround is to add PIPE_BIND_something, which would do what you
need it to do, and use it where you need to use it. I don't care about
the name as long as it works for nouveau. Does that sound reasonable?

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Dave Airlie]

On 15 September 2016 at 13:03, Ilia Mirkin  wrote:
> On Wed, Sep 14, 2016 at 10:15 PM, Michel Dänzer  wrote:
>>> No, the current impl is pretty radeon-specific (note - it doesn't work
>>> on nouveau, and no other drivers support the interfaces, so ... it's
>>> radeon-specific).
>>
>> We're getting into semantics here, but since the reason it doesn't work
>> well with nouveau is a fundamental issue in nouveau (which should also
>> affect at least DRI3 in general), while you may call it "de facto radeon
>> specific" if you're so inclined, that doesn't make the implementation
>> actually radeon specific.
>
> No one's reported any issues with DRI3, I use it on my home desktop
> every day. And VDPAU used to work great until these changes to
> st/vdpau went in. Prior to those changes in st/vdpau, saying that
> "shared == gart" was a perfectly reasonable thing to say, since no one
> tried blending/readback on those surfaces (or at least not enough for
> it to matter). But now ... poof ... it doesn't work [actually, worse -
> it works - but can't come close to keeping up with 24fps video].
>
> Anyways, I realize this is a losing argument. Interfaces and usages
> move forward and change over time. This happens to be a change that
> leaves nouveau behind. As a spare-time contributor, I can't keep up
> with multiple full timers. I had hoped that there'd be some way to
> make it all still work, but that doesn't seem to be the case.
> Unfortunately end users are going to lose out on functionality as a
> result.

So (a) this is a regression, regressions aren't allowed, so it would
be good to back the change out until it can be fixed.

The problem is the combo of LINEAR and SHARED means that
GART placement is most likely, radeon should be doing the same
in most circumstances.

We should possible introduced SHARED_OTHER_GPU maybe
and use that throughout the stack where it matters.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Ilia Mirkin]

On Wed, Sep 14, 2016 at 10:15 PM, Michel Dänzer  wrote:
>> No, the current impl is pretty radeon-specific (note - it doesn't work
>> on nouveau, and no other drivers support the interfaces, so ... it's
>> radeon-specific).
>
> We're getting into semantics here, but since the reason it doesn't work
> well with nouveau is a fundamental issue in nouveau (which should also
> affect at least DRI3 in general), while you may call it "de facto radeon
> specific" if you're so inclined, that doesn't make the implementation
> actually radeon specific.

No one's reported any issues with DRI3, I use it on my home desktop
every day. And VDPAU used to work great until these changes to
st/vdpau went in. Prior to those changes in st/vdpau, saying that
"shared == gart" was a perfectly reasonable thing to say, since no one
tried blending/readback on those surfaces (or at least not enough for
it to matter). But now ... poof ... it doesn't work [actually, worse -
it works - but can't come close to keeping up with 24fps video].

Anyways, I realize this is a losing argument. Interfaces and usages
move forward and change over time. This happens to be a change that
leaves nouveau behind. As a spare-time contributor, I can't keep up
with multiple full timers. I had hoped that there'd be some way to
make it all still work, but that doesn't seem to be the case.
Unfortunately end users are going to lose out on functionality as a
result.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Ilia Mirkin]

On Wed, Sep 14, 2016 at 10:15 PM, Michel Dänzer  wrote:
>> This shouldn't be too hard - just make the compositor output to a temporary
>> surface before copying things out to the prime-shareable one.
>
> You mean something like https://patchwork.freedesktop.org/patch/110375/ ?

Something like that, but presumably something would have to be applied
to st/vdpau so that it doesn't create its output surfaces with the
PIPE_BIND_SHARED flag either.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Michel Dänzer]

On 15/09/16 11:01 AM, Ilia Mirkin wrote:
> On Wed, Sep 14, 2016 at 9:42 PM, Michel Dänzer  wrote:
>> On 15/09/16 08:20 AM, Ilia Mirkin wrote:
>>> On Wed, Sep 7, 2016 at 12:06 PM, Marek Olšák  wrote:
 On Wed, Sep 7, 2016 at 5:36 PM, Ilia Mirkin  wrote:
> On Wed, Sep 7, 2016 at 4:08 AM, Michel Dänzer  wrote:
>> On 07/09/16 04:19 AM, Christian König wrote:
>>> Am 06.09.2016 um 21:05 schrieb Ilia Mirkin:
 On Tue, Sep 6, 2016 at 2:22 PM, Christian König
  wrote:
> Am 06.09.2016 um 16:23 schrieb Ilia Mirkin:
>> On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer 
>> wrote:
>>> On 05/09/16 04:37 AM, Ilia Mirkin wrote:
 On Tue, Mar 8, 2016 at 7:21 AM, Christian König
  wrote:
> @@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>   res_tmpl.depth0 = 1;
>   res_tmpl.array_size = 1;
>   res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW |
> PIPE_BIND_RENDER_TARGET |
> -   PIPE_BIND_LINEAR;
> +   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
 Hi Christian,

 This change appears to have semi-broken vdpau on nouveau. Whenever 
 I
 flip on the OSD in mplayer, the rendering becomes *extremely* slow.
 However regular up-scaling without the OSD is plenty fast. This
 effectively is forcing the output surfaces to live in GART instead 
 of
 VRAM.
>>> Strictly speaking, they'd only need to be forced to GART while 
>>> they're
>>> actually being shared between different GPUs. That's how it works 
>>> with
>>> the amdgpu and radeon kernel drivers.
>> Any suggestions on how to handle this? Perhaps reallocate + copy the
>> surface in st/vdpau when actual dmabuf sharing is requested?
>>
>> To be clear - with this change, vdpau with nouveau is unusable in the
>> presence of an OSD in mplayer. The OSD comes up whenever you seek
>> around in the video, so in effect, it's unusable. Used to work great.
>
> Well I think you should clearly figure out why adding
> PIPE_BIND_SHARED has
> such dramatic effect.
 Because the buffer goes into GART. And then you try to blend on it,
 which involves readback from GART (that's how the functions OSD is
 based on work, I believe). We normally don't allocate renderable
 surfaces or textures in GART.

> We not only need this for DMA-buf based interop, but also for the
> DRI3 based
> sharing of buffers with X.
>
> So that clearly sounds like a bug in nouveau to me.
 OK, so SHARED != GART? With nouveau, buffers are placed statically in
 either VRAM or GART, so I think that if it's shared it has to end up
 in GART, no?
>>>
>>> As far as I understand it no. Shared just means that we can share it
>>> between applications, doesn't it? Or does it mean the buffer should be
>>> shareable between GPUs?
>>>
>>> Could be that my understanding was wrong and so if it's the later feel
>>> free to provide a patch to just remove the flag.
>>>
 I'm pretty weak on all these concepts, as well as how the DRI3 stuff
 works, unfortunately.
>>>
>>> I have to confess I'm not so deeply into this stuff either. Marek,
>>> Michel what exactly is the meaning of the flag?
>>
>> According to src/gallium/docs/source/screen.rst:
>>
>> * ``PIPE_BIND_SHARED``: A sharable buffer that can be given to another
>>   process.
>>
>> It's also used e.g. for buffers shared via DRI3. So I'm afraid this is
>> something nouveau has to deal with better.
>
> Any suggestions that don't involve rewriting nouveau bo handling at
> every level (kernel, ddx, mesa)?
>
> Otherwise I'll send a revert for this change.

 PIPE_BIND_SHARED means texture_get_handle is expected to be used on
 the resource, meaning that inter-API, inter-process, or inter-device
 sharing is possible. All window back buffers should have the flag. If
 they don't, it's a bug. If the flag causes nouveau to put the buffer
 in GART, it's a bug too. There is no reason to use GART for inter-API
 and inter-process sharing like VDPAU and DRI3 are.

 To be honest, the flag is pratically useless with respect to EGL and
 VDPAU, which allow sharing almost any texture.

 I suggest you fix nouveau. The first step would be to become less
 dependent on BIND flags whose existence is already questionable.
>>>
>>> As I suspected, merely flipping away from using 

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Ilia Mirkin]

On Wed, Sep 14, 2016 at 9:42 PM, Michel Dänzer  wrote:
> On 15/09/16 08:20 AM, Ilia Mirkin wrote:
>> On Wed, Sep 7, 2016 at 12:06 PM, Marek Olšák  wrote:
>>> On Wed, Sep 7, 2016 at 5:36 PM, Ilia Mirkin  wrote:
 On Wed, Sep 7, 2016 at 4:08 AM, Michel Dänzer  wrote:
> On 07/09/16 04:19 AM, Christian König wrote:
>> Am 06.09.2016 um 21:05 schrieb Ilia Mirkin:
>>> On Tue, Sep 6, 2016 at 2:22 PM, Christian König
>>>  wrote:
 Am 06.09.2016 um 16:23 schrieb Ilia Mirkin:
> On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer 
> wrote:
>> On 05/09/16 04:37 AM, Ilia Mirkin wrote:
>>> On Tue, Mar 8, 2016 at 7:21 AM, Christian König
>>>  wrote:
 @@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
   res_tmpl.depth0 = 1;
   res_tmpl.array_size = 1;
   res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW |
 PIPE_BIND_RENDER_TARGET |
 -   PIPE_BIND_LINEAR;
 +   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
>>> Hi Christian,
>>>
>>> This change appears to have semi-broken vdpau on nouveau. Whenever I
>>> flip on the OSD in mplayer, the rendering becomes *extremely* slow.
>>> However regular up-scaling without the OSD is plenty fast. This
>>> effectively is forcing the output surfaces to live in GART instead 
>>> of
>>> VRAM.
>> Strictly speaking, they'd only need to be forced to GART while 
>> they're
>> actually being shared between different GPUs. That's how it works 
>> with
>> the amdgpu and radeon kernel drivers.
> Any suggestions on how to handle this? Perhaps reallocate + copy the
> surface in st/vdpau when actual dmabuf sharing is requested?
>
> To be clear - with this change, vdpau with nouveau is unusable in the
> presence of an OSD in mplayer. The OSD comes up whenever you seek
> around in the video, so in effect, it's unusable. Used to work great.

 Well I think you should clearly figure out why adding
 PIPE_BIND_SHARED has
 such dramatic effect.
>>> Because the buffer goes into GART. And then you try to blend on it,
>>> which involves readback from GART (that's how the functions OSD is
>>> based on work, I believe). We normally don't allocate renderable
>>> surfaces or textures in GART.
>>>
 We not only need this for DMA-buf based interop, but also for the
 DRI3 based
 sharing of buffers with X.

 So that clearly sounds like a bug in nouveau to me.
>>> OK, so SHARED != GART? With nouveau, buffers are placed statically in
>>> either VRAM or GART, so I think that if it's shared it has to end up
>>> in GART, no?
>>
>> As far as I understand it no. Shared just means that we can share it
>> between applications, doesn't it? Or does it mean the buffer should be
>> shareable between GPUs?
>>
>> Could be that my understanding was wrong and so if it's the later feel
>> free to provide a patch to just remove the flag.
>>
>>> I'm pretty weak on all these concepts, as well as how the DRI3 stuff
>>> works, unfortunately.
>>
>> I have to confess I'm not so deeply into this stuff either. Marek,
>> Michel what exactly is the meaning of the flag?
>
> According to src/gallium/docs/source/screen.rst:
>
> * ``PIPE_BIND_SHARED``: A sharable buffer that can be given to another
>   process.
>
> It's also used e.g. for buffers shared via DRI3. So I'm afraid this is
> something nouveau has to deal with better.

 Any suggestions that don't involve rewriting nouveau bo handling at
 every level (kernel, ddx, mesa)?

 Otherwise I'll send a revert for this change.
>>>
>>> PIPE_BIND_SHARED means texture_get_handle is expected to be used on
>>> the resource, meaning that inter-API, inter-process, or inter-device
>>> sharing is possible. All window back buffers should have the flag. If
>>> they don't, it's a bug. If the flag causes nouveau to put the buffer
>>> in GART, it's a bug too. There is no reason to use GART for inter-API
>>> and inter-process sharing like VDPAU and DRI3 are.
>>>
>>> To be honest, the flag is pratically useless with respect to EGL and
>>> VDPAU, which allow sharing almost any texture.
>>>
>>> I suggest you fix nouveau. The first step would be to become less
>>> dependent on BIND flags whose existence is already questionable.
>>
>> As I suspected, merely flipping away from using PIPE_BIND_SHARED
>> doesn't work. By flipping the logic like this:
>>
>> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
>> 

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Michel Dänzer]

On 15/09/16 08:20 AM, Ilia Mirkin wrote:
> On Wed, Sep 7, 2016 at 12:06 PM, Marek Olšák  wrote:
>> On Wed, Sep 7, 2016 at 5:36 PM, Ilia Mirkin  wrote:
>>> On Wed, Sep 7, 2016 at 4:08 AM, Michel Dänzer  wrote:
 On 07/09/16 04:19 AM, Christian König wrote:
> Am 06.09.2016 um 21:05 schrieb Ilia Mirkin:
>> On Tue, Sep 6, 2016 at 2:22 PM, Christian König
>>  wrote:
>>> Am 06.09.2016 um 16:23 schrieb Ilia Mirkin:
 On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer 
 wrote:
> On 05/09/16 04:37 AM, Ilia Mirkin wrote:
>> On Tue, Mar 8, 2016 at 7:21 AM, Christian König
>>  wrote:
>>> @@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>>>   res_tmpl.depth0 = 1;
>>>   res_tmpl.array_size = 1;
>>>   res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW |
>>> PIPE_BIND_RENDER_TARGET |
>>> -   PIPE_BIND_LINEAR;
>>> +   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
>> Hi Christian,
>>
>> This change appears to have semi-broken vdpau on nouveau. Whenever I
>> flip on the OSD in mplayer, the rendering becomes *extremely* slow.
>> However regular up-scaling without the OSD is plenty fast. This
>> effectively is forcing the output surfaces to live in GART instead of
>> VRAM.
> Strictly speaking, they'd only need to be forced to GART while they're
> actually being shared between different GPUs. That's how it works with
> the amdgpu and radeon kernel drivers.
 Any suggestions on how to handle this? Perhaps reallocate + copy the
 surface in st/vdpau when actual dmabuf sharing is requested?

 To be clear - with this change, vdpau with nouveau is unusable in the
 presence of an OSD in mplayer. The OSD comes up whenever you seek
 around in the video, so in effect, it's unusable. Used to work great.
>>>
>>> Well I think you should clearly figure out why adding
>>> PIPE_BIND_SHARED has
>>> such dramatic effect.
>> Because the buffer goes into GART. And then you try to blend on it,
>> which involves readback from GART (that's how the functions OSD is
>> based on work, I believe). We normally don't allocate renderable
>> surfaces or textures in GART.
>>
>>> We not only need this for DMA-buf based interop, but also for the
>>> DRI3 based
>>> sharing of buffers with X.
>>>
>>> So that clearly sounds like a bug in nouveau to me.
>> OK, so SHARED != GART? With nouveau, buffers are placed statically in
>> either VRAM or GART, so I think that if it's shared it has to end up
>> in GART, no?
>
> As far as I understand it no. Shared just means that we can share it
> between applications, doesn't it? Or does it mean the buffer should be
> shareable between GPUs?
>
> Could be that my understanding was wrong and so if it's the later feel
> free to provide a patch to just remove the flag.
>
>> I'm pretty weak on all these concepts, as well as how the DRI3 stuff
>> works, unfortunately.
>
> I have to confess I'm not so deeply into this stuff either. Marek,
> Michel what exactly is the meaning of the flag?

 According to src/gallium/docs/source/screen.rst:

 * ``PIPE_BIND_SHARED``: A sharable buffer that can be given to another
   process.

 It's also used e.g. for buffers shared via DRI3. So I'm afraid this is
 something nouveau has to deal with better.
>>>
>>> Any suggestions that don't involve rewriting nouveau bo handling at
>>> every level (kernel, ddx, mesa)?
>>>
>>> Otherwise I'll send a revert for this change.
>>
>> PIPE_BIND_SHARED means texture_get_handle is expected to be used on
>> the resource, meaning that inter-API, inter-process, or inter-device
>> sharing is possible. All window back buffers should have the flag. If
>> they don't, it's a bug. If the flag causes nouveau to put the buffer
>> in GART, it's a bug too. There is no reason to use GART for inter-API
>> and inter-process sharing like VDPAU and DRI3 are.
>>
>> To be honest, the flag is pratically useless with respect to EGL and
>> VDPAU, which allow sharing almost any texture.
>>
>> I suggest you fix nouveau. The first step would be to become less
>> dependent on BIND flags whose existence is already questionable.
> 
> As I suspected, merely flipping away from using PIPE_BIND_SHARED
> doesn't work. By flipping the logic like this:
> 
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
> b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
> index f2e304f..5532794 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
> @@ -377,7 +377,8 @@ nv50_miptree_create(struct 

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Ilia Mirkin]

On Wed, Sep 7, 2016 at 12:06 PM, Marek Olšák  wrote:
> On Wed, Sep 7, 2016 at 5:36 PM, Ilia Mirkin  wrote:
>> On Wed, Sep 7, 2016 at 4:08 AM, Michel Dänzer  wrote:
>>> On 07/09/16 04:19 AM, Christian König wrote:
 Am 06.09.2016 um 21:05 schrieb Ilia Mirkin:
> On Tue, Sep 6, 2016 at 2:22 PM, Christian König
>  wrote:
>> Am 06.09.2016 um 16:23 schrieb Ilia Mirkin:
>>> On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer 
>>> wrote:
 On 05/09/16 04:37 AM, Ilia Mirkin wrote:
> On Tue, Mar 8, 2016 at 7:21 AM, Christian König
>  wrote:
>> @@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>>   res_tmpl.depth0 = 1;
>>   res_tmpl.array_size = 1;
>>   res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW |
>> PIPE_BIND_RENDER_TARGET |
>> -   PIPE_BIND_LINEAR;
>> +   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
> Hi Christian,
>
> This change appears to have semi-broken vdpau on nouveau. Whenever I
> flip on the OSD in mplayer, the rendering becomes *extremely* slow.
> However regular up-scaling without the OSD is plenty fast. This
> effectively is forcing the output surfaces to live in GART instead of
> VRAM.
 Strictly speaking, they'd only need to be forced to GART while they're
 actually being shared between different GPUs. That's how it works with
 the amdgpu and radeon kernel drivers.
>>> Any suggestions on how to handle this? Perhaps reallocate + copy the
>>> surface in st/vdpau when actual dmabuf sharing is requested?
>>>
>>> To be clear - with this change, vdpau with nouveau is unusable in the
>>> presence of an OSD in mplayer. The OSD comes up whenever you seek
>>> around in the video, so in effect, it's unusable. Used to work great.
>>
>> Well I think you should clearly figure out why adding
>> PIPE_BIND_SHARED has
>> such dramatic effect.
> Because the buffer goes into GART. And then you try to blend on it,
> which involves readback from GART (that's how the functions OSD is
> based on work, I believe). We normally don't allocate renderable
> surfaces or textures in GART.
>
>> We not only need this for DMA-buf based interop, but also for the
>> DRI3 based
>> sharing of buffers with X.
>>
>> So that clearly sounds like a bug in nouveau to me.
> OK, so SHARED != GART? With nouveau, buffers are placed statically in
> either VRAM or GART, so I think that if it's shared it has to end up
> in GART, no?

 As far as I understand it no. Shared just means that we can share it
 between applications, doesn't it? Or does it mean the buffer should be
 shareable between GPUs?

 Could be that my understanding was wrong and so if it's the later feel
 free to provide a patch to just remove the flag.

> I'm pretty weak on all these concepts, as well as how the DRI3 stuff
> works, unfortunately.

 I have to confess I'm not so deeply into this stuff either. Marek,
 Michel what exactly is the meaning of the flag?
>>>
>>> According to src/gallium/docs/source/screen.rst:
>>>
>>> * ``PIPE_BIND_SHARED``: A sharable buffer that can be given to another
>>>   process.
>>>
>>> It's also used e.g. for buffers shared via DRI3. So I'm afraid this is
>>> something nouveau has to deal with better.
>>
>> Any suggestions that don't involve rewriting nouveau bo handling at
>> every level (kernel, ddx, mesa)?
>>
>> Otherwise I'll send a revert for this change.
>
> PIPE_BIND_SHARED means texture_get_handle is expected to be used on
> the resource, meaning that inter-API, inter-process, or inter-device
> sharing is possible. All window back buffers should have the flag. If
> they don't, it's a bug. If the flag causes nouveau to put the buffer
> in GART, it's a bug too. There is no reason to use GART for inter-API
> and inter-process sharing like VDPAU and DRI3 are.
>
> To be honest, the flag is pratically useless with respect to EGL and
> VDPAU, which allow sharing almost any texture.
>
> I suggest you fix nouveau. The first step would be to become less
> dependent on BIND flags whose existence is already questionable.

As I suspected, merely flipping away from using PIPE_BIND_SHARED
doesn't work. By flipping the logic like this:

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
index f2e304f..5532794 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
@@ -377,7 +377,8 @@ nv50_miptree_create(struct pipe_screen *pscreen,
}
bo_config.nv50.tile_mode = mt->level[0].tile_mode;

-   if (!bo_config.nv50.memtype && (pt->bind & PIPE_BIND_SHARED))
+   

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Bas Nieuwenhuizen]

On Wed, Sep 7, 2016 at 6:23 PM, Christian König  wrote:
> Am 07.09.2016 um 18:06 schrieb Marek Olšák:
>>
>> On Wed, Sep 7, 2016 at 5:36 PM, Ilia Mirkin  wrote:
>>>
>>> On Wed, Sep 7, 2016 at 4:08 AM, Michel Dänzer  wrote:

 On 07/09/16 04:19 AM, Christian König wrote:
>
> Am 06.09.2016 um 21:05 schrieb Ilia Mirkin:
>>
>> On Tue, Sep 6, 2016 at 2:22 PM, Christian König
>>  wrote:
>>>
>>> Am 06.09.2016 um 16:23 schrieb Ilia Mirkin:

 On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer 
 wrote:
>
> On 05/09/16 04:37 AM, Ilia Mirkin wrote:
>>
>> On Tue, Mar 8, 2016 at 7:21 AM, Christian König
>>  wrote:
>>>
>>> @@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>>>res_tmpl.depth0 = 1;
>>>res_tmpl.array_size = 1;
>>>res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW |
>>> PIPE_BIND_RENDER_TARGET |
>>> -   PIPE_BIND_LINEAR;
>>> +   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
>>
>> Hi Christian,
>>
>> This change appears to have semi-broken vdpau on nouveau. Whenever
>> I
>> flip on the OSD in mplayer, the rendering becomes *extremely*
>> slow.
>> However regular up-scaling without the OSD is plenty fast. This
>> effectively is forcing the output surfaces to live in GART instead
>> of
>> VRAM.
>
> Strictly speaking, they'd only need to be forced to GART while
> they're
> actually being shared between different GPUs. That's how it works
> with
> the amdgpu and radeon kernel drivers.

 Any suggestions on how to handle this? Perhaps reallocate + copy the
 surface in st/vdpau when actual dmabuf sharing is requested?

 To be clear - with this change, vdpau with nouveau is unusable in
 the
 presence of an OSD in mplayer. The OSD comes up whenever you seek
 around in the video, so in effect, it's unusable. Used to work
 great.
>>>
>>> Well I think you should clearly figure out why adding
>>> PIPE_BIND_SHARED has
>>> such dramatic effect.
>>
>> Because the buffer goes into GART. And then you try to blend on it,
>> which involves readback from GART (that's how the functions OSD is
>> based on work, I believe). We normally don't allocate renderable
>> surfaces or textures in GART.
>>
>>> We not only need this for DMA-buf based interop, but also for the
>>> DRI3 based
>>> sharing of buffers with X.
>>>
>>> So that clearly sounds like a bug in nouveau to me.
>>
>> OK, so SHARED != GART? With nouveau, buffers are placed statically in
>> either VRAM or GART, so I think that if it's shared it has to end up
>> in GART, no?
>
> As far as I understand it no. Shared just means that we can share it
> between applications, doesn't it? Or does it mean the buffer should be
> shareable between GPUs?
>
> Could be that my understanding was wrong and so if it's the later feel
> free to provide a patch to just remove the flag.
>
>> I'm pretty weak on all these concepts, as well as how the DRI3 stuff
>> works, unfortunately.
>
> I have to confess I'm not so deeply into this stuff either. Marek,
> Michel what exactly is the meaning of the flag?

 According to src/gallium/docs/source/screen.rst:

 * ``PIPE_BIND_SHARED``: A sharable buffer that can be given to another
process.

 It's also used e.g. for buffers shared via DRI3. So I'm afraid this is
 something nouveau has to deal with better.
>>>
>>> Any suggestions that don't involve rewriting nouveau bo handling at
>>> every level (kernel, ddx, mesa)?
>>>
>>> Otherwise I'll send a revert for this change.
>>
>> PIPE_BIND_SHARED means texture_get_handle is expected to be used on
>> the resource, meaning that inter-API, inter-process, or inter-device
>> sharing is possible. All window back buffers should have the flag. If
>> they don't, it's a bug. If the flag causes nouveau to put the buffer
>> in GART, it's a bug too. There is no reason to use GART for inter-API
>> and inter-process sharing like VDPAU and DRI3 are.
>>
>> To be honest, the flag is pratically useless with respect to EGL and
>> VDPAU, which allow sharing almost any texture.
>
>
> Actually I can think of a very good use case for the kernel where I could
> reduce the per command submission / per BO handle overhead significantly if
> we could mark BOs which are never shared between applications as such.
>

We could use that for vulkan, as memory allocations are not shareable
by default, and hence can implement a reliable shared or 

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Christian König]

Am 07.09.2016 um 18:06 schrieb Marek Olšák:

On Wed, Sep 7, 2016 at 5:36 PM, Ilia Mirkin  wrote:

On Wed, Sep 7, 2016 at 4:08 AM, Michel Dänzer  wrote:

On 07/09/16 04:19 AM, Christian König wrote:

Am 06.09.2016 um 21:05 schrieb Ilia Mirkin:

On Tue, Sep 6, 2016 at 2:22 PM, Christian König
 wrote:

Am 06.09.2016 um 16:23 schrieb Ilia Mirkin:

On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer 
wrote:

On 05/09/16 04:37 AM, Ilia Mirkin wrote:

On Tue, Mar 8, 2016 at 7:21 AM, Christian König
 wrote:

@@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
   res_tmpl.depth0 = 1;
   res_tmpl.array_size = 1;
   res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW |
PIPE_BIND_RENDER_TARGET |
-   PIPE_BIND_LINEAR;
+   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;

Hi Christian,

This change appears to have semi-broken vdpau on nouveau. Whenever I
flip on the OSD in mplayer, the rendering becomes *extremely* slow.
However regular up-scaling without the OSD is plenty fast. This
effectively is forcing the output surfaces to live in GART instead of
VRAM.

Strictly speaking, they'd only need to be forced to GART while they're
actually being shared between different GPUs. That's how it works with
the amdgpu and radeon kernel drivers.

Any suggestions on how to handle this? Perhaps reallocate + copy the
surface in st/vdpau when actual dmabuf sharing is requested?

To be clear - with this change, vdpau with nouveau is unusable in the
presence of an OSD in mplayer. The OSD comes up whenever you seek
around in the video, so in effect, it's unusable. Used to work great.

Well I think you should clearly figure out why adding
PIPE_BIND_SHARED has
such dramatic effect.

Because the buffer goes into GART. And then you try to blend on it,
which involves readback from GART (that's how the functions OSD is
based on work, I believe). We normally don't allocate renderable
surfaces or textures in GART.


We not only need this for DMA-buf based interop, but also for the
DRI3 based
sharing of buffers with X.

So that clearly sounds like a bug in nouveau to me.

OK, so SHARED != GART? With nouveau, buffers are placed statically in
either VRAM or GART, so I think that if it's shared it has to end up
in GART, no?

As far as I understand it no. Shared just means that we can share it
between applications, doesn't it? Or does it mean the buffer should be
shareable between GPUs?

Could be that my understanding was wrong and so if it's the later feel
free to provide a patch to just remove the flag.


I'm pretty weak on all these concepts, as well as how the DRI3 stuff
works, unfortunately.

I have to confess I'm not so deeply into this stuff either. Marek,
Michel what exactly is the meaning of the flag?

According to src/gallium/docs/source/screen.rst:

* ``PIPE_BIND_SHARED``: A sharable buffer that can be given to another
   process.

It's also used e.g. for buffers shared via DRI3. So I'm afraid this is
something nouveau has to deal with better.

Any suggestions that don't involve rewriting nouveau bo handling at
every level (kernel, ddx, mesa)?

Otherwise I'll send a revert for this change.

PIPE_BIND_SHARED means texture_get_handle is expected to be used on
the resource, meaning that inter-API, inter-process, or inter-device
sharing is possible. All window back buffers should have the flag. If
they don't, it's a bug. If the flag causes nouveau to put the buffer
in GART, it's a bug too. There is no reason to use GART for inter-API
and inter-process sharing like VDPAU and DRI3 are.

To be honest, the flag is pratically useless with respect to EGL and
VDPAU, which allow sharing almost any texture.


Actually I can think of a very good use case for the kernel where I 
could reduce the per command submission / per BO handle overhead 
significantly if we could mark BOs which are never shared between 
applications as such.


Christian.



I suggest you fix nouveau. The first step would be to become less
dependent on BIND flags whose existence is already questionable.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Christian König]

Am 07.09.2016 um 17:36 schrieb Ilia Mirkin:

On Wed, Sep 7, 2016 at 4:08 AM, Michel Dänzer  wrote:

On 07/09/16 04:19 AM, Christian König wrote:

Am 06.09.2016 um 21:05 schrieb Ilia Mirkin:

On Tue, Sep 6, 2016 at 2:22 PM, Christian König
 wrote:

Am 06.09.2016 um 16:23 schrieb Ilia Mirkin:

On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer 
wrote:

On 05/09/16 04:37 AM, Ilia Mirkin wrote:

On Tue, Mar 8, 2016 at 7:21 AM, Christian König
 wrote:

@@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
   res_tmpl.depth0 = 1;
   res_tmpl.array_size = 1;
   res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW |
PIPE_BIND_RENDER_TARGET |
-   PIPE_BIND_LINEAR;
+   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;

Hi Christian,

This change appears to have semi-broken vdpau on nouveau. Whenever I
flip on the OSD in mplayer, the rendering becomes *extremely* slow.
However regular up-scaling without the OSD is plenty fast. This
effectively is forcing the output surfaces to live in GART instead of
VRAM.

Strictly speaking, they'd only need to be forced to GART while they're
actually being shared between different GPUs. That's how it works with
the amdgpu and radeon kernel drivers.

Any suggestions on how to handle this? Perhaps reallocate + copy the
surface in st/vdpau when actual dmabuf sharing is requested?

To be clear - with this change, vdpau with nouveau is unusable in the
presence of an OSD in mplayer. The OSD comes up whenever you seek
around in the video, so in effect, it's unusable. Used to work great.

Well I think you should clearly figure out why adding
PIPE_BIND_SHARED has
such dramatic effect.

Because the buffer goes into GART. And then you try to blend on it,
which involves readback from GART (that's how the functions OSD is
based on work, I believe). We normally don't allocate renderable
surfaces or textures in GART.


We not only need this for DMA-buf based interop, but also for the
DRI3 based
sharing of buffers with X.

So that clearly sounds like a bug in nouveau to me.

OK, so SHARED != GART? With nouveau, buffers are placed statically in
either VRAM or GART, so I think that if it's shared it has to end up
in GART, no?

As far as I understand it no. Shared just means that we can share it
between applications, doesn't it? Or does it mean the buffer should be
shareable between GPUs?

Could be that my understanding was wrong and so if it's the later feel
free to provide a patch to just remove the flag.


I'm pretty weak on all these concepts, as well as how the DRI3 stuff
works, unfortunately.

I have to confess I'm not so deeply into this stuff either. Marek,
Michel what exactly is the meaning of the flag?

According to src/gallium/docs/source/screen.rst:

* ``PIPE_BIND_SHARED``: A sharable buffer that can be given to another
   process.

It's also used e.g. for buffers shared via DRI3. So I'm afraid this is
something nouveau has to deal with better.

Any suggestions that don't involve rewriting nouveau bo handling at
every level (kernel, ddx, mesa)?


Either just ignore the flag or handle it better, but it's current effect 
of placing buffers into GART is certainly completely wrong and not only 
in this use case.


Regards,
Christian.



Otherwise I'll send a revert for this change.

   -ilia



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Marek Olšák]

On Wed, Sep 7, 2016 at 5:36 PM, Ilia Mirkin  wrote:
> On Wed, Sep 7, 2016 at 4:08 AM, Michel Dänzer  wrote:
>> On 07/09/16 04:19 AM, Christian König wrote:
>>> Am 06.09.2016 um 21:05 schrieb Ilia Mirkin:
 On Tue, Sep 6, 2016 at 2:22 PM, Christian König
  wrote:
> Am 06.09.2016 um 16:23 schrieb Ilia Mirkin:
>> On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer 
>> wrote:
>>> On 05/09/16 04:37 AM, Ilia Mirkin wrote:
 On Tue, Mar 8, 2016 at 7:21 AM, Christian König
  wrote:
> @@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>   res_tmpl.depth0 = 1;
>   res_tmpl.array_size = 1;
>   res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW |
> PIPE_BIND_RENDER_TARGET |
> -   PIPE_BIND_LINEAR;
> +   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
 Hi Christian,

 This change appears to have semi-broken vdpau on nouveau. Whenever I
 flip on the OSD in mplayer, the rendering becomes *extremely* slow.
 However regular up-scaling without the OSD is plenty fast. This
 effectively is forcing the output surfaces to live in GART instead of
 VRAM.
>>> Strictly speaking, they'd only need to be forced to GART while they're
>>> actually being shared between different GPUs. That's how it works with
>>> the amdgpu and radeon kernel drivers.
>> Any suggestions on how to handle this? Perhaps reallocate + copy the
>> surface in st/vdpau when actual dmabuf sharing is requested?
>>
>> To be clear - with this change, vdpau with nouveau is unusable in the
>> presence of an OSD in mplayer. The OSD comes up whenever you seek
>> around in the video, so in effect, it's unusable. Used to work great.
>
> Well I think you should clearly figure out why adding
> PIPE_BIND_SHARED has
> such dramatic effect.
 Because the buffer goes into GART. And then you try to blend on it,
 which involves readback from GART (that's how the functions OSD is
 based on work, I believe). We normally don't allocate renderable
 surfaces or textures in GART.

> We not only need this for DMA-buf based interop, but also for the
> DRI3 based
> sharing of buffers with X.
>
> So that clearly sounds like a bug in nouveau to me.
 OK, so SHARED != GART? With nouveau, buffers are placed statically in
 either VRAM or GART, so I think that if it's shared it has to end up
 in GART, no?
>>>
>>> As far as I understand it no. Shared just means that we can share it
>>> between applications, doesn't it? Or does it mean the buffer should be
>>> shareable between GPUs?
>>>
>>> Could be that my understanding was wrong and so if it's the later feel
>>> free to provide a patch to just remove the flag.
>>>
 I'm pretty weak on all these concepts, as well as how the DRI3 stuff
 works, unfortunately.
>>>
>>> I have to confess I'm not so deeply into this stuff either. Marek,
>>> Michel what exactly is the meaning of the flag?
>>
>> According to src/gallium/docs/source/screen.rst:
>>
>> * ``PIPE_BIND_SHARED``: A sharable buffer that can be given to another
>>   process.
>>
>> It's also used e.g. for buffers shared via DRI3. So I'm afraid this is
>> something nouveau has to deal with better.
>
> Any suggestions that don't involve rewriting nouveau bo handling at
> every level (kernel, ddx, mesa)?
>
> Otherwise I'll send a revert for this change.

PIPE_BIND_SHARED means texture_get_handle is expected to be used on
the resource, meaning that inter-API, inter-process, or inter-device
sharing is possible. All window back buffers should have the flag. If
they don't, it's a bug. If the flag causes nouveau to put the buffer
in GART, it's a bug too. There is no reason to use GART for inter-API
and inter-process sharing like VDPAU and DRI3 are.

To be honest, the flag is pratically useless with respect to EGL and
VDPAU, which allow sharing almost any texture.

I suggest you fix nouveau. The first step would be to become less
dependent on BIND flags whose existence is already questionable.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Ilia Mirkin]

On Wed, Sep 7, 2016 at 4:08 AM, Michel Dänzer  wrote:
> On 07/09/16 04:19 AM, Christian König wrote:
>> Am 06.09.2016 um 21:05 schrieb Ilia Mirkin:
>>> On Tue, Sep 6, 2016 at 2:22 PM, Christian König
>>>  wrote:
 Am 06.09.2016 um 16:23 schrieb Ilia Mirkin:
> On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer 
> wrote:
>> On 05/09/16 04:37 AM, Ilia Mirkin wrote:
>>> On Tue, Mar 8, 2016 at 7:21 AM, Christian König
>>>  wrote:
 @@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
   res_tmpl.depth0 = 1;
   res_tmpl.array_size = 1;
   res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW |
 PIPE_BIND_RENDER_TARGET |
 -   PIPE_BIND_LINEAR;
 +   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
>>> Hi Christian,
>>>
>>> This change appears to have semi-broken vdpau on nouveau. Whenever I
>>> flip on the OSD in mplayer, the rendering becomes *extremely* slow.
>>> However regular up-scaling without the OSD is plenty fast. This
>>> effectively is forcing the output surfaces to live in GART instead of
>>> VRAM.
>> Strictly speaking, they'd only need to be forced to GART while they're
>> actually being shared between different GPUs. That's how it works with
>> the amdgpu and radeon kernel drivers.
> Any suggestions on how to handle this? Perhaps reallocate + copy the
> surface in st/vdpau when actual dmabuf sharing is requested?
>
> To be clear - with this change, vdpau with nouveau is unusable in the
> presence of an OSD in mplayer. The OSD comes up whenever you seek
> around in the video, so in effect, it's unusable. Used to work great.

 Well I think you should clearly figure out why adding
 PIPE_BIND_SHARED has
 such dramatic effect.
>>> Because the buffer goes into GART. And then you try to blend on it,
>>> which involves readback from GART (that's how the functions OSD is
>>> based on work, I believe). We normally don't allocate renderable
>>> surfaces or textures in GART.
>>>
 We not only need this for DMA-buf based interop, but also for the
 DRI3 based
 sharing of buffers with X.

 So that clearly sounds like a bug in nouveau to me.
>>> OK, so SHARED != GART? With nouveau, buffers are placed statically in
>>> either VRAM or GART, so I think that if it's shared it has to end up
>>> in GART, no?
>>
>> As far as I understand it no. Shared just means that we can share it
>> between applications, doesn't it? Or does it mean the buffer should be
>> shareable between GPUs?
>>
>> Could be that my understanding was wrong and so if it's the later feel
>> free to provide a patch to just remove the flag.
>>
>>> I'm pretty weak on all these concepts, as well as how the DRI3 stuff
>>> works, unfortunately.
>>
>> I have to confess I'm not so deeply into this stuff either. Marek,
>> Michel what exactly is the meaning of the flag?
>
> According to src/gallium/docs/source/screen.rst:
>
> * ``PIPE_BIND_SHARED``: A sharable buffer that can be given to another
>   process.
>
> It's also used e.g. for buffers shared via DRI3. So I'm afraid this is
> something nouveau has to deal with better.

Any suggestions that don't involve rewriting nouveau bo handling at
every level (kernel, ddx, mesa)?

Otherwise I'll send a revert for this change.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Marek Olšák]

On Tue, Sep 6, 2016 at 9:19 PM, Christian König  wrote:
> Am 06.09.2016 um 21:05 schrieb Ilia Mirkin:
>>
>> On Tue, Sep 6, 2016 at 2:22 PM, Christian König 
>> wrote:
>>>
>>> Am 06.09.2016 um 16:23 schrieb Ilia Mirkin:

 On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer 
 wrote:
>
> On 05/09/16 04:37 AM, Ilia Mirkin wrote:
>>
>> On Tue, Mar 8, 2016 at 7:21 AM, Christian König
>>  wrote:
>>>
>>> @@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>>>   res_tmpl.depth0 = 1;
>>>   res_tmpl.array_size = 1;
>>>   res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW |
>>> PIPE_BIND_RENDER_TARGET |
>>> -   PIPE_BIND_LINEAR;
>>> +   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
>>
>> Hi Christian,
>>
>> This change appears to have semi-broken vdpau on nouveau. Whenever I
>> flip on the OSD in mplayer, the rendering becomes *extremely* slow.
>> However regular up-scaling without the OSD is plenty fast. This
>> effectively is forcing the output surfaces to live in GART instead of
>> VRAM.
>
> Strictly speaking, they'd only need to be forced to GART while they're
> actually being shared between different GPUs. That's how it works with
> the amdgpu and radeon kernel drivers.

 Any suggestions on how to handle this? Perhaps reallocate + copy the
 surface in st/vdpau when actual dmabuf sharing is requested?

 To be clear - with this change, vdpau with nouveau is unusable in the
 presence of an OSD in mplayer. The OSD comes up whenever you seek
 around in the video, so in effect, it's unusable. Used to work great.
>>>
>>>
>>> Well I think you should clearly figure out why adding PIPE_BIND_SHARED
>>> has
>>> such dramatic effect.
>>
>> Because the buffer goes into GART. And then you try to blend on it,
>> which involves readback from GART (that's how the functions OSD is
>> based on work, I believe). We normally don't allocate renderable
>> surfaces or textures in GART.
>>
>>> We not only need this for DMA-buf based interop, but also for the DRI3
>>> based
>>> sharing of buffers with X.
>>>
>>> So that clearly sounds like a bug in nouveau to me.
>>
>> OK, so SHARED != GART? With nouveau, buffers are placed statically in
>> either VRAM or GART, so I think that if it's shared it has to end up
>> in GART, no?
>
>
> As far as I understand it no. Shared just means that we can share it between
> applications, doesn't it? Or does it mean the buffer should be shareable
> between GPUs?
>
> Could be that my understanding was wrong and so if it's the later feel free
> to provide a patch to just remove the flag.
>
>> I'm pretty weak on all these concepts, as well as how the DRI3 stuff
>> works, unfortunately.
>
>
> I have to confess I'm not so deeply into this stuff either. Marek, Michel
> what exactly is the meaning of the flag?

The flag is virtually useless because all textures can be shared using
the EGL DMABUF extension.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Michel Dänzer]

On 07/09/16 04:19 AM, Christian König wrote:
> Am 06.09.2016 um 21:05 schrieb Ilia Mirkin:
>> On Tue, Sep 6, 2016 at 2:22 PM, Christian König
>>  wrote:
>>> Am 06.09.2016 um 16:23 schrieb Ilia Mirkin:
 On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer 
 wrote:
> On 05/09/16 04:37 AM, Ilia Mirkin wrote:
>> On Tue, Mar 8, 2016 at 7:21 AM, Christian König
>>  wrote:
>>> @@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>>>   res_tmpl.depth0 = 1;
>>>   res_tmpl.array_size = 1;
>>>   res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW |
>>> PIPE_BIND_RENDER_TARGET |
>>> -   PIPE_BIND_LINEAR;
>>> +   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
>> Hi Christian,
>>
>> This change appears to have semi-broken vdpau on nouveau. Whenever I
>> flip on the OSD in mplayer, the rendering becomes *extremely* slow.
>> However regular up-scaling without the OSD is plenty fast. This
>> effectively is forcing the output surfaces to live in GART instead of
>> VRAM.
> Strictly speaking, they'd only need to be forced to GART while they're
> actually being shared between different GPUs. That's how it works with
> the amdgpu and radeon kernel drivers.
 Any suggestions on how to handle this? Perhaps reallocate + copy the
 surface in st/vdpau when actual dmabuf sharing is requested?

 To be clear - with this change, vdpau with nouveau is unusable in the
 presence of an OSD in mplayer. The OSD comes up whenever you seek
 around in the video, so in effect, it's unusable. Used to work great.
>>>
>>> Well I think you should clearly figure out why adding
>>> PIPE_BIND_SHARED has
>>> such dramatic effect.
>> Because the buffer goes into GART. And then you try to blend on it,
>> which involves readback from GART (that's how the functions OSD is
>> based on work, I believe). We normally don't allocate renderable
>> surfaces or textures in GART.
>>
>>> We not only need this for DMA-buf based interop, but also for the
>>> DRI3 based
>>> sharing of buffers with X.
>>>
>>> So that clearly sounds like a bug in nouveau to me.
>> OK, so SHARED != GART? With nouveau, buffers are placed statically in
>> either VRAM or GART, so I think that if it's shared it has to end up
>> in GART, no?
> 
> As far as I understand it no. Shared just means that we can share it
> between applications, doesn't it? Or does it mean the buffer should be
> shareable between GPUs?
> 
> Could be that my understanding was wrong and so if it's the later feel
> free to provide a patch to just remove the flag.
> 
>> I'm pretty weak on all these concepts, as well as how the DRI3 stuff
>> works, unfortunately.
> 
> I have to confess I'm not so deeply into this stuff either. Marek,
> Michel what exactly is the meaning of the flag?

According to src/gallium/docs/source/screen.rst:

* ``PIPE_BIND_SHARED``: A sharable buffer that can be given to another
  process.

It's also used e.g. for buffers shared via DRI3. So I'm afraid this is
something nouveau has to deal with better.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Christian König]

Am 06.09.2016 um 21:05 schrieb Ilia Mirkin:

On Tue, Sep 6, 2016 at 2:22 PM, Christian König  wrote:

Am 06.09.2016 um 16:23 schrieb Ilia Mirkin:

On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer  wrote:

On 05/09/16 04:37 AM, Ilia Mirkin wrote:

On Tue, Mar 8, 2016 at 7:21 AM, Christian König
 wrote:

@@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
  res_tmpl.depth0 = 1;
  res_tmpl.array_size = 1;
  res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET |
-   PIPE_BIND_LINEAR;
+   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;

Hi Christian,

This change appears to have semi-broken vdpau on nouveau. Whenever I
flip on the OSD in mplayer, the rendering becomes *extremely* slow.
However regular up-scaling without the OSD is plenty fast. This
effectively is forcing the output surfaces to live in GART instead of
VRAM.

Strictly speaking, they'd only need to be forced to GART while they're
actually being shared between different GPUs. That's how it works with
the amdgpu and radeon kernel drivers.

Any suggestions on how to handle this? Perhaps reallocate + copy the
surface in st/vdpau when actual dmabuf sharing is requested?

To be clear - with this change, vdpau with nouveau is unusable in the
presence of an OSD in mplayer. The OSD comes up whenever you seek
around in the video, so in effect, it's unusable. Used to work great.


Well I think you should clearly figure out why adding PIPE_BIND_SHARED has
such dramatic effect.

Because the buffer goes into GART. And then you try to blend on it,
which involves readback from GART (that's how the functions OSD is
based on work, I believe). We normally don't allocate renderable
surfaces or textures in GART.


We not only need this for DMA-buf based interop, but also for the DRI3 based
sharing of buffers with X.

So that clearly sounds like a bug in nouveau to me.

OK, so SHARED != GART? With nouveau, buffers are placed statically in
either VRAM or GART, so I think that if it's shared it has to end up
in GART, no?


As far as I understand it no. Shared just means that we can share it 
between applications, doesn't it? Or does it mean the buffer should be 
shareable between GPUs?


Could be that my understanding was wrong and so if it's the later feel 
free to provide a patch to just remove the flag.



I'm pretty weak on all these concepts, as well as how the DRI3 stuff
works, unfortunately.


I have to confess I'm not so deeply into this stuff either. Marek, 
Michel what exactly is the meaning of the flag?


Regards,
Christian.



   -ilia



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Ilia Mirkin]

On Tue, Sep 6, 2016 at 2:22 PM, Christian König  wrote:
> Am 06.09.2016 um 16:23 schrieb Ilia Mirkin:
>>
>> On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer  wrote:
>>>
>>> On 05/09/16 04:37 AM, Ilia Mirkin wrote:

 On Tue, Mar 8, 2016 at 7:21 AM, Christian König
  wrote:
>
> @@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>  res_tmpl.depth0 = 1;
>  res_tmpl.array_size = 1;
>  res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET |
> -   PIPE_BIND_LINEAR;
> +   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;

 Hi Christian,

 This change appears to have semi-broken vdpau on nouveau. Whenever I
 flip on the OSD in mplayer, the rendering becomes *extremely* slow.
 However regular up-scaling without the OSD is plenty fast. This
 effectively is forcing the output surfaces to live in GART instead of
 VRAM.
>>>
>>> Strictly speaking, they'd only need to be forced to GART while they're
>>> actually being shared between different GPUs. That's how it works with
>>> the amdgpu and radeon kernel drivers.
>>
>> Any suggestions on how to handle this? Perhaps reallocate + copy the
>> surface in st/vdpau when actual dmabuf sharing is requested?
>>
>> To be clear - with this change, vdpau with nouveau is unusable in the
>> presence of an OSD in mplayer. The OSD comes up whenever you seek
>> around in the video, so in effect, it's unusable. Used to work great.
>
>
> Well I think you should clearly figure out why adding PIPE_BIND_SHARED has
> such dramatic effect.

Because the buffer goes into GART. And then you try to blend on it,
which involves readback from GART (that's how the functions OSD is
based on work, I believe). We normally don't allocate renderable
surfaces or textures in GART.

>
> We not only need this for DMA-buf based interop, but also for the DRI3 based
> sharing of buffers with X.
>
> So that clearly sounds like a bug in nouveau to me.

OK, so SHARED != GART? With nouveau, buffers are placed statically in
either VRAM or GART, so I think that if it's shared it has to end up
in GART, no?

I'm pretty weak on all these concepts, as well as how the DRI3 stuff
works, unfortunately.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Christian König]

Am 06.09.2016 um 16:23 schrieb Ilia Mirkin:

On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer  wrote:

On 05/09/16 04:37 AM, Ilia Mirkin wrote:

On Tue, Mar 8, 2016 at 7:21 AM, Christian König  wrote:

@@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
 res_tmpl.depth0 = 1;
 res_tmpl.array_size = 1;
 res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET |
-   PIPE_BIND_LINEAR;
+   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;

Hi Christian,

This change appears to have semi-broken vdpau on nouveau. Whenever I
flip on the OSD in mplayer, the rendering becomes *extremely* slow.
However regular up-scaling without the OSD is plenty fast. This
effectively is forcing the output surfaces to live in GART instead of
VRAM.

Strictly speaking, they'd only need to be forced to GART while they're
actually being shared between different GPUs. That's how it works with
the amdgpu and radeon kernel drivers.

Any suggestions on how to handle this? Perhaps reallocate + copy the
surface in st/vdpau when actual dmabuf sharing is requested?

To be clear - with this change, vdpau with nouveau is unusable in the
presence of an OSD in mplayer. The OSD comes up whenever you seek
around in the video, so in effect, it's unusable. Used to work great.


Well I think you should clearly figure out why adding PIPE_BIND_SHARED 
has such dramatic effect.


We not only need this for DMA-buf based interop, but also for the DRI3 
based sharing of buffers with X.


So that clearly sounds like a bug in nouveau to me.

Regards,
Christian.



   -ilia



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Ilia Mirkin]

On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer  wrote:
> On 05/09/16 04:37 AM, Ilia Mirkin wrote:
>> On Tue, Mar 8, 2016 at 7:21 AM, Christian König  
>> wrote:
>>> @@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>>> res_tmpl.depth0 = 1;
>>> res_tmpl.array_size = 1;
>>> res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET |
>>> -   PIPE_BIND_LINEAR;
>>> +   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
>>
>> Hi Christian,
>>
>> This change appears to have semi-broken vdpau on nouveau. Whenever I
>> flip on the OSD in mplayer, the rendering becomes *extremely* slow.
>> However regular up-scaling without the OSD is plenty fast. This
>> effectively is forcing the output surfaces to live in GART instead of
>> VRAM.
>
> Strictly speaking, they'd only need to be forced to GART while they're
> actually being shared between different GPUs. That's how it works with
> the amdgpu and radeon kernel drivers.

Any suggestions on how to handle this? Perhaps reallocate + copy the
surface in st/vdpau when actual dmabuf sharing is requested?

To be clear - with this change, vdpau with nouveau is unusable in the
presence of an OSD in mplayer. The OSD comes up whenever you seek
around in the video, so in effect, it's unusable. Used to work great.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Michel Dänzer]

On 05/09/16 04:37 AM, Ilia Mirkin wrote:
> On Tue, Mar 8, 2016 at 7:21 AM, Christian König  
> wrote:
>> @@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>> res_tmpl.depth0 = 1;
>> res_tmpl.array_size = 1;
>> res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET |
>> -   PIPE_BIND_LINEAR;
>> +   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
> 
> Hi Christian,
> 
> This change appears to have semi-broken vdpau on nouveau. Whenever I
> flip on the OSD in mplayer, the rendering becomes *extremely* slow.
> However regular up-scaling without the OSD is plenty fast. This
> effectively is forcing the output surfaces to live in GART instead of
> VRAM.

Strictly speaking, they'd only need to be forced to GART while they're
actually being shared between different GPUs. That's how it works with
the amdgpu and radeon kernel drivers.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Ilia Mirkin]

On Tue, Mar 8, 2016 at 7:21 AM, Christian König  wrote:
> @@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
> res_tmpl.depth0 = 1;
> res_tmpl.array_size = 1;
> res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET |
> -   PIPE_BIND_LINEAR;
> +   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;

Hi Christian,

This change appears to have semi-broken vdpau on nouveau. Whenever I
flip on the OSD in mplayer, the rendering becomes *extremely* slow.
However regular up-scaling without the OSD is plenty fast. This
effectively is forcing the output surfaces to live in GART instead of
VRAM. I believe that the OSD involves blending of some sort, so I can
definitely imagine that being slow. Any thoughts on the proper way to
address that? Removing the PIPE_BIND_SHARED from that line "fixes" it.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev