wined3d: Do not treat oversized textures as failure
Hi. Attached patch is enough to cure the failure in "Operation Flashpoint" when its menu is displayed on my little i945GM card. As the oversised case is (was) explicitely treated as a failure, I think there is some reasone for it. Does someone remember what it is for ? Regards, -- Vincent Pelletier
Le Sunday 28 December 2008 16:21:25 Vincent Pelletier, vous avez écrit :
Attached patch is enough to cure the failure in "Operation Flashpoint" when its menu is displayed on my little i945GM card.
It also fixes mipmap test in d3d9/tests/visual.c, removing the need for a patch I sent earlier which purpose was to skip mipmap test when texture allocation fails. Some other notes on IWineD3DDeviceImpl_CreateTexture: If oversize is treated as an error and return value is changed to some error code, there seems to be a memory leak: it crashes happens after a rouhly constant number of frames are rendered, but this time hr has a non-null value in IWineD3DDeviceImpl_CreateTexture. -- Vincent Pelletier
2008/12/28 Vincent Pelletier <plr.vincent(a)gmail.com>:
Le Sunday 28 December 2008 16:21:25 Vincent Pelletier, vous avez écrit :
Attached patch is enough to cure the failure in "Operation Flashpoint" when its menu is displayed on my little i945GM card.
It also fixes mipmap test in d3d9/tests/visual.c, removing the need for a patch I sent earlier which purpose was to skip mipmap test when texture allocation fails.
The test should probably check the device caps before trying to create the texture.
Some other notes on IWineD3DDeviceImpl_CreateTexture: If oversize is treated as an error and return value is changed to some error code, there seems to be a memory leak: it crashes happens after a rouhly constant number of frames are rendered, but this time hr has a non-null value in IWineD3DDeviceImpl_CreateTexture.
CreateTexture() and similar calls leak on error, yeah. This is something that needs to be fixed.
2008/12/28 Vincent Pelletier <plr.vincent(a)gmail.com>:
Hi.
Attached patch is enough to cure the failure in "Operation Flashpoint" when its menu is displayed on my little i945GM card.
As the oversised case is (was) explicitely treated as a failure, I think there is some reasone for it. Does someone remember what it is for ?
In general you're not supposed to create textures larger than what the hardware allows. I think SFLAG_OVERSIZE is used to allow ddraw to do this anyway in certain cases, but I'm pretty sure this change isn't correct for d3d8 and d3d9. I wonder if the pool has any effect on this though.
This patch is wrong; You can't use oversized surfaces for 3D texturing because the driver doesn't support the given size. What is the texture size limit on your card, and what texture size does the game try to use? However, the oversize surface stuff is kinda hacky and poorly integrated. I think we should remove it and implement proper sysmem->framebuffer blitting. I used this oversized surface stuff to work around problems with swat 3's (approx) 3500x32 surface which contains the letters it blits onto the main menu. It was the wrong solution though, we should not create a GL texture for sysmem surfaces and use glDrawPixels instead(or temp textures in opengl 3)
-----Original Message----- From: wine-devel-bounces(a)winehq.org [mailto:wine-devel- bounces(a)winehq.org] On Behalf Of Vincent Pelletier Sent: Sunday, December 28, 2008 4:21 PM To: wine-devel(a)winehq.org Subject: wined3d: Do not treat oversized textures as failure
Hi.
Attached patch is enough to cure the failure in "Operation Flashpoint" when its menu is displayed on my little i945GM card.
As the oversised case is (was) explicitely treated as a failure, I think there is some reasone for it. Does someone remember what it is for ?
Regards, -- Vincent Pelletier
Le Sunday 28 December 2008 16:53:44, vous avez écrit :
This patch is wrong; You can't use oversized surfaces for 3D texturing because the driver doesn't support the given size.
So it seems fixing the crash I get requires to make CreateSurface fail when texture is marked as oversized (currently it passes through D3DCB_CreateSurface return value, which is WINED3D_OK), and fixing the leaks. When CreateSurface returns an error, game menu stays on noticeably longer (but notover 3 seconds or so). As it still crashed, I suspected a leak so I artificially made oversized texture be accepted (to have it freed correctly).
What is the texture size limit on your card, and what texture size does the game try to use?
It tries to create a 1024x1024 texture, and my card (Intel 945GM) is limited to 512x512: glxinfo -l | grep GL_MAX_TEXTURE_SIZE GL_MAX_TEXTURE_SIZE = 512 -- Vincent Pelletier
It tries to create a 1024x1024 texture, and my card (Intel 945GM) is limited to 512x512:
glxinfo -l | grep GL_MAX_TEXTURE_SIZE GL_MAX_TEXTURE_SIZE = 512 Wow, that is small. Even my pretty old radeon 9000 supports 2048x2048 textures...
I recommend to check the max texture size on Windows(does the game work on this card on Windows?). I'd say there's some driver problem here, 512x512 sounds way too small for any semi-recent card. That said, we should still fix the memory leak if CreateTexture fails...
2008/12/28 Stefan Dösinger <stefan(a)codeweavers.com>:
It tries to create a 1024x1024 texture, and my card (Intel 945GM) is limited to 512x512:
glxinfo -l | grep GL_MAX_TEXTURE_SIZE GL_MAX_TEXTURE_SIZE = 512 Wow, that is small. Even my pretty old radeon 9000 supports 2048x2048 textures...
I recommend to check the max texture size on Windows(does the game work on this card on Windows?). I'd say there's some driver problem here, 512x512 sounds way too small for any semi-recent card.
My i915 can certainly do more than 512x512.
That said, we should still fix the memory leak if CreateTexture fails...
Yes, but it's a bit more structural than just CreateTexture(). Most of the create methods in device are flawed in this way.
Le Sunday 28 December 2008 18:11:15, vous avez écrit :
Wow, that is small. Even my pretty old radeon 9000 supports 2048x2048 textures...
I recommend to check the max texture size on Windows(does the game work on this card on Windows?). I'd say there's some driver problem here, 512x512 sounds way too small for any semi-recent card.
I discussed with Thunderbird on IRC right after sending last reply. I noticed that I was not using latest intel driver, so I'm building them atm to give it a try. (Debian sid is quite outdated these days, because of work on next stable, I even have to rebuild the kernel) As for windows, I don't know. I'll certainly try if the rebuild does nothing. -- Vincent Pelletier
Le Sunday 28 December 2008 20:20:43 Vincent Pelletier, vous avez écrit :
I discussed with Thunderbird on IRC right after sending last reply. I noticed that I was not using latest intel driver, so I'm building them atm to give it a try. (Debian sid is quite outdated these days, because of work on next stable, I even have to rebuild the kernel)
With 2.5.1 version: GL_MAX_TEXTURE_SIZE = 2048 I reverted the patch on my local tree, and the game works fine. Maybe wine should warn for broken drivers when GL_MAX_TEXTURE_SIZE is below 1024 or something... So after all, it seems to be a non-bug. My bad. -- Vincent Pelletier
participants (3)
-
Henri Verbeet -
Stefan Dösinger -
Vincent Pelletier