some GDC 2004 D3D papers are up at ati developer page

Yes, and although the "B" designation seems suggest > PS_2_a, it's not the case. PS_2_B still doesn't support arbitrary swizzle, unlimited texture dependency, gradient instructions, or predication. PS_2_b is basically a step back from 2_a and adds *yet another* profile. PS_2_b = PS_2.0 with higher instruction limit and slightly more registers. Whoop de do.


ATI's GDC presentation is a poster boy for why DirectX's approach to compilation sucks. The compiler won't generate predicates, won't generate subroutines, has a very *narrow* type of for() loop it can handle, and has hardcoded heuristics that it decides for a whole class of devices which kind of branch compilation technique to use (dynamic or inline)

The best place to decide branch heuristics is in IHV code because latencies and penalties for branches will be very GPU specific.

OpenGL please!
 
DemoCoder said:
Yes, and although the "B" designation seems suggest > PS_2_a, it's not the case. PS_2_B still doesn't support arbitrary swizzle, unlimited texture dependency, gradient instructions, or predication. PS_2_b is basically a step back from 2_a and adds *yet another* profile. PS_2_b = PS_2.0 with higher instruction limit and slightly more registers. Whoop de do.
Click to expand...

Well their we go the two bigest players now have their very own flipping render target great well their goes the whole platform independance doesn't it now everyone is going to do PS_2_0 PS_2_a PS_2_b and PS_3_0 or they will annoy atleast one of the vendors.
 
They should just label them PS_2_nv and PS_2_at and be done with it. PS_2_at is a subset of PS_2_nv. We're back at the situation with PS_1.3 vs PS_1.4
 
ps_2_we_suck_too_much_to_just_make_it_3 (ps_2_a) and ps_2_wtf_we_dont_need_this (ps_2_b). I think that would be a lot classier.

HLSL targets supported by only one IHV suck. I say we ask developers not to use them.
 
The Baron said:
ps_2_we_suck_too_much_to_just_make_it_3 (ps_2_a) and ps_2_wtf_we_dont_need_this (ps_2_b). I think that would be a lot classier.

HLSL targets supported by only one IHV suck. I say we ask developers not to use them.
Click to expand...

I like the names. Alot.

I agree 100% though. This is getting to be retarded, HLSL has done nothing but push us back because of ps_2_a and now ps_2_b, which is just retarded to me. If ATi is boosting the instruction count, why not use ps_2_a and end the story? Setting up another Target is just a bad idea.

Centroid sampling on the other hand..
 
Waltar said:
The Baron said:
ps_2_we_suck_too_much_to_just_make_it_3 (ps_2_a) and ps_2_wtf_we_dont_need_this (ps_2_b). I think that would be a lot classier.

HLSL targets supported by only one IHV suck. I say we ask developers not to use them.
Click to expand...

I like the names. Alot.

I agree 100% though. This is getting to be retarded, HLSL has done nothing but push us back because of ps_2_a and now ps_2_b, which is just retarded to me. If ATi is boosting the instruction count, why not use ps_2_a and end the story? Setting up another Target is just a bad idea.

Centroid sampling on the other hand..
Click to expand...

because they can't actually support the 2_a target from feature point of view. Besides it's more optimized for the nv3x architecture anyway
 
The Baron said:
MuFu said:
Maybe PS_2_b is a special suprise bonus for R3x0 users? :cool:
Click to expand...
Oh, you mean the thing that FINALLY exposes centroid sampling?

But what about the F-buffer... :LOL:
Click to expand...

centroid will be supported in ps_2_0 and upwards with dx9c
 
NVidia's paper is troubling. They don't mention sparse sampling at all in their discussion of MSAA, only OGSS and RGMS. Does this mean NV40 doesn't have any new AA?
 
DemoCoder said:
NVidia's paper is troubling. They don't mention sparse sampling at all in their discussion of MSAA, only OGSS and RGMS. Does this mean NV40 doesn't have any new AA?
Click to expand...
Wouldn't RGMS be "new" for nVidia?
 
DemoCoder said:
The "Custom AA" is basically a theoretically thing. I doubt many developers will bother with it. Too much work.
Click to expand...

RTHDRIBL is doing something like custom Multisampling (it does motion blurring at the same time, it makes sense since when thing moves you don't care about their visible edges). Of course it is nicer when you have a lot of available power (or a simpler scene).

LeGreg
 
I'll add that it had to do it that way since most of its rendering
takes place in 16 bits float rendertargets.

LeGreg
 
You must log in or register to reply here.
Back
Top