Hi! I have some piece of software here, developed using SlimDX (D3D9) on a GF8800. I make quite heavy use of VolumeTextures, as I abuse them as 3D-arrays for a GPGPU use. The following call is my issue: VolumeTexture Stipples = new VolumeTexture(device, w, h, d, 1, Usage.None, Format.R32F, Pool.Managed); This works just smoothly on my desktop PC with the GF8800, but I now tried to run things on my notebook, on which I intended to present this software - it's my bachelor thesis, which is why I have reached a good level of despair now. The notebook has a ATI Mobility Radeon X1600, and the above call simply throws an "Invalid call" exception. I tried to run this with the debug runtime switched on, but that only leads to #Develop crashing at this point, and ultimately even less specific info on what went wrong. Also, running outside the IDE only lead to the message, that a user defined breakpoint has been reached, and crashing if I choose to debug. The texture's dimensions in this testcase were: w=560; h=375; d=7 That leaves me with a texture of about 5,880,000 bytes, and even accounting for some excess due to strides won't really make this huge. Some other processes from before in the program worked all well, however none of them used volume textures. Only 2D floating point textures (R32F too, so the format seems to be okay itself). Before I go on with the part with my problem, I properly wipe the device and all resources I used before, and create an entirely fresh D3D and device object. At the point of creation, it is the ONLY resource for the device. Nothing but a shader has been created in it's context, so I do not really expect lack of memory to be an issue here. But then, what is? Many thanks for any help! I've got to figure that one out until Wednesday, so please don't hesitate to throw every whatever improbable idea at me. I will test about everything! :) PS: Subtitution by N 2D textures is not a solution, since the depth is variable, and can easily reach ~100 and more. A hundred texture samplers in my shader are not really that feasible, and I do need all layers in it at once.

According to the caps spreadsheet (DX_SDK/Samples/C++/Direct3D/ConfigSystem), the X1600 only supports power of 2 textures. That means you'll have to create a volume texture where each side is a power of two - there's no way around that unless you want to create multiple blocks to make up the size you need, but that'll be pretty painful I expect.

Alternatively, you can use the reference rasterizer on your laptop, but expect a frame rate in seconds per frame rather than frames per second.

Yikes, if I run the caps viewer on both machines, the notebook shows
D3DPTEXTURECAPS_POW2 = Yes
but my desktop PC doesn't even display this cap at all. Nevertheless, IF my X1600 doesn't support non-power of 2 textures, how comes, that the 2D textures did well? After all, these have the exact same dimensions for w and h as the volume has, which in this case are far from being a pow2.

Oh, remigius, didn't see you at first - damn you're fast today dudes :)

1) see above
2) I'll try, but it botheres me that 2D textures of the same format work just well
3) ... I just spent too much money on that one ~1.5 years ago. I'm a student - it'd take me about 1 year at least to get that amount of excess cash, if all went well. Baaaaad idea! ;)

Quote:Original post by Medium9
Nevertheless, IF my X1600 doesn't support non-power of 2 textures, how comes, that the 2D textures did well?

Sounds like a driver bug to me, or if you were using the D3DX version of CreateTexture (Or if SlimDX does internally), it'll create a power of 2 texture for you behind the scenes.

EDIT: Ah, the X1600 has the D3DPTEXTURECAPS_NONPOW2CONDITIONAL cap bit too - that means that you can use non-pow 2 textures with some restrictions, see The docs on the subject; I assume that applies to volume textures as well as "normal" textures:

Quote:
D3DPTEXTURECAPS_POW2 is also set, conditionally supports the use of 2D textures with dimensions that are not powers of two. A device that exposes this capability can use such a texture if all of the following requirements are met.

The texture addressing mode for the texture stage is set to D3DTADDRESS_CLAMP.

Texture wrapping for the texture stage is disabled (D3DRS_WRAP n set to 0).

Mipmapping is not in use (use magnification filter only).

Texture formats must not be D3DFMT_DXT1 through D3DFMT_DXT5.

If this flag is not set, and D3DPTEXTURECAPS_POW2 is also not set, then unconditional support is provided for 2D textures with dimensions that are not powers of two.

A texture that is not a power of two cannot be set at a stage that will be read based on a shader computation (such as the bem - ps and texm3x3 - ps instructions in pixel shaders versions 1_0 to 1_3). For example, these textures can be used to store bumps that will be fed into texture reads, but not the environment maps that are used in texbem - ps, texbeml - ps, and texm3x3spec - ps. This means that a texture with dimensions that are not powers of two cannot be addressed or sampled using texture coordinates computed within the shader. This type of operation is known as a dependent read and cannot be performed on these types of textures.

I presume the refrast isn't feasible for what you need (requires the SDK be installed, and is extremely slow)?

You were all right with the power of 2. A volume of 512x256x8 is properly created, but this devastates me. There is no way I could rewrite the whole thing in two days to cope with this :(
Also, this will lead to quite large textures in a lot of cases making almost sure I'll run into memory problems too soon, since segmenting would lead to extreme headaches and probably a good week of work (the whole part relying on this is rather extensive and complicated).

I'm gonna try the ref rasterizer, although this defeats the whole purpose of why I even bothered to do this stuff on the GPU - I have made a CPU-only version before, and it was way slow. But hey, maybe it's okay for mere presentation.

(Btw: Is a X1600 really THAT old?)

Edit: Just saw your edit :)
Okay, uhm - how do I control these conditions in SlimDX? I've never set anything for addressing or wrapping mode outside of my shaders, to which the textures are bound after both are created. I don't use mipmapping, and none of the mentioned formats.
Or are volume textures just an entirely different game?

Okay, 4 years is quite some time. The driver... don't get me started on this topic. I've spent 3 evenings on trying everything I could imagine or have found in various forums: There just seems to be NO friggin way to update this stinky beast. ATI driver installers say: Nay, not going to happen, go ask you notebook manufactor. Asus says: Nay, just the 2006 drivers here, for newer stuff go ask ATI. What the...? (2006, that could have been a hint on the chip's age *cough*)
Omega drivers screwd up my entire system once, I have little intention of reinstalling everything yet again (I just did 4 days ago). Well, at least one thing is certain: Never again a notebook by Asus, never again with an ATI chip. I can miss out on that form of support very easily *rant*.

What would be the "canon" way of obtaining anything from the debug runtimes? Since #Develop goes entirely overboard when it hits an error with the dbg on, I probably never came to see how a proper output from them would look like. (I unfortunately do not have any Visual Studio available at the moment too.)

Edit: Uhm, how could setting this stuff in the shaders make any difference? The shader isn't set before the texture is created, and the texture isn't associated with the shader until rigth before rendering. How could D3D then know what I declared in my texture samplers? *scratchinghead*

Actually, the more I think about it, the more I reckon it's either a driver bug, or the D3DPTEXTURECAPS_NONPOW2CONDITIONAL bit only applies to 2D textures - if you can't even create the texture, then it shows that the driver doesn't care what state the device is in at the time it's used.

As remigius said; a driver update may help, or you could try contacting ATI/AMD about it.
I've posted on the DirectX MVP newsgroups to try and find out if the D3DPTEXTURECAPS_NONPOW2CONDITIONAL flag applied to volume textures as well, but I can't say if/when I'll get an answer there.

Contacting ATI might be a good thing to do right now, you're right. And many thanks for taking this into the newsgroups! I might be able to go with my software solution first, and update it afterwards. At least I seem to have a good reason for this delay.