Wine 1.1.21 and Fglrx

[Laughing1]

I have a radeon 4870 + wine 1.1.21 (just updated to it) but it still locks up in Half life: Source games... -- no change from previous wine versions!

fglrxinfo:

display: :0.0  screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Radeon HD 4800 Series 
OpenGL version string: 2.1.8494 Release

Here is the logfile:
http://pastebin.com/f50fb76e3

Edit: I don't think it is a fglrx issue due to:

E: shm.c: mmap() failed: Cannot allocate memory
steamapps\user\half-life\hl.exe: pulse.c:200: pulse_new: Assertion `p->context' failed.

Edit2:

I disabled alsa (no sound now, heh...) in winecfg and now it works, now I know it is a pulseaudio bug that is causing me this issue!

[bridgman]

Maybe the right way to phrase it that it's not useless but wrong unless Wine should have per-driver version hacks. Old versions should be allowed to fail if they have bugs. New versions should be allowed to work.

Pretty much every game in the world runs different code paths for different hardware vendors.

Despite everyone's best efforts two implementations of the same standard are not likely to be identical once you start pushing the limits of functionality, even after passing all the compliance tests. If you're just using basic functions and not relying on things like internal memory manager behaviour then writing one set of code and running it everywhere pretty much works.

[nanonyme]

Pretty much every game in the world runs different code paths for different hardware vendors.

Despite everyone's best efforts two implementations of the same standard are not likely to be identical once you start pushing the limits of functionality, even after passing all the compliance tests. If you're just using basic functions and not relying on things like internal memory manager behaviour then writing one set of code and running it everywhere pretty much works.

I didn't mean there's anything wrong with having a different code path per hardware vendor. I just would consider it extremely silly if it would have different code paths for the same hardware vendor's different driver versions.

[bridgman]

If you mean "different code paths for 9.1 Cat and 9.2 Cat" then I agree completely; code for the most recent. In a case such as pre-6xx support stopping at 9.3 you might end up with a bit of code specific to 9.3 on pre-6xx but in general you want to code for the most recent driver on any hardware class.

This all echoes around between the vendors of course; it's not unusual for HW vendor A to have a bug, app vendor B to code in a workaround for that bug which breaks support on HW vendor C, so HW vendor C's drivers have to be hacked to duplicate the buggy behavior under certain conditions to make the app work, then when HW vendor A fixes their bug the new version of the app takes out the workaround and HW vendor C has to change *their* driver to take out the simulated bug which made the previous version of the app work. When anyone fixes a bug it takes a while for the ripples to fade

Between the proprietary and open source drivers I would expect some differences, but the code paths will probably be different anyways because of the different extension sets and the branch criteria would probably not be based on the driver itself.

[Qaridarium]

If you mean "different code paths for 9.1 Cat and 9.2 Cat" then I agree completely; code for the most recent. In a case such as pre-6xx support stopping at 9.3 you might end up with a bit of code specific to 9.3 on pre-6xx but in general you want to code for the most recent driver on any hardware class.

This all echoes around between the vendors of course; it's not unusual for HW vendor A to have a bug, app vendor B to code in a workaround for that bug which breaks support on HW vendor C, so HW vendor C's drivers have to be hacked to duplicate the buggy behavior under certain conditions to make the app work, then when HW vendor A fixes their bug the new version of the app takes out the workaround and HW vendor C has to change *their* driver to take out the simulated bug which made the previous version of the app work. When anyone fixes a bug it takes a while for the ripples to fade

Between the proprietary and open source drivers I would expect some differences, but the code paths will probably be different anyways because of the different extension sets and the branch criteria would probably not be based on the driver itself.

its completly pointless to fix bugs in new software for very old hartware...

hey i switch from X800 to an 4670 now i have a 4350 and 4670 for gaming an old computers only to surf/klickaround no 3D is needet...

its completly pointless to make special fixes for modern 3D games vor pre DX10 hartware becourse hd2000 class hartware cost only 5€ used....

upper hartware have 1 more nvidia extansion in openGL soo more code can be shared and upper hartware can use textured vertex shaders X1000 class hartware only can do this in an very diverend way thats hartwork for the wine dev's...

so in my Point of View its stubit to dev for an X1000 class hartware and older...

[Laughing1]

Now that I can get in game (I disabled audio) it just randomly freezes my whole system up when I use wine for opengl...

[AdrenalineJunky]

its completly pointless to fix bugs in new software for very old hartware...

hey i switch from X800 to an 4670 now i have a 4350 and 4670 for gaming an old computers only to surf/klickaround no 3D is needet...

its completly pointless to make special fixes for modern 3D games vor pre DX10 hartware becourse hd2000 class hartware cost only 5€ used....

upper hartware have 1 more nvidia extansion in openGL soo more code can be shared and upper hartware can use textured vertex shaders X1000 class hartware only can do this in an very diverend way thats hartwork for the wine dev's...

so in my Point of View its stubit to dev for an X1000 class hartware and older...

some of that hardware hardly qualifies as very old

the X2000 series didnt even come out till about this time in 07.... which means that prior to 2 years ago that the X1000 series represented ati's top of the line pc graphics cards... and some of it (an X1950 for insance) can still run an awefull lot of games just fine.

i certianly agree that the majority of effort should be spent on developing for newer hardware, but i certianly can see why they would want to address major bugs for "legacy" hardware.

[Kano]

Well ATI/AMD is such a small company that can not handle things that NVIDIA can do just fine:

* latest kernel support (even with all tricks possible i get dmesg errors with 2.6.30)
* h264 accelleration (and even vc1 if somebody needs it)
* wine working correctly
* vdrift does not crash x server on exit

[AdrenalineJunky]

i fully understand the reasons why amd decided to drop off support - they've been taking a beating and something has to give.

just saying from the wine developers perspective - i think its perfectly reasonable to address major bugs on "legacy" hardware.

[rohcQaH]

Well ATI/AMD is such a small company that can not handle things that NVIDIA can do just fine:

yeah, like providing full hardware specs and open source drivers. Oh, wait...

also, please everyone ignore that AMD has three times as many employees as nvidia and the whole argument as presented is pointless.

* latest kernel support (even with all tricks possible i get dmesg errors with 2.6.30)

I get dmesg errors with nvidia-drivers all the time, no matter the kernel version. What was your point again?

* wine working correctly

this isn't entirely ATIs fault, as wine's D3D-layer was developed for nvidia hardware/drivers. Try the same games on wine on intel GPUs - given intel's size, it should be flawless, right?

Let me rephrase your post:

Nvidia's drivers suit my specific needs way better than ATI's, therefore ATI must suck. Because I like my world simple, I'll just blame company size.

What matters isn't company size, but dedicated linux resources and priorities.

nvidia can support recent kernels by throwing our betas like there's no tomorrow, ATI has longer internal testing phases for the proprietary drivers (and as a result less bloopers in publicly available drivers), but does support new kernels immediately using the in-kernel DRM of mesa.

NVidia has time to develop VPDAU, while AMD is tied up in a massive open sourcing effort, writing up specs and maintaining two drivers at once.

right now, nvidia's drivers may suit your needs better than others. That's fine, keep using them. But concluding that AMD/ATI dedicates less resources to their linux support than nvidia is pretty uninformed.