Pixel shader incompatibility ?

I work with simulators everyday, and they are very slow, unless they are the FPGA type (which are extremely expensive). A refrast does not simulate the hardware, it just gives you the same output as the hardware should (a big difference). It would not be very hard to make, and I'm very sure that NVidia makes refrast-like software for each of their chips.

This allows drivers and demos to be made (at least to a certain stage) before the hardware is available.

If Microsoft wanted to buy it, I don't see how any company would have much problem with it, since it doesn't expose any secrets of the hardware or drivers.

Anyway, I'm just telling you what I've heard. I could be wrong. Still, the refrast is just the refrast's writer's interpretation of correct, be it Microsoft or whoever. Others may not agree with this. One example is how ATI determines which mipmap to use on any given triangle, which is noticeably different than NVidia's method (it's not just a linear LOD bias thing), as Hellbinder once pointed out.

 

Well, if you want to convince me, you'll have to provide facts. We have enough rumors flying around on this website!

I could just as easily claim that I heard ATI wrote refrast from a source, and provide a logical reason why it might be so (remember the rumors of ATI becoming Microsoft's new favorite and influencing DX9 more than anyone? And as you say, ATI must have their own refrast for the exact same reasons as NVidia would need to write one. Thus, if ATI was the primary IHV that worked with MS to create PS1.4 and PS2.0, then it's logical MS would license their refrast!)

MS has 100x the software resources of any of the software vendors, and enough luminaries in the field of computer graphics that they hardly need an IHV to write their API simulators for them.

 

And it certainly isn't called the reference rasterizer for nothing.

I.e. the hardware should match the output of the refrast, or its in error.

 

Which "it" is that?

As I said, there are a couple of things in the refrast which, IMHO, aren't ideal. and so enforcing such a requirement would be a mistake.

 

So, you're saying its just a highly recommended rasterizer?

I guess from my experience on the DX mailing list, the answer to the question "My code does X, is this right?" was always "What does the refrast do?"

 

I suspect that the chance of the refrast+driver being correct is probably higher than Manufacturer X's driver (tuned for all-out speed) combined with hardware.

Anyway, code should be tested on as many platforms as possible, and using the refrast at least increases the number of architectures by 1

 

Simon, would you share your observations?

 

I don't really want to get into details, but as a very simple example where you can't really say that the Refrast was correct and HW "X" was wrong would be with floating point. While the "Reals" form a mathematical field, computer floating point doesn't.

If you look at how the RefRast does the vertex shader DP4 calculation, for example, you'll see it is coded in an obvious way for doing it in C. OTOH, the way you'd probably do it in HW (i.e. to make the overall latency as small as possible) could easily produce different (but no less valid) results.

The important thing is that a particular system always does it consistently.

 

Indeed - the whole notion of a reference point is one of something that doesn't change while you test around it. It doesn't have to be a model of perfection or something that everything else aims towards; it just has to remain consistent.

 

There's also the case with umpteen sample anisotropic filtering which may very well exceed refrast.

Cheers
Gubbi