It's a bit involved to get this right (beginner topic ?), but you can save you the trouble: MJP made a blog post, source included. Works great.
If you want to time compute shaders it's even more delicate. Using above code without further care I either got disjoints or silly numbers. MJP once made a note in the DX forum (maybe you can find that post): You need GPU-sync points, IIRC e.g. a CPU-read-back (I guess CopyResource and Map of a something the compute shader spit out) or something similar. That, in turn, will likely bias your timings.
Actually, the D3D 9 viewport is in pixel-space (well, x and y at least). Normalized device coordinates are in [-1..1] (and [0..1] for z). But yes, aspect ratio is handled with the projection.
Point sprites ? I hear they have sometimes driver issues. Though you already checked software vertex processing, also try the reference device.
I'm concerned about that wireframe rendering though. Shouldn't the lines be continuous ? It really looks like you (still) have a rendertarget/window size mismatch (which then causes the squash of the points, too) ? I recommend doing (again) what Tispe recommended earlier, i.e. checking all relevant size information: client area, swapchain size, viewport, projection aspect ratio, Present parameters (if you're still using custom rectangles). Best dump it as text in every window and watch it live.
Or post your rendering code, maybe I see something.
Another proof it's a sampling artifact: Zoom in and out on Álvaro's anti-aliased image with your browser (IE,Firefox, Opera: CTRL + mouse wheel) and watch these circles come and go. One can sometimes even notice a second Moiré effect in a checkerboard fashion probably due to a box filter for the images.
This is fun. I think I remember the formula for the last video from aregee. Had copy the link manually, but the resolution is really bad, therefore...
C# code (console app, copy paste, add reference for System.Drawing)
static void Main(string args)
int width = 640;
int height = 480;
var scale = 50.0;
scale /= height; // adjust for resolution
var xh = width / 2;
var yh = height / 2;
var bitmap = new Bitmap(width, height);
for (int y = 0; y < height; y++)
var yy = (y - yh) * scale;
for (int x = 0; x < width; x++)
var xx = (x - xh) * scale;
var value = xx * xx + yy * yy; // f(x,y) = x^2 + y ^ 2
value = value % 1.0; // mod, though Hue should actually wrap anyway
var color = Hue((float)value);
bitmap.SetPixel(x, y, color);
#region Color functions
public static byte ToByte(float value)
return (byte)System.Math.Max(0, System.Math.Min(255, System.Math.Round(255f * value)));
public static Color FromFloat(float r, float g, float b)
return Color.FromArgb(ToByte(r), ToByte(g), ToByte(b));
public static Color Hue(float hue)
float oneSixth = 1f / 6f;
float h = hue - (int)hue;
int index = (int)(h / oneSixth);
h = (h / oneSixth) - index;
var q = 1f - h;
case 0: return FromFloat(1, h, 0);
case 1: return FromFloat(q, 1, 0);
case 2: return FromFloat(0, 1, h);
case 3: return FromFloat(0, q, 1);
case 4: return FromFloat(h, 0, 1);
default: return FromFloat(1, 0, q);
Playing with the scale: scale = 10 scale = 20 scale = 50
There's also a constant buffer for the tex-coords (cbFixed), filled with default values. These only work with the effect framework, so you have to fill it manually and set it to the correct slot, just like the other constant buffers. For this particular case I for one wouldn't even use a constant buffer but declare this array as a static (which then gets hardwired in the shader)
Is there a way to revise the topic to add RESOLVED or similar?
You're not supposed to according to forum rules in order to not prevent further discussion. And I actually have to say something here.
First: Congrats. I've never seen this approach working (rerouting the output to other HWND with Present), so nice to know it's possible.
Usually when rendering to different windows one is supposed to create additional swapchains, one for each window. Doing so has one big advantage: You can omit the obnoxious D3D9 device reset when changing resolution. Though I nowadays mainly play with D3D11 I used this approach even for the main window: Create a (small) dummy backbuffer and use a custom swapchain instead. One can then even e.g. flip v-sync without a device reset
Your approach still has an advantage I think: I guess each swapchain will reserve device memory, so when you got a bloody lot of child windows you're "wasting" precious memory. Maybe you could combine both approaches, meaning: Use a central swapchain for all your child windows.
In the hope you get the same erroneous behaviour: Use PIX ! When the debug layer doesn't give useful clues (I don't think the leaks are the culprit here) it's time to get a closer look at what actually happens. Compare it with the running version and maybe use a very simple mesh (e.g. cube) and only a couple of instances for a start.
As an aside: Not sure, but since instancing needs SM 3, try actually using vs_3_0 and ps_3_0 in your shaders.
Now I think I finally get your confusion. You're probably not even after subsets at all. If it's just about drawing different objects, it's even simpler: Bind the buffers for one object, draw, bind another, draw...
IASetVertexBuffers/IASetIndexBuffer don't "stack" like you probably suspect. When issuing a draw call, only the latest call to them matters. Buffers and their content also don't get lost/destroyed after drawing, if I get your meaning. They stay alive until you did your final Release() call (or more precise: when their reference counter reaches 0).
The purpose for binding multiple buffers at once is rather for e.g. instancing (where one buffer defines the geometry, another the transformations) or if you want to split vertex attributes (e.g. one buffer could hold positions, another normals. In that case, they still define the same object).