I do this by a simple bitfield for the 6 planes (e.g. 0×001010 would mean test the third and fifth frustum plane) which is used to index a table saying how many and which planes to test.

That would be just fine for the SSE version. I’ll definitely try it and post the results as soon as I can.

I’m aware of the algorithm you mention. It was probably my fault. I should have mentioned the potential applications of the above algorithm. The snippets presented in the post is suited more to situations where you have a lot of AABBs you want to test at once. E.g. all the objects in a leaf of a hierarchy. The algorithm you describe is still very useful in order to reach the leaves. And it’s not that much of a trouble to keep the bitfields around, while traversing the hierarchy, and test only the planes needed.

On the other hand, integrating that idea to the SSE version of the above snippet, wouldn’t do any good, imho. I haven’t tested it, but I assume that inserting a hardly predicted conditional branch in the inner loop of the last snippet would hurt performance. In the SSE case which process 4 AABBs at once, you have to OR the bitfields of the 4 AABBs into one, and only check those planes which are relevant to at least one of the four AABBs.

I might check it in the future just for the fun of it.

Thanks for stopping by.

Given the speediness of SSE testing, this optimization may not be worth the trouble, but I thought I’d mention it. This idea is from Bishop, L., D. Eberly, T. Whitted, M. Finch, and M. Shantz, “Designing a PC Game Engine,” IEEE Computer Graphics and Applications, pp. 46-53, Jan./Feb. 1998.

As for the 4 parallel min/max, I’ve thought of that, but I think it’s applicable only when the app is 64-bits due to the greater number of XMM regs (16 if I’m not mistaken). Doing it that way requires at least 8 regs for the 4 min/max pairs, so I’m out of registers when compiled as 32-bit code. The goal is to minimize dependencies in the inner loop. With MINPS/MAXPS I think I can do that for 2 min/max pairs at the expense of using unaligned loads. I’ll try this idea too.

Thanks for the feedback.

Another thing which may help (if there are enough registers) is to do a parallel min/max in chunks of 4 vertices – i.e. compute 4 min vectors and 4 max vectors, each for (i % 4) == k, k=0..3, and then reduce 4 results to 1.

RDTSC should actually be fine on multicore systems (it should stay in sync), but it’s still kind of problematic. In particular RDTSC is bad for measuring wall-clock time since it may vary over time e.g. due to SpeedStep. Also, I’m not sure what effect Turbo Boost might have on RDTSC — it might not affect RDTSC rate measurements, which would mean the processor is actually processing more cycles than RDTSC reports. For best results at trying to measure cycles you probably want to use RDTSC and turn off Turbo Boost or fully load all your cores. But with all these varying clock rates and hyperthreads and things, it’s becoming less meaningful to talk about measuring actual clock cycles, and you might want to just stick to wall-clock microseconds on a specific processor, or such.

For measuring moderately-small things with wall-clock time, QueryPerformanceCounter is preferred. It’s supposed to be based on the hardware bus clock rate, which won’t ever vary. (However, the Frequency isn’t 100.0000% accurate, so you can’t actually use it for long-term wall-clock times.)

I know that averages without stdev don’t say much, so I’ll try to calculate it next time.

The numbers have been calculated by running the following snippet 100000 times, sorting the results in ascending order, and calculating the mean from the middle 60000 iterations:

InitializeArrays();
float cyclesPerVertex = Profile();
Cleanup();

RDTSC isn’t the best way to profile code on multi-core systems, from what I’ve read. I was wondering if there’s an alternative way to count cycles with minimal overhead. Do you have any ideas?

How much of the speedup is really due to SSE and how much is due to the prefetching?

I just rerun the SSE tests without prefetching. The difference is 1 – 2 cycles depending on batch size. Prefetching seems to be useful for batch sizes larger than 1024 vertices. Smaller batches give identical results with or without prefetching.

What exactly are you measuring?

Here is my profile function.

void Profile_TransformVec3Pos(_Vector3f* __restrict src, _Vector4f* __restrict dst, unsigned int numVertices, float* __restrict matrix)
{
	SetProcessAffinityMask(GetCurrentProcess(), 0x01);
	SetThreadAffinityMask(GetCurrentThread(), 0x01);
	SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_HIGHEST);
 
	PCM* monitor = PCM::getInstance();
	printf("\n");
	if(monitor->good())
	{
		PCM::CustomCoreEventDescription events[4];
		events[0].event_number = 0x24;
		events[0].umask_value = 0x01; // 
		events[1].event_number = 0x24;
		events[1].umask_value = 0x02; // 
		events[2].event_number = 0x10;
		events[2].umask_value = 0x10; // SSE fp packed uops
		events[3].event_number = 0x10;
		events[3].umask_value = 0x20; // SSE fp scalar uops
 
		monitor->resetPMU();
		if(monitor->program(PCM::CUSTOM_CORE_EVENTS, &events[0]) != PCM::Success)
		{
			printf("Error while trying to program PCM\n");
		}
	}
 
	printf("Starting measurement...\n");
	CoreCounterState before_sstate, after_sstate;
 
	before_sstate = monitor->getCoreCounterState(0); 
	{
		TransformVec3Pos(src, dst, numVertices, matrix);
	}
	after_sstate = monitor->getCoreCounterState(0);
 
	unsigned __int64 totalCycles = getCycles(before_sstate, after_sstate);
	double cyclesPerVertex = (double)totalCycles / (double)numVertices;
 
	printf("IPC: %g\n", getIPC(before_sstate, after_sstate));
	printf("Cycles: %I64u\n", totalCycles);
	printf("Cycles/vertex: %.2f\n", (float)cyclesPerVertex);
	printf("Event 0: %I64u\n", getNumberOfCustomEvents(0, before_sstate, after_sstate));
	printf("Event 1: %I64u\n", getNumberOfCustomEvents(1, before_sstate, after_sstate));
	printf("Event 2: %I64u\n", getNumberOfCustomEvents(2, before_sstate, after_sstate));
	printf("Event 3: %I64u\n", getNumberOfCustomEvents(3, before_sstate, after_sstate));
 
	monitor->cleanup();
}

TransformVec3Pos is a macro which points to one of the two functions mentioned in the post. Do you see something strange in this code? I’ve verified that MSVC doesn’t inline either one of the functions. Any ideas on what might affect the results?

(I hope code blocks appear correctly in comments Apparently it messed up the code a bit, but I’ve corrected it)

I’m unclear why you would see such wide variation in timings with batch size on either code. Even a batch size of 128 should run the C version enough to minimize any non-iteration overhead, so it seems highly implausible that the C code should get get 6 times faster as the batch size goes from 128 to 16384 (although it’s possible that’s the hardware prefetcher coming into play). This seems more like the kind of variation you see in java benchmarks (which have huge startup overheads). What exactly are you measuring?

Thanks for all the feedback. I hope the flickering does not prevent you from using the application. If you have any other problems while working with Memory Analyzer, we will be glad to help.

I’ve managed to reproduce the issue with the version linked in the project’s page (for some strange reason it doesn’t seem to appear every time). The bug doesn’t seem to be present in the current version of the code, so I hope it has been fixed (couldn’t find a related issue in the bug tracker, so it’s either been fixed accidentally or hasn’t made it to the bug tracker).

Please try the new version (direct link) and report back. Thanks.

c:\windows\winsxs\x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_405b0943\MFC90.DLL
c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\MSVCR90.DLL
c:\windows\winsxs\wow64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.3790.3959_x-ww_5fa17f4e\COMCTL32.DLL
c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\MSVCP90.DLL

Since you’ve run it from a debugger, can you please tell me which DLLs are being loaded? I’m more interested in the MFC’s DLL folders (which contain the version number). Maybe we can reproduce the bug, if we know the exact versions.

Thanks again for the feedback.

The application uses MFC (obviously) so I can’t think of a reason it should be a problem. I have the same configuration (VS2008 SP1) but on Win7 64-bit and it works. We’ve tested it on WinXP 32-bit as well as Vista 32-bit (on virtual machines) and it worked correctly (with the appropriate redistributable package).

The only thing I can think of is that the application doesn’t use the correct version of the MFC DLLs for some reason. We’ll try to reproduce the problem on a virtual machine with WinXP 64-bit. I’ll be back later with more info.

And I’m sorry for the captcha problem. It’s WP’s (or maybe the plugin’s) fault. We’ll look into it to.

mfc90.dll!CControlFrameWnd::PostNcDestroy() Line 74 C++ ctlframe.cpp
mfc90.dll!CWnd::OnNcDestroy() Line 863 + 0xa bytes C++

I think the GUI is the problem.

BTW: please don’t delete my comment when I input the wrong captcha code, that SUCKS!

It seems that this is a common bug which doesn’t appear on our machines. It doesn’t seem to be related to the Windows version (also happened in Win7 Enterprise with the previous version).

Thanks for reporting it. You will try to fix it asap.

In the meantime, can you also post the modules base address or the offset to the exception code in order to debug it and see what’s going on. The address at which the exception occurs is, unfortunately, useful only if it’s relative to the module’s base.

Thanks again for trying Memory Analyzer.

This is on Win7 Enterprise (32-bit), and an application that was built using VS2008.

Has the MemAnalyzer had any updates since 9/2009 that might help me get it running?

Thanks!
Thom

That seems like a great tool. It’s nice to see the progress since your Gamasutra articles. We are still working on and off on our tool but we haven’t had the chance to post an update since our last post (one year ago).

We’ll be watching your youtube channel for updates on this tool. If there is a demo somewhere I’ll also be glad to give it a try.

Thanks for stopping by.

http://www.youtube.com/watch?v=T4fEijatabk

ARG!! This explains why it works great on my 9400M laptop but makes it run even slower on my 6600 (from 24fps before stenciling to 19fps)

-Greg

First of all, thanks for the feedback. Some of the things you mentioned (like resizing all controls when the window was resized) were in our TODO list. We have fixed the scrolling issue and we have added mouse wheel support and larger block sizes (up to 256 bytes).

You can download the new version of Memory Analyzer from here: Memory Analyzer v1.0 (build 20090607). I’ve also updated the original post in order to point to the new archive.

The new version also includes some small additions (e.g. you can now manually specify which functions you would like to suppress through an external file) and bug fixes.

Regarding the single view of the entire virtual memory. Unfortunately there isn’t a way right now to do that. We plan to add one more view for that, with color encoded fixed size blocks, and without callstack and source code info. If you have something specific in mind about how this view should look, please share it with us.

Thanks again for testing Memory Analyzer and for the feedback.

Dragging the scrollbar doesn’t seem to work. If I drag the view often stays at the top of the selected heap.

If you have a really small heap that doesn’t fill the view, the view doesn’t completely repaint, so you see the old data from the previously viewed heap at the end. Clicking on the scrollbar appears to force a refresh.

Note that I saw these just by using your tool with Excel (2003).

Is there some way to get a single view of the entire virtual memory (not specific to any given heap)? This would be helpful in seeing the overall picture of the application’s memory when I don’t care which heap the allocation came from.

First of all I would like to thank you for the excellent demo and presentation.

At first I didn’t fully understood what you were suggesting, but after thinking about it a bit more I think I got it. Dynamic placement of decals on a prebaked virtual texture. The reason I didn’t get it the first time was because we haven’t come to the “game” side of things yet. Let me explain. Currently the virtual texture is generated by painting several different materials on it (see another post on the subject) inside an editor, and by manipulating decals and roads (by translating, rotating and scaling them). In those case, a complete invalidation of all the affected tiles from all mipmap levels is required, in contrast with the game side of things, where *static* decals are generated whenever the player shoots something. For those cases, your idea sounds really good, but I guess we’ll have to start implementing it in order to fully understand the alignment problem you describe. Either way, thanks a lot for the idea.

On the subject of editing the virtual texture, we’ve mainly focused out attention to the speed of the software rasterizer (since the last post). After a lot of optimizations and by taking into account that we are generating a texture for a terrain (top-down axis aligned quad(s)), the speed has been improved a lot, and the average time for baking the diffuse color and normalmap of an arbitrary tile with 12 terrain layers and about 200 decals (quads) and roads (arbitrary quadrilaterals) is about 5msec. This number doesn’t say anything on its own, but compared to the 18 msec for 3 layers (without normalmaps and decals) we mentioned in the other post, it’s a nice improvement. Unfortunately, I don’t know how that compares to a GPU implementation because we haven’t tried it yet.

Our main focus lately is on ways to improve the visual quality of the final output. The main problem when you use a single texture for terrain rendering is the excessive stretching on steep slopes. We implemented the indirection mapping technique, but it didn’t seemed practical especially for the terrain sizes we’ve tested (2048 and up). The result might have been a bit better (increased the resolution of the texture on steep slopes), but this didn’t help a lot with stretching since it actually requires different UV parametrization. So we decided to use extra geometry for a selected number of terrain layers with triplanar mapping. The results are a lot better than the previous method at the expense of extra rendering passes (which, unfortunately, is in contrast with the idea of virtual textures). We’ll consider the technique again in the future, but for now we’ll stick with the extra pass.

One idea we had (but didn’t have time to test) is the usage of a 2D texture array for the tile cache. This way, the tiles will be independent of each other, minimizing the artifacts when using trilinear or anisotropic filtering. You’ll still get some artifacts when the filter kernel is larger than the border used, but the data that will be fetched will actually be relevant to the tile (no worries about sampling a rock texture for a neighboring tile when you are expecting something grass-like). Have you tried something similar? Any problems we have to keep in mind when we’ll try it?

Thanks again for dropping by.

This is mostly interesting for decals. The idea is that you just mipmap the decal, and then apply the mipmaps of the decal to the mipmapped underlying image, rather than recompute the mipmap. This is obviously inaccurate (features that get covered up by the decal at high-res mipmap levels will bleed through at lower mipmap levels as the decal’s alpha drops), but if you pretend you’re using trilinear, the goal of the mipmaps are to minimize the visible transition between mipmap levels, not to produce (say) the RMSE-optimized idealized filtered version. So if in general mipmapping is good enough, it shouldn’t be surprising that mipmapping of the decal independently is good enough (if you imagine what happens during an LOD transition).

One subtlety: if you mipmap the decal with a box filter, then you have an alignment issue: if your decal appears at (0,0) on the texture, it will align with the underlying mipmap and mipmap “identically” with how it would, but if it appears at (1,1) in the texture, to apply the mipmap to the next level up it now falls at a subpixel position, so you either need to snap, or bilerp it. Bilerping will introduce extra blurring, and snapping will introduce a visible movement as you transition LODs.

My solution in my demo was to produce 4 mipmap variants from the base, each shifted by (0,0), (1,0), (0,1), and (1,1). This requires 4 times as much storage, but the mipmap is 1/4 the size. If you wanted to do it “right”, you would need 16 variants of the next level up, 64 of the next level up, etc. This would require just as much storage per mipmap level as the original image. Instead, I just computed 4 shifts at each level total, allowing some translation as you went up mipmap levels (but only half as much as the naive solution would produce).

An alternative would be to use a mipmap that’s not biased to any particular shift; you could do this with just some different filter that’s more friendly, or you can just use the *average* of all the mipmaps that would be computed in the above process. This would probably be what I would do if I wanted to do this for real on the CPU. (If you can GPU accelerate it, then maybe the bilerp of the naive decal mipmaps is good enough.)

GPU decal application to baked mipmaps has a drawback–once your decal mip level reaches 1×1, if it has a non-zero alpha, you actually want to continue generating higher level mipmaps (e.g. you have a 1×1 decal with alpha=0.6, then you want a next-higher mipmap that is a 1×1 decal with alpha=0.15). Hardware designers missed this orthogonality.

I’ve already mentioned depth bounds testing in combination with scissoring, in order to speed up shadow mask calculations, at the end of post. I’m also aware of the timer query extension, but i haven’t had the chance to work with it yet. I didn’t know that those two are nvidia only extensions (especially depth bounds testing), so i’ll have that in mind.

Thanks again for your comments.

JD

If you are programming on an nvidia card, you should have 2 useful extensions available to you:
- GL_DEPTH_BOUNDS_TEST_EXT: I use it as a work-around to render light volumes in my deferred renderer if early-stencil rejection isn’t working ( => nvidia).
- GL_EXT_timer_query: very accurate to time GPU calls and to use as a GPU profiler. it has been very valuable to me, as sometimes the driver screw things up when you switch FBOs or change to FBO -funky- configurations, etc… some operations are not very well supported by the driver (or maybe not meant to be?).

Hope this helps.

Cheers,
Kc

I’ll have to make some tests for early depth rejection at some point. Fortunately i’m not sharing the depth renderbuffer between FBOs, so there should be no problems with that. I’m currently changing the color attachments of an FBO and keeping the depth buffer attached all the time. Are there any problems with that?

Thanks again for the valuable information.

JD

While running on a Geforce 8800GTX, early depth rejection and early stencil rejection always work, either on the window framebuffer of offscreen FBO.

It’s also worth noticing that early depth rejection and early stencil rejection are triggered only with specific render-states combinations, which ARENT the same for Nvidia or ATI graphic cards.

AFAIK: with Nvidia, stencil-write must be disabled for early stencil rejection to kick out.
On ATI, you can write the stencil while testing it, early rejection keep working in theory (hummm havent tried that myself).
For early depth rejection, it might only work with specific depth-compare functions (not all – depends on vendors). trying the share offscreen depth-texture between different FBO is likely to trash early depth cull memory, etc…

Definitely a lot of fun to get all that working xD

About the first comment in the link you posted. The resulting shader will look like the second fragment shader i posted above, with the exception that since we have an atlas, it’s more natural to first find the correct vector and then sample the shadowmap atlas. The idea is the same, but unfortunately it can’t be applied in my case since i don’t have access to the 4 shadow vectors from a vertex shader. What i have is the pixel’s position in world space, and i have to work with that. This means calculating the 4 shadowmap vectors in the fragment shader (by passing the matrices as constants), then finding the correct one using the calculated index and finally sampling the shadowmap. This needs only one TEX but it’s math heavy so i don’t know if there is actually a speed up.

Unfortunately, i don’t have ShaderX6 so i can’t comment on the article you suggested. It’s in my list for books to buy but i didn’t have a chance to get it yet. The good thing is that you gave me an idea to improve the shader. Here it is:

Since all 4 matrices (1 per split) are based on the same light projection matrix, with different crop matrices, i think it’s possible to simplify the shader by passing the light projection matrix as uniforms, and store the crop matrices in the texture. The good thing is that the crop matrices have a simple representation and they can be packed in 4 floats, which requires only one texel in the matrixTex. This way we still need the transformation from world to light space (4 DOTs), but we can substitute the 4 TEXs to the matrixTex with 1 TEX, 1 MUL and 1 MAD.

I haven’t tried it yet, but i’ll definitely do so once i have the chance.

Thanks again for the comments.

JD

You can also see it in the first comment of this: http://pixelstoomany.wordpress.com/2007/09/21/fast-percentage-closer-filtering-on-deferred-cascaded-shadow-maps/

I’m not really sure if I could get the setup wrong, and here is why:

1) I’m using a renderbuffer for the depth/stencil surface, so there is only one way to create and set it up.
2) Dimensions are the same as the color texture, primarly because they are both created in the same function which takes the dimensions as parameters, but most importantly, differently sized attachments aren’t supported by my 7950, so i would expect the FBO to be incomplete (i check for that).
3) There is only one format supported for rendering to a stencil buffer with FBOs, and this is DEPTH24_STENCIL8 (GL_EXT_packed_depth_stencil) so I don’t have a lot of options here.

I haven’t checked GLexpert, so i don’t know if it complains about my setup, so i’ll have to do it sometime. AFAIK this is the only way to check if something is wrong under GL. Hopefully the debug profile under GL 3.0 will make tracing down such problems easier, but i’m not really sure about that until complete GL 3.0 drivers are out (and i’m able to get a GL 3.0 capable card, but this is another story).

One thing I’ve tested since i posted this, is what happens if i don’t render anything to the stencil buffer. I just clear it to the correct value and let the fragments pass if the value is different than the clear value. Again, when rendering to the window FPS is pretty high (because no fragments pass the test), but when i render to the FBO the FPS is the same with or without the test, such as the test happens after the fragment shader (the output is correct in both cases).

If you have any suggestions on how to test this further i’d be glad to hear them.

JD

First of all, thanks for reading.

The actual shader i’m using is the last one. I know that 5 TEXs should be expensive, but unfortunately in my case this seemed like the best approach. I think the 4 TEXs from the matrix texture should be very coherent so they should be fast, but I’m not really sure about that.

Your approach of rendering all 4 splits into the 4 different channels of the same texture sounds good. May I ask what format you are using for that? I assume RGBA16f (or RGBA32f), in contrast with my implementation where I use one regular depth24 texture for all shadow maps. If this is the case, isn’t there a difference in performance from rendering to a floating point texture?

What I can’t understand is how do you sample your shadowmap. The way i think about it, you have 2 options:

1) Perform 4 TEXs (using the 4 different shadowmap space vectors) and select the correct one based on the calculated index (see the second fragment shader from above), or
2) Select the correct shadowmap space vector and perform only one TEX at the correct location (the channel can be easily extracted using the split index).

In the second case (which is the only one i can think with 1 TEX) how do you select the correct shadowmap space vector using the split index?

JD