Wrapper question

What do you mean?

 

He means that ordered grid supersampling has a very bad EER (Edge Equivalent Resolution).

With the same sample count a rotated grid implementation provides much better edge anti aliasing.

 

Microsoft provides the wrapper functionality already. Driver writers don't write any DX6 drivers for modern hardware. It's translated to at least DX9 level by the runtime / driver interface. Unless there are bugs in the MS implementation that they won't fix I don't see what purpose this would serve.

 

Yeah Microsoft already does the "wrapping" for you. PhysX uses CUDA so not sure how you'd "license" that for your non-NVIDIA hardware...

Huh? The ref rasterizer is not exactly an ideal or anything. It actually has some bugs or lower-precision cases that the real implementations don't.

 

Zero point in that - complementary Z buffer with fp32 gives the same or better quality everywhere. For legacy apps (if that's what you care about?) the driver could just use this format, but maybe that's what you mean by "emulate".

 

There are actual two “wrappers“ since DX11. The one that was already part of Vista converts any API below DX9 to the DX9Ex drier interface. But it will never use the DX10+ driver interface. The other wrapper is used to allow the 9er feature levels for DX11. It’s a DX10+ user space device driver that converts the calls to the DX9 user space device driver.

Therefore the problem is that even if you hook at device driver level you can’t use the DX10+ features for a <= DX9 app.

The correct solution for the dither problem is to force the render targets to 32 bit. The old games that looks ugly because of the missing dither use a 16 bit targets. There is only a problem when the game although writes to the target directly.

 

Fair enough although in how many applications do you legitimately see Z-buffer precision fighting nowadays? 16-24bit mostly solved that if you use reasonable near planes.

 

This is not exactly correct. 16 bit color textures work perfectly fine on DX10/11 hardware. The quality is identical to the older APIs.

If you are rendering to a 565/1555 render target (back buffer), you no longer have the option to enable dithering to your color writes (regardless of the format of the textures you read your color data from). A simple wrapper that would replace 565 back buffer with 8888 back buffer would improve the alpha blending quality of the old games nicely (and would also remove the 16 bit dithering artifacts completely along the banding). No need to go to DX11, since all the older DX-versions also supported 32 bit backbuffers. Just intercept the CreateDevice call and replace the back buffer format parameter.

Same simple replacement can be done with z-buffers as well. Just intercept the call to CreateDevice, and replace the z-buffer format. It would work just fine for huge majority of DX3-DX7 games, since most games at that time rendered the scene to the back buffer. For current titles replacements such as this do not work that well, since the games have so many offscreen surfaces, and majority of graphics isn't rendered directly to the back buffer. Shaders have changed everything. In old games the render targets and textures were just color data, nowadays the data can be basically anything. The API doesn't know what the data represents. Forced bit precision increase or forced antialiasing can really break the algorithms developers have carefully planned. You can't for example antialias a back buffer containing data pointers (indices) to your scene's light sources and blend the edge subsamples together (blending colors is ok, but blending pointers is not).

There is no way to force MSAA on all deferred shaded DX10/DX11 games either, without doing specific driver code and shaders for all the possible variations and updating the driver every time a new game is released. If the game developer doesn't code a support for MSAA, the driver cannot add it later by any simple universal methods.

There are countless of different deferred sharing implementations (full deferred shading, different light prepass methods, light indexed deferred shading, inferred shading, variations of rendering light geometry and dividing the screen to blocks and rendering the lights on batches, etc). In addition to this, games store their g-buffers in different formats with different data in them (motion vectors, light indices, object indices, differently encoded normals, etc). The number of MRTs vary wildly, and the format of the MRTs vary wildly (some games even have mixed formats for different MRTs). Some deferred shading methods require multipassing the scene twice (first light prepass renderers and LiDR) and some require extra combination passes (combine light accumulation with surface colors). And to make things even complicated, new deferred sharing methods are invented all the time. Since the game application doesn't tell the API what kind of data all the buffers and textures contain, there is no straightforward way to implement working antialiasing in the driver side.

And I am sad to say this... but I predict that virtual texturing will be huge in the future. So soon there will be no more simple forced anisotropic filtering in the driver either that works on all games.

 

It's not as simple as that. You would have to convert the buffers back to 565/1555 when they were locked as well. Many older games lock the backbuffer during rendering.

 

Or even worse doing strange GDI operations on the back buffer.

I have worked around the conversion problem for a specific game that only writes to the back buffer by converting this writes to line primitives.

You need some programming experiences in this area. Nvidia solve such stuff at a deeper level and don’t need to hook Api calls.

 

How much of a performance hit do these wrapper layers incur? Recently, I have revived my Wndows XP and run some lower-level benchmark which turned out to be significantly faster on XP than on 7/Vista (on both systems in the four-digit-fps range).

 

If you take smartshader as an example (not exactly a wrapper, but a software renderer) runs ut2004 1650x1080 high, player against a single bot small level does 7fps on a q6600

glide wrappers not sure what the hit is but a solid 60fps is achievable in any glide game on a modern pc

or are you talking about the DX9 to the DX9Ex driver interface


win7 vs xp (xp is faster but could be down to driver immaturity as the article was from aug 2009)

Performance Delta (7's values relative to XP's values)
C:\Windows\ directory size: +216.62%
3D Mark 2001 (0xAA): -18.06%
3D Mark 2001 (4xAA): NA
3D Mark 2005 (1280x1024): -16.58%
3D Mark 2005 (1600x1200): -11.11%
Crysis (1280x1024): NA
Crysis (1680x1050): -30.83%
Doom 3 (1280x1024): -49.57%
Doom 3 (1600x1200): -57.01%
UT3 (1280x1024): -29.75%
UT3 (1680x1050): -33.43%
WinRAR compression: -8.56%
DIVX upscale: -4.25%
Sonar 8 mix-down: -45.71%

 

Let me just call this out immediately and say that if they are both in the "four digit fps range" then neither is "significant faster". This is *precisely* why you should use milliseconds per frame to measure performance and not fps. You're measuring trivial overheads that are in the microsecond range at best and concluding that something is "significantly faster" because your huge numbers are the reciprocals of the tiny numbers that you ought to be comparing!

 

well one could be 1000fps the other 9999fps that would qualify as significant faster

ps: what games are you testing to get that sort of frame rate

 

No it wouldn't that's my entire point - that is a difference of a whole .9 milliseconds! The difference between 30 and 31 fps is more than that. Just use milliseconds.

Also not sure where those Win7 vs XP numbers are coming from. From this article (which is also pretty old - also from Aug 2009), I'll quote the conclusion:

 

sorry not with you its 10x the frame rate as for your 30/31 example if we used something much more complex the difference would be 30/300 a lot bigger than 30/31 something even more complex it would be 3/30 or unplayable to playable

edit:
here
http://www.tomshardware.com/forum/841-63-windows-benchmarked-complete

pps: another quote from the article you linked to :

The 3-Way battle between Windows XP, Vista, and Windows 7 is much closer when you exclude the second GPU benchmarks; other than ARMA II, the Radeon and GeForce GPUs performed remarkably similar regardless of OS (as long as you exclude the GeForce Windows XP x64 numbers). No one OS really pulls away from the other, they just trade wins and more often than not, they’re tied in performance