Benchmarks Of AMD's Newest Gallium3D Driver

[duby229]

means ... galium3D is ready and the hd6000 support will come with only galium3D only support

the classic mesa is not a "proprietary driver design" means they just drop classic mesa.

why do you don't speak clear words ? like: yay galium3D is ready now we can kill classic mesa ....

I dont think that is what he is saying. I took it as they are working with members of the hardware team and probably also the catalyst team who are now assembling docs and code for the next gen in catalyst. Which means that they can more easily get information that they need in better formats.

Previous generations of hardware were not documented for open source drivers. Working with the original teams writing docs will help them enormously.

[bridgman]

Right. Nothing to do with Gallium3D vs classic... the r600g driver has *also* reached the point where we're going to use it for initial support of new GPUs, but that is total coincidence.

What I'm talking about is piggybacking on the "learn about the new HW changes" portion of the SW design effort for proprietary drivers. We're quite late for the 2011 graphics core effort (most of the SW design work is finished) but we should be able to get some benefit anyways.

[runeks]

i know the obvious response at this point will be "but if you moved the catalyst for linux developers to the open source driver then you could have gl4 etc...", but that's not how it works. We develop the catalyst driver code and share it across 100% of the pc market (ie all oses), but if we moved the devs who make that common code available on linux to working on the open source driver then they would not be able to leverage the work done for all of the other oses, ie they would be working on a linux-specific code base, and the same number of developers would *not* be able to deliver the same level of features and performance.

Put simply, open source drivers share code across hw vendors (ie the intel, radeon and nouveau driver stacks share a lot of common code, which is why they have similar features) while proprietary drivers share code across oses.

Is implementing Gallium3D on Windows and Mac OS, to enable cross platform (OS) driver support, in any way realistic?

Do you think that this would reduce your workload significantly, or are you already, in the development of the Catalyst driver, sharing so much API- and driver code between OSes that Gallium won't make that much of a difference?

[glisse]

Is implementing Gallium3D on Windows and Mac OS, to enable cross platform (OS) driver support, in any way realistic?

Do you think that this would reduce your workload significantly, or are you already, in the development of the Catalyst driver, sharing so much API- and driver code between OSes that Gallium won't make that much of a difference?

Catalyst code will never be release, too much IP in it. I am pretty sure they will also never switch to gallium even if it's doable to use gallium to do DX or GL driver for windows. Gallium infrastructure is about sharing accross different GPU manufacturer and this means they are design choice that doesn't fit well all the hw but are the best compromise. So for a really fast driver able to squeeze all the performance out of the GPU you need a stack that is designed for it, i believe this is what catalyst is.

I think bottom line is AMD won't put more $ resource on open source hw unless the suddenly see a load of $ coming back, thing is there is no way for them to know how much an open source driver matter to OEM or HP, Dell, Lenovo ... It's all about selling hw, if having a good open source driver give them a 5% increase or more in market share then they will put resource on open source driver. It's obviously not the case today but things like chromeos or others nettop or laptop design under linux might lead to more incentive from OEM to improve the open source stuff.

[runeks]

Yeah, I see your point. I guess Gallium isn't very suited for cross OS compatibility after all, if hacks/intentional bugs added to the Catalyst driver are the norm to make them work faster with buggy games. That just sounds like mess to bring into the Gallium code. If these application-specific hacks could be separated into a specific state tracker, that would help though.

But on the other hand, if the Gallium infrastructure would save the AMD developers some time in the end, this time could be used to implement further optimizations (that they wouldn't have time to do were they not using Gallium), and thus - perhaps - gaining a bit of the performance back that Gallium takes away in order to reduce complexity?

But of course if they have to develop the whole thing from scratch because of the IP issues you mention, this obviously isn't a viable option. But I imagine that if it indeed is true that moving the driver development over to Gallium would save time in the end, then this will happen quite automatically and organically, as the Gallium drivers mature, and the advantages, and disadvantages, become more obvious.
It is with this as with most things probably; a sudden and drastic change - scrapping all Catalyst code, and developing the drivers from scratch for Gallium - doesn't work. Only a slow, gradual migration from the current Catalyst infrastructure to Gallium has a chance to work.

[Jonno]

Regarding porting, Gallium3D already works on MS Windows!

However, all the hw pipe drivers also require the kernel direct rendering infrastructure version 2 (dri2, implying kms), which is not ported from Linux to the Windows kernel, so you only get softpipe/llvmpipe.

Porting dri2 and kms to Windows Vista/2k8/7/2k8R2 should be doable, but would require a lot of work for very little gain, and is thus unlikely to happen. Perhaps if ReactOS moves to the Vista driver model, instead of the WinXP/2k3 driver model they currently use, it would be of interest to them, and as ReactOS kernel modules are binary compatible with Windows kernel modules you would get Windows compatibility for free. Don't bet on it though...

[runeks]

However, all the hw pipe drivers also require the kernel direct rendering infrastructure version 2 (dri2, implying kms), which is not ported from Linux to the Windows kernel, so you only get softpipe/llvmpipe.

Hmm. I thought the purpose of Gallium was to separate out the API/driver/OS bits from each other. How can it be that the drivers rely on something OS specific?
I also don't understand why there are GPU-specific stuff ("radeon", "r600", "nouveau" etc.) in the "winsys" source folder of mesa which, as far as I have understood, is just for the OS specific stuff. But then again I am just beginning to learn how this whole puzzle fits together, so it's entirely possible that I'm missing something.

[Jonno]

Hmm. I thought the purpose of Gallium was to separate out the API/driver/OS bits from each other. How can it be that the drivers rely on something OS specific?
I also don't understand why there are GPU-specific stuff ("radeon", "r600", "nouveau" etc.) in the "winsys" source folder of mesa which, as far as I have understood, is just for the OS specific stuff. But then again I am just beginning to learn how this whole puzzle fits together, so it's entirely possible that I'm missing something.

First of, winsys isn't OS specific, it is windowing system specific. A single windowing system may be supported on multiple operating system, and a single operating system may offer multiple windowing systems. For example the fbdev, xlib and drm winsys are all available on Linux, while xlib are available on *BSD and (Open)Solaris as well.

Secondly, most windowing system specific code can not be shared between between pipe drivers, which is why there are separate "sw", "radeon", "r600", "nouveau", etc folders in the winsys folder. Most hardware drivers are only support the drm windowing system, which is the direct rendering module of X11 (which uses the direct rendering infrastructure on Linux, *BSD and (Open)Solaris kernels), as most other windowing systems do not allow direct hardware access. Gallium3D requires drm2, which requires dri2, which currently is only implemented on Linux, but *BSD and (Open)Solaris support is reportedly in the works.

The only supported windowing system on MS windows is GDI/GDI+, which does not allow direct HW access. For HW support on Windows you would need to either write a WDDM winsys and a WDDM kernel driver for each hardware, or port the dri kernel driver to the windows kernel (hooking it into WDDM), and update libdrm and the drm winsys to work with it.

[glisse]

Few precisions, there is no such things as drm2. DRI2 is specific to X, it's how X & direct rendering client communicate to each other about front buffer & others auxialiry buffer such as zbuffer or stencil.

Gallium driver doesn't care about dri2, drm or anythings. In winsys there is a part about windowing system in targets/ folder that target a specific windowing system (here you will mostly see dri fold along egl one).

The hw specific folder in winsys are their to abstract from the pipe driver how to communicate with the hw. On linux we use drm, if one wanted to use r600 on windows what is needed is a winsys r600 implementation that should endup in winsys/r600/win and which implement all the interface defined in drivers/r600/r600.h. Other piece needed is somethings to integrate with the windowing system that should endup in targets/win-r600 for instance.

Thing is we decided that we wanted memory management as a requirement for r600g that means we exclude non kms setup and so we restricted r600g to only work on dri2+kms. This doesn't mean that dri2 or kms are needed for r600g, in fact one could make a dri1 winsys for r600g, we would just ignore it.

[bridgman]

The main reason we are not likely to "move to Gallium3D" is that we started moving to something *like* Gallium3D a few years earlier. The new driver stack showed up first in Vista GL, and arrived in Linux around Sept 2007.

The open source stack has a very small hardware-specific layer and most of the code is common between vendors. The proprietary stack has relatively more of the code in the hardware-specific layer because that allows slightly higher performance (although it's a lot more work as well). That was one of the factors that led to our initial guesses that the open source stack would end up somewhere around 60-70% of fglrx 3D performance.

So... bottom line is that we already run on a Gallium3D-ish architecture (and I imagine that other proprietary drivers do as well) so I don't think there would be much benefit to changing again.