Announcement

Collapse
No announcement yet.

Gallium3D Now At Version 0.3 In Mesa

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

  • Gallium3D Now At Version 0.3 In Mesa

    Phoronix: Gallium3D Now At Version 0.3 In Mesa

    It has been a number of months since version 0.2 of Gallium3D was declared, but today Keith Whitwell finally bumped the version to 0.3. While Gallium3D isn't yet in a state for end-users, may changes have went on since the creation of the Gallium3D v0.2 branch...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    In case of Gallium3D for the Cell.

    Is that an effort to try and work around that the PS3 hyper visor disables the 3D acceleration?

    If that's the case, that could be a "problem" Sony would take seriously, as they don't want game developers to be able to release games without buying a license from Sony.

    Comment


    • #3
      No the Gallium3D driver for the cell implements opengl on the cell processor, not the RSX (the 3d chip in the PS3). The cell, because fo the way the SPUs work, actually makes a fairly decent 3d chip. However, the cell will not available for other things (physics processing, for example). Because of this, the performance will never match that of licensed software, which can use both the cell and the RSX

      The RSX is an NVIDIA chip, and while there are efforts underway to get around the hypervisor restrictions, they have met with only a small amount of success.

      Comment


      • #4
        State Trackers

        I was thinking I had a rough handle on the architecture of Gallium3D (a state tracker, connected to a virtualization of modern graphics hardware as an IR, then a translation layer between the IR and graphics hardware, possibly that translation layer replaced with LLVM optimizing compiler and an LLVM hardware description. Also the winsys library to isolate the communications with the OS/windowing system.)

        What confuses me is when we lump DRI2, EGL, G3DVL, GLX, Python, WGL, and Xorg all in as state trackers. I mean it makes sense (to me) that we have a GLX state tracker - it manages OpenGL running on the machine, and makes the appropriate calls via Gallium's IR to handle OpenGL requests.

        But what is the Python state machine? And why is DRI2 called a statemachine (when it seems much more like the winsys layer to me) [Isn't DRI2 in the kernel? Is Gallium3D a userspace driver or it just Xorg that will be moving to userspace with KMS?]

        [BTW - are there plans for D3D state trackers that WINE could leverage to reduce translation? (D3D -> GL -> TGSI -> LLVM -> HARDWARE ... knock GL out of that list)]
        Last edited by Craig73; 25 March 2009, 10:46 AM.

        Comment


        • #5
          Originally posted by TechMage89 View Post
          No the Gallium3D driver for the cell implements opengl on the cell processor, not the RSX (the 3d chip in the PS3). The cell, because fo the way the SPUs work, actually makes a fairly decent 3d chip. However, the cell will not available for other things (physics processing, for example). Because of this, the performance will never match that of licensed software, which can use both the cell and the RSX

          The RSX is an NVIDIA chip, and while there are efforts underway to get around the hypervisor restrictions, they have met with only a small amount of success.
          Okay, so it is to enable some sort of 3D acceleration to the PS3 in a legal way

          When you say Cell, is that just the CPU, or is the the CPU and all the SPU's?

          Wouldn't the SPU's be better for 3D than the core CPU?

          I am really sad that hackers are trying to hack the PS3, as Sony have really done the right thing be enabling Linux out-of-the-box.

          And now this Linux feature plays an important instrument in hacking the PS3 (decrypting the harddrive files).

          It is a pretty safe bet, that the PS4, just will be an overclocked PS3 with 4 times as much memory, so if Linux killed the PS3, Linux won't make it PS4. That's for sure.

          Comment


          • #6
            r300 state

            Hello!

            For some simple statistics, the Cell Gallium3D driver is about 18,900 lines of code, the Nouveau driver spread between the NV04/10/20/30/40/50 series is about 26,800 lines of code, the R300 driver is 9,189 lines of code, ...
            Does this mean only 1/3 of the r300 driver is complete?

            Ciao,
            Olaf

            Comment


            • #7
              Actually, the RSX of the PS3 has been completely accessible already a yeah ago or so. It's only possible to do in certain firmware versions, though, and I don't think there's any decent 3D driver out here for it, yet (on the other hand, I read there was someone porting nouveau to the PS3's RSX).

              About a D3D state tracker in Gallium3D, there is a talk about that at #winehackers at the moment and the current results from that discussion are that a D3D implementation would 1) be unportable (Gallium3D doesn't support Macs or BSD yet) 2) not fit to the current infrastructure in Wine 3) not work on binary blobs and thus be doubled effort (and then the OSS drivers still would only get up to 80% of the blobs' performance) 4) generally be wasted effort as fixing existing bottlenecks is a more efficient way of doing things.

              Comment


              • #8
                When will Gallium3D have support for intel IPG?

                Comment


                • #9
                  Originally posted by Craig73 View Post
                  I was thinking I had a rough handle on the architecture of Gallium3D (a state tracker, connected to a virtualization of modern graphics hardware as an IR, then a translation layer between the IR and graphics hardware, possibly that translation layer replaced with LLVM optimizing compiler and an LLVM hardware description. Also the winsys library to isolate the communications with the OS/windowing system.)

                  What confuses me is when we lump DRI2, EGL, G3DVL, GLX, Python, WGL, and Xorg all in as state trackers. I mean it makes sense (to me) that we have a GLX state tracker - it manages OpenGL running on the machine, and makes the appropriate calls via Gallium's IR to handle OpenGL requests.

                  But what is the Python state machine? And why is DRI2 called a statemachine (when it seems much more like the winsys layer to me) [Isn't DRI2 in the kernel? Is Gallium3D a userspace driver or it just Xorg that will be moving to userspace with KMS?]
                  Your understanding is pretty good. I think you're just seeing typical development challenges, ie "the initial design was pretty good but the initial folder naming needs some tweaks ".

                  The Python part is presumably "Python bindings for Gallium3D", ie the glue code which allows a Python program to use the Gallium API just like any other state tracker. I guess high performance 3D drivers were about the only thing you *couldn't* write in Python before

                  DRI2 isn't really "in the kernel", it's a protocol which lets direct rendering (userspace) drivers communicate with the (userspace) server to obtain information about window locations etc..., but some of that communication may involve the kernel driver (drm). At first glance it does seem that DRI2 should be part of Winsys, but I haven't looked at the code in detail.

                  Gallium3D is userspace; the Xorg "state tracker" is a userspace X driver which (a) passes modesetting commands down to a kernel driver (drm) with KMS, and (b) code that implements EXA acceleration over Gallium3D, just like an OpenGL state tracker implements OpenGL acceleration over Gallium3D. The confusing part is that the xorg state tracker also acts as a pass-through for modesetting, which is not normal for a state tracker -- but the EXA acceleration part *is* normal.

                  If you think of it as "an EXA state tracker with modesetting pass-through to KMS" it makes more sense.
                  Last edited by bridgman; 25 March 2009, 12:49 PM.
                  Test signature

                  Comment


                  • #10
                    Originally posted by NeoBrain View Post
                    Actually, the RSX of the PS3 has been completely accessible already a yeah ago or so. It's only possible to do in certain firmware versions, though, and I don't think there's any decent 3D driver out here for it, yet (on the other hand, I read there was someone porting nouveau to the PS3's RSX).
                    Wow. You are right. I had no idea that they had access to the RSX and workaround the memory split.



                    Comment

                    Working...
                    X