[Sunday]

http://www.dailytech.com/article.aspx?newsid=9656

I'm really disappointed with Cevat comments, 'cos it's so obvious that TWIMTBP money talk from him! DX10.1 is incremental update to DX10, but it solves some serious thing in shading domain, things that could be of real importance to his monstrously unoptimized DX10 implementation of DX10 path under Crysis. Hell since we all know that "Very High" (or DX10) could be unlocked under XP, it's questionable do they really have DX10 implementation after all!?
DX10.1 whitepaper:
http://www.legitreviews.com/images/r...per%20v0.4.pdf

[Zengar]

Ok, so what does it solve? The only big feature I see is controllable AA (and that is a very nice thing indeed)

[Spyhawk]

Indeed....oh well it doesnt change the fact that these HD3800s with DX10.1 will sell like hotcakes because of thier price/performance ratio and not because of DX10.1. So in the end who cares really what they say at this point. As far as Im concerned it wont have any negative impact on RV670 sales.

[SuperCow]

Being able to (finally) access multisampled depth buffer as textures (or through direct sample access) is one of the biggest addition in DX10.1. Most new games coming out need access to the scene depth information one way or the other (e.g. screen space ambient occlusion, post-processing effects, etc.) and DX10 requires a special path for handling the MSAA case (basically depth output into alpha channel/second render target or additional geometry pass), which reduces performance and increases code complexity.
Being able to run the pixel shader at sample level is also essential to implement some algorithms.

[_xxx_]

Err...

Microsoft's senior global director of Microsoft games on Windows, Kevin Unangst, replied, "DX10.1 is an incremental update that won’t affect any games or gamers in the near future."

From the horse's mouth, so how is this downplaying anything? I mean, why would MS downplay their own product?

[Jawed]

This message is sponsored by NVidia, by the way.

Originally Posted by DailyTech left this out

No developer has plans for DX10.1 exclusive content. We encourage you to contact developers to confirm our findings.

Jawed

[SuperCow]

Originally Posted by DailyTech left this out
No developer has plans for DX10.1 exclusive content. We encourage you to contact developers to confirm our findings.

It's indeed too early for DX10.1 exclusive game content (although synthetic benchmarks could include DX10.1-only content). However I can't see what would be preventing developers from implementing an optimized or "enhanced" DX10.1 path in their games, e.g. to accelerate the code path mentioned in my previous post.

[Mariner]

Pfft. More wholly expected marketing nonsense.

If the boot was on the other foot and NVidia had DX10.1 with ATI stuck on 10.0, Crytek would no doubt have found some way to make 10.1 indispensible in their game. Can't blame Crytek too much as it sounds as though NV have been throwing serious resources at them and you don't bite the hand that feeds you.

Isn't marketing great? (The answer is no)

[Novum]

There is in fact nothing that fancy about D3D10.1. The only big thing could be that you can can read subsamples from the Z buffer which is a good thing for engines that do defered shading, because it enables you to do correct AA.

But for Crysis I also don't see much use of D3D10.1. Crysis also directly supports Crossfire and wants to sell their engine to other customers, so I don't think they didn't optimize as much as possible for ATI cards as well.

There is not always a conspiracy...

[Lux_]

Any info WRT WDDM 2.1 and preemptive context switching?

[JHoxley]

I don't have my 10.1 specs to hand, but I did get the impression that 10.1 is more about refinements than ground-breaking new features.

You can multi-target an application to 10.0 and 10.1, so that does make the migration easier. I'd imagine you'll start to see the advanced engines having a main 10.0 path and a 10.1 path for those who have it - all using much the same codebase.

The MSAA thing only specifies a palette of modes that you can enumerate and mandates only the 4xMSAA mode. It's nice, but not such a big deal in my opinion.

The depth/stencil readback for MSAA and deferred shading is a big deal, and I also plan on using the bit-fiddling to convert compressed textures. Using the BC[n] formats in 10.0 purely in code was more hassle than I liked, so I'm glad that's improving.

Any info WRT WDDM 2.1 and preemptive context switching?

I've not seen any indication of what (if any) updates are in SP1. Would be interesting to get more detail though.


Jack

[Anarchist4000]

I'd be more inclined to believe DX10.1 is what DX10 should have been but an IHV crapped out on the specs. If deferred rendering was the goal of DX10 it seems kind of pointless to have left out access to depth and multiple samples. The whole thing seems kind of geared towards reading back data for a second pass. Granted you can just make a huge render target and down-sample it but that's not exactly the greatest method.

[Humus]

Originally Posted by Novum

There is in fact nothing that fancy about D3D10.1. The only big thing could be that you can can read subsamples from the Z buffer which is a good thing for engines that do defered shading, because it enables you to do correct AA.

Reading subsamples of the depth buffer is pretty fancy in my book. This alone could be enough to support a DX10.1 path in a game. It's not just deferred shading that benefits from it. Any kind of algorithm that needs the depth and you wish to use multisample with will benefit from it.

Another nicety is that Fetch4 finally gets official in DX (under the name Gather4).

[Mintmaster]

There's nothing wrong with any of the statements there. We won't see DX10.1 improvements in the near future, and we definately won't see any content that exclusively runs on DX10.1 and higher.

Originally Posted by Novum

There is in fact nothing that fancy about D3D10.1. The only big thing could be that you can can read subsamples from the Z buffer which is a good thing for engines that do defered shading, because it enables you to do correct AA.

You don't think being able to control the multisample mask in the pixel shader is just as important?

How about antialiased alpha tested textures without the TrAA perf hit, i.e. customized alpha to coverage? Or using AA hardware to quadruple shadow map resolution for free? Or stencil shadows without resending geometry for each light?

EDIT: Scratch that last one...

[Mariner]

So, do ATI (well, AMD) have another PS1.4 situation on their hands?

i.e. a hardware solution which is functionally superior to the competition which will become useful in the future but is probably not very relevant to the current generation of products (or even the following one).

[JHoxley]

Originally Posted by Mintmaster

We won't see DX10.1 improvements in the near future, and we definately won't see any content that exclusively runs on DX10.1 and higher.

I completely agree that you won't see 10.1 exclusive but I do think we will see some 10.0 and 10.1 engines/games in the not too distant future. I've only read the spec for 10.1 (still waiting for my damned Vista SP1 access ) but it looks like you could swap out the syntax for your 10.0 app and make it technically "10.1" without using any 10.1 features. The downside is you presumably take out a dependency on Vista with SP1. You can then go back and add in your 10.1/SM4.1 goodies incrementally.

Basically, just trying to say that the effort from going 9.0-10.0 was pretty big (if not complicated, just a lot of time) but once you're at 10.0 you can jump to 10.1 a lot quicker and with a lot less hassle.

So, do ATI (well, AMD) have another PS1.4 situation on their hands?

Yes and no. It all depends what your gamble on DX11's release date is. Very few people have any insight into this, but if 10.1 is the current API for all of 2008 and most of 2009 (speculation) then AMD might actually have first-to-market advantage.

Jack

[Xmas]

Originally Posted by Mintmaster

How about antialiased alpha tested textures without the TrAA perf hit, i.e. customized alpha to coverage?

Well, you get the performance hit of alpha to coverage, perhaps even a bit more because you have to generate a bit mask instead of letting hardware generate a bitmask from the alpha value for you.

The sample mask makes sense if you need control over exactly which samples you need to write, not necessarily if you just want to control how many you want to write. Although this at least gives you a choice between dithered and non-dithered alpha to coverage.

Or using AA hardware to quadruple shadow map resolution for free?

It's only free if hardware resources are idle in the non-AA case.

Or stencil shadows without resending geometry for each light?

Could you explain that in more detail? Where does the sample mask come in?

[AlexV]

Originally Posted by JHoxley

I completely agree that you won't see 10.1 exclusive but I do think we will see some 10.0 and 10.1 engines/games in the not too distant future. I've only read the spec for 10.1 (still waiting for my damned Vista SP1 access ) but it looks like you could swap out the syntax for your 10.0 app and make it technically "10.1" without using any 10.1 features. The downside is you presumably take out a dependency on Vista with SP1. You can then go back and add in your 10.1/SM4.1 goodies incrementally.

Basically, just trying to say that the effort from going 9.0-10.0 was pretty big (if not complicated, just a lot of time) but once you're at 10.0 you can jump to 10.1 a lot quicker and with a lot less hassle.

Yes and no. It all depends what your gamble on DX11's release date is. Very few people have any insight into this, but if 10.1 is the current API for all of 2008 and most of 2009 (speculation) then AMD might actually have first-to-market advantage.

Jack

I'm sure you know there's a hack that enables getting even the latest RC build for SP1 through Windows update. You must stop being politically correct, if MS left that backdoor, use it!

[JHoxley]

Originally Posted by Morgoth the Dark Enemy

I'm sure you know there's a hack that enables getting even the latest RC build for SP1 through Windows update. You must stop being politically correct, if MS left that backdoor, use it!

I didn't know about that! Thing is, I should have *two* methods of getting on the official SP1 beta, just they don't appear to work and I've not had the time to find out why...

[Demirug]

Originally Posted by JHoxley

but it looks like you could swap out the syntax for your 10.0 app and make it technically "10.1" without using any 10.1 features. The downside is you presumably take out a dependency on Vista with SP1. You can then go back and add in your 10.1/SM4.1 goodies incrementally.

There is a generic solution to enable your engine to use D3D10.1 with SP1 without dropping non SP1 support. You just need a special code file and doing a simple search and replace with your current code.

[sebbbi]

For my point of view DX10.1 has lots of really useful features. Our new renderer is a fully deferred one, and DX10.1 seems to have focused on improving the shortcomings on that side.

Subsample reading allows me to finally do proper antialiasing. Currently we need to either do a edge-detect blur filter in post process pass, or render everything in 2x1 (or 2x2) resolution and downsample the result in combine pass (or both for best quality). Subsample reading both improves the AA quality and speeds up the rendering, and it helps the shadow map rendering as well. This is the hands down biggest feature in DX10.1.

Separate blend modes for MRT is also useful when rendering complex volumetric effects to deferred buffers (you need separate blending modes for particle normals, volume density accumulation and other parameters). But it's not that important for basic rendering. I can easily life without it (and most likely we spend resources on something else instead of it).

It's also good that they finally properly support Gather4, instead of the current Fetch4 hack implementation. We are using Fetch4 in lots of our post process filters, so it's a good thing to have it in DX10.1 feature list. Soon all the Fetch4 optimizations will be usable on Geforces as well (or I am hoping so at least).

For me cube maps in texture arrays is just a small and natural incremental feature addition to the texture array operation. It can be used improve ambient lighting quality, but storing huge amount of cubemaps is going to consume a lot of memory, and is not going to feasible in most real games (compared to a small one room ATI techdemo). It's a fun feature to play around with in the future, but certainly not something that resolves the whole realtime global illumination problem, like PR and marketing departments like to say

[Mintmaster]

Originally Posted by Xmas

Well, you get the performance hit of alpha to coverage, perhaps even a bit more because you have to generate a bit mask instead of letting hardware generate a bitmask from the alpha value for you.

Right, but I don't think TrAA does that. It supersamples. I may be using the wrong terminology, but I'm trying to refer to the artifact free, bulletproof transparency antialiasing.

Alpha to coverage doesn't always work as a replacement for alpha tests, particularly for clever rounded boundaries using low resolution textures, or during magnification of textures.

One of the other reasons I really liked this coverage control is the idea of being able to apply it to techniques like this:
http://fabio.policarpo.nom.br/docs/C...iefMapping.pdf
There are flaws in the technique that the author doesn't mention (which I uncovered when independently "inventing" a similar technique just before this paper came out ), but I think there is some promise.

Although this at least gives you a choice between dithered and non-dithered alpha to coverage.

That what I was referring to most. For alpha testing it's better to properly determine coverage with additional texture samples. Also, when using alpha to coverage for hacky order independent transparency, the dithering is rather ugly, so some shader control could probably ameliorate that. Combining alpha to coverage and alpha blending could be a nice compromise in certain situations too.

It's only free if hardware resources are idle in the non-AA case.

True. I was thinking more about VSM or other techniques where you write custom values instead of just Z. Though even there subsample access probably won't give anything better looking than resolving first, so I guess I overstated the benefit.

Could you explain that in more detail? Where does the sample mask come in?

Nevermind, I had a bit of a brainfart there.

[Mintmaster]

Originally Posted by sebbbi

Subsample reading allows me to finally do proper antialiasing. Currently we need to either do a edge-detect blur filter in post process pass, or render everything in 2x1 (or 2x2) resolution and downsample the result in combine pass (or both for best quality). Subsample reading both improves the AA quality and speeds up the rendering, and it helps the shadow map rendering as well. This is the hands down biggest feature in DX10.1.

What was holding you back from simply adding Z (actually, distance) as another rendertarget in the G-buffer creation? You can read subsamples of that in DX10.0, right?

[Xmas]

Originally Posted by Mintmaster

Right, but I don't think TrAA does that. It supersamples. I may be using the wrong terminology, but I'm trying to refer to the artifact free, bulletproof transparency antialiasing.

Ok, "TrAA" isn't really specific.

However, transparency supersampling isn't artifact free or bulletproof as it's still just a threshold test per sample. At some point in the mipmap pyramid the texels will all go to one side of the threshold, so in the distance you either get an opaque surface or none at all. What you really want is blending without the sorting problem, and alpha to coverage does a pretty good job with that. The magnification problem remains, but Humus' transparency AA demo shows that there's a solution for that, too.

One of the other reasons I really liked this coverage control is the idea of being able to apply it to techniques like this:
http://fabio.policarpo.nom.br/docs/C...iefMapping.pdf
There are flaws in the technique that the author doesn't mention (which I uncovered when independently "inventing" a similar technique just before this paper came out ), but I think there is some promise.

Yes, enabling AA in silhouette-modifying shaders should be one of the main use cases for a shader controllable sample mask.

That what I was referring to most. For alpha testing it's better to properly determine coverage with additional texture samples. Also, when using alpha to coverage for hacky order independent transparency, the dithering is rather ugly, so some shader control could probably ameliorate that.

The dithering should actually work out quite nicely if you apply a filter like ATI's "edge detect" downsampling. Since the samples are different all those dithered areas should be filtered as edges, turning them into really smooth gradients. Though I've yet to see this in practice.

[Arun]

Originally Posted by Mintmaster

What was holding you back from simply adding Z (actually, distance) as another rendertarget in the G-buffer creation? You can read subsamples of that in DX10.0, right?

Honestly, I'd suspect colour-sample readback is (or was, at least) so badly documented in 10.0 that many devs don't even realize it's fully supported...