Re: [1/9] wined3d: Make the card selection for binary drivers depend only on gl_renderer like it already is for the mesa drivers and remove the gl_info parameter from the select_card callback. (try2)
Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> writes:
--- dlls/wined3d/directx.c | 568 +++++++++++++++++++++++-------------------------- 1 file changed, 269 insertions(+), 299 deletions(-)
It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d8.dll -p d3d8_test.exe.so device && touch device.ok err:d3d:resource_init Out of adapter memory wine: Unhandled page fault on read access to 0x69766574 at address 0x6862ab1c (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x69766574 in 32-bit code (0x6862ab1c). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:6862ab1c ESP:0032fa50 EBP:0032fb08 EFLAGS:00010202( R- -- I - - - ) EAX:68667f05 EBX:68678e50 ECX:00000000 EDX:69766564 ESI:68667f05 EDI:0032fab8 Stack dump: 0x0032fa50: 68667f05 00000000 00000000 0032fab8 0x0032fa60: 00000000 00000000 00000280 000001e0 0x0032fa70: 00000000 00000000 00000000 00000000 0x0032fa80: 00000000 00000000 00060048 68667229 0x0032fa90: 00139670 68668b04 00139688 0032fab8 0x0032faa0: 00000000 00132818 0032fad8 00134650 Backtrace: =>0 0x6862ab1c test_swapchain+0x28c() [/home/julliard/wine/wine/dlls/d3d8/tests/device.c:261] in d3d8_test (0x0032fb08) 1 0x68644593 func_device+0x832() [/home/julliard/wine/wine/dlls/d3d8/tests/device.c:6461] in d3d8_test (0x0032fd48) 2 0x6862a22f main+0x37e(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/d3d8/tests/../../../include/wine/test.h:584] in d3d8_test (0x0032fe18) 3 0x68667e20 __wine_spec_exe_entry+0x7f(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in d3d8_test (0x0032fe58) 4 0x7b85f65c call_process_entry+0xb() in kernel32 (0x0032fe78) 5 0x7b8606a3 start_process+0x62(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1097] in kernel32 (0x0032feb8) 6 0x7bc7fac0 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) 7 0x7bc82a6d call_thread_func+0x7c(entry=0x7b860640, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2630] in ntdll (0x0032ffa8) 8 0x7bc7fa9e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 9 0x7bc53f0e start_process+0x1d(kernel_start=0x7b860640) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2856] in ntdll (0x0032ffe8) 10 0x680316dd wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 11 0x6803179b wine_switch_to_stack+0x2a(func=0x7bc53ef0, arg=0x7b860640, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xff81e868) 12 0x7bc59a09 LdrInitializeThunk+0x238(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2910] in ntdll (0xff81e8a8) 13 0x7b866ea3 __wine_kernel_init+0xa02() [/home/julliard/wine/wine/dlls/kernel32/process.c:1269] in kernel32 (0xff81f7a8) 14 0x7bc5a903 __wine_process_init+0x192() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3119] in ntdll (0xff81f838) 15 0x6802ede8 wine_init+0x2c7(argc=0x3, argv=0xff81fd74, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:952] in libwine.so.1 (0xff81f898) 16 0x7bf00d6c main+0x7b(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:237] in <wine-loader> (0xff81fcd8) 17 0x682518c5 __libc_start_main+0xf4() in libc.so.6 (0x00000000) 0x6862ab1c test_swapchain+0x28c [/home/julliard/wine/wine/dlls/d3d8/tests/device.c:261] in d3d8_test: call *0x10(%edx) 261 hr = IDirect3DSwapChain8_GetBackBuffer(swapchain3, 0, 0, &backbuffer); -- Alexandre Julliard julliard(a)winehq.org
On Monday 14 July 2014 17:20:38 Alexandre Julliard wrote:
Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> writes:
It doesn't work here:
../../../tools/runtest -q -P wine -T ../../.. -M d3d8.dll -p d3d8_test.exe.so device && touch device.ok err:d3d:resource_init Out of adapter memory wine: Unhandled page fault on read access to 0x69766574 at address 0x6862ab1c (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x69766574 in 32-bit code (0x6862ab1c). Register dump:
Does that test pass without my changes? I'm asking because for me it crashes with vanilla wine. I logged a bug for mesa about a month ago: https://bugs.freedesktop.org/show_bug.cgi?id=79575
Andrei Slavoiu <andrei.slavoiu(a)gmail.com> writes:
On Monday 14 July 2014 17:20:38 Alexandre Julliard wrote:
Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> writes:
It doesn't work here:
../../../tools/runtest -q -P wine -T ../../.. -M d3d8.dll -p d3d8_test.exe.so device && touch device.ok err:d3d:resource_init Out of adapter memory wine: Unhandled page fault on read access to 0x69766574 at address 0x6862ab1c (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x69766574 in 32-bit code (0x6862ab1c). Register dump:
Does that test pass without my changes? I'm asking because for me it crashes with vanilla wine. I logged a bug for mesa about a month ago: https://bugs.freedesktop.org/show_bug.cgi?id=79575
Yes, of course it passes on my box, otherwise it wouldn't have been committed ;-) -- Alexandre Julliard julliard(a)winehq.org
What happens is that the renderer string is "GeForce 210/PCIe/SSE2", which now ends up getting matched against "GeForce", and the rest mostly just follows from there.
În ziua de Lun 14 Iul 2014, la 18:38:09, Henri Verbeet a scris:
What happens is that the renderer string is "GeForce 210/PCIe/SSE2", which now ends up getting matched against "GeForce", and the rest mostly just follows from there.
I see on Nvidia's site that the oldest cards supported by the legacy drivers on Linux are Geforce 5 FX series. So is it ok if I just remove all the D3D8 and lower cards completely?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-07-14 21:22, schrieb Andrei Slăvoiu:
În ziua de Lun 14 Iul 2014, la 18:38:09, Henri Verbeet a scris:
What happens is that the renderer string is "GeForce 210/PCIe/SSE2", which now ends up getting matched against "GeForce", and the rest mostly just follows from there.
I see on Nvidia's site that the oldest cards supported by the legacy drivers on Linux are Geforce 5 FX series. So is it ok if I just remove all the D3D8 and lower cards completely? Aren't there different legacy drivers for even older cards? I think we still have some (>= 1) users that use GeForce 4 MX cards(*), which are actually just GeForce 2 GPUs.
(*): http://bugs.winehq.org/show_bug.cgi?id=34574 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTxC/iAAoJEN0/YqbEcdMwEyQP/1/lfu5+kh/Z/826AzVerd3j YmL1huZ0dIG4c48LFUGHKeeOgN9uALUomeZiubdIPgXR73Gj67lYbiqybpZETmKi wdFXkWH5qQbED5kAH997NAPE8CM1b1q9LDR7+AABqSrCRdhNsTpfVutuoPtGTL2a c+iXKMmT0ASd9ML25PJxcQl2Ur4s10/JXBF/z2ctMq683xtYzCIuEvgXYxO25nCP VXxYstFqgdFNHAFMH4D2RHdg72s84JGUPVoTVH1L2aowiBkocqkPLPLercpJTyBf vvhN/asRbPX0e1ne0ywuJ29xMxm+QdhPlhR/Pl4jfgtJmv7NLuiBJcENfTun8RNG uI5e0cp3xFXARKTLU0N8KjMdOE2kRXKHcDAEr+UpP9GIO17QC0guo2bmnuf6yaNc hFPlO4LMEFPIOfoi+MBl5EHWI1be6p9PVubqoxcAr3p4CH4uZ2xdJxn1zX4sd68a T+dB2KgMAhsmWrEpssfzFPCq4mUefQOKUnrp+Qf96/e+XjC6F7hID3kQumox1RT0 K6a2uZx2xtmcyeJlpsNhQC5xtUo52FsBxaRUAOQpeyqHN9SFdy6WA9zoPqae/mRE CuWnTwQWQcmYXRq4eY8i3j107/1BzmKbz6BB1EIEPeKDWMr2es6cJetzKZrkRsxN RXh3AAojahZkBScVxHi9 =tVi6 -----END PGP SIGNATURE-----
În ziua de Lun 14 Iul 2014, la 21:30:43, Stefan Dösinger a scris:
Am 2014-07-14 21:22, schrieb Andrei Slăvoiu:
În ziua de Lun 14 Iul 2014, la 18:38:09, Henri Verbeet a scris:
What happens is that the renderer string is "GeForce 210/PCIe/SSE2", which now ends up getting matched against "GeForce", and the rest mostly just follows from there.
I see on Nvidia's site that the oldest cards supported by the legacy drivers on Linux are Geforce 5 FX series. So is it ok if I just remove all the D3D8 and lower cards completely?
Aren't there different legacy drivers for even older cards? I think we still have some (>= 1) users that use GeForce 4 MX cards(*), which are actually just GeForce 2 GPUs.
So leave those supported by driver 96.43.23, that would be all D3D8 cards + Geforce4 MX. Previous to that was driver 71.86.15 from August 2011. I hope nobody uses that with a recent wine version any more.
On 14 July 2014 21:22, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote:
I see on Nvidia's site that the oldest cards supported by the legacy drivers on Linux are Geforce 5 FX series. So is it ok if I just remove all the D3D8 and lower cards completely? Possibly, but it's a bit besides the point. You can't match against something generic like "GeForce", and returning CARD_NVIDIA_RIVA_TNT instead of PCI_DEVICE_NONE breaks the fallback mechanism.
În ziua de Lun 14 Iul 2014, la 22:58:40, Henri Verbeet a scris:
On 14 July 2014 21:22, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote:
I see on Nvidia's site that the oldest cards supported by the legacy drivers on Linux are Geforce 5 FX series. So is it ok if I just remove all the D3D8 and lower cards completely?
Possibly, but it's a bit besides the point. You can't match against something generic like "GeForce", and returning CARD_NVIDIA_RIVA_TNT instead of PCI_DEVICE_NONE breaks the fallback mechanism.
Yes, I realize now this was completely broken, and patch nr. 3 was just a partial fix for the damage I done here. But how do I get the exact renderer string for those old cards? I guess from the comments that the original Geforce cards or either identified as "Geforce 256" or "Geforce DDR". But what about the Quadro cards? How do I make those less generic? So the easy fix is to just get rid of those old cards identified by such generic strings. Now the question is how should I update the series, the current patch 3 no longer makes sense, and removing the old Nvidia cards should have been a change of its own before this one. Is it ok to renumber patches 1 and 2 as 2 and 3 and make a new patch 1 or should I keep the original numbering, scrap patch 3 and remove the old cards as part of the gl_info removal?
On 15 July 2014 01:37, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote:
Yes, I realize now this was completely broken, and patch nr. 3 was just a partial fix for the damage I done here. But how do I get the exact renderer string for those old cards? I guess from the comments that the original Geforce cards or either identified as "Geforce 256" or "Geforce DDR". But what about the Quadro cards? How do I make those less generic? So the easy fix is to just get rid of those old cards identified by such generic strings. I'd probably let the cards that currently aren't matched against a specific renderer string just hit the fallback code, since that's effectively what was happening before. I probably wouldn't bother removing existing entries, since it doesn't really gain us anything. For what it's worth, you may also want to consider splitting this by e.g. first getting rid of d3d_level_from_gl_info() in select_card_nvidia_binary(), then in select_card_amd_binary(), etc., and try to avoid large series. I.e., first work on getting the first 5 or so patches comitted, then work on the next couple, etc.
În ziua de Mar 15 Iul 2014, la 12:52:25, Henri Verbeet a scris:
I'd probably let the cards that currently aren't matched against a specific renderer string just hit the fallback code, since that's effectively what was happening before. So remove the matchers that I added (GeForce3 and Geforce) and leave the existing ones. BTW, GeForce2 was a already there, but because of the OpenGL level check it was not matched for newer cards. Now it might cause problems if Nvidia decides to use GeForce2000 for a future card.
For what it's worth, you may also want to consider splitting this by e.g. first getting rid of d3d_level_from_gl_info() in select_card_nvidia_binary(), then in select_card_amd_binary(), etc., and try to avoid large series. I.e., first work on getting the first 5 or so patches comitted, then work on the next couple, etc. So drop this series completely and start over with smaller ones?
participants (4)
-
Alexandre Julliard -
Andrei Slavoiu -
Henri Verbeet -
Stefan Dösinger