Jump to content
  • Advertisement
Sign in to follow this  
Medium9

[SlimDX] VolumeTexture creation fails

This topic is 3054 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites

You might want to give DebugView a try to capture the DirectX debug output. Without more information we'd just be guessing and it's quite possible that if you haven't routinely run your project with the debug runtime yet, it could be balking at something completely unrelated before reaching the actual error.

Some random guesses:

1) Try power-of-2 texture sizes
2) Try another format like A32R32G32B32F
3) Get a laptop with a GF8x00 [smile]

Edit - I need to type faster :p

Share this post


Link to post
Share on other sites
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! ;)

Share this post


Link to post
Share on other sites
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)?

    Share this post


    Link to post
    Share on other sites
    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?

    Share this post


    Link to post
    Share on other sites

    Quote:
    Original post by Medium9
    (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?



    Afaik, just setting those conditions (states) on the samplers in your shaders should be fine.

    And well, the X1600 somewhat old. I got mine about 4 years ago I think, which does make its raw output a bit lacking by now. About the featureset, I don't think I ever had any real issue with it like you're having now, but then again I mostly stuck to the beaten path with power-of-two textures and such.

    Volume texture support off the beaten path may be a bit flakey, but I still find it incredible myself that it's being this problematic. I strongly suggest you try to get the output of the debug runtimes to verify what's happening.

    Perhaps a driver update would be a good idea too, although I have some misgivings that with AMD's legacy driver program for the X1600 series, the quality isn't improving much. I'm not sure if this is true, but I'd try both the latest drivers and the original drivers that came with the card.

    Share this post


    Link to post
    Share on other sites
    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*

    Share this post


    Link to post
    Share on other sites
    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.

    Share this post


    Link to post
    Share on other sites
    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.

    Share this post


    Link to post
    Share on other sites
    Sign in to follow this  

    • Advertisement
    ×

    Important Information

    By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

    Participate in the game development conversation and more when you create an account on GameDev.net!

    Sign me up!