Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 26

Thread: Wine 1.1.21 and Fglrx

  1. #11
    Join Date
    Nov 2007
    Posts
    77

    Default Source games and Wine = Lockup

    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:
    Code:
    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:

    Code:
    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!
    Last edited by Laughing1; 05-09-2009 at 10:27 PM.

  2. #12
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote Originally Posted by nanonyme View Post
    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.
    Last edited by bridgman; 05-10-2009 at 02:14 AM.

  3. #13
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,671

    Default

    Quote Originally Posted by bridgman View Post
    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.

  4. #14
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    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.
    Last edited by bridgman; 05-10-2009 at 03:59 AM.

  5. #15
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by bridgman View Post
    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...

  6. #16
    Join Date
    Nov 2007
    Posts
    77

    Default

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

  7. #17

    Default

    Quote Originally Posted by Qaridarium View Post
    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.

  8. #18
    Join Date
    Aug 2007
    Posts
    6,641

    Default

    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

  9. #19

    Default

    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.

  10. #20
    Join Date
    Nov 2008
    Posts
    776

    Default

    Quote Originally Posted by Kano View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •