Posts: 6.069
Threads: 68
Joined: May 2010
Reputation:
167
Location: Grenoble, France
03-12-2013, 08:55 PM
(This post was last modified: 03-12-2013, 11:05 PM by gregory.)
Hum that strange. Did one your mesa test show a correct rendering ? I know mesa 9.1 is broken, not sure about mesa 8.0.5!
On my side, the signature was done on FGLRX and mesa 8.0.5 with texture float.
Edit: definitevely seem like some rounding difference between our drivers.
I try to compare both files, here the results. 10240 floats values are differents (on 54431). All diff are in the 4th byte which mean (if I'm correct) the lowest bit of the mantissa. The repartition of the difference is
2048 -> 4
6144 -> 8
2048 -> 12
However I don't know if the rounding is critical or not. I don't know if it affect the rendering.
Edit2:
I take the float 20800 as example. From you dump, you get "0x40010000" (2.015625E0) mine is "40010800" (2.01611328125E0). When I look at your apitrace your upload 2.01611 (like me actually), apitrace round the value too but it is close of mine.
Just to be sure that we compare the same things, can you check that you got this message.
ZZOgl-PG: Use GL_RGBA32F for blockdata.
Posts: 6.069
Threads: 68
Joined: May 2010
Reputation:
167
Location: Grenoble, France
You can compare file with "cmp -l". The file contains an array of floats. Each float is 32bits (or 4 bytes). To read the value you will an hexadecimal editor.
Because of endianness you need to read the float 4 bytes from right to left (then you can use an online converter)
On apitrace, you can lookup the glTexImage2D that upload the texture (IIRC the first one). You put 0 for stride, 1 for component and GL_FLOAT for the type. Then you will gate all float values.
Hum on my GPU (HD5770) mesa 8 with texture float is fine. Maybe it is not related to mesa but maybe the DRM or others part of the graphical stack.
Posts: 15
Threads: 1
Joined: Feb 2013
Reputation:
0
You need a new version of libdrm to build mesa 9, I used official "current" package 2.4.42. However i built mesa 8 with texture float with libdrm 2.4.33 and results are identical. I changed also llvm from 3.2 to 3.0 to 2.9 for bisect old mesa versions and upgraded xorg from 1.12.3 to 1.13.2 and xf86-video-ati from 6.14.4 to 7.1.0.In next days I gonna try another kernel (now i'm running 3.7.1-smp) but I bet that will change anything so I'm prone to think it's a mesa driver problem.
Posts: 6.069
Threads: 68
Joined: May 2010
Reputation:
167
Location: Grenoble, France
Nah don't lose you time. I got a better idea. I will upload your texture dump into my GPU and check if I got same rendering issue as you. Then you will do a report to Alex.
FYI, I got linux 3.7, drm 2.4.40, ddx ati, 6.14.4 and xorg 1.12.4
Posts: 6.069
Threads: 68
Joined: May 2010
Reputation:
167
Location: Grenoble, France
Good news. I got same issue a you. Your texture is wrongly rounded for an unknown reason.
Posts: 15
Threads: 1
Joined: Feb 2013
Reputation:
0
Thanks for your test and for update the bug page.
I just have a doubt. Driver dump is about texture float in plugin so I have lut.tex file only if I'm using mesa compiled with --enable-texture-float. But I found Mesa new versions cause the same bad rendering also if built without texture float. So what that mean? Maybe some code in new driver is related to texture float?
Posts: 6.069
Threads: 68
Joined: May 2010
Reputation:
167
Location: Grenoble, France
maybe they convert 16 bits integer to float. The texture float mesa flags only impact few lines of codes. Anyway let's wait they fix the issue with texture float. If we still have issue with integer format (that I plan to remove soon anyway), we will append the bug report.