Bug 96625

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.

and this is bad :-( we are many here with this issue
im facing it on e5500 freescale P5020 and on G5 Quad

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.

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

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.

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'.

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.

We are happy to apply good patches.

(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

(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.

-- 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.