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@lists.freedesktop.org Reporter: j.ribeirovega@outlook.com
Created attachment 124649 --> https://bugs.freedesktop.org/attachment.cgi?id=124649&action=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.
https://bugs.freedesktop.org/show_bug.cgi?id=96625
Christian König deathsimple@vodafone.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement
--- Comment #1 from Christian König deathsimple@vodafone.de --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=96625
--- Comment #2 from intermediadc@hotmail.com intermediadc@hotmail.com --- and this is bad :-( we are many here with this issue im facing it on e5500 freescale P5020 and on G5 Quad
https://bugs.freedesktop.org/show_bug.cgi?id=96625
--- Comment #3 from Christian König deathsimple@vodafone.de --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=96625
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Product|DRI |Mesa QA Contact| |dri-devel@lists.freedesktop | |.org Component|DRM/Radeon |Drivers/Gallium/r600
https://bugs.freedesktop.org/show_bug.cgi?id=96625
--- Comment #4 from Mathieu Malaterre mathieu.malaterre@gmail.com --- 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
https://bugs.freedesktop.org/show_bug.cgi?id=96625
--- Comment #5 from Daniel Stone daniel@fooishbar.org --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=96625
--- Comment #6 from Mathieu Malaterre mathieu.malaterre@gmail.com --- 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'.
https://bugs.freedesktop.org/show_bug.cgi?id=96625
--- Comment #7 from Christian König deathsimple@vodafone.de --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=96625
--- Comment #8 from Alex Deucher alexdeucher@gmail.com --- We are happy to apply good patches.
https://bugs.freedesktop.org/show_bug.cgi?id=96625
--- Comment #9 from Rui Salvaterra rsalvaterra@gmail.com --- (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
https://bugs.freedesktop.org/show_bug.cgi?id=96625
--- Comment #10 from Alex Deucher alexdeucher@gmail.com --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=96625
GitLab Migration User gitlab-migration@fdo.invalid changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |MOVED
--- Comment #11 from GitLab Migration User gitlab-migration@fdo.invalid --- -- 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.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org