Gallium3D Now At Version 0.3 In Mesa

[phoronix]

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...

http://www.phoronix.com/vr.php?view=NzE2OQ

[Louise]

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.

[TechMage89]

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.

[Louise]

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.

[NeoBrain]

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.

[Louise]

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.

http://wiki.ps2dev.org/ps3:rsx

http://www.youtube.com/watch?v=ZJQkXmG6UTI

[Craig73]

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)]

[bridgman]

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.

[Craig73]

...further clarifications provided...

Thanks Bridgman. I'm very excited for this, the open source driver space is very interesting (well... especially because I don't get to see inside of the closed source drivers ;-) )

And also thanks NeoBrain, certainly all those reasons make sense.

[larva]

I'm a little suprised by the size reported for these drivers. Though I must admit I don't know how big any corresponding drivers were pre-Gallium. Hence I'm curious if these Gallium drivers are matching expectations -- are they smaller and clearer than the original, non-Gallium drivers?

I realize that this comparison is probably made difficult or impossible by lack of feature parity and that Gallium is still quite new, but I should hope some level of sanity check is possible after all this time.