Bug 100960

Created attachment 131244 [details]
screenshot (working) on windows

Created attachment 131245 [details]
screenshot(broken) on linux

If you replay the trace on windows does it render correctly?

Yes, the screenshot from comment 1 is from the same apitrace, but taken on windows.
I also retested on linux, and as of Mesa 18.2.0-devel (git-bd35345e85) the issue is still present.

I can confirm this renders correctly on Nvidia's Linux driver.

The rendering of the block can be seen in Frame 815 via three calls to glCallList().

glCallList(55503), glCallList(55504) and glCallList(55505)

These call lists are compiled in Frame 814.

Editing the y param to the glTranslatef() call that exists before glCallList() is called allows us to move the block to a more correct location.

There are a bunch of gl{Push,Pop}Matrix() calls before this but as far as I can tell Mesa's implementation of these functions looks fine.

I couldn't find any reason for the block to be rendered in the wrong position on Mesa drivers but thought I'd record this information in case anyone else wants to take a look.

Also doesn't work on Intel: Intel HD Graphics 620 (Kaby Lake GT2)
with git master and 13.0.6

Proposed workaround: https://patchwork.freedesktop.org/patch/249043/

Hello, Fabian.
Could i ask you to check one thing?
I'm attaching modified and trimmed trace: trimmmed.tar.gz.
Will you able to run it on Windows (https://people.freedesktop.org/~jrfonseca/apitrace/)?
If yes, then, please, do:
1. move to the latest call "2245521 @0 glPopMatrix()"
2. lookup it state
3. after its played, than 'current state' will appear on the right side
4. please, attach image from 'Surfaces/Framebuffers'

Created attachment 141542 [details]
trimmed and modified trace

Created attachment 141566 [details]
Windows - Call 2245521 - Framebuffer

Thanks, Fabian.
That proves that Windows has a workaround for (0,0,0)-vector and treat it as (1,0,0)-vector

Hello again.
Fabian, could you, please, do one more thing: use trace vr.trace and provide an image that it gives on Windows?

And Timothy, could you, please, do the same for Nvidia Linux driver?

Created attachment 141846 [details]
vr.trace

Created attachment 141856 [details]
vr.trace windows picture

Attaching the requested picture.

Thanks, Fabian. Your image looks the same as mesa with patch https://patchwork.freedesktop.org/patch/249043/ v3

Proposed additionally piglit-test: https://patchwork.freedesktop.org/patch/255629/

Apitrace to check on other platforms: zero-vector-rotate.trace.tar.gz
The final version of test gives image: Mesa_zero-vector-rotate.png

Created attachment 141973 [details]
Mesa_zero-vector-rotate.png

Created attachment 141974 [details]
zero-vector-rotate.trace.tar.gz

Hello, Fabian.

Unfortunately, probably, no one will be interest in that fix in the Mesa so much.
The reason: actually issue is in the game. Specification doesn't specify exact way how to handle it. So at this moment its implementation-dependent. 

Suggestion is: please, post an issue to Minecraft-mod owner. Probably, that is the fastest way to fix it: instead of calls
      'glRotated(angle = 180, x = 0, y = 0, z = 0)'
application should call:
      'glRotated(angle = 180, x = 1, y = 0, z = 0)'.
And, please, provide a link to it.

Proposed patches are still actual and adds compatibility for Mesa with Nvidia and Windows. But still: current behavior of Mesa is also can be treated as 'correct'.

Hello, Fabian.
At this moment i'm looking on possibility to workaround it only for Minecraft.
Could i ask for a help?:
1. To run Minecraft with mod
2. To get outputs of:
2.1 ps -fux
2.2 sudo grep i965_dri.so /proc/*/maps
3. And attach outputs here

Hey there, sorry for the late answer.

The mod has fixed the issue in its latest version, so for me this issue isn't relevant anymore. Do we still want a change in this, or do we consider this a "NOTOURBUG"?

Sidenote, why i965_dri.so? I though I'm using radeonsi.

(In reply to Fabian Maurer from comment #19)
> Hey there, sorry for the late answer.
> 
> The mod has fixed the issue in its latest version, so for me this issue
> isn't relevant anymore. Do we still want a change in this, or do we consider
> this a "NOTOURBUG"?
> 
> Sidenote, why i965_dri.so? I though I'm using radeonsi.

IMO NOTOURBUG seems the correct resolution here

(In reply to Fabian Maurer from comment #19)
> 
> Sidenote, why i965_dri.so? I though I'm using radeonsi.

Hello, Fabian.
Actually, its common "issue" for i965 and redaonsi and generally saying its common for Mesa.