Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
Cyberpunk 2077 will be DirectX12 only
Page: «3/4»
  Go to:
Shmerl Jul 5, 2020
Quoting: EhvisIt was possible. NVIDIA made OptiX to do it. But it needs hardware support for realtime graphics. If you want it actually be used by game developers, it needs a standardized cross-vendor API. This makes VK_KHR_ray_tracing not just "a convenience", it makes it essential.

That's exactly the point. Without dedicated hardware, it was all up to general GPU compute units. So extension will need to fall back to them anyway. And a year ago nothing had that dedicated hardware either way.

Therefore there was no benefit in using DXR vs using Vulkan. It was just a bait by both Nvidia and MS who pushed that junk probably colluding with each other.

Last edited by Shmerl on 5 July 2020 at 8:35 am UTC
Ehvis Jul 5, 2020
Quoting: ShmerlTherefore there was no benefit in using DXR vs using Vulkan. It was just a bait by both Nvidia and MS who pushed that junk probably colluding with each other.

Well, we might not like it, but DXR provides the exact same thing as VK_KHR_ray_tracing does. It might be closed, but it is functionally the same. The REDEngine is clearly built around DX11, so switching to DX12 with optional DXR meant the least work. A clear benefit and also a prime example of Vendor lock-in right there.

Nvidia is being normal here. They create new technology and try to push it in order to keep their lead. Same as any company would do. AMD on the other hand create a shiny demonstration video that clearly demonstrated they understood the importance of realtime ray tracing, but did nothing with it. They need to catch up like they did with their CPUs. Consumers need Nvidia to have a full blown competitor, not a company that's several years behind.
Shmerl Jul 5, 2020
Nvidia aren't being normal, if they provide DX support for their features and not Vulkan (you said DXR was a year ahead?). Sounds like MS are paying them to do push lock-in first. That's not normal, it's called collusion.

Last edited by Shmerl on 5 July 2020 at 9:25 am UTC
mylka Jul 5, 2020
Quoting: GuestI've removed it from my wishlist on Steam. Without Vulkan support I will not get this game. DX12 is a bad move.

why? VKD3D works pretty good.
Shmerl Jul 5, 2020
Quoting: GuestThey weren't going to write their own custom compute version.

Yet they somehow are OK with compute fallback for those who don't have dedicated hardware? If they are OK with that, they could write their own too, since back then there was no dedicated hardware anyway.

Quoting: GuestLock-in from MS or not, they were there with something that could be used first, and that matters. Nvidia had raytracing extensions for Vulkan for a while, but they weren't anywhere near considered stable.

So how is that their DXR was stable before their Vulkan extensions? That's dirty corpo in action to me with cozy money from MS flowing into Nvidia's pockets.

Last edited by Shmerl on 5 July 2020 at 2:50 pm UTC
Shmerl Jul 5, 2020
Quoting: mylkawhy? VKD3D works pretty good.

I'm not going to buy it either, at least not for full price for sure. Until there is either a Linux version or until there is a major sale or they at least add a Vulkan renderer. Not interested in encouraging this corrupt DX12 junk.

Last edited by Shmerl on 5 July 2020 at 2:48 pm UTC
Shmerl Jul 5, 2020
Quoting: GuestDo you think you could write an entire fallback raytraced renderer on your own?

Ray tracing exists for decades. It's not something new or unheard of. So yeah, they totally can write whatever they want, if they don't aim for dedicated hardware. It was never going to perform well in real time anyway.

Last edited by Shmerl on 5 July 2020 at 3:24 pm UTC
Shmerl Jul 5, 2020
Quoting: Guest]Because Vulkan is not under the control of a single entity, and attempts to be something cross-vendor. Microsoft are in a position to make something, and then dictate that vendors conform to their specification. Same reason that Apple released Metal before Vulkan was released. Same reason that Mantle came from a single vendor first. Same reason that nvidia control CUDA and don't have to adapt it to OpenCL.

Not really applicable here, since Nvidia made their own extensions for Vulkan first. No one had to collaborate on them. Only the common extensions required collaborative input already. So I see it as clear corruption that Nvidia made DXR first and only then their own Vulkan extensions. Money from MS must have been convincing.

Last edited by Shmerl on 5 July 2020 at 3:28 pm UTC
Shmerl Jul 5, 2020
Quoting: GuestWith that statement, it does actually show that you're not aware of the complexities involved. No, they can't just write a raytracer on their own and tac it onto their game. It's simply not feasible.

How is it not feasible? Ray tracing algorithms are well known and documented. As I said, it's not a new idea, it's been around for decades. If it's feasible to write a fallback compute path for those extensions, it should be totally feasible to write it without them. Even ray tracing on the CPU has been written ages ago.

Last edited by Shmerl on 5 July 2020 at 3:31 pm UTC
Shmerl Jul 5, 2020
Quoting: GuestI suggest you change your thinking then, if that's how you see it.
nvidia cannot dictate to the entirety of Vulkan how everything will be; they can hint, provide guidance, and their solution will likely be 95% of what is ultimately accepted, but they can't dictate everything.

And if you're suggesting everything be written only for nvidia hardware (and then, only for specific drivers), that defeats the whole purpose of Vulkan.

I'm suggesting that Nvidia first produce extensions for their own hardware. That's ones with _NV_. They can do it at any time. Then there is a collaborative work to make something common which takes longer. So again, how is that they produced DXR ones before their own for Vulkan? I'm not talking about common ones.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register


Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.

Buy Games
Buy games with our affiliate / partner links: