https://bugs.winehq.org/show_bug.cgi?id=41213
Bug ID: 41213 Summary: Missing textures Product: Wine Version: 1.9.17 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: montanawoody@gmail.com Distribution: ---
Created attachment 55467 --> https://bugs.winehq.org/attachment.cgi?id=55467 Compressed terminal output
The D3D 11 renderer for Elder Scrolls Online is almost working with the latest Wine version. The only issue I'm see now are missing textures, and these related error/fixme messages:
err:d3d:wined3d_debug_callback 0x15c2400: "GL_INVALID_OPERATION in glUseProgram(program 15 not linked)". fixme:d3d:context_bind_shader_resources Shader 0x7ff6c9ae0b70 needs 21 samplers, but only 16 are supported.
I've attached the terminal output as a compressed file since it was 35MB uncompressed.
I have a patch that I will attach as well that fixes the problem -- but is probably a hack. Hopefully someone more knowledgeable will know of a proper solution.
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #1 from Jason Wood montanawoody@gmail.com --- Created attachment 55468 --> https://bugs.winehq.org/attachment.cgi?id=55468 Patch to increase the maximum number of fragment samplers
I don't know what the appropriate value is here. Bumping MAX_FRAGMENT_SAMPLERS to 32 from 16 seemed to have no ill effect and fixed the missing texture issue.
https://bugs.winehq.org/show_bug.cgi?id=41213
Jason Wood montanawoody@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #55468|0 |1 is obsolete| |
--- Comment #2 from Jason Wood montanawoody@gmail.com --- Created attachment 55469 --> https://bugs.winehq.org/attachment.cgi?id=55469 Patch to increase the maximum number of fragment samplers
Here is a properly formated patch
https://bugs.winehq.org/show_bug.cgi?id=41213
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Missing textures |Elder Scrolls Online has | |missing textures with D3D11 | |renderer Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=41213
Eric Sandall sandalle@sourcemage.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sandalle@sourcemage.org
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #3 from Eric Sandall sandalle@sourcemage.org --- With this patch applied (and WINE recompiled per https://wiki.winehq.org/Building_Biarch_Wine_On_Ubuntu), I am able to see the ground in Elder Scrolls Online! The ground still seems to flicker a bit, but this is a major improvement, thank you @Jason.
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #4 from Jason Wood sandain@hotmail.com --- I don't know GL or D3D, but it seems to me that this value shouldn't be hard coded. A little searching leads me to believe that my patch is wrong, a default value if 16 is probably correct. However, either newer versions of GL/D3D or the hardware itself supports more than 16. I think this value can be queried using GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS, but I don't know GL so I might be off. If the actual number that is supported can be queried, that is probably the right way to go.
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #5 from Jason Wood sandain@hotmail.com --- Oops, make that GL_MAX_FRAGMENT_TEXTURE_IMAGE_UNITS.
https://bugs.winehq.org/show_bug.cgi?id=41213
James Christie james.aaron.christie@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |james.aaron.christie@gmail. | |com
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #6 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Jason Wood from comment #4)
I don't know GL or D3D, but it seems to me that this value shouldn't be hard coded.
Actually it isn't, see gl_info->limits.fragment_samplers in wined3d_adapter_init_limits(). MAX_FRAGMENT_SAMPLERS is used as an upper bound though and the reason is that there are a number of data structures and bitmasks in wined3d which are statically sized (the masks would need to be updated to account for the change, btw). In turn, some of those really shouldn't depend on the d3d max sampler count (e.g. resource_info in struct wined3d_shader_reg_maps) but on the max resource count. That's because of historical reasons i.e. the two values happened to match for d3d <= 9.
In the end, raising MAX_FRAGMENT_SAMPLERS probably isn't the correct fix for the bug, this would need more work.
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #7 from Jason Wood sandain@hotmail.com --- (In reply to Matteo Bruni from comment #6)
Actually it isn't, see gl_info->limits.fragment_samplers in wined3d_adapter_init_limits(). MAX_FRAGMENT_SAMPLERS is used as an upper bound though and the reason is that there are a number of data structures and bitmasks in wined3d which are statically sized (the masks would need to be updated to account for the change, btw). In turn, some of those really shouldn't depend on the d3d max sampler count (e.g. resource_info in struct wined3d_shader_reg_maps) but on the max resource count. That's because of historical reasons i.e. the two values happened to match for d3d <= 9.
In the end, raising MAX_FRAGMENT_SAMPLERS probably isn't the correct fix for the bug, this would need more work.
It is exactly the statically sized data structures defined in wined3d_private.h that I was speaking of when I was talking about the value being hard coded. I imagine anything that utilizes any of the values listed under /* Device caps */ (line 179) to define the size of a data structure is probably going to hit a similar issue as reported here, particularly with the MAX_FRAGMENT_SAMPLERS as already mentioned, MAX_VERTEX_SAMPLERS, and MAX_COMBINED_SAMPLERS constants.
Would it be possible to switch to run-time initialization of these structs? Or maybe reallocate the stucts once the device caps are known? Since I am unfamiliar with the code base and I'm not sure what masks would need to be updated, I'll probably defer any further work on this to someone that knows the code. I might keep poking around since it would be nice to have a real fix for this issue, but I doubt that I'll make much progress.
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #8 from Matteo Bruni matteo.mystral@gmail.com --- The point is that many of those structures should actually follow the d3d fragment samplers limit, which is 16 even for SM5 / d3d11. MAX_VERTEX_SAMPLERS instead should probably be incremented to 16 (that changed with SM4 / d3d10) but that's somewhat of a different issue.
The first step in fixing this bug (i.e. allowing for more than 16 OpenGL samplers, which aren't the same thing as d3d samplers) is to figure out which structure fields should depend on which limit. Only then deciding how to fix it makes sense, be it allocating dynamically some of those arrays (unlikely IMHO) or otherwise.
https://bugs.winehq.org/show_bug.cgi?id=41213
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joseph.kucia@gmail.com
--- Comment #9 from Józef Kucia joseph.kucia@gmail.com --- Created attachment 56180 --> https://bugs.winehq.org/attachment.cgi?id=56180 Patch
Could you please test if this patch fixed the problem?
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #10 from Jason Wood sandain@hotmail.com --- Created attachment 56184 --> https://bugs.winehq.org/attachment.cgi?id=56184 Wine 1.9.23 no patch screenshot
Note that I moved my mouse causing the repeating areas that should be ground. The ground texture in this image is missing, but other textures are working just fine (just not overwritten by the ground when the mouse moved).
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #11 from Jason Wood sandain@hotmail.com --- Created attachment 56185 --> https://bugs.winehq.org/attachment.cgi?id=56185 Wine 1.9.23 my patch screenshot
This mostly looks as expected (although my avatar is stuck in a weird pose)
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #12 from Jason Wood sandain@hotmail.com --- Created attachment 56186 --> https://bugs.winehq.org/attachment.cgi?id=56186 Wine 1.9.23 Józef Kucia patch screenshot
Józef Kucia, here is a screen shot with your patch. Note that the ground is displayed, but the texture is wrong and very green.
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #13 from Jason Wood sandain@hotmail.com --- Józef Kucia: I don't know Wine's policy on this, but your patch has a bunch of white space changes that make it hard to review what is actually changed. If you really want the whitespace the way it is, I would submit that as a separate patch. Same with the renaming of variables (e.g. s/i/prev_stage/g and s/j/prev_unit/g).
https://bugs.winehq.org/show_bug.cgi?id=41213
allneuts@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |allneuts@yahoo.co.uk
--- Comment #14 from allneuts@yahoo.co.uk --- Created attachment 56898 --> https://bugs.winehq.org/attachment.cgi?id=56898 Tutorial area crash on loot
Hi all,
Sorry, this is my first bug post and I am still figuring out how to read the traces and such. I thought I would submit an image and some traces and hope that it helps toward a solution.
Regards,
Jen
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #15 from allneuts@yahoo.co.uk --- Created attachment 56899 --> https://bugs.winehq.org/attachment.cgi?id=56899 Crash when I might have met the prophet in the tutorial area
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #16 from allneuts@yahoo.co.uk --- Created attachment 56900 --> https://bugs.winehq.org/attachment.cgi?id=56900 Green water
I think water is green an not animated. Hope these help.
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #17 from Jason Wood sandain@hotmail.com --- I ran a test with a clean prefix using wine 2.2 and the situation has improved a bit. The ground is still missing its texture, but there is now at least a bumpy green surface to run around on. My patch above still works with 2.2 and makes the ground texture function
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #18 from Jason Wood sandain@hotmail.com --- I just noticed that http://source.winehq.org/git/wine.git/commit/3f3b3e1772b36868caf7ee3bdba5de0... was recently committed to the wine tree. I wonder if this is the real fix for this missing texture issue. I'll try to compile wine with that patch this evening when I get home from work to see if it does the trick.
https://bugs.winehq.org/show_bug.cgi?id=41213
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #19 from Józef Kucia joseph.kucia@gmail.com --- (In reply to Jason Wood from comment #18)
I just noticed that http://source.winehq.org/git/wine.git/commit/ 3f3b3e1772b36868caf7ee3bdba5de04b00ae9c6 was recently committed to the wine tree. I wonder if this is the real fix for this missing texture issue.
No, 3f3b3e1772b36868caf7ee3bdba5de04b00ae9c6 isn't a fix for this bug.
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #20 from Jason Wood sandain@hotmail.com --- You are right, 3f3b3e1772b36868caf7ee3bdba5de04b00ae9c6 does not affect this bug, my patch is still needed. I just noticed that your patch was touching MAX_FRAGMENT_SAMPLERS and gl_info->limits.fragment_samplers which is where my limited understanding places the problem.
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #21 from Józef Kucia joseph.kucia@gmail.com --- Please retest if the problem is fixed in the current git version. If the problem still persists, please attach a "+d3d" log.
https://bugs.winehq.org/show_bug.cgi?id=41213
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED Fixed by SHA1| |1865352e3f33db85bf533be5694 | |133095fdd964f
--- Comment #22 from Józef Kucia joseph.kucia@gmail.com --- (In reply to Józef Kucia from comment #21)
Please retest if the problem is fixed in the current git version. If the problem still persists, please attach a "+d3d" log.
Marking as fixed by commit 1865352e3f33db85bf533be5694133095fdd964f.
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #23 from James Christie james.aaron.christie@gmail.com --- This issue is now 100% fixed for me on Intel video running via Mesa (latest stable). However, I still get identical behavior to the broken functionality when using nVidia proprietary drivers on an 800M. I'm testing a 760 desktop GPU shortly.
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #24 from James Christie james.aaron.christie@gmail.com --- Created attachment 57642 --> https://bugs.winehq.org/attachment.cgi?id=57642 +d3d log of ground rendering issues @ version 2.4 x86_64
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #25 from James Christie james.aaron.christie@gmail.com --- I attached a +d3d log of the wine debug output while the game is running. It generates a truly immense amount of this (100+ mb log file for a couple minutes to load in and get this log.
This is using wine 2.4 (64bit build). If the commit fixing this was not included in that particular release, please disregard this and I'll retest with a release that does. (2.4 does fix it for Intel video, at the very least.)
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #26 from Jason Wood sandain@hotmail.com --- I can confirm that my patch/hack is no longer needed for Wine 2.4 using Mesa on a Radeon RX 480. Thank you for all your hard work on this Józef Kucia.
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #27 from James Christie james.aaron.christie@gmail.com --- Testing from the 760 (desktop GPU) resulted in the same outcome: the ground is still not drawn correctly and looks identical to wine versions prior to 2.4 (I did confirm the fix for Mesa drivers was in 2.4).
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #28 from Józef Kucia joseph.kucia@gmail.com --- (In reply to James Christie from comment #24)
Created attachment 57642 [details] +d3d log of ground rendering issues @ version 2.4 x86_64
This log is not useful. It doesn't seem to even be a +d3d log (only d3d11 FIXMES are included). For this bug the most useful would be the first few thousands lines of +d3d log.
https://bugs.winehq.org/show_bug.cgi?id=41213
stamatisv@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stamatisv@hotmail.com
--- Comment #29 from stamatisv@hotmail.com --- Created attachment 57654 --> https://bugs.winehq.org/attachment.cgi?id=57654 Compressed wine debug d3d log
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #30 from stamatisv@hotmail.com --- Not sure if I had to create a new bug report or post it here. I am using nvidia-378 proprietary driver through bumblebee on Ubuntu 16.04 64bit. My graphics card is GeForce GT 650M.
With wine-2.4 I noticed improvement (no more greenish ground), but I still have missing textures on loading screen and rendering issues in game (more noticable while moving and near the ground).
I am attaching the d3d output + some screenshots. The trace till I get iin game was huge (4G) so I stripped it down a bit in 3 parts. Init.txt contains the initial thousand lines, charselect.txt contains the initial thousand lines beginning when the game enters character selection screen and ingame.txt the lines beginning when the game is loaded.
Hope they help identifying more the issue.
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #31 from stamatisv@hotmail.com --- Created attachment 57655 --> https://bugs.winehq.org/attachment.cgi?id=57655 couple of screens
https://bugs.winehq.org/show_bug.cgi?id=41213
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Elder Scrolls Online has |Elder Scrolls Online |missing textures with D3D11 |requires more than 16 |renderer |samplers in pixel shaders | |with D3D11 renderer
https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #32 from Józef Kucia joseph.kucia@gmail.com --- (In reply to Stamatis from comment #30)
Not sure if I had to create a new bug report or post it here. I am using nvidia-378 proprietary driver through bumblebee on Ubuntu 16.04 64bit. My graphics card is GeForce GT 650M.
A new bug report would be better. This bug was initially created for the problem with pixel shaders requiring more than 16 samplers. This should work now with your GPU, and it fixes the green ground bug.
I am attaching the d3d output + some screenshots. The trace till I get iin game was huge (4G) so I stripped it down a bit in 3 parts. Init.txt contains the initial thousand lines, charselect.txt contains the initial thousand lines beginning when the game enters character selection screen and ingame.txt the lines beginning when the game is loaded.
Hope they help identifying more the issue.
Unfortunately, the attached logs don't seem to give any obvious hints why some textures are still missing.
https://bugs.winehq.org/show_bug.cgi?id=41213
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #33 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 2.5.
https://bugs.winehq.org/show_bug.cgi?id=41213
Adrià Cereto i Massagué ssorgatem@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ssorgatem@gmail.com
--- Comment #34 from Adrià Cereto i Massagué ssorgatem@gmail.com --- With the latest update of Elder Scrolls Online, this issue is back, except now it asks for more than 32 fragment samplers:
fixme:d3d:context_bind_shader_resources Shader 0x7fff03eb85a0 needs 37 samplers, but only 32 are supported.
Other than that, it looks and behaves exactly like this old issue.
Should I open a new bug report?
https://bugs.winehq.org/show_bug.cgi?id=41213
Christian Weiske cweiske@cweiske.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cweiske@cweiske.de
--- Comment #35 from Christian Weiske cweiske@cweiske.de --- Followup for the 32-are-not-enough-problem is bug #44514.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla