Quote:Original post by MJP
I would try doing it with a secondary vertex buffer, like you'd do for hardware instancing. Make a smaller secondary buffer with only position data, and lock/update that buffer whenever the mesh changes.

Either way make sure you profile in PIX to see whether your lock is stalling the pipeline. Stalls will show up as red in the frame graph.

Quote:Original post by remigius

Quote:Original post by Vertex333
Nevertheless I do not understand how I can "map/bring" a second vertex buffer into the shader in a way (as described in my last post) that not the vertices get processed, but I can access this buffer while processing the vertices of another vertex buffer.

I'm not sure what you're after exactly and I'd imagine things changed a lot in DX10 which I don't use, so I guess I probably shouldn't even be replying [smile]

Anyway, in DX9 you can mix in data from another vertex buffer by setting it up on an additiontal stream. By specifiying that stream for certain elements in the vertex declaration and by using the appropriate stream source frequency, this will make the Runtime/Driver/Card interleave the data from the 2nd buffer with the original vertex data. This way you can just access the data from the 2nd buffer in the vertex shader through the semantics you defined in the declaration.

...

I got a feeling I'm not really making this any clearer, but I hope it helps and/or makes sense for DX10.

Quote:Original post by remigius

Quote:Original post by Vertex333
But thinking twice this forces me to use a vertex buffer (although it might be smaller and has a different frequency). Is there no way to access it like other normal global FX variables?

Vertex

Well, you could stick the positional data in a shader constants array, much like you'd do with skinning or shader instancing. In DX9 this requires you to add some index to your vertices to fetch the correct data element from the array, but from what I've read this index is generated automatically for you in DX10 (by way of the SV_VertexID semantic).

With this approach you'll be bound by the maximum number of constants supported by your graphics card though. Again from what I've read, the D3D10/SM4 spec requires cards to support 4096 constant registers, so with a few constants needed for various matrices and other stuff, you'd be limited to about 4000 vertices using a single float4 each for data. In addition to this limitation, I doubt it's really going to be much faster than using a vertex buffer, so as MJP pointed out profiling is key.

Quote:Original post by remigius

Quote:Original post by Vertex333
This solution (arrays) has two problems: First, the limitation (I think 4000 is not enough, or let's say I can't limit it, although it may never be reached). Second, I have to "precompile" this in my FX file. So, there is no way to define a pointer or something like an array with an undefined size. If I would use let's say 4000 as the fixed size for the array, then I would always have to update the 4000 through the Updatesubresource or however the Effect framework does this.

Well, if the constants limitation is already a show-stopper, then there's little point in discussing the possibilities of setting specific smaller ranges of the array, even moreso since I don't know how this works out in DX10 anyway [smile] In DX9 though, it was possible to use a fixed size array and set individual array elements and/or ranges through the effect framework.

Quote:I thought that a texture (better limitations, 1D or even using the 1Ds of a 2D texture for the data). But there are also two problems: I think that I can't access the texture so, that I do not get sampled or interpolated values (in other words I want the raw and correct data). The second problem is that the texture reads may be very expensive (in contrast to constant buffers).

Yeah, I figured texture reads would be more expensive than either constant buffers or vertex buffers. I think you could get non-interpolated data from the texture using appropriate point filtering, not using mipmaps and fixing up just the right texcoords. You might want to check the Sparse Morph Sample in the DX SDK. As I recall that uses a texture to store morph targets as vertex positions, but I'm not sure.

Anyway, I think if you're worried about vertex buffer locking, then texture locking might prove just as bad. I'm not going to reiterate the importance of profiling [wink]

Quote:
The concept to not use a vertex buffer and create the vertices with the VS works quite well (a simple rectangle) "for me", since my vertex data may change very often. For drawing an "unlimited" amount of vertices this should work too. "for me" means I want to produce as less CPU load as possible. Locking VB costs more than setting the some constant shader variables (both for every object).

Any suggestions?

Do you mean your first idea in the topic start by creating vertices with the VS? I'm not quite sure I follow, since to my mind you'd have to create and set your data *somehwere*, be it in a texture, additional VB, constants or dynamic buffer. You can try and find the optimal vehicle to get the data to the card, but in the end you'll still get some CPU overhead to generate and send it.

Unless of course you can generate the data procedurally, in which case you could calculate it all using vertex and/or geometry shaders without the need to set it explicitly using the CPU.