Re: Latest Git build 7aeffc442cc1 for Wine 1.1.23
On 06/05/2009 08:15 PM, Austin English wrote:
On Fri, Jun 5, 2009 at 7:11 PM, chris ahrendt<celticht32(a)yahoo.com> wrote:
Tried it several times.. and different iterations of the registry keys (you will find them attached) and both cases it fails the same way any of the d3d tests will fail or the machine locks up.
????????
Hi! With new wine (1.1.23+ git) I'm getting wide range of failures of different games. System: Ubuntu Jaunty x86 ATI Radeon HD4870 512 MB fglrx 9.5 - The most significant crash (with several games): wine: Unhandled page fault on read access to 0x00000018 at address 0x7c71fb02 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000018 in 32-bit code (0x7c71fb02). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7c71fb02 ESP:0033e2a4 EBP:7d838810 EFLAGS:00210246( R- -- I Z- -P- ) EAX:00000001 EBX:00000001 ECX:7d49d6a0 EDX:00000000 ESI:00000000 EDI:7d715258 Stack dump: 0x0033e2a4: 7c70ca7f 00000000 00000000 7d847520 0x0033e2b4: 7d612f90 7d612f90 00000000 00000000 0x0033e2c4: 00000000 00000000 7d82e7b8 7d612f90 0x0033e2d4: 7d82e7b8 7d848010 00000000 7d82e7b8 0x0033e2e4: 00000000 00000000 7d7e2628 00000000 0x0033e2f4: 7d612f90 7d6a7e88 00000000 00000000 Backtrace: =>0 0x7c71fb02 in fglrx_dri.so (+0x713b02) (0x7d838810) 0x7c71fb02: movl 0x18(%edx),%eax Inside ati driver. - Sims 3 exits without any error message. (it worked before with fbo's, now exits. it can be started with backbuffer setting) 2009. 06. 5, péntek keltezéssel 18.03-kor chris ahrendt ezt írta:
On 06/05/2009 08:15 PM, Austin English wrote:
On Fri, Jun 5, 2009 at 7:11 PM, chris ahrendt<celticht32(a)yahoo.com> wrote:
Tried it several times.. and different iterations of the registry keys (you will find them attached) and both cases it fails the same way any of the d3d tests will fail or the machine locks up.
????????
2009/6/6 Kovács András <andras(a)csevego.net>:
wine: Unhandled page fault on read access to 0x00000018 at address 0x7c71fb02 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000018 in 32-bit code (0x7c71fb02). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7c71fb02 ESP:0033e2a4 EBP:7d838810 EFLAGS:00210246( R- -- I Z- -P- ) EAX:00000001 EBX:00000001 ECX:7d49d6a0 EDX:00000000 ESI:00000000 EDI:7d715258 Stack dump: 0x0033e2a4: 7c70ca7f 00000000 00000000 7d847520 0x0033e2b4: 7d612f90 7d612f90 00000000 00000000 0x0033e2c4: 00000000 00000000 7d82e7b8 7d612f90 0x0033e2d4: 7d82e7b8 7d848010 00000000 7d82e7b8 0x0033e2e4: 00000000 00000000 7d7e2628 00000000 0x0033e2f4: 7d612f90 7d6a7e88 00000000 00000000 Backtrace: =>0 0x7c71fb02 in fglrx_dri.so (+0x713b02) (0x7d838810) 0x7c71fb02: movl 0x18(%edx),%eax
That's probably the same issue as http://bugs.winehq.org/show_bug.cgi?id=18794 I'm afraid the conclusion there is simply going to be that fglrx's FBO support sucks. We could probably justify not checking depth stencil formats, but it's perfecly reasonable to try GL_COMPRESSED_RED_GREEN_RGTC2_EXT. The driver should of course crash on neither of those. I suppose we could blacklist EXT_framebuffer_object on fglrx, but that will likely just hurt more in the long term.
Would it be a good/stupid idea to check for fglrx during wineboot, and set OSRM to a different value than fbo? 2009/6/6 Henri Verbeet <hverbeet(a)gmail.com>:
2009/6/6 Kovács András <andras(a)csevego.net>:
wine: Unhandled page fault on read access to 0x00000018 at address 0x7c71fb02 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000018 in 32-bit code (0x7c71fb02). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7c71fb02 ESP:0033e2a4 EBP:7d838810 EFLAGS:00210246( R- -- I Z- -P- ) EAX:00000001 EBX:00000001 ECX:7d49d6a0 EDX:00000000 ESI:00000000 EDI:7d715258 Stack dump: 0x0033e2a4: 7c70ca7f 00000000 00000000 7d847520 0x0033e2b4: 7d612f90 7d612f90 00000000 00000000 0x0033e2c4: 00000000 00000000 7d82e7b8 7d612f90 0x0033e2d4: 7d82e7b8 7d848010 00000000 7d82e7b8 0x0033e2e4: 00000000 00000000 7d7e2628 00000000 0x0033e2f4: 7d612f90 7d6a7e88 00000000 00000000 Backtrace: =>0 0x7c71fb02 in fglrx_dri.so (+0x713b02) (0x7d838810) 0x7c71fb02: movl 0x18(%edx),%eax
That's probably the same issue as http://bugs.winehq.org/show_bug.cgi?id=18794 I'm afraid the conclusion there is simply going to be that fglrx's FBO support sucks. We could probably justify not checking depth stencil formats, but it's perfecly reasonable to try GL_COMPRESSED_RED_GREEN_RGTC2_EXT. The driver should of course crash on neither of those.
I suppose we could blacklist EXT_framebuffer_object on fglrx, but that will likely just hurt more in the long term.
-- J. Leclanche / Adys
Sure that is possible but it is something we should avoid. In the longterm having this enabled by default is better as it would get ATI and others to fix their drivers. If we would restore the old value (the old method is also not great for modern games and causes a lot of issues, FBOs are needed for proper d3d9 support) it would take longer for ATI to fix the remaining driver bugs. Roderick On Sat, Jun 6, 2009 at 12:32 PM, Jerome Leclanche<adys.wh(a)gmail.com> wrote:
Would it be a good/stupid idea to check for fglrx during wineboot, and set OSRM to a different value than fbo?
2009/6/6 Henri Verbeet <hverbeet(a)gmail.com>:
2009/6/6 Kovács András <andras(a)csevego.net>:
wine: Unhandled page fault on read access to 0x00000018 at address 0x7c71fb02 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000018 in 32-bit code (0x7c71fb02). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7c71fb02 ESP:0033e2a4 EBP:7d838810 EFLAGS:00210246( R- -- I Z- -P- ) EAX:00000001 EBX:00000001 ECX:7d49d6a0 EDX:00000000 ESI:00000000 EDI:7d715258 Stack dump: 0x0033e2a4: 7c70ca7f 00000000 00000000 7d847520 0x0033e2b4: 7d612f90 7d612f90 00000000 00000000 0x0033e2c4: 00000000 00000000 7d82e7b8 7d612f90 0x0033e2d4: 7d82e7b8 7d848010 00000000 7d82e7b8 0x0033e2e4: 00000000 00000000 7d7e2628 00000000 0x0033e2f4: 7d612f90 7d6a7e88 00000000 00000000 Backtrace: =>0 0x7c71fb02 in fglrx_dri.so (+0x713b02) (0x7d838810) 0x7c71fb02: movl 0x18(%edx),%eax
That's probably the same issue as http://bugs.winehq.org/show_bug.cgi?id=18794 I'm afraid the conclusion there is simply going to be that fglrx's FBO support sucks. We could probably justify not checking depth stencil formats, but it's perfecly reasonable to try GL_COMPRESSED_RED_GREEN_RGTC2_EXT. The driver should of course crash on neither of those.
I suppose we could blacklist EXT_framebuffer_object on fglrx, but that will likely just hurt more in the long term.
-- J. Leclanche / Adys
2009/6/6 Jerome Leclanche <adys.wh(a)gmail.com>:
Would it be a good/stupid idea to check for fglrx during wineboot, and set OSRM to a different value than fbo?
That's essentially what blacklisting EXT_framebuffer_object would do, although during wined3d initialization, not wineboot. We want to avoid that for the reasons already mentioned by Roderick. Not using FBOs (EXT_framebuffer_blit in particular) also has a significant performance impact in a number of applications. HL2 and CS:S are good examples.
That's probably the same issue as http://bugs.winehq.org/show_bug.cgi?id=18794 I'm afraid the conclusion there is simply going to be that fglrx's FBO support sucks. We could probably justify not checking depth stencil formats, but it's perfecly reasonable to try GL_COMPRESSED_RED_GREEN_RGTC2_EXT. The driver should of course crash on neither of those. Hmm. Does fglrx support this extension at all? I think fglrx has GL_ATI_texture_compression_3dc, which is essentially the same, but uses GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI.
Besides that, I don't think I have ever seen renderable compressed textures anywhere, so I'd say it is reasonable not to test it either. Still, the driver shouldn't crash.
2009/6/6 Stefan Dösinger <stefandoesinger(a)gmx.at>:
Hmm. Does fglrx support this extension at all? http://bugs.winehq.org/attachment.cgi?id=21581
That's attached to bug 18794.
On Fri, Jun 5, 2009 at 8:03 PM, chris ahrendt<celticht32(a)yahoo.com> wrote:
On 06/05/2009 08:15 PM, Austin English wrote:
On Fri, Jun 5, 2009 at 7:11 PM, chris ahrendt<celticht32(a)yahoo.com> wrote:
Tried it several times.. and different iterations of the registry keys (you will find them attached) and both cases it fails the same way any of the d3d tests will fail or the machine locks up.
????????
Use that attached .reg file. -- -Austin
participants (7)
-
Austin English -
chris ahrendt -
Henri Verbeet -
Jerome Leclanche -
Kovács András -
Roderick Colenbrander -
Stefan Dösinger