Announcement

Collapse
No announcement yet.

Updated and Optimized Ubuntu Free Graphics Drivers

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

  • Mesa is built with llvm 3.5 now.
    I don't plan to upload newer xorg, it would require to rebuild many drivers, the advantages are not enough.

    Comment


    • Originally posted by oibaf View Post
      Mesa is built with llvm 3.5 now.
      I don't plan to upload newer xorg, it would require to rebuild many drivers, the advantages are not enough.

      Can you build Mesa with the D3D9 state tracker? It will be appreciated be many.

      Comment


      • Originally posted by artivision View Post
        Can you build Mesa with the D3D9 state tracker? It will be appreciated be many.
        I don't have time to look into this now. If someone is interested and has a working patch can post it here, I could eventually add it to the ppa.

        Comment


        • Trouble on the way...

          There is some trouble on the way. It comes to OpenCL - the dependencies are now not fully correct.

          Updated stack brought LLVM-3.5 and most driver part are now built agains LLVM 3.5, making LLVM 3.4 mostly obsolete.

          However, mesa-opencl-icd package from your PPA depends on at least ocl-icd-libopencl1 and libclc-r600 which are NOT provided by your PPA. Ancient system versions of these packages are used instead (about half year old).
          Thats where we have trouble on the way (obsoleted) libclc-r600 depends on (obsoleted) libclang-common-3.4-dev (and also on ancient libclc-dev). So OpenCL stack would NOT use brand-new 3.5-rc, which is pity since LLVM 3.4 is totally broken in this regard.

          What worse, dependencies are not fully correct at this point. It is now perfectly possible to purge libclang1-3.4 (not referenced by other packages). This however would break OpenCL to degree it cant build OpenCL programs.

          Needless to say, programs using opencl can face nuclear fallout in strange ways:
          Code:
          [2014-07-26 22:02:26] In file included from <built-in>:296:
          In file included from <command line>:7:
          In file included from /usr/include/clc/clc.h:18:
          /usr/include/clc/clctypes.h:3:10: fatal error: 'stddef.h' file not found
          ???Segmentation fault
          I do think you may want to build ocl-icd-libopencl1, libclc-r600 and libclc-dev packages against LLVM 3.5 and appropriate versions of each other? Sorry for some extra work :\.

          P.S. and as for MESA DX state tracker: what practical use of it? Wine does not relies on it and it's not like if there were some DX apps built for Linux. So it has been ditched for a reason - there is virtually no use for this artifact and it got abandoned.
          Last edited by 0xBADCODE; 07-26-2014, 02:38 PM.

          Comment


          • Originally posted by 0xBADCODE View Post
            P.S. and as for MESA DX state tracker: what practical use of it?
            As example @tizbac answered me on YouTube that with Gallium-Nine and Nouveau he have better performance in GTA4 than in Nvidia blob and WineD3D. So I suppose it's can be interesting experiment.

            Originally posted by 0xBADCODE View Post
            Wine does not relies on it and it's not like if there were some DX apps built for Linux.
            As far as I get Wine patch that required to support it isn't that big at all.
            Patched Wine can be easily distributed with something like PlayOnLinux.

            Originally posted by 0xBADCODE View Post
            So it has been ditched for a reason - there is virtually no use for this artifact and it got abandoned.
            No it's not abandoned. There is repo it's recently merged into recent Mesa:
            https://github.com/iXit/Mesa-3D/commits/master
            And some guys still around on #d3d9 IRC on freenode.

            PS: I didn't yet made any test of current version so I can't say in what state it is.
            Last edited by _SXX_; 07-26-2014, 02:52 PM.

            Comment


            • Quick update: its possible to fix OpenCL without Oibaf by installing libclang1-3.5 package manually. Then LLVM 3.5 seems to be used - it improves things vs 3.4 heck a LOT.

              Comment


              • Originally posted by _SXX_ View Post
                So I suppose it's can be interesting experiment.
                Has nouveau got working reclocking, after all? This is absolutely mandatory for anyhow serious competition with anything around. From what I've read from Phoronix, it looks rather pessimistic and I wouldn't count on nouveau for me at all (and I'm not a big fan of blob drivers in opensource systems either). Needless to say, for that reason I prefer Intel GPU on notebook and AMD GPUs on desktop and somesuch (looking forward to get some few powerful opencl based number crunchers on wheels, could be something *really* interesting to try on opensource stack, eh?).

                As far as I get Wine patch that required to support it isn't that big at all.
                Patched Wine can be easily distributed with something like PlayOnLinux.
                My personal opinion is that Linux have to support native code in first place as first priority, support of foreign proprietary code doomed to be suboptimal and troublesome here and there anyway. If someone want to run proprietary windows binary, they can boot windows, after all (I doubt you've bought Windows game without being able to run it, eh?). If someone want game to run on Linux, they would be better to ask vendor for native port. Causing ton of headache to others with all these odd things is IMO a really wrong idea.

                No it's not abandoned. There is repo it's recently merged into recent Mesa:
                https://github.com/iXit/Mesa-3D/commits/master
                And some guys still around on #d3d9 IRC on freenode.
                Whatever. I bet DX would never be first class citizen in Linux due to proprietary/vendor locked nature of this API. Which makes it "unwelcome guest" IMO. And if someone wants "windows but opensource", there is already ReactOS. But looking on how crappy it performs 15 years since launch it looks like if not too much devs actually want to be just a mindless followers of MS who blindly reimplemends MS-only proprietary APIs. For these reasons I mostly classify all thsi DX-in-Linux as waste of time. MS would always have advantage as creator of API, so there is no point to even try to beat them. This is battle you can't win for sure.

                Long story short: I think Linux is good enough to have own path, without being "Windows but opensource" or whatever else.
                Last edited by 0xBADCODE; 07-26-2014, 03:16 PM.

                Comment


                • Originally posted by 0xBADCODE View Post
                  Has nouveau got working reclocking, after all? This is absolutely mandatory for anyhow serious competition with anything around.
                  As stated in comment to video I linked it's was only partially reclocked GPU and not reclocked memory, but still had better performance than Nvidia blob. Considering @tizbac done tons of Gallium Nine testing I have no reasons to not trust him.

                  Originally posted by 0xBADCODE View Post
                  My personal opinion is that Linux have to support native code in first place as first priority, support of foreign proprietary code doomed to be suboptimal and troublesome here and there anyway. If someone want to run proprietary windows binary, they can boot windows, after all (I doubt you've bought Windows game without being able to run it, eh?). If someone want game to run on Linux, they would be better to ask vendor for native port. Causing ton of headache to others with all these odd things is IMO a really wrong idea.
                  We already have Wine and many people use it. Does it hurt if we work a bit better?

                  Anyway this is really off-topic and unfortunately I not the guy who able to maintain patches for Mesa because nearly zero of free time. So we might create some other topic for Gallium nine if you want some slow discussion about that.

                  ...

                  Back on topic. Is LLVM 3.5 bring any improvements at all for LLVM backend of R600g driver or no?

                  Comment


                  • Originally posted by 0xBADCODE View Post
                    Has nouveau got working reclocking, after all? This is absolutely mandatory for anyhow serious competition with anything around. From what I've read from Phoronix, it looks rather pessimistic and I wouldn't count on nouveau for me at all (and I'm not a big fan of blob drivers in opensource systems either). Needless to say, for that reason I prefer Intel GPU on notebook and AMD GPUs on desktop and somesuch (looking forward to get some few powerful opencl based number crunchers on wheels, could be something *really* interesting to try on opensource stack, eh?).


                    My personal opinion is that Linux have to support native code in first place as first priority, support of foreign proprietary code doomed to be suboptimal and troublesome here and there anyway. If someone want to run proprietary windows binary, they can boot windows, after all (I doubt you've bought Windows game without being able to run it, eh?). If someone want game to run on Linux, they would be better to ask vendor for native port. Causing ton of headache to others with all these odd things is IMO a really wrong idea.


                    Whatever. I bet DX would never be first class citizen in Linux due to proprietary/vendor locked nature of this API. Which makes it "unwelcome guest" IMO. And if someone wants "windows but opensource", there is already ReactOS. But looking on how crappy it performs 15 years since launch it looks like if not too much devs actually want to be just a mindless followers of MS who blindly reimplemends MS-only proprietary APIs. For these reasons I mostly classify all thsi DX-in-Linux as waste of time. MS would always have advantage as creator of API, so there is no point to even try to beat them. This is battle you can't win for sure.

                    Long story short: I think Linux is good enough to have own path, without being "Windows but opensource" or whatever else.



                    We want to play our favorite games (art), without the need of proprietary software (player) like Windowz and D3D. To any computer available, not make as buy consoles or x86 without our will. Meaning open resources like OGL and dynamically linked compilation like LLVM-JIT (maybe with persistent cache). No DRM. Same performance, universal play.

                    Because we don't have that, we need a compatibility layer (mostly D3D) on Linux, plus a better recompiler like a better Qemu-LLVM or better.

                    My main concern for today's D3D on Linux is that a D3D state tracker can be based on an OGL one and can be developed 10 times faster than Wine's translation layer, just with one developer. Only then i measure the native speed. As for availability, i believe with a Gallium patch, a state tracker can be used even with closed drivers, like when you install mesa on Windowz.

                    Comment


                    • I pushed an updated libclc (current git), now also built with llvm-3.5. Mesa is rebuilding now. Please try it in a hour or so.
                      BTW, which OpenCL applications do you use? Are them applications in Ubuntu archive or external apps?

                      Comment

                      Working...
                      X