[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=96625

GitLab Migration User  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #11 from GitLab Migration User  ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/588.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96625

--- Comment #10 from Alex Deucher  ---
(In reply to Rui Salvaterra from comment #9)
> (In reply to Christian König from comment #3)
> > Well feel free to provide patches. The relevant source is in
> > src/gallium/drivers/radeon/radeon_uvd.c.
> > 
> > Probably all the 32 and 16 bit fields set into the message and feedback
> > buffer in get_h264_msg(), get_h265_msg(), get_vc1_msg(), get_mpeg2_msg(),
> > get_mpeg4_msg() and ruvd_end_frame() needs to be byte swapped.
> > 
> > It should actually be pretty trivial to do so, it's just a huge bunch of
> > work nobody so far has time to work on.
> 
> Hi, Christian,
> 
> I'm not at all familiar with the Mesa codebase, but doesn't it provide
> arch-specific endian helpers, akin to the Linux kernel ({b,l}e_to_cpu and
> friends)? If not, maybe it would be an interesting GSoC project, assuming
> such patches were accepted?

Yes, endian swap helpers exist in mesa.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96625

--- Comment #9 from Rui Salvaterra  ---
(In reply to Christian König from comment #3)
> Well feel free to provide patches. The relevant source is in
> src/gallium/drivers/radeon/radeon_uvd.c.
> 
> Probably all the 32 and 16 bit fields set into the message and feedback
> buffer in get_h264_msg(), get_h265_msg(), get_vc1_msg(), get_mpeg2_msg(),
> get_mpeg4_msg() and ruvd_end_frame() needs to be byte swapped.
> 
> It should actually be pretty trivial to do so, it's just a huge bunch of
> work nobody so far has time to work on.

Hi, Christian,

I'm not at all familiar with the Mesa codebase, but doesn't it provide
arch-specific endian helpers, akin to the Linux kernel ({b,l}e_to_cpu and
friends)? If not, maybe it would be an interesting GSoC project, assuming such
patches were accepted?

Best regards,

Rui

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96625

--- Comment #8 from Alex Deucher  ---
We are happy to apply good patches.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96625

--- Comment #7 from Christian König  ---
Well to answer your question from a technical point of view:

The ring buffers and IBs can be byte swapped by the MC, but in difference to
older generations the hardware does no actively support big endian
architectures any more.

So you need to do all the byte swapping on the driver side before giving the
data to the hardware.

Linux support for big endian architectures are only done best effort. So we can
help develop features and fix bugs, but don't actively spend time on coding
things.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96625

--- Comment #6 from Mathieu Malaterre  ---
Daniel - I've been re-reading my questions twice but completely failed to
understand what you called 'unfair position'.

Christian - Based on Daniel feedback, I sincerely apologize for putting you in
an 'unfair position'.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96625

--- Comment #5 from Daniel Stone  ---
Mathieu - I don't work for AMD or any related company, but I can tell you that
demanding engineers provide position statements on behalf of 10,000-employee
companies isn't going to work. Christian is an engineer who is just working to
improve open source, and you're putting him in a very unfair position.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96625

--- Comment #4 from Mathieu Malaterre  ---
Dear Christian König,

I see that you are working for AMD, so I assume that you are representing your
employer here when you say "[...]pretty trivial to do so, it's just a huge
bunch of work nobody so far has time to work on.[...]"

Would you care clarifying AMD position with regards to Big Endian machine(s) ?

Specifically:

1. When a bug is carefully reported, a proper diagnosis is found (by yourself
in the case of #96625). It is correct to assume that none of the AMD employee
will work on addressing it. The patch is required to be prepared by customer(s)
of an AMD card instead.

2. When a bug is carefully reported, a patch is prepared and reviewed (by
yourself in the case of #95017). It is correct to assume that none of the AMD
employee will work on actually merging the patch upstream.

Regards

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96625

Alex Deucher  changed:

   What|Removed |Added

Product|DRI |Mesa
 QA Contact||dri-devel at lists.freedesktop
   ||.org
  Component|DRM/Radeon  |Drivers/Gallium/r600

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96625

--- Comment #3 from Christian König  ---
Well feel free to provide patches. The relevant source is in
src/gallium/drivers/radeon/radeon_uvd.c.

Probably all the 32 and 16 bit fields set into the message and feedback buffer
in get_h264_msg(), get_h265_msg(), get_vc1_msg(), get_mpeg2_msg(),
get_mpeg4_msg() and ruvd_end_frame() needs to be byte swapped.

It should actually be pretty trivial to do so, it's just a huge bunch of work
nobody so far has time to work on.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96625

--- Comment #2 from intermediadc at hotmail.com  
---
and this is bad :-( we are many here with this issue
im facing it on e5500 freescale P5020 and on G5 Quad

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96625

Christian König  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Christian König  ---
Yeah that is a known issue. Big endian systems are not really supported by the
hardware any more.

Because of this we would need to add manual byte swapping in the userspace
driver and nobody had the time yet to do so.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 96625] GPU lockup when using r600g VDPAU on powerpc

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96625

Bug ID: 96625
   Summary: GPU lockup when using r600g VDPAU on powerpc
   Product: DRI
   Version: unspecified
  Hardware: PowerPC
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: j.ribeirovega at outlook.com

Created attachment 124649
  --> https://bugs.freedesktop.org/attachment.cgi?id=124649=edit
dmesg

I installed a Radeon HD6670 on a PowerMac G5 Quad, hoping to use VDPAU to play
videos. 

When using mpv with opengl and vdpau hwdec and testing with a 720p sample from
samplevideos the gpu locks up and I am forced to reboot.

Attached dmesg after crash.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: