   Vertex cache question
  Hi, I am reading a paper from Microsoft about transparent vertex cachingThere the author states a vertex cache entry is 32 bytes large, consisting of the following itemsposition x,y,z //3 floats ~ 12 bytesnormal nx,ny,nz //again 3 floats ~ 12 bytescolor rgba //1 byte per component ~ 4 bytes//so we already got 28 bytestexture 1 u vtexture 2 u v//so you had to use 1 byte per texture coordinate wich allows a precision of only 1.0f/256.0f ~ 0.5% of a texture width/heightso my question is it practical to use such uv coordinates, or do most games not use the color item?or are vertex cache entry sizes large than 32 bytes?Also GF2-3 had 16 vertex registers, gf4 + ~24 how many do modern graphic cards have?thx in advance   
Quote:Original post by BasirorHi, I am reading a paper from Microsoft about transparent vertex cachingThere the author states a vertex cache entry is 32 bytes large, consisting of the following itemsposition x,y,z //3 floats ~ 12 bytesnormal nx,ny,nz //again 3 floats ~ 12 bytescolor rgba //1 byte per component ~ 4 bytes//so we already got 28 bytestexture 1 u vtexture 2 u v//so you had to use 1 byte per texture coordinate wich allows a precision of only 1.0f/256.0f ~ 0.5% of a texture width/heightIts probably 2 bytes per coordinate- which would bring the total to 32 bytes.Quote:so my question is it practical to use such uv coordinates, or do most games not use the color item?I'm not sure what you mean. Vertex cache usage is something you really don't have any control over- it's managed by the h/w and drivers. Quote:or are vertex cache entry sizes large than 32 bytes?Not likely, but if they were they would probably be 64 bytes large. A lot of data structures in computers are sized in powers of two because they are quicker to address- bit shifts and the likes can be used etc..Quote:Also GF2-3 had 16 vertex registers, gf4 + ~24 how many do modern graphic cards have?thx in advanceAbout the same I believe, though maybe its gone up to 32 by now. Like I said though, I wouldn't be too worried about it. If you used indexed geometry or triangle strips etc. then the hardware / driver will look after the rest, and manage the cache.;  i am currently preparing a seminar where i found a graph showing that more than 20 vertex registers hardly reduces the amount of cache misses, so 24-32 would be perfect even on future hardwarethere i discuss a technique explained by hugues hoppe form MS how to optimize tri strips for certain vertex cache sizes by lookahead simulations.if the vertex entries have a capacity of ~64 bytes how do they handle all the vertex shader registers then? Are these seperated from the vertex registerse.g.:data -> shader registers --(transformation)--> transformed vertex into vertex register?   ;  Actually I ve heard that the vertex cache work optimally when vertex size is a multiple of 32, as in that case it will be aligned and each vertex will be stored in one and only one cache entry. If bigger (say 40) two entries will have to be red each time a vertex is accessed, which is not as optimal. That's why they recommend using such a size. In your example I would recommend throwing out the color, as each texture coords needs 4 bytes (tu and tv).;  I thought a vertex chache entry held ALL your vertex elements. So the reason you'd want to keep your vertex size to multiples of 32 bytes, is because the read back into the vertex buffer currently reads in chunks of this size. Then, the reason sizes like 64 bytes could be more advantaguous than say 48 bytes, is that the latter would potentially require 3 reads when it crosses 2 32 byte boundaries, whereas the former would always be aligned to 64 bytes, crossing 1 border, consistently requireing 2 reads.It's also worth mentioning that sizes a fraction of 32 bytes, such as 16 or 8 bytes, will not harm performance. You might not be able to fetch more than 1 vertex at a time, but they will still never cross the 32 byte boundaries for 1 vertex, and they will require less memory bandwith.   