Quoting: Philadelphus

Quoting: ArehandoroLast night I dreamed that I was the first customer to receive the console, but somehow felt small, light and with a tiny screen. I mustn't read GOL before going to sleep xD

No no, see, that was the Dream Deck. Totally different console, but it's easy to see how they might be confused…

Now wait for Stream Deck!

View this comment - View article - View full comments

Quoting: TrainDoc

Quoting: Lofty(Actually can we get a steam controller 2 please whilst we are at it )

The Steamdeck is Valve's logical conclusion of their original plans for a second steam controller. Combine the haptics and sensors of the knuckles controllers and the touchpads of the original steam controller (which still exist on the deck just in a different form) and then add a screen to it like various Steam controller prototypes did. Then, "just" add a small PC into it and tada, Steam controller 2: a.k.a Steamdeck.

Was I dreaming it, or didn't they say you can use the deck as a controller to a pc? That's SC2 right there (a very expensive one though).

If that's not true, then they should make it true!

View this comment - View article - View full comments

Quoting: slaapliedjeMy other worry is all the people that will just buy this and install Windows on it... seems to defeat the purpose of the Deck for me; as who wants to deal with another Windows install...

While _some_ would inevitably do it (like some inevitably install Linux on anything that computes), I'm not too worried. It'd be a miserable experience IMO. Windows is not attempting to make itself look like a console, so it'll give pop ups, update at the worst times etc. Some might bear it to have more games, but it will definitely remove the nice just-pick-it-up-and-game feeling.

Also, while some higher end games have problems with proton, I seriously doubt those would be the kind of games people play on this!

View this comment - View article - View full comments

> everything feels like someone set a knocked a magical speed dial up

Luckily implementing such magic in computer games is as easy as `*2`.

View this comment - View article - View full comments

Quoting: Guest

Quoting: ShabbyX

Quoting: Guest

Quoting: ShabbyX

Quoting: Guest

Quoting: ShabbyX

Quoting: Guest

Quoting: marshmallow_madman

Quoting: Guest

Quoting: PeakHopefully the dynamic rendering extension means we will finally be able to get Halo Infinite running.

Not sure what one has to do with the other?

Halo Infinite, being a flagship Microsoft product built on a new game engine, acts as sort of a tech demo for Microsoft to show off new features in DirectX12 Ultimate/Xbox Series consoles. In other words, they get deep in the DX12 API and use features most other games haven't adopted yet. Some of those more obscure, less used DX12 Ultimate features don't have trivial or straightforward analogs in the current version of Vulkan, which makes the game challenging to support flawlessly with DXVK.

A new version of Vulkan with new features means that some of those DX12 features now do have straightforward Vulkan equivalents, which means that DXVK can better support them and games like Halo Infinite might work a little better. Dynamic rendering sounds like it's one of those features.

I see where you're coming from, but no, dynamic rendering is nothing to do with that. It relates more dynamic usage (hence the name) of the default framebuffer for rendering output. In essence is allows a lot of framebuffer and renderpass setup to be simplified when interacting with Vulkan, for certain use cases.

Actually it's probably more useful for handling things like DX9 or OpenGL over Vulkan.

It's more than for _certain_ use cases and GL emulation. The dynamic rendering extension dispenses with framebuffers and render pass objects altogether, which have been a constant source of pain for developers. In truth, render passes are still _the_ optimal way for tile-based renderers, but dynamic rendering makes things much simpler for apps targeted at desktop.

If you want to get picky, be my guest, but I'll feel obliged to point out simpler for apps targeted at desktop that don't use render sub-passes (for example, if an initial colour pass is also calculating normal values and feeding them along with depth values directly into a lighting pass, then that can be optimised greatly using a sub-pass even on desktop). Once any particular sub-pass is desired, then the benefits of the dynamic rendering extension are limited somewhat and may as well not be used.

Are you suggesting the driver merges the two subpasses' fragment shaders in one in that case? I guess that's doable, though I haven't heard of any driver doing that. Why would an app use two subpasses in that case when they can just do the whole thing in one pass?

Subpasses shine on TBR hardware because an app can do all sorts of stuff in one pass (blend, overdraw etc), then use the results in the second pass without the framebuffer data leaving tile memory. On IMR hardware the draw results end up reaching the memory during the first pass anyway (yes, there's some cache), there's really no benefit to one render pass with two subpasses compared with two render passes as far as I know.

If you know something about this I don't know, I'd be very keen to learn :)

Lighting (specifically deferred lighting) I mentioned because it's the one case I've found where a sub-pass has given good performance boosts: it's the same framebuffer size, and is a distinct pass (intervening geometry means you can't simply incorporate it into the colour/normal/depth pass). Deferred lighting of this fashion is falling out of favour because of newer techniques that handle transparency better though.

Anyway, performance improvements were seen even on desktop GPUs, which from a hardware perspective I believe use a kind of tile-based immediate mode these days (though to be honest I've not kept track with the latest desktop or mobile GPU architectures, which might have diverged again), and the driver can definitely take hints from the program to setup that nicely (even if just for caching). My limits of knowledge on the matter end there - I know the driver can optimise sub-passes even on desktop, but exactly what it does I've never bothered to look into detail at (and it'd change between hardware anyway).

All that being said, I'm also aware that many (myself included) don't like the render pass interface (it's a bit of a pain to setup) and I'm sure there are hints elsewhere that a driver can use (or that Khronos will introduce) just so that the benefits of sub-passes can be used (where applicable) without annoying the developer.

Interesting, my team (ANGLE) is dedicated to TBRs right now, and I never thought to measure on IMR, but I'm still a bit surprised you could measure anything noticeable. I guess I need an arch update too.

You'll have to tell me if the new extensions make life easier at all, because I'm insatiably curious about such things!

Hah, it'll be years before we can use anything shiny on Android (at which point they are not shiny anymore). More importantly, no, it's known that dynamic rendering on TBR is actually less optimal than explicit subpasses. It may one day be better though.

That said, yes it would have made things easier if we didn't have framebuffer objects etc, though some existing extensions do alleviate the pain already (like imageless framebuffers)

View this comment - View article - View full comments

Quoting: Guest

Quoting: ShabbyX

Quoting: Guest

Quoting: ShabbyX

Quoting: Guest

Quoting: marshmallow_madman

Quoting: Guest

Quoting: PeakHopefully the dynamic rendering extension means we will finally be able to get Halo Infinite running.

Not sure what one has to do with the other?

Halo Infinite, being a flagship Microsoft product built on a new game engine, acts as sort of a tech demo for Microsoft to show off new features in DirectX12 Ultimate/Xbox Series consoles. In other words, they get deep in the DX12 API and use features most other games haven't adopted yet. Some of those more obscure, less used DX12 Ultimate features don't have trivial or straightforward analogs in the current version of Vulkan, which makes the game challenging to support flawlessly with DXVK.

A new version of Vulkan with new features means that some of those DX12 features now do have straightforward Vulkan equivalents, which means that DXVK can better support them and games like Halo Infinite might work a little better. Dynamic rendering sounds like it's one of those features.

I see where you're coming from, but no, dynamic rendering is nothing to do with that. It relates more dynamic usage (hence the name) of the default framebuffer for rendering output. In essence is allows a lot of framebuffer and renderpass setup to be simplified when interacting with Vulkan, for certain use cases.

Actually it's probably more useful for handling things like DX9 or OpenGL over Vulkan.

It's more than for _certain_ use cases and GL emulation. The dynamic rendering extension dispenses with framebuffers and render pass objects altogether, which have been a constant source of pain for developers. In truth, render passes are still _the_ optimal way for tile-based renderers, but dynamic rendering makes things much simpler for apps targeted at desktop.

If you want to get picky, be my guest, but I'll feel obliged to point out simpler for apps targeted at desktop that don't use render sub-passes (for example, if an initial colour pass is also calculating normal values and feeding them along with depth values directly into a lighting pass, then that can be optimised greatly using a sub-pass even on desktop). Once any particular sub-pass is desired, then the benefits of the dynamic rendering extension are limited somewhat and may as well not be used.

Are you suggesting the driver merges the two subpasses' fragment shaders in one in that case? I guess that's doable, though I haven't heard of any driver doing that. Why would an app use two subpasses in that case when they can just do the whole thing in one pass?

Subpasses shine on TBR hardware because an app can do all sorts of stuff in one pass (blend, overdraw etc), then use the results in the second pass without the framebuffer data leaving tile memory. On IMR hardware the draw results end up reaching the memory during the first pass anyway (yes, there's some cache), there's really no benefit to one render pass with two subpasses compared with two render passes as far as I know.

If you know something about this I don't know, I'd be very keen to learn :)

Lighting (specifically deferred lighting) I mentioned because it's the one case I've found where a sub-pass has given good performance boosts: it's the same framebuffer size, and is a distinct pass (intervening geometry means you can't simply incorporate it into the colour/normal/depth pass). Deferred lighting of this fashion is falling out of favour because of newer techniques that handle transparency better though.

Anyway, performance improvements were seen even on desktop GPUs, which from a hardware perspective I believe use a kind of tile-based immediate mode these days (though to be honest I've not kept track with the latest desktop or mobile GPU architectures, which might have diverged again), and the driver can definitely take hints from the program to setup that nicely (even if just for caching). My limits of knowledge on the matter end there - I know the driver can optimise sub-passes even on desktop, but exactly what it does I've never bothered to look into detail at (and it'd change between hardware anyway).

All that being said, I'm also aware that many (myself included) don't like the render pass interface (it's a bit of a pain to setup) and I'm sure there are hints elsewhere that a driver can use (or that Khronos will introduce) just so that the benefits of sub-passes can be used (where applicable) without annoying the developer.

Interesting, my team (ANGLE) is dedicated to TBRs right now, and I never thought to measure on IMR, but I'm still a bit surprised you could measure anything noticeable. I guess I need an arch update too.

View this comment - View article - View full comments

Quoting: Purple Library Guy

Quoting: ShabbyX

Quoting: Eike

Quoteunified save names for PC - MAC/Linux

Yes please!

I mostly play on my Linux box, but sometimes also on my wife's Windows PC and my father-in-law's gaming box, so that's very handy.

Finally, the cool future has come when someone can play on their *father in-law's* gaming box!

Oh, that's it! Now I have to get my grandson or granddaughter to play a game on my computer.

Amazing!

Also, if that means they will experience Linux now, by all means!

View this comment - View article - View full comments

Quoting: Eike

Quoteunified save names for PC - MAC/Linux

Yes please!

I mostly play on my Linux box, but sometimes also on my wife's Windows PC and my father-in-law's gaming box, so that's very handy.

Finally, the cool future has come when someone can play on their *father in-law's* gaming box!

View this comment - View article - View full comments

Quoting: Guest

Quoting: ShabbyX

Quoting: Guest

Quoting: Guest

Quoting: Guest

Quoting: PeakHopefully the dynamic rendering extension means we will finally be able to get Halo Infinite running.

Not sure what one has to do with the other?

Halo Infinite, being a flagship Microsoft product built on a new game engine, acts as sort of a tech demo for Microsoft to show off new features in DirectX12 Ultimate/Xbox Series consoles. In other words, they get deep in the DX12 API and use features most other games haven't adopted yet. Some of those more obscure, less used DX12 Ultimate features don't have trivial or straightforward analogs in the current version of Vulkan, which makes the game challenging to support flawlessly with DXVK.

A new version of Vulkan with new features means that some of those DX12 features now do have straightforward Vulkan equivalents, which means that DXVK can better support them and games like Halo Infinite might work a little better. Dynamic rendering sounds like it's one of those features.

I see where you're coming from, but no, dynamic rendering is nothing to do with that. It relates more dynamic usage (hence the name) of the default framebuffer for rendering output. In essence is allows a lot of framebuffer and renderpass setup to be simplified when interacting with Vulkan, for certain use cases.

Actually it's probably more useful for handling things like DX9 or OpenGL over Vulkan.

It's more than for _certain_ use cases and GL emulation. The dynamic rendering extension dispenses with framebuffers and render pass objects altogether, which have been a constant source of pain for developers. In truth, render passes are still _the_ optimal way for tile-based renderers, but dynamic rendering makes things much simpler for apps targeted at desktop.

If you want to get picky, be my guest, but I'll feel obliged to point out simpler for apps targeted at desktop that don't use render sub-passes (for example, if an initial colour pass is also calculating normal values and feeding them along with depth values directly into a lighting pass, then that can be optimised greatly using a sub-pass even on desktop). Once any particular sub-pass is desired, then the benefits of the dynamic rendering extension are limited somewhat and may as well not be used.

Are you suggesting the driver merges the two subpasses' fragment shaders in one in that case? I guess that's doable, though I haven't heard of any driver doing that. Why would an app use two subpasses in that case when they can just do the whole thing in one pass?

Subpasses shine on TBR hardware because an app can do all sorts of stuff in one pass (blend, overdraw etc), then use the results in the second pass without the framebuffer data leaving tile memory. On IMR hardware the draw results end up reaching the memory during the first pass anyway (yes, there's some cache), there's really no benefit to one render pass with two subpasses compared with two render passes as far as I know.

If you know something about this I don't know, I'd be very keen to learn :)

View this comment - View article - View full comments

Quoting: Guest

Quoting: Guest

Quoting: Guest

Quoting: PeakHopefully the dynamic rendering extension means we will finally be able to get Halo Infinite running.

Not sure what one has to do with the other?

Halo Infinite, being a flagship Microsoft product built on a new game engine, acts as sort of a tech demo for Microsoft to show off new features in DirectX12 Ultimate/Xbox Series consoles. In other words, they get deep in the DX12 API and use features most other games haven't adopted yet. Some of those more obscure, less used DX12 Ultimate features don't have trivial or straightforward analogs in the current version of Vulkan, which makes the game challenging to support flawlessly with DXVK.

A new version of Vulkan with new features means that some of those DX12 features now do have straightforward Vulkan equivalents, which means that DXVK can better support them and games like Halo Infinite might work a little better. Dynamic rendering sounds like it's one of those features.

I see where you're coming from, but no, dynamic rendering is nothing to do with that. It relates more dynamic usage (hence the name) of the default framebuffer for rendering output. In essence is allows a lot of framebuffer and renderpass setup to be simplified when interacting with Vulkan, for certain use cases.

Actually it's probably more useful for handling things like DX9 or OpenGL over Vulkan.

It's more than for _certain_ use cases and GL emulation. The dynamic rendering extension dispenses with framebuffers and render pass objects altogether, which have been a constant source of pain for developers. In truth, render passes are still _the_ optimal way for tile-based renderers, but dynamic rendering makes things much simpler for apps targeted at desktop.

View this comment - View article - View full comments