Quoting: F.UltraConsidering how quickly they managed to port Wolfenstein Youngblood to not only Linux but also ARM Linux shows that those rumours that they had DOOM running natively on Linux way back where highly likely true.

Yes exactly, having the driver ready for ARM is one thing, showing an ARM port of an AAA game is at least equally impressive (and serves indeed food for lots of rumors :)).

View this comment - View article - View full comments

Quoting: CorbenThe strong jittering/latency is definitely introduced with and caused by the new async reprojection implementation, but the games themselves are now butter smooth when turning your head.

Actually I'm glad to see that those issues are now also present with NVIDIA, I hope that gives the SteamVR team enough motivation to look into this considering more people are now affected by this.

If one may hope, i would love to have the following issues resolved:
https://github.com/ValveSoftware/SteamVR-for-Linux/issues/230 [External Link]
https://github.com/ValveSoftware/SteamVR-for-Linux/issues/395 [External Link] (already mentioned above)
https://github.com/ValveSoftware/SteamVR-for-Linux/issues/430 [External Link]

View this comment - View article - View full comments

Quoting: CatKiller

Quoting: jensDo you have a specific example?

Not a specific example, I'm just going from the description from here [External Link]

Some of the features that programmers can access using NVAPI include:

Driver Management: Initialization and driver version controls.
GPU Management: Enumeration of physical and logical GPUs. Thermal and Cooling controls.
Display Management: Enumeration of NVDIA displays, display postion and timings controls.
System Management: Ability to query chipset and system specific information.
Connecting and Configuring Monitors: Ability to set views on multiple target monitors.

and the stuff on assigning handles for GPUs and the like.

Maybe the thermal management stuff is too hardware specific, but being able to find GPUs and what they can do, how to address them, how to allocate memory, and things like that, are things that Vulkan covers. Being able to map those functions from NVAPI, that people are already using, to Vulkan, that people might want to use in the future, seems like it might be handy. There may well be other functions in there that Vulkan could do, but doesn't yet do, that would just be a good idea. NVAPI seems to me like Nvidia's grab-bag of handy things that they couldn't get done another way (pre-Vulkan) and Vulkan so far has worked well as a means of standardising everyone's good ideas so that more people can benefit.

I have no idea if Nvidia, Khronos, or anyone else, would actually do it, but it seems to me to be something that could be done.

Thanks for your response. As far as I know, the Nvidia Vulkan driver implements all things that Vulkan specifies for GPU and capability discovery. Other things like memory management are up the application developer when programming against Vulkan. Not sure if display management and thermal stuff should become part of it. It doesn't really fit into a graphics API and it is indeed either vendor specific or platform specific (or both). To be honest, I think all that sysinfo stuff should stay in vendor controls panels and as far as possible in the background. Game developers should possibly stay away of that and focus more on the renderers itself ;).

PS: The Nvidia drivers for Linux ships NVML (https://developer.nvidia.com/nvidia-management-library-nvml), some of the NVAPI methods for querying temperature etc can be mapped to that library.

View this comment - View article - View full comments

Quoting: CatKillerA lot of the stuff that's in NVAPI, which people have been using and wasn't included in OpenGL or DirectX, is in scope for Vulkan. Things like device discovery and capability enumeration.

Do you have a specific example?

View this comment - View article - View full comments

Quoting: Ehvis

Quoting: rustybroomhandleWhile it's nice of them to make this stuff open source, it's probably not tech that anyone should be using, since it's hardware specific and serves as a vector to lock-in.

Maybe, but it's already used on Windows, so it's definitely something good for Wine. Even implementing the functionality separately would be a possibility (although not necessarily useful). And then make it run on AMD would at least be hilarious. :grin:

Well, those are header files to build an alternative implementation of NVIDIA's own nvapi library. The library surface is huge, Nvidia put everything in it from display configuration to Direct3D extension plus it grew heavily of the years. Fortunately lots of games use only a small subset or even just a few methods. So it is absolutely doable to create an nvapi compatible library which provides some usefulness, even for AMD cards. In fact, I did exactly that :)

View this comment - View article - View full comments

Quoting: KetilI am very opposed to the idea of treating education like an assembly line,…

I think that (unfortunately) very much depends on who you ask within a hospital or university :)

View this comment - View article - View full comments

Very cool, I liked the predecessor, this looks promising too.

View this comment - View article - View full comments

Nice to see progress, I’m still looking forward to this one.

View this comment - View article - View full comments

“Historisch gewachsen” is a bit broader than “technical dept”. Legacy bagage fits a bit better imho.
I mean you can have an older still perfect piece of software from a technical point of view (thus nearly no technical dept) but still with tons of useless or wrongly used features due to which people want it to disappear. The latter fits more into “legacy bagage”, evolving into a state like this over a longer period of time happens due to historical reasons / of reasons (“historisch so gewachsen”).
Granted, both technical dept and legacy bagage are often linked together in software development, assuming that I understood the scope of “legacy bagage” correctly.

View this comment - View article - View full comments

Wow, async reprojection on Nvidia is really cool. Let’s hope that this will give the SteamVR team some arguments to get SteamVR itself back in shape again on Linux!

View this comment - View article - View full comments