Interstellar Marines On Linux With Catalyst: Bull S*#@

[BradN]

SO basically AMD is taking all the good parts of fglrx and plugging it into Mesa. This should allow great kernel support, great 3D support, great 2d support, and no bullshit 1 click upgrade to non-pro and pro radeon stacks. It allows simultaneous improvement from both AMD and the open source community.

I don't think this is totally correct. My impression was that the kernel side driver (that manages hardware access, manages video memory, various low level stuff, etc) will be open source and shared between mesa and AMD's proprietary driver.

AMD will still have a proprietary, closed source OpenGL/OpenCL driver. Just, none of it will run in kernel space.

I think the biggest concrete benefit that might be had out of this is that using the proprietary driver won't be as painful during kernel updates, maybe some kernel side bugs will get fixed compared to the current open source offering, and perhaps using VGA passthru with virtual machines might work a little better being as that's mostly a concern of the low level kernel side code that's becoming fully open source.

[teeedubb]

Crappy performance from the catalyst driver? How is this even news?

[bridgman]

Nope. Catalyst and Mesa are literally being merged. Catalyst will go through the kernel just like Mesa, and will in fact use mostly Mesa kernel code paths.

The only parts that are not being opened are proprietary bits that are essential to AMD driver security and patents.

You will be able to choose
1: Mostly open source
2: A balance of both
3: Mostly closed source

There is a driver model slide AMD put out that explains it. Basically the merge fixes everything that is wrong with both drivers.

At least that is how I understood it. Someone correct me if I am wrong.

Not really merging anything into Mesa.

The closed-source and open-source userspace stacks will run over a common open source kernel driver derived from radeon and a common open source X driver derived from radeon/ati.

You will be able to choose between all-open and "hybrid" stacks, where "hybrid" is Catalyst userspace plus the common open source kernel and X drivers.

[grndzro]

I don't think this is totally correct. My impression was that the kernel side driver (that manages hardware access, manages video memory, various low level stuff, etc) will be open source and shared between mesa and AMD's proprietary driver.

AMD will still have a proprietary, closed source OpenGL/OpenCL driver. Just, none of it will run in kernel space.

I think the biggest concrete benefit that might be had out of this is that using the proprietary driver won't be as painful during kernel updates, maybe some kernel side bugs will get fixed compared to the current open source offering, and perhaps using VGA passthru with virtual machines might work a little better being as that's mostly a concern of the low level kernel side code that's becoming fully open source.

I agree with all of that. I would like to point out that there will be absolutely no binary blobs in the kernel. That's what led to my reasoning that what we now know as fglrx will be kind of a sidecar to amdgpu and superceding(but still passing through) it when installed. Kind of like plugins.

[nanonyme]

Not really merging anything into Mesa.

The closed-source and open-source userspace stacks will run over a common open source kernel driver derived from radeon and a common open source X driver derived from radeon/ati.

You will be able to choose between all-open and "hybrid" stacks, where "hybrid" is Catalyst userspace plus the common open source kernel and X drivers.

Aww, I was kind of hoping the modesetting driver to already be ready enough to sunset the radeon driver in X for this new driver

[duby229]

I agree with all of that. I would like to point out that there will be absolutely no binary blobs in the kernel. That's what led to my reasoning that what we now know as fglrx will be kind of a sidecar to amdgpu and superceding(but still passing through) it when installed. Kind of like plugins.

That's not true, the firmwares are all binary blobs.

[bridgman]

The microcode images are not "in the kernel", they're just external files which the kernel code copies into the hardware.

I think grndzro is trying to say that the kernel driver will be completely open source, which is the plan.

[duby229]

The microcode images are not "in the kernel", they're just external files which the kernel code copies into the hardware.

I think grndzro is trying to say that the kernel driver will be completely open source, which is the plan.

I don't mean anything negative by it. But, the kernel driver won't function without the appropriate firmwares. So it's the same difference.

[grndzro]

I don't mean anything negative by it. But, the kernel driver won't function without the appropriate firmwares. So it's the same difference.

Firmware is hardware drivers. IE bios/cmos. It is an off system intermediary between the actual hardware and the OS. Microcode falls into this category.

Linus and everyone else who manages the kernel would throw a fit if there was anything closed source/binary in the kernel.

Considering I haven't been corrected by Bridgeman yet I'll assume I am on the right track.

[grndzro]

where "hybrid" is Catalyst userspace plus the common open source kernel and X drivers.

Does that mean the xf86-video-amdgpu userspace will have kind of a passthrough for the Catalyst drivers? If so then the xf86-video-amdgpu part will have 3 modes. Would the Catalyst components be provided out of the box in open source sensitive distro's?

Sorry I'm just trying to wrap my head around it all. By merging I meant from a kernel access perspective.