| Bug ID | 109371 |
|---|---|
| Summary | Textures seem to be byteswapped on big endian architectures |
| Product | Mesa |
| Version | 18.3 |
| Hardware | PowerPC |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/DRI/nouveau |
| Assignee | nouveau@lists.freedesktop.org |
| Reporter | kungfujesus06@gmail.com |
| QA Contact | nouveau@lists.freedesktop.org |
When using an NV43 based GPU on a PPC64 kernel with a 64 bit u= serspace, it seems applications will have byte swapped textures when specified with GL_R= GBA and GL_UNSIGNED_BYTE. Matplotlib will do this when blit=3DTrue for the plot routines, and several games will have this issue. In particular, for Legacy Doom, I've found that if I swap the textures so that they are A,B,G,R just before the textures are mapped, everything is correct.=20=20 I also found that doing glPixelStorei(GL_UNPACK_BYTES, GL_TRUE) and choosing GL_UNSIGNED_INT_8_8_8_8 as the representation seemed to also remedy this. I found that the _REV variant didn't byte swap the textures back to the incor= rect ordering (this is probably a different bug). Easiest way to demonstrate the bug: svn co https://svn.code.sf.net/p/doomlegacy/svn/legacy_one/trunk doomlegacy cd doomlegacy make OS=3DLINUX make cd bin Grab this archive: https://sourceforge.net/projects/doomlegacy= /files/1.47.2/doomlegacy_1.47.2_common.zip/download, unzip it, extract legacy.wad into the bin directory Grab this archive: https://github.com/freedoom/freedoom/releases/download/= v0.11.3/freedoom-0.11.3.zip, extract, move freedoom1.wad into the bin directory. Then do: ./doomlegacy -iwad freedoom1.wad -opengl
You'd save me a bunch of effort by performing these steps your= self, and tracing using apitrace (https://gi= thub.com/apitrace/apitrace). Ideally record an as-short-as-possible trace, and check that it still looks bad on replay, and then xz -9 it and attach here.
Created attachment 14313=
8 [details]
Trace demoing the issue
Heh, the issue is there by the time I hit the title screen.
Unfortunately it appears that my G5 is dead. It half-booted on= ce (died right around nfsroot load time). Then for a bit it would turn on, with fans going= but no light and no chime. Now the fans don't even turn on. So I think that's t= he end. The things I would have done: 1. Check whether the textures look OK in qapitrace's inspector 2. Look at the transfer methods being used (in nv30_transfer.c). Try commen= ting some out, although that can also lead to failures. 3. Try to create a simple program based on the apitrace which reproduces the issue, and debug it step by step, to figure out where the byteswap might be happening. A few bits of info: The GPUs are LE deep down inside. However they have BE modes which byteswap "some stuff". So like MMIO accesses, FIFO commands, etc. So they = can still be packed like integers as usual, without an extra byteswap, and the GPU will "take care of it". I don't have a clean idea of whether and how b= yteswapping happens between GART and VRAM, as well as in various "blit"/copy = methods, where the byteswap would be different depending on whether it's u8, u16, or u32 datatype. This is most relevant to index buffers though, not textures. [Like let's say you're feeding the data via FIFO commands, there's an implicit byteswap there, etc.] Have a look at nv30_format.c for the supported texture formats/etc. As always, feel free to ask stuff in #nouveau. It should be noted that with a patch to apitrace (https://github.com/apitrace/apitrace/issues/601#issuecomment-45501= 9551), the attached trace replays fine on both nv42 and nv34 on x86.
| What | Removed | Added |
|---|---|---|
| Resolution | --- | MOVED |
| Status | NEW | RESOLVED |
-- 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/1167.