http://bugs.winehq.org/show_bug.cgi?id=34574
Bug #: 34574 Summary: Kega Fusion 3.64 - Fullscreen not working anymore Product: Wine Version: 1.7.2 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: joaogojunior@hotmail.com Classification: Unclassified
As of wine-1.7.2 I can not run kega fusion 3.64 in fullscreen anymore... Running a regression test here... soon I'll post results...
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #1 from João Guilherme joaogojunior@hotmail.com 2013-09-22 16:01:50 CDT --- Sorry I have reported wrong wine version! fullscreen is not working on current git, it does works on wine-1.7.2... still running regression...
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #2 from João Guilherme joaogojunior@hotmail.com 2013-09-23 11:09:03 CDT --- Done running a regression test, here is the result:
f29c24f2de70807d1f4c9c24935ba634e56be276 is the first bad commit commit f29c24f2de70807d1f4c9c24935ba634e56be276 Author: Stefan Dösinger stefan@codeweavers.com Date: Mon Sep 16 12:43:17 2013 +0200
wined3d: Pass the context to surface_internal_preload.
:040000 040000 4a85a017841dd11a4cdcbb399f6f6379860697b4 897379d65a84a8c4a2288528f3a9cd17b34324cf Mdlls
http://bugs.winehq.org/show_bug.cgi?id=34574
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Regression SHA1| |f29c24f2de70807d1f4c9c24935 | |ba634e56be276
http://bugs.winehq.org/show_bug.cgi?id=34574
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #3 from Henri Verbeet hverbeet@gmail.com 2013-09-24 04:49:00 CDT ---
From bug 34542, it may be relevant to note that this is on a GeForce4 MX 4000,
with proprietary NVIDIA 96.43.23 drivers, and doesn't have FBO ORM because of that.
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #4 from João Guilherme joaogojunior@hotmail.com 2013-09-24 09:50:58 CDT --- Thanks Henri Verbeet! Forgot to mention that! :)
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #5 from Stefan Dösinger stefan@codeweavers.com 2013-09-24 16:34:30 CDT --- Does this driver have no FBOs at all, or just no FBO_blit? Can you attach the glxinfo output?
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #6 from Stefan Dösinger stefan@codeweavers.com 2013-09-24 18:14:55 CDT --- Created attachment 46065 --> http://bugs.winehq.org/attachment.cgi?id=46065 wined3d: Avoid nested context_acquire calls when handling onscreen surfaces.
I can reproduce the problem by manually forcing backbuffer offscreen rendering. The attached patch fixes the issue for me, can you test it?
The specific issue with this that the blit from the shadow front buffer to the real front buffer first acquires a context to draw to the real front buffer. This context has render_offscreen set to false. Then the source surface - an offscreen render target - is loaded, which in this case means transfering it from the WGL backbuffer to a texture. For this purpose a context is acquired by surface_load_fb_texture with the source as its target. The GL context is the same, but render_offscreen is set to true. Since context_release doesn't restore the previous setting, the following draw to the WGL frontbuffer fails.
The issue doesn't just affect render_offscreen. If the application uses multiple swapchains, surface_load_fb_texture(), surface_blt_to_drawable() and read_from_framebuffer() could activate an entirely different GL context.
The attached patch resolves this by avoiding calling preload with a render-target specific context set. This is somewhat ugly. Preload requires the caller to set up a context, so it shouldn't modify the context in some cases. Yet it has to, because the caller cannot know that it has to read from or write to a onscreen drawable.
A better solution may be to restore the previous context and its properties after those three calls. I'll investigate this option tomorrow. A third option is to make context_release able to restore the old context, but I think this is an overkill. Except for those 3 functions, there shouldn't be a need for nested context_acquire calls ever.
(The "if (0)" in arb_program_shader.c is a workround for an unrelated problem I ran into. I'll submit a proper fix for this issue tomorrow.)
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #7 from João Guilherme joaogojunior@hotmail.com 2013-09-24 23:05:09 CDT --- Created attachment 46067 --> http://bugs.winehq.org/attachment.cgi?id=46067 glxinfo output from a geforce4 mx4000
glxinfo output from a geforce4 mx4000 64MB on NVIDIA 96.43.23, slackware 13.37
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #8 from João Guilherme joaogojunior@hotmail.com 2013-09-24 23:59:07 CDT --- Thanks for the patch, now Kega fusion goes to fullscreen again! Thank you!
http://bugs.winehq.org/show_bug.cgi?id=34574
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #46065|0 |1 is obsolete| |
--- Comment #9 from Stefan Dösinger stefan@codeweavers.com 2013-09-25 07:36:39 CDT --- Created attachment 46068 --> http://bugs.winehq.org/attachment.cgi?id=46068 wined3d: Restore the previous context after accessing the WGL drawable.
Can you give this patch a try? I prefer it over the previous one because it keeps the problems of the nested context_acquire calls confined to the three functions that do those calls.
I also noticed that the rendering output is not positioned correctly in windows mode. Does this problem happen on your system too? Is it a regression as well?
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #10 from Stefan Dösinger stefan@codeweavers.com 2013-09-25 08:46:35 CDT --- The incorrect positioning is more or less by design. The game renders to an offscreen ddraw surface and then tries to blit the result to the frontbuffer. The frontbuffer happens to be an offscreen surface as well (the shadow frontbuffer). The shadow frontbuffer is a lot bigger (screen size) than the GL drawable (window size). The old fallback code in surface_blt_special handles the copy via glCopyTexImage because the game's offscreen surface currently happens to be stored in the GL backbuffer. ARBfp_blit first copies the offscreen surface to a GL texture, then puts the destination surface (=ddraw frontbuffer) into the GL backbuffer and draws a textured quad. Later on the ddraw frontbuffer is copied back into a texture and blitted onto the real frontbuffer to make the contents show up on the screen.
The problem now is that the GL drawable is a lot smaller than the ddraw frontbuffer, so the blit from the game's offscreen surface to the shadow frontbuffer can only write to a part of the frontbuffer, cutting off parts of the draw. That's not fixable without FBOs. We should keep this restriction in mind when continuing with the blit cleanup - maybe we should fall back to CPU blits when blitting to an offscreen surface that is bigger than the GL drawable. Maybe we can keep the glCopyTexImage code, but this code only works properly by luck in this case (no stretching, and the source surface is upside down because it is an offscreen surface).
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #11 from Henri Verbeet hverbeet@gmail.com 2013-09-25 08:59:51 CDT --- (In reply to comment #10)
happens to be stored in the GL backbuffer. ARBfp_blit first copies the offscreen surface to a GL texture, then puts the destination surface (=ddraw
It probably doesn't matter much wrt. the general issue here, but note that the hardware in question doesn't have fragment shaders either.
The problem now is that the GL drawable is a lot smaller than the ddraw frontbuffer, so the blit from the game's offscreen surface to the shadow frontbuffer can only write to a part of the frontbuffer, cutting off parts of the draw. That's not fixable without FBOs.
Well, sort of. In principle the drawable only has to be large enough to fit the area that's being copied, not the entire surface. I think in most cases that's enough in practice, though even if it isn't you could in principle do the copy in multiple passes.
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #12 from Stefan Dösinger stefan@codeweavers.com 2013-09-25 09:41:25 CDT --- (In reply to comment #11)
It probably doesn't matter much wrt. the general issue here, but note that the hardware in question doesn't have fragment shaders either.
Ya, João won't see that issue because of that.
Well, sort of. In principle the drawable only has to be large enough to fit the area that's being copied, not the entire surface. I think in most cases that's enough in practice, though even if it isn't you could in principle do the copy in multiple passes.
That's possible for blits, but I think it's overkill. If you don't have FBOs some things aren't going to work.
For the shadow ddraw frontbuffer moving the shadow frontbuffer into wined3d would help. For all other cases I'd say get a card/driver with FBOs if you want to run a game that does complicated offscreen operations.
(Either way, all this has no relation to the original issue in this bug.)
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #13 from João Guilherme joaogojunior@hotmail.com 2013-09-26 06:37:59 CDT --- Hello Stefan Dösinger, I will test the patch for sure and post here about it, I know that my hardware is a bit limited, I like to run very old systems like this... thats why all my testing is done with games and software that in general the same hardware has capable to run under windows, I know that would be asking to much from wine to make this mx4000 run lets say gta san andreas, because I know that in windows it wont work anyway (because of missing pixel shader i think)... I will be limiting the testing to mostly to the old games from the correct era! :D But in general I am very satisfied with wine performance at least on my hardware, at least with nvidia blob the performance has already surpassed windows xp perfomance... But answering the question I haven't noticed any incorrect positioning on the rendering in windows mode, at leas on kega...
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #14 from Stefan Dösinger stefan@codeweavers.com 2013-09-26 06:42:33 CDT --- Testing on old hardware and reporting regressions is a good thing. Wine has a policy of not breaking things that once worked, and we don't have the resources to test everything ourselves.
That said, yes, we can't do magic. Your card is essentially a Geforce 2, but rebranded as Geforce 4 for some reason. My guess is that Nvidia wanted to sell some leftover stock of Geforce 2-era chips. It won't do pixel shaders, so any game that needs it won't run. Regular Geforce 4 GPUs support Pixel Shader 1.x on Windows. They don't support that on Wine. To do so, we'd have to write a GL_NV_register_combiner+GL_NV_texture_shader shader backend, which probably only a handful of people would use.
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #15 from João Guilherme joaogojunior@hotmail.com 2013-09-26 07:56:20 CDT --- Wow! I did not knew about that, now that you have said, even the boards from geforce2 and geforce4 are very close the same...
I'll keep running on this old hardware, and eventually on some new hardware too! I agree, that backend to support pixel shader v1 on wine for mx4000 would be very sweet for completeness, but I know that it isn't an trivial matter to write it. I can't program by myself yet even though I can read some C. But I must ask: Do you have some more info on this? There is some alike code to be examined, for reference? The backend works like a wrapper to low level functions?
Again I agree with you, even if someone bother only I few people will use it, but.. I am one of those people... and at atleast I can do testing and submit bugs...
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #16 from Stefan Dösinger stefan@codeweavers.com 2013-09-26 08:07:31 CDT --- There's no way to implement pixel shader 1 on Geforce 4 MX cards. As you can see in http://en.wikipedia.org/wiki/GeForce_4_Series#GeForce4_MX , the MX is just a re-branded Geforce 2. You need a Geforce 4 Ti for Pixel Shader 1 support.
For some related code, see dlls/wined3d/nvidia_texture_shader.c This is an implementation of the fixed function fragment pipeline using the Geforce3/4 specific extensions. Look at the GL_NV_register_combiner* and GL_NV_texture_shader* GL extension specs for details on the programming interface of the cards. Arb_program_shader.c and glsl_shader.c should give you a rough idea how the wined3d side of this works.
If you are interested in this and have further questions I recommend to write to wine-devel@winehq.org as this topic is mostly off-topic for this bug report.
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #17 from João Guilherme joaogojunior@hotmail.com 2013-09-28 07:14:50 CDT --- Hello again! I just have tested your last proposed patch, but unfortunately the results was not good for me... Kega entered fullscreen but the performance has degraded, the emulation goes out-of-sync and the video pauses here and there, also the fps counter has problem staying on 60fps... At first I was surprised and tought that could be some other regression introduced recently, but if I reversed this patch and patch again with the obsolete patch, kega works ok on fullscreen, no fps problems, no out of sync emu and no video pauses... so with the old patch everything is OK working good again, with the new patch it enters fullscreen, but the perfomance is altered...
http://bugs.winehq.org/show_bug.cgi?id=34574
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #18 from Stefan Dösinger stefan@codeweavers.com 2013-10-01 06:47:38 CDT --- Sorry, I've no idea why the new patch caused performance problems. There shouldn't be any real difference to the old one. Are you sure you didn't have some background process running?
I can try to reproduce your symptoms on my old Radeon 9000 GPU, but it'll take a while to update Wine and other software on that old machine.
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #19 from João Guilherme joaogojunior@hotmail.com 2013-10-05 23:14:23 CDT --- Hello again Stefan, I did rerun the tests with de last git revision and the results still the same, fullscreen does not work on clean git, if I apply your patch, it does enter fullscreen but the emulation that was running perfetcly on windowed mode starts to act strange, losing sync and fps... No big process on background here, but if there was some process interfering on the performance that would be notable in window mode too, isn't?, but was not the case... Your obsolete patch did not cleanly applied to the last git, but analising the rej file I could patch it manually and then fullscreen finally worked like a charm, so in other words the diference on the results are clear to me... If you need something just let me know...!
http://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #20 from Stefan Dösinger stefan@codeweavers.com 2013-10-08 04:58:20 CDT --- I ran Fusion on my old Radeon 9000 laptop in the hope that I can reproduce a performance difference there. Unfortunately I couldn't - both patches give 46-48 fps and fluent gameplay. The performance is the same in windowed and fullscreen mode. FBO offscreen rendering achieves the same performance as well.
Can you create a +d3d,+d3d_surface log with both patches in fullscreen mode? Don't run it for long - 2-3 seconds are enough, and preferably kill the application with wineserver -k instead of exiting normally. This way I don't have to find out which part of the log is the app's shutdown code and what is actual gameplay.
http://bugs.winehq.org/show_bug.cgi?id=34574
Luke Bratch l_bratch@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |l_bratch@yahoo.co.uk
https://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #21 from Austin English austinenglish@gmail.com --- This is your friendly reminder that there has been no bug activity for over a year. Is this still an issue in current (1.7.51 or newer) wine?
https://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #22 from Stefan Dösinger stefan@codeweavers.com --- Fwiw, I still expect this bug to be present on old enough GPUs. Nothing changed in the way we handle contexts on non-FBO offscreen rendering.
https://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #23 from Stefan Dösinger stefan@codeweavers.com --- Note that commit 4c4552c5a1910a9d5adf8eccff0ac62d89ffe376 added another regression on top of the existing one.
https://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #24 from Stefan Dösinger stefan@codeweavers.com --- The original regression has been hidden by commit 7524258aaf57fe11de6d3dbf9d0842eb2accf966, but as mentioned in my previous comment a different commit introduced a breakage with the same symptoms but for other reasons. The original problem with nested context_acquire calls is also still there, but hidden in most cases.
https://bugs.winehq.org/show_bug.cgi?id=34574
--- Comment #25 from Stefan Dösinger stefan@codeweavers.com --- The problem this bug was originally about should be fixed by b28511f73b04d54dfdc4f31e31e4606e7e0e5b0e, 7af0ede8fe72d7a01ec3dbfd2b6f5fd288fb69e2 and 14f024048b301cd6ccc7e15e731d069cd68b13c0. I'm marking this fixed, although the emulator still isn't working without FBOs due to bug 35718.
Also the way I fixed this is the way that João Guilherme said made things slower than they used to be. I couldn't reproduce this in my testing, but I don't have a Geforce 2 GPU myself any more. If anyone still has such a GPU please give it a try yourself and see if you can reproduce the findings.
https://bugs.winehq.org/show_bug.cgi?id=34574
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |b28511f73b04d54dfdc4f31e31e | |4606e7e0e5b0e Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #26 from Stefan Dösinger stefan@codeweavers.com --- Forgot to mark it fixed.
https://bugs.winehq.org/show_bug.cgi?id=34574
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #27 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.54.
https://bugs.winehq.org/show_bug.cgi?id=34574
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net Component|-unknown |directx-d3d
-
wine-bugs＠winehq.org