One thing that would be interesting is if Intel licensed the DLSS tech from Nvidia. They do have the hardware, since they're chasing the same machine learning market as Nvidia. Tensor cores on consumer products is essentially a lemons -> lemonade situation. On the one hand they won't want to give Intel a leg up in the dedicated GPU market, nor in the very lucrative machine learning market, but on the other hand a feature that both Nvidia and Intel have that AMD doesn't will put the squeeze on their mutual competitor.

View this comment - View article - View full comments

Quoting: ShmerlSo instead of being essentially a fancy display, the headset will have its own GPU?

That moves things into interesting direction of eventually rendering everything on the headset itself, but I guess they need to get small enough first while being powerful. Current GPUs required for VR use a ton of power and need serious heat dissipation.

Standalone VR headsets already exist with their own GPU. The Oculus Quest uses the Adreno 540 and the Quest 2 uses the Adreno 650. In terms of graphics power they're pretty weak, but going stronger risks melting your face. The idea of this is that you can offload some of the face melting stuff to a different machine, but have enough local processing power that the latency doesn't make you hurl.

View this comment - View article - View full comments

Quoting: gradyvuckovic

Quoting: CatKillerSo, I think the idea is to use the same kind of tech as game streaming; the computer renders the scene based on position information from the headset, and sends essentially a 360° video stream to the headset, which can be freely navigated using the headset. If there's enough bandwidth, that could be quite interesting.

Ya know, if they included depth information per pixel, it would be possible to not only correctly correct the 360 image to adjust for head rotation, but also give proper depth displacement to the 360 video to account for head movement with near zero latency as well. Would hide a lot of latency or frame rate issues in most circumstances.

So, looking at the patent, that seems to be something that's also included in the stream. The headset sends movement data, and the computer guesstimates where the headset will be at render time based on that. The stream it sends to the headset includes pixel data (so, the video stream) as well as pose data, depth data, motion vector data, parallax occlusion data, and "extra pixel data." So if the next frame is late, or the guesstimate is a bit wrong, the headset has enough data to correct for it. Could be neat.

Also, the computer seems to render the scene, but the headset renders the player model, which should also reduce any latency discrepancy between what the player's doing and what they're seeing.

View this comment - View article - View full comments

So, I think the idea is to use the same kind of tech as game streaming; the computer renders the scene based on position information from the headset, and sends essentially a 360° video stream to the headset, which can be freely navigated using the headset. If there's enough bandwidth, that could be quite interesting.

View this comment - View article - View full comments

I haven't looked into it more than what's written here yet, but

Flags to enable motion support in an acceleration structure

seems really interesting to me. Acceleration structures are computationally expensive to build (it's one of the things that the RT cores provide hardware acceleration for) and choosing when to modify an existing one and when to tear it down and build a new one is quite a difficult optimisation problem. If this makes it easier to have some parts of an existing acceleration structure behave sanely under motion, that could be really handy.

View this comment - View article - View full comments

Quoting: tuubiUse whatever you find interesting and/or practical, but don't go around telling people that their choice is wrong.

Yeah, that is the most harmful thing people can do to Linux adoption. People think that by trash-talking distros they'll make their own favourite distro seem better, and they get in the habit of doing so in whichever distro-bubble they frequent.

If you're coming from something like Windows, OS X, Android or iOS where the only version choice is "current version" or "old version" just the idea of having to choose between distros is completely overwhelming and stress-inducing. The phenomenon is generally referred to by names like, "the tyranny of choice."

Having people going around sneerily saying "oh, you mustn't use Ubuntu, noob," or click-bait listicles of "$obscure_distro that you must use" - just the idea that it's possible to make the wrong choice - won't make them choose whatever it is you're pushing, it will just make them flee back to what they're used to, which doesn't make them choose.

It's so frustrating to see members of our community sabotaging us like that.

View this comment - View article - View full comments

Quoting: LoftyWould this improve older earlier Linux ports that used openGL and had poor performance like DeusEX mankind divided?

excuse my ignorance on the matter, this is new to me.

Not directly.

The OpenGL model is a single threaded state machine. At the time, for the uses it was created for, the hardware itself was a single threaded state machine. Fairly quickly, though, that stopped being the case - programmable shaders and multicore processors being the big deviations from that model, but others too. So OpenGL drivers lied through their teeth about what they were doing: they'd reorder instructions, and batch draw calls, and cache things or not cache things as they saw fit, for better performance; but as far as the application is concerned it was all "single threaded immediate rendering, honest guv," since that's what the spec calls for. Applications have no way of knowing WTF is actually going on.

Vulkan makes all this stuff explicit. The application has to handle the scheduling and the memory allocation and so on, and Vulkan provides the means to find out what the hardware can do and what it's actually doing. No more lies from the driver, but more work for the developer.

Automatically implementing OpenGL on Vulkan (which is what Zink does) means that the driver can provide consistent state-of-the-art lies to the application, but the application's still restricted to the OpenGL model, and was written in the context of the OpenGL driver lies of the time it was written. So Zink might make performance a bit better by providing better lies than average, but an OpenGL driver that provided the lies that the application writer was expecting and testing against would be just as good.

View this comment - View article - View full comments

Hmm. My little one loves machines and loves puzzles. Showing a five year old how to pick locks couldn't possibly have negative future consequences, right?

View this comment - View article - View full comments

Quoting: whizseStill not too fond of the colour arrangement. Too much brown. Like Quake 2 mixed with early Ubuntu.

You're thinking of the first Quake: that was the brown one. Quake 2 is grey with whoa! coloured lights slapped everywhere. The early Ubuntu versions were also very brown, though.

View this comment - View article - View full comments

Quoting: Eike"One problem is that OpenGL is a big API with a lot of legacy stuff that has accumulated since its initial release in 1992."

Yeah, OpenGL was driven by the needs of CAD software when programs were single-threaded and hardware was a fixed-function rendering pipeline. Modern software and hardware aren't really like that at all.

There's an interesting set of articles [External Link] from one of the PowerVR people that describes how Vulkan does things differently to OpenGL.

View this comment - View article - View full comments