ATI R600g Gains Mip-Map, Face Culling Support

[bridgman]

Yes, but given the high skill of crackers, and the fact that you can trace (and alter) the GPU command stream anyway (see renouveau and revenge), it's not obvious that it makes a significant difference (especially if the open code is just a minimal command submission/resource manager layer).

The problem is that we have to "stay well back from the abyss"... it's not like we can keep opening things up until something bad happens then back off a bit

Yes, that could be a concern.
It's interesting to note though that in the x86 market you don't even need a software stack, and the architecture is very well documented (including performance aspects and sometimes architecture details), yet no one manages to compete with AMD and Intel outside perhaps of very low-end markets (e.g. VIA).

Getting into x86 isn't that simple. Not my area to talk about though. There is a non-trivial software stack, BTW, it's just between OS and hardware rather than app and hardware. I wasn't really aware of the CPU software stack until we joined up with AMD.

Interesting.
Perhaps the reason is that the perception of the drivers has actually improved much less than the drivers themselves? (due to the open drivers still being primitive and fglrx's past inferiority). While trivial, perhaps renaming "fglrx" to "Catalyst" and favorable independent comparisons with nVidia could help shed those old perceptions.

It is actually called Catalyst for Linux, or something like that. I just don't like being nitpicky by correcting everyone who calls it fglrx (and fglrx is way easier to type ).

Would you really need to release substantial code?
Isn't the current open Radeon kernel driver already good enough at least for supporting fglrx in single GPU configurations where KMS already works? Or maybe you have a different and better kernel architecture (e.g. userspace vs kernel command submission) and thus would need to open that?

I don't have actual test results, but I suspect that the current Mesa driver over our libdrm/kernel code would be *much* faster than the current proprietary 3D driver over the open libdrm/kernel code.

That doesn't mean the devs don't know how to write a fast kernel driver, just that the focus right now is still on functionality & robustness rather than performance optimization. Any of the devs working on the kernel driver can rattle off a list of all the things they would like to improve given time.

Why not just adapt to the changes in the open drivers? The Linux kernel has an approximately 3 month release cycle, which should give time to prepare at least a Linux-only update for any ABI changes. Also, incompatible changes to the ABI tend to be frowned upon (see the Nouveau ABI break debate for instance).

We would have to do that, of course, but it would be all to easy to end up in a situation where kernel driver changes that make Mesa faster also make the proprietary driver slower, for example. What is "the right decision" in that scenario ?

Really? I would expect multi-GPU instead to be more prominent in the future, as software support improves and compute gets more prevalent (with "GPU SMP" systems becoming standard for compute servers).

Multi-GPU support for compute is less of a problem since the nature of the workload makes it easier for the split across multiple engines to be exposed at an application/API level. Graphics is a tougher challenge because you have to pretty much invisibly emulate a single GPU.

[monraaf]

The problem is that we have to "stay well back from the abyss"... it's not like we can keep opening things up until something bad happens then back off a bit

Exactly. That's why we are not only not opening up XvBA but also demand of the chosen few who do have access to the XvBA sdk that any app/library they develop shall remain closed source. Sort of a reverse GPL. All in all, this doesn't score AMD points for open source friendliness.

[Agdr]

It is actually called Catalyst for Linux, or something like that. I just don't like being nitpicky by correcting everyone who calls it fglrx (and fglrx is way easier to type ).

The kernel module is still called "fglrx.ko", the X driver is called "fglrx_drv.so" and they both print messages with the "fglrx" string.
It should be possible to rename to "catalyst" and keep compatibility with symlinks and module aliases.

We would have to do that, of course, but it would be all to easy to end up in a situation where kernel driver changes that make Mesa faster also make the proprietary driver slower, for example. What is "the right decision" in that scenario ?

Given that you are willing to release GPU documentation, I guess it should be possible to come to a technical agreement over what is best, or support two options if really necessary (both of which could eventually be useful to the open driver too).

[Agdr]

Exactly. That's why we are not only not opening up XvBA but also demand of the chosen few who do have access to the XvBA sdk that any app/library they develop shall remain closed source. Sort of a reverse GPL. All in all, this doesn't score AMD points for open source friendliness.

Isn't the VA-API support through xvba-video good enough for the closed driver? (I haven't tried it personally, so I have no opinion)

[bridgman]

XvBA is a bit of a different story - it was developed for a market where everything is closed anyways, so the idea of making the API public would be the last thing any of our customers would want. That doesn't do much for the consumer PC client market, of course, so that's the next thing we need to address. For now, gbeauche's VA-API to XvBA adapter is a real nice way to try out the code while we finish development.

We also found that there was a "middle ground" embedded market where everything looked just like a traditional embedded product but it used GPL apps, which made the idea of a closed API kind of problematic. We're hoping that the solution for consumer client PC will also work for that "not quite embedded" market.

[pingufunkybeat]

So XvBA is getting addressed?

At least this is good to know.

[Agdr]

So XvBA is getting addressed?

At least this is good to know.

By the way, the oldest available version of xvba-video has an only 40KB binary, which decompiles using the IDA Pro Hex Rays decompiler to only 5450 lines of C code containing 147 functions.

It even includes asserts and error messages, and both x86-64 and i386 versions are available allowing to more easily determine what is a pointer and what an integer.

Overall, it looks quite easy to reverse engineer to produce open documentation of the XvBA API (although possibly partial due to xvba-video possibly not using all of it).

Not sure however if that provides any advantage over just using it in binary form (given that one needs to rely on closed source code anyway for the XvBA implementation).

[bridgman]

So XvBA is getting addressed? At least this is good to know.

All I can say with 100% certainty is that it hasn't been forgotten and that we're trying to push it ahead.

[monraaf]

Isn't the VA-API support through xvba-video good enough for the closed driver? (I haven't tried it personally, so I have no opinion)

XvBA has been problematic with many cards and has been broken with Evergreen cards since forever. I think the author of xvba-video himself was so frustrated with the state of XvBA that he stated to not really care much about it. If he decides to abandon it then sooner or later there's a real chance of ABI breakage.

Sure you can reverse-engineer it, but why should you. If AMD was as a good open source citizen such as Intel it would just open source their XvBA library. Not that I expect them to do so, but they could at least open up the native API. Even Nvidia is not like that!

[monraaf]

That doesn't do much for the consumer PC client market, of course, so that's the next thing we need to address. For now, gbeauche's VA-API to XvBA adapter is a real nice way to try out the code while we finish development.

When, in 2020? I see you already add support for the Llano and Ontario APUs to XvBA but you could not even fix the Evergreen bug .