RADV Ray-Tracing Now Rendering Quake II RTX Correctly But Very Slowly

[Venemo]

tomas give it a period of time after release when people will realize there are too many games that has issues with it. and then we'll see how many will stay on linux. steam survey still have a very low % of linux user even after so many years

If you see issues, please open a bug report, so we have a chance to fix it.

[smitty3268]

Everyone seems to talk about wasted potential, but all of the proposed solutions boil down to "AMD should spend more money", ie "AMD should stop doing something that takes a small amount of engineering time and instead do something that takes a large amount of engineering time".

I have a tough time reconciling those two points.

radv currently takes 0 amount of money from AMD. I have a hard time seeing how having 1 developer work on it part time is going to bankrupt you.

It also wouldn't take a single dime for AMD to provide early hardware access to Baz so he could get the driver up and running faster when the next hardware generations come out. It's pretty difficult to view AMD as being friendly towards radv when something so easily done isn't.

Edit - for the record, I'm not saying AMD is obligated to do any of that. Obviously they aren't, and AMD isn't actively hostile towards radv. I just think it's a bit of a stretch to talk about how friendly AMD is towards it, and how difficult it is to provide any assistance to it, when it's not that difficult at all.

[tomas]

tomas give it a period of time after release when people will realize there are too many games that has issues with it. and then we'll see how many will stay on linux. steam survey still have a very low % of linux user even after so many years

It almost sounds like you want the Deck to fail or at least that everyone should install Windows on the Deck?
I fail to see what the percentage of Linux users in Steam have to do with the prospect of SteamOS on the Deck. Those are 2 very different kind of situations. The former is about the incentive for a current Windows users to install Linux on his/her computer in order to play a subset of the games he/she is currently playing. The latter is about a new handheld console-like device (Yes, I know it's technically a PC, but most people will not see it as such. Otherwise we would not see all comparisons with the Nintendo Switch). You overestimate the number of users that have the skills and motivation to tinker with the Deck in order to install Windows on it and get it working well. The survey I linked to proves that. Allthough not a scientifically conducted study, I think It's fairly accurate given the number of respondents and sample selection. If you actually read the comments made to that survey you will also see a lot of users that never used Linux before but anyway state that they will not bother to install Windows, even though they know that it rules out Microsoft Game Pass and other games stores. In fact, many talk about using the Deck for emulators (like Dolphin and others) and those run just fine (better even) on Linux.

[user1]

radv currently takes 0 amount of money from AMD. I have a hard time seeing how having 1 developer work on it part time is going to bankrupt you.

It also wouldn't take a single dime for AMD to provide early hardware access to Baz so he could get the driver up and running faster when the next hardware generations come out. It's pretty difficult to view AMD as being friendly towards radv when something so easily done isn't.

Edit - for the record, I'm not saying AMD is obligated to do any of that. Obviously they aren't, and AMD isn't actively hostile towards radv. I just think it's a bit of a stretch to talk about how friendly AMD is towards it, and how difficult it is to provide any assistance to it, when it's not that difficult at all.

Exactly. I mean does it cost anything to provide RADV devs with early hardware documentation? Or will that involve some bureaucratic issues?
Heck, I don't even think assigning an AMD developer to work on RADV will create that much difference, because RADV already has a lot of talented developers (after all, the main difference between RADV and RadeonSi developers is that the first is sponsored by Valve and the latter by AMD). But simply providing them with early hardware documentation like RadeonSi devs, will create a huge difference.

[loganj]

tomas you got me wrong

i really want it to see a huge success with it under linux. that way maybe devs will start to consider linux clients or at least use vulkan instead of dx.
and the % i've mention is not the user that wants to install linux but the user that actually use linux. its a big difference and lets face it that windows is very popular due to all the games that runs on it.
also this is not the only console that use ryzen cpu. there is one very similar to this one with 4000 series cpu and that one has w10 on it.

[tomas]

tomas... very similar to this one with 4000 series cpu and that one has w10 on it.

And it lacks the brand recognition of Valve and Steam. The Deck will outsell that one several times. And I bet you that in the end only a minority will install and run Windows as their primary OS on the Deck. Have some faith. 😊.

[agd5f]

I mean does it cost anything to provide RADV devs with early hardware documentation?

It's already provided in the form of radeonsi and kernel driver code releases prior to launch. Writing good documentation takes a lot of time and effort and getting and enforcing NDAs on documentation for random developers for chips where accidental leaks could have a major impact on AMD's bottom line are a big risk.

[smitty3268]

It's already provided in the form of radeonsi and kernel driver code releases prior to launch. Writing good documentation takes a lot of time and effort and getting and enforcing NDAs on documentation for random developers for chips where accidental leaks could have a major impact on AMD's bottom line are a big risk.

I mean no offense by this, but this is exactly the type of response you get from a big corporation trying to blow you off and ignore you, rather than one that's trying to make a genuine effort to solve problems.

Yes, technically everything you say is correct. But AMD could absolutely solve this type of thing if they wanted to. They do for all sorts of others, because the money is there and it's worth it for them. You don't see AMD telling governments they can't view their proprietary code because it's a security risk. You don't see them not shipping early hardware out to their hardware partners because it's a security risk - in spite of the fact that's where 99% of early leaks come from. Because they view that as a cost of doing business.

There are plenty of ways to mitigate risk while helping radv if AMD wanted to, but they choose not to bother with it for radv, because they don't care about solving any problems there enough to worry about it.

[agd5f]

I mean no offense by this, but this is exactly the type of response you get from a big corporation trying to blow you off and ignore you, rather than one that's trying to make a genuine effort to solve problems.

Yes, technically everything you say is correct. But AMD could absolutely solve this type of thing if they wanted to. They do for all sorts of others, because the money is there and it's worth it for them. You don't see AMD telling governments they can't view their proprietary code because it's a security risk. You don't see them not shipping early hardware out to their hardware partners because it's a security risk - in spite of the fact that's where 99% of early leaks come from. Because they view that as a cost of doing business.

There are plenty of ways to mitigate risk while helping radv if AMD wanted to, but they choose not to bother with it for radv, because they don't care about solving any problems there enough to worry about it.

I think you misunderstood my point. Getting sensitive documentation out to developers prior to hardware launch (which is what was requested by the OP), would expose AMD to a lot of risk if some random developer were to leak the information at that point. Partners and random developers are two very different things. Partners of course have access to the materials they need to make our joint projects work. Once a product launches, that is a different matter.

In addition to the source code I mentioned, we also have developers that actively work on upstream projects and are approachable via email and IRC to discuss these sort of things.