i get what you mean - but that would mean doing each face in series…if you want to render 6 different triangles to 6 different targets at the same time you would need 6 rasterizers, yes?
point is the current multi-rendertarget machines use the same rasterizer for each target- you can just adjust what color & maybe depth values are written to each.
the rasterizer is upstream from the fragment processors - so to get all the frag processors operating in parallel you need 6 different rasterizer units.
[This message has been edited by vshader (edited 08-11-2002).]
[This message has been edited by vshader (edited 08-11-2002).]
white it could be funny to work with 6 different rastericers its absolutely useless for this problem. we don’t want to render to 6 different targets, nor want we to render 6 different triangles. we want one triangle, and it should go on one target. the cubemap.
and about the 4 different targets on dx9. in fact its one big 128bit buffer and you have 4 32bit values in. now in the full floatingpoint pixelshader you can eighter store r,g,b,a in the 128bit buffer, or use one of the compressioninstructions to compress say a full floatvector into one 32bit rgba value (4 unsigned chars then), or two of them into one 32bit “HILO” value (means two shorts), or two of the minto one 32bit float 2d vector, where you use half precision floats (each one 16bits). so you can store in the end 16 different values for your triangle, all 8bit unsigned chars, or 4 floats, or some unsigned shorts, some unsigned chars, some floats, some halffloats, in what ever combination. its just one fat 128bit target. and you can copy out one of the 4 32bit components (or even one of the 8bit, i dunno?) onto a texture, or some of them, or however, for reuse…
hope that chaotic text clarified something about next gen hw…
hope that chaotic text clarified something about next gen hw…
thanks, it does…means we’d have to wait until 256bit framebuffers before there’d be enough room for 6x24+bit depth values
the scheme you are talking about is easier at the app end, but it means rasterized fragments would also have to carry a cubemap face index as well as current x,y and depth values. not sure wether that is easiest for hardware to implement, or 6 complete pipelines, with the app doing visibility determination for each face…
[This message has been edited by vshader (edited 08-12-2002).]
if the gpu supports 6 rastericers, then i want the gpu to rasterice 6 triangles at once. that would mean 6times as fast. but for a cubemap i would have to use one rastericer anyways at the time. it would not help…
and you don’t need an aditional face index btw…
it is rendering onto one target. not only for the app but as well for the gpu. what you suggest is the same as we have today, just with a faster hw. that doesn’t help, as we can render to a single target faster then as well…
setting up a rastericer to rasterice cubemaps as well should not be that much of a problem. the only real problem is, its slighly different, and todays rastericers are pushed since years till the extreme so they are sort of perfect. and you need this perfection for the todays speed of them… so it would be (at least the first versions) possibly quite a bit slower… but generating scanlines for one target or for at max 4 is not a big trouble really… (i think 4 is the maximum of cubesides one triangle can get drawn…)