Created attachment 233404 [details] Lunar Magic OpenGL issues.log so first noticed when I attempted to install a local poudriere build, but assumed it was my setup, as I've never had one work from a local poudriere build. But when I noticed Latest had updated on the official repo I re-installed wine and mesa-dri from the official repo to get the i386 package installed using the pkg32.sh script. I cannot get anything using i386 and direct3d to work at all. Pure 64-bit mode works fine. Anything i386 unity will just crash, bascially with cannot allocate memory to the framebuffer. 32bit Things like Lunar Magic (super mario world rom editor) will load, but give OpenGL/wined3d errors and cannot display anything once a rom is loaded, which is odd as I didn't even think that would be using directx. running dxdiag just crashes itself never going beyond console messages finally indicating a missing midi sequencer but the app never displays a window, and gives tons of errors on the framebuffer device for Dirextx11 not sure what is going on. amd64 13.0-p10 nvidia drivers. Everything worked fine under the older version of wine. I even reinstalled nvidia-driver to be sure as wine used to run some script post-install that would mangle the nvidia drivers that thankfully doesn't seem to run anymore. 00e4:err:d3d:wined3d_debug_callback 0x15bdfc0: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for buffer object.". 00e4:err:d3d:wined3d_debug_callback 0x15bdfc0: "GL_INVALID_FRAMEBUFFER_OPERATION error generated. Operation is not valid because a bound framebuffer is not framebuffer complete.". 00e4:fixme:d3d:wined3d_context_gl_check_fbo_status FBO status GL_FRAMEBUFFER_UNSUPPORTED (0x8cdd).
Hello, i cant reproduce it, using an AMD Card.
Created attachment 234654 [details] Screenshot with Log
(In reply to Alexander Vereeken from comment #1) Interesting, so it might be something with Nvidia, wonder if its a loader issue with the 64bit libraries loading before the 32 bit ones due to them not being in the i386 prefix. I'll give copying them into the prefix a try. will have to see if nvidia updated somewhere in between too to see if something changed there, but it was working in 6.0.3 fine so not sure what could have changed. I tried moving to wine-devel and found the same issue with my own local poudriere built i386 wine-devel. I can't wait for the PE transition to be complete so we don't have to deal with this hacked wow64 anymore. So at present neither version works for me. Would be nice to hear if anyone using nvidia drivers has this working, not sure if somehow a registry corruption could cause this, but it acts like i have no graphics card for i386 so not sure its as simple as that.
so nvidia went to 510 around the same time wine went to 6.0.4, so likely never a wine issue, but not sure how to fix. Here is what I found ldconfig -32 -r indicates nvidia 32 bit libraries are not in the elf hints for 32 bit, they also fail to resolve dependencies when trying ldd against them. not sure if this is a problem or normal. /usr/local/lib32 isn't even in the default search path for ldconfig service per rc.conf, nor is their any ldconfig helper files like some other ports. ldconfig -32 -m /usr/local/lib32 and they become resolvable with ldd, and appear in ldconfig -32 -r output but wine 32 bit apps still have no opengl clearing the experiment by rebooting and then copying the libraries into the i386-pkg-wine prefix including the vdpau library doesn't fix things either. so I think I might just be in ld hell, but this is not something I know how to fix, not sure if anyone has any ideas, or if its as simple as I'm using ldconfig incorrectly. I've contemplated downgrading to nvidia 470 to test, or at least seeing how it might be packaged differently. The only thing I'm fairly certain is this started on amd64 13.0 and now I've running 13.1 from a src update with a full ports rebuild using portmaster. I have seen people indicating issues with 510 even on linux, but others claim they are crazy, but their most posted solution is to always build a pure 64 bit prefix so maybe something is up with 32 bit wine and nivdia 510. if someone has nvidia drivers working for wine please speak up, or anyone that might know a lot more how elf loading works with some guidance for that matter.
You could actually try to workaround this OpenGL error by using DXVK, if you have a Vulkan card. You can install it by using winetricks dxvk in your $WINEPREFIX. It also could be a simple wow64 transition regression, where it only works in an i386 only prefix. It can be tested by using WINE_NO_WOW64=1 in an new $WINEPREFIX.
(In reply to Alexander Vereeken from comment #5) so I tried the dxvk on my 64bit prefix, and it was not happy, vulkan just halts the machine, or more specifically freezes X11 and requires killing it from the console. I tried in a pure 32bit prefix I had, and even created a new one with the same results. I think I have read that sometimes nvidia cards do not like switching to vulkan once they are in GLX mode. vulkaninfo showed support but gave some weird messages as well so not clear there is 100% support or not, or if it was just angry at the MESA "card" it found. This wouldn't surprise me as it doesn't even support a graphical text console and X11, you have to go to text mode only on the console if you do switching between X11 and the console. I restored my prefix backups and I downgraded to Nvidia-driver 470, and everything works again fine. So there is definitely something up with 510 and wine, not sure exactly what is going on. As this affects both wine and wine-devel I am updating the bug description to make the issue at hand clearer. I don't know what is going on. in 470 ldconfig -32 -r likewise doesnt show the nvidia libraries so do not think that is the issue. For now I'll stick with wine-devel since it seems to be working ok with my locally built version of i386 libs. I think these might be the mesa components WARNING: [Loader Message] Code 0 : loader_scanned_icd_add: Driver /usr/local/lib/libvulkan_lvp.so supports Vulkan 1.1, but only supports loader interface version 4. Interface version 5 or newer required to support this version of Vulkan (Policy #LDP_DRIVER_7) WARNING: [Loader Message] Code 0 : loader_scanned_icd_add: Driver /usr/local/lib/libvulkan_radeon.so supports Vulkan 1.2, but only supports loader interface version 4. Interface version 5 or newer required to support this version of Vulkan (Policy #LDP_DRIVER_7) WARNING: [Loader Message] Code 0 : loader_scanned_icd_add: Driver /usr/local/lib/libvulkan_intel.so supports Vulkan 1.2, but only supports loader interface version 4. Interface version 5 or newer required to support this version of Vulkan (Policy #LDP_DRIVER_7) ERROR: [../src/amd/vulkan/radv_device.c:1062] Code 0 : VK_SUCCESS WARNING: lavapipe is not a conformant vulkan implementation, testing use only.
again, if anyone has working wine or wine-devel i386 working with Nvidia 510 please speak up. and just as importantly if it isn't working either
(In reply to alt2600 from comment #7) The 5xx driver broke wine-devel for me too. I had no time to take a closer look and fixed it by downgrading to 4xx. OS Version: FreeBSD 13.1 and Current Hardware: Geforce RTX 2080 TI PKGs: local poudriere repo
wondering if 510 uses a quirk or maybe this multi-sampling the code comments speak of. Either way the unexpected filling convention error is one that I saw. so my basic searching around for the errors i saw seem to come here https://github.com/wine-mirror/wine/blob/master/dlls/wined3d/utils.c line 4017 bool wined3d_caps_gl_ctx_test_filling_convention(struct wined3d_caps_gl_ctx *ctx, float offset) { static const struct wined3d_color red = {1.0f, 0.0f, 0.0f, 1.0f}; const struct wined3d_gl_info *gl_info = ctx->gl_info; unsigned int x, y, clear = 0, draw = 0; GLuint texture, fbo; DWORD readback[8][8]; /* This is a very simple test to find out how GL handles polygon edges: * Draw a 1x1 quad exactly through 4 adjacent pixel centers in an 8x8 * viewport and see which pixel it ends up in. So far we've seen top left * and bottom left conventions. This test may produce unexpected results * if the driver forces multisampling on us. * * If we find a bottom-left filling behavior we also move the x-axis * by the same amount. This is necessary to keep diagonals that go * through the pixel center intact. * * Note that we are ignoring some settings that might influence the * driver: How we switch GL to an upper-left coordinate system, * shaders vs fixed function GL. Testing these isn't possible with * the current draw_test_quad() infrastructure. Also the test is * skipped if we are not using FBOs. Drawing into the onscreen * frame buffer may also yield different driver behavior. * * The minimum offset also depends on the viewport size, although * the relation between those two is GPU dependent and not exactly * sensible. E.g. a 8192x8192 viewport on a GeForce 9 needs at * least an offset of 1/240.9, whereas a 8x8 one needs 1/255.982; * 32x32 needs 1/255.935. 4x4 and lower are happy with something * below 1/256. The 8x8 size below has been arbitrarily chosen to * get a useful result out of that card and avoid allocating a * gigantic texture during library init. * * Newer cards usually do the right thing anyway. In cases where * they do not (e.g. Radeon GPUs in a macbookpro14,3 running MacOS) * an offset of 1/2^20 is enough. */ const struct wined3d_vec3 edge_geometry[] = { {(-1.0f + offset) / 8.0f, (-1.0f + offset) / 8.0f, 0.0f}, {( 1.0f + offset) / 8.0f, (-1.0f + offset) / 8.0f, 0.0f}, {(-1.0f + offset) / 8.0f, ( 1.0f + offset) / 8.0f, 0.0f}, {( 1.0f + offset) / 8.0f, ( 1.0f + offset) / 8.0f, 0.0f}, }; gl_info->gl_ops.gl.p_glGenTextures(1, &texture); gl_info->gl_ops.gl.p_glBindTexture(GL_TEXTURE_2D, texture); gl_info->gl_ops.gl.p_glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0); gl_info->gl_ops.gl.p_glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 8, 8, 0, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, NULL); gl_info->fbo_ops.glGenFramebuffers(1, &fbo); gl_info->fbo_ops.glBindFramebuffer(GL_FRAMEBUFFER, fbo); gl_info->fbo_ops.glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, texture, 0); checkGLcall("create resources"); gl_info->gl_ops.gl.p_glViewport(0, 0, 8, 8); gl_info->gl_ops.gl.p_glClearColor(0.0f, 0.0f, 1.0f, 1.0f); gl_info->gl_ops.gl.p_glClear(GL_COLOR_BUFFER_BIT); draw_test_quad(ctx, edge_geometry, &red); checkGLcall("draw"); gl_info->gl_ops.gl.p_glBindTexture(GL_TEXTURE_2D, texture); gl_info->gl_ops.gl.p_glGetTexImage(GL_TEXTURE_2D, 0, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, readback); checkGLcall("readback"); gl_info->gl_ops.gl.p_glDeleteTextures(1, &texture); gl_info->fbo_ops.glDeleteFramebuffers(1, &fbo); gl_info->fbo_ops.glBindFramebuffer(GL_FRAMEBUFFER, 0); checkGLcall("delete resources"); /* We expect that exactly one fragment is generated. */ for (y = 0; y < ARRAY_SIZE(readback); ++y) { for (x = 0; x < ARRAY_SIZE(readback[0]); ++x) { if (readback[y][x] == 0xff0000ff) clear++; else if (readback[y][x] == 0xffff0000) draw++; } } if (clear != 63 || draw != 1) { FIXME("Unexpected filling convention test result.\n"); return FALSE; } /* One pixel was drawn, check if it is the expected one */ return readback[3][3] == 0xffff0000; }
I had the same issue (some game refusing to work: Mafia 2, The Witcher 2, maybe Northgard) with an nvidia GTX 960M, with the 5XX drivers. The last version of the driver that worked for me is 495.46 . Note that this test is on an hybrid graphics laptops using prime render offloading
Damjan, maybe you have an idea?
I think it is a bug in Nvidia drivers, not in Wine. I had the same problem with 510.xx and 515.xx versions of the driver. As far I remember, I didn't test with 520.xx. But the newest beta version, 525.53 works again with 32-bit apps, without any changes to Wine.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=105fcdb438740d018e368853a89865b4ef130c80 commit 105fcdb438740d018e368853a89865b4ef130c80 Author: Bartek Jasicki <thindil@laeran.pl.eu.org> AuthorDate: 2023-02-28 19:26:55 +0000 Commit: Kevin Bowling <kbowling@FreeBSD.org> CommitDate: 2023-03-02 09:15:18 +0000 x11/nvidia-driver, x11/linux-nvidia-libs: update to 515.86.01 PR: 269129, 268983, 263475 Approved by: maintainer timeout x11/linux-nvidia-libs/Makefile | 2 +- x11/linux-nvidia-libs/distinfo | 6 +++--- x11/nvidia-driver/Makefile | 8 +++++++- x11/nvidia-driver/distinfo | 6 +++--- 4 files changed, 14 insertions(+), 8 deletions(-)