New Nvidia Cards

[Dio]

That maybe the 3090 - aimed at "the professional" - is subsidising the gamer's 3070 / 3080, just because nVidia need to make a play on that space, before AMD enters the room.

The market for the 3090 is small and primarily defined by their own competing product, not anything else. At only +20%-ish performance but +100% price, you have to be a real money-no-object buyer to take the plunge there - the performance uplift isn't enough to turn anyone's task from impossible to possible.

The 3090's selling point for the pro space is primarily the much larger onboard memory. If you don't need that, you don't need a 3090.

[KlaxonCow]

I think there was also some suggestion form Linus that they expect yields to be increased this time around, so whilst they will be more expensive to produce they won't be wasting as many and thus could keep costs similar.

Yes.

I didn't jump up and down on that point, but it was there in my post with the picture I nabbed from his video of the cards with their transistor counts (as it just visually nails the information we need to know in one photo, rather than me detailing all those numbers manually).

I slotted it into a parenthesised aside:

(and, presumably, Samsung's 8nm fabrication just has better yields, judging by the prices).

[gilesgoat]

I still haven't heard from Dio what AMD has to offer to "counter act" all this, so what's the best AMD one can buy ?

[The ghost of raids past]

I still haven't heard from Dio what AMD has to offer to "counter act" all this, so what's the best AMD one can buy ?

He can't tell you about the new cards from AMD as he will be under a NDA. Currently when the 30 series comes out nothing beats Nvidia. When AMD announce their new cards this may change

[gilesgoat]

I still haven't heard from Dio what AMD has to offer to "counter act" all this, so what's the best AMD one can buy ?

He can't tell you about the new cards from AMD as he will be under a NDA. Currently when the 30 series comes out nothing beats Nvidia. When AMD announce their new cards this may change

In other words .. WAIT ...

[The ghost of raids past]

I wouldnt have thought Team Red have anything significantly more powerful under the wraps. I am guessing they spent alot of time in meetings today re-evaluating their pricing.

I would love to be proved wrong though

[Jamesac]

I still haven't heard from Dio what AMD has to offer to "counter act" all this, so what's the best AMD one can buy ?

He can't tell you about the new cards from AMD as he will be under a NDA. Currently when the 30 series comes out nothing beats Nvidia. When AMD announce their new cards this may change

In other words .. WAIT ...

That's been 100% true on all PC hardware for the last 30-40 years. I got my GeForce 2080 Super last fall and am feeling ok about it, because no matter what there will always be something better coming along. I'm just glad the next round waited until now instead of showing up last December or so.

[Dio]

It's more true than usual at the moment. Waiting until both ranges are fully fleshed out from top to bottom will give you the best range of value options, and then the rate of change will drop off for a while.

[gravy]

I'm not convinced that DLSS is better than good algorithmic solutions.

Can't talk much about the rest. They do appear to be being very aggressive on pricing - the 3090 price looks about as expected, but there doesn't look much room for profit in the 3070/80.

I think DLSS 2.0 leans more towards algorithmic with deep learning assistance.

Been more than happy to see something along these lines from AMD though

[Dio]

FidelityFX was very competitive with the first version of DLSS - more efficient, a much more reliable result, works on all GPUs not just those with the funky ML hardware. There's really no need to use ML for this, but of course nvidia are desperate to do that to light up those otherwise dead transistors.

I don't think we're planning to sit on our arses on this one.

[gilesgoat]

FidelityFX was very competitive with the first version of DLSS - more efficient, a much more reliable result, works on all GPUs not just those with the funky ML hardware. There's really no need to use ML for this, but of course nvidia are desperate to do that to light up those otherwise dead transistors.

I don't think we're planning to sit on our arses on this one.

Can you add something to allow me to render 43 different views of the same data set in one single pass pleeease

[edit] - also "understood" the "linking" between VS/FS/whatever to get a "blob" named "program" ( if you like ) could we have some "fixed data in/out" you can set so you can "switch on the fly" programs with "compatible" data in/out without the need of re-creating a whole "pipeline" ( that is much more than that ) and possibly with no need to deal with "descriptors" or shit like that ?

I.e. if the input/output "is the same" but what changes "is the program in the middle" sure one could "just swap the program" by leaving all the rest untouched.

( it seemed to remember you told me "you can't really do that because the 'program' itself also 'changes all the rest around' " but could you modify the way all that works ).

Could you have then maybe "a simplified version/pipeline of all this" were "with some other constraints" but could allow "certain more flexibility/speed" at the cost of something else ?

I mean like to have "pipeline type 1" where "you can do all you can do normally now" but also a "pipeline type 2" where you can't do ALL BUT you CAN do "some things much quicker than in 1" ?

Can i have .. can I have ? .. ( more lists of things )

Oh yeah "some more native HW support/help for VR" , to help with timewarping/prediction/sensors input and such.

Ta

[edit2] - also in this new "HW assisted Ray Tracing" ( that I still don't know how it works ) can you replace "shader style" ( i.e. by compiling/adding something) the "whatever tests intersection with ray/poly/surface" with your own rather than having a fixed test ? )

Like the "intersection shader" ?

[Dio]

The RT model is to give you a compute shader which can call TraceRay on an acceleration structure, and that automatically calls a material shader on the result. Using only one material shader is generally recommended to avoid divergent execution or rescheduling overheads.

I'm unconvinced by the arguments over PSOs. I'm not sure anyone really wants to be surprised by the thing they're about to render. Fixing the workflow seems like it would lead to a much more usable system. Using ubershaders with specialisation versions does seem to be a useful thing and there is some work going on here to make this a little more friendly in future DX12.

[gilesgoat]

The RT model is to give you a compute shader which can call TraceRay on an acceleration structure, and that automatically calls a material shader on the result. Using only one material shader is generally recommended to avoid divergent execution or rescheduling overheads.

I'm unconvinced by the arguments over PSOs. I'm not sure anyone really wants to be surprised by the thing they're about to render. Fixing the workflow seems like it would lead to a much more usable system. Using ubershaders with specialisation versions does seem to be a useful thing and there is some work going on here to make this a little more friendly in future DX12.

I never been fully convinced on the idea of "Ubershaders" .. aren't shaders really bad at branching/ifs within ?

I mean ok you could have a thing like " if (this) do this, if (that) do that, if (someting else) do somehting else" in "a single piece of code" but isn't this precisely what shaders are very bad at ?

[Dio]

Yes, but for those suffering the hundred-million-shader-combinations issue then using an ubershader by default and specialising it once it's seen avoids the compilation issues.

[gilesgoat]

Yes, but for those suffering the hundred-million-shader-combinations issue then using an ubershader by default and specialising it once it's seen avoids the compilation issues.

I still think ( from my point of view ) that "not having a real separation" between shaders stages is ... "odd" I mean I don't know at this point "if it makes any sense" to talk about VS/FS/xxxS and/or in the end "gets all into a single compiled mess" and/or if we should call them alL "compute something shader" and that's it.

If you see it like that as "it's a thing that does things starting from a bunch of 'data' ending in some 'pixels' " then it would make "a lot of sense" ( again to me ) if at least "if the data that enters in and the pixels that gets out" are "the same" I should be able to "switch that blob in the middle" by litearally ( and I MEAN IT in this case H. ) "swapping a pointer in a register to point from one compiled blob to another".

Yes you can NOT cover "all the gazillions combinations" BUT there's "a fuckload you could do" by that.

I mean a case like :

Code: Select all

"Startup"

FOR EACH SHADER I in VS/FS/BLAH in LIST A[]
 COMPILE AND LINK A[I] into Blob[I]
END FOR

"While running"

Set Pipeline X ( descriptors, format, input, output, whetver )

While I decide it's ok 
 {
   if ( current_something != something )
    {
     Set Blob[ something];
    }
   current_something = something;
   Render();
}

While at the present the thing is more like :

Code: Select all

"Startup"

FOR EACH SHADER I in VS/FS/BLAH in LIST A[]
 COMPILE AND LINK A[I] into Blob[I]
END FOR

FOR EACH CombinationOfShit J in(  LIST B[] and Blob[] )
 Build Pipeline ( descriptors, format, input, output, whetver )  into Pipeline [J]
END FOR


"While running"

While I decide it's ok 
 {
   if ( current_something != something )
    {
     Set Pipeline[ something];
    }
   current_something = something;
   Render();
}

Basically the "granularity" is the pipeline when shaders are involved, which is a bit of PITA !

Yes you end up with "ubershaders" or such precisely for this reason.

I think "you melted too many things into one" with the result that "touch ONE thing and you mess all the 'blob' ( pipeline )".