Bug 100960

Summary: Special block from Minecraft mod rendered out of place
Product: Mesa Reporter: Fabian Maurer <dark.shadow4>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED NOTOURBUG QA Contact: mesa-dev
Severity: minor    
Priority: medium    
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
i915 platform: i915 features:
Attachments: Compressed apitrace, 142MB unpacked
screenshot (working) on windows
screenshot(broken) on linux
trimmed and modified trace
Windows - Call 2245521 - Framebuffer
vr.trace windows picture

Description Fabian Maurer 2017-05-07 20:36:37 UTC
Created attachment 131243 [details]
Compressed apitrace, 142MB unpacked

Running a certain mod (ProjectE) with Minecraft results in a special block being rendered to high. It's hard to describe, please check the apitrace and screenshots for more info.
LIBGL_ALWAYS_SOFTWARE doesn't change the result.

Apitrace attached.
Images in following comments, both taken from frame 850 of the trace file:
-One on linux
-One on win10 with latest closed source AMD drivers.

System the bug was tested on:
- Arch Linux 64bit
- Linux 4.10.13, AMDGPU driver
- Mesa 17.2.0-devel (git-ccf9669cc1) / Mesa 17.0.5
- Radeon R9 285
Comment 1 Fabian Maurer 2017-05-07 20:37:45 UTC
Created attachment 131244 [details]
screenshot (working) on windows
Comment 2 Fabian Maurer 2017-05-07 20:38:03 UTC
Created attachment 131245 [details]
screenshot(broken) on linux
Comment 3 Timothy Arceri 2018-05-09 06:53:15 UTC
If you replay the trace on windows does it render correctly?
Comment 4 Fabian Maurer 2018-05-09 18:35:11 UTC
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.
Comment 5 Timothy Arceri 2018-09-12 02:22:08 UTC
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.
Comment 6 Sergii Romantsov 2018-09-12 13:35:23 UTC
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/
Comment 7 Sergii Romantsov 2018-09-13 11:12:51 UTC
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'
Comment 8 Sergii Romantsov 2018-09-13 11:14:06 UTC
Created attachment 141542 [details]
trimmed and modified trace
Comment 9 Fabian Maurer 2018-09-14 20:34:57 UTC
Created attachment 141566 [details]
Windows - Call 2245521 - Framebuffer
Comment 10 Sergii Romantsov 2018-09-17 11:13:23 UTC
Thanks, Fabian.
That proves that Windows has a workaround for (0,0,0)-vector and treat it as (1,0,0)-vector
Comment 11 Sergii Romantsov 2018-10-03 11:55:56 UTC
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?
Comment 12 Sergii Romantsov 2018-10-03 11:56:35 UTC
Created attachment 141846 [details]
Comment 13 Fabian Maurer 2018-10-03 14:22:04 UTC
Created attachment 141856 [details]
vr.trace windows picture

Attaching the requested picture.
Comment 14 Sergii Romantsov 2018-10-10 10:56:25 UTC
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
Comment 15 Sergii Romantsov 2018-10-10 10:56:56 UTC
Created attachment 141973 [details]
Comment 16 Sergii Romantsov 2018-10-10 10:57:53 UTC
Created attachment 141974 [details]
Comment 17 Sergii Romantsov 2018-10-17 12:26:19 UTC
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'.
Comment 18 Sergii Romantsov 2018-10-31 11:24:09 UTC
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
Comment 19 Fabian Maurer 2018-12-08 20:49:09 UTC
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.
Comment 20 Tapani Pälli 2018-12-10 06:38:05 UTC
(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
Comment 21 Sergii Romantsov 2018-12-17 07:26:08 UTC
(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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.