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" <imir...@alum.mit.edu> wrote:

> On Thu, Sep 15, 2016 at 4:54 PM, Marek Olšák <mar...@gmail.com> wrote:
> > On Thu, Sep 15, 2016 at 5:14 AM, Dave Airlie <airl...@gmail.com> wrote:
> >> On 15 September 2016 at 13:03, Ilia Mirkin <imir...@alum.mit.edu>
> wrote:
> >>> On Wed, Sep 14, 2016 at 10:15 PM, Michel Dänzer <mic...@daenzer.net>
> 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

Reply via email to