Announcement

Collapse
No announcement yet.

Wine 1.1.21 and Fglrx

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wine 1.1.21 and Fglrx

    Wine 1.1.21 was released today and it has at least one fix specifically for Fglrx:

    Code:
    Stefan D?singer (19):
          d3d: Limit d3d8 and d3d9 vshader constants to 256.
          wined3d: Support the full amount of constants in GLSL.
          wined3d: Fix a few more direct buffer accesses.
          wined3d: Activate a thread before mapping a buffer.
          wined3d: Fix an issue in buffer_get_sysmem.
          wined3d: Emulate R16G16F and R32G32F if GL_ARB_texture_rg is not supported.
          wined3d: Set the max mipmap level in the pbo test.
          wined3d: Hardcode local loop control ints into the code in reps.
          wined3d: Implement texldd.
          wined3d: Make use of GL_ARB_half_float_vertex.
          wined3d: Pack ARB srgb constants better.
          wined3d: Pack hardcoded local constants in ARB.
          wined3d: Keep track of used float constants.
          wined3d: Always declare single constants in ARB if rel addr is not used.
          [B]wined3d: Work around a bad crash in fglrx.[/B]
          wined3d: Add a point size test.
          winedd: Move shader_*_add_instruction_modifiers into the shader backend.
          wined3d: Pass the instr to pshader_gen_output_modifier_line.
          wined3d: Get rid of pshader_gen_output_modifier_line.
    Anyone tried this version yet? If so, what was your experience?

  • #2
    Originally posted by Qaridarium
    yes for old catalyst nice.. but stefan d?singer use 9-4...

    the 9-5 will have some wine fixes again!

    next week the 9-5 will come so we will see if 9-5+wine1.1.21 works well or "Stefan D?singer" fixes some only-9-4-catalyst bugs and the 9-5 one brings the same result to 1.1.20 wine.
    Quo vadis?

    Comment


    • #3
      Originally posted by Qaridarium
      yes for old catalyst nice.. but stefan d?singer use 9-4...
      Actually the work around is for 9.3:

      Originally posted by wine.git
      fglrx crashes with a very bad kernel panic if GL_POINT_SPRITE_ARB is set to GL_COORD_REPLACE_ARB on more than one texture unit. This means that the d3d9 visual point size test will cause a kernel panic on any machine running fglrx 9.3(latest that supports r300 to r500 cards).

      Originally posted by Qaridarium
      or "Stefan D?singer" fixes some only-9-4-catalyst bugs and the 9-5 one brings the same result to 1.1.20 wine.
      It's AMD's job to fix the bugs in their drivers, not Stefan's job.

      Comment


      • #4
        Originally posted by Qaridarium
        yes for old catalyst nice.. but stefan d?singer use 9-4...

        the 9-5 will have some wine fixes again!

        next week the 9-5 will come so we will see if 9-5+wine1.1.21 works well or "Stefan D?singer" fixes some only-9-4-catalyst bugs and the 9-5 one brings the same result to 1.1.20 wine.
        I think Stefan only has a X1000 series card so he can't be using 9-4 unless he got a dx10 card recently.

        Comment


        • #5
          so AMD should provide a 4890 to him

          Comment


          • #6
            Originally posted by Qaridarium
            Yes thats right but the bugs are fixed in 9-4 catalyst and 9-5 catalyst!

            Its not stefan's job yes yes yes but its useles to make workarounds for the broken 9-3 catalyst,.
            Unless you have a card not supported by the Catalyst 9.4 and 9.5, which doesn't work with an x1000 series card or older.

            Comment


            • #7
              Originally posted by monkeynut View Post
              Unless you have a card not supported by the Catalyst 9.4 and 9.5, which doesn't work with an x1000 series card or older.
              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.

              Comment


              • #8
                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:
                Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.


                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; 09 May 2009, 10:27 PM.

                Comment


                • #9
                  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; 10 May 2009, 02:14 AM.
                  Test signature

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X