Few question about DirectX 11

Started by
12 comments, last by Papadopol 11 years, 7 months ago
Hi. Im learning DirectX 11 and graphic programming and I want to understand everything before I go further. So I'll might ask some stupid question here and I'll be glad if you could help a noob.

1. The vertices order in a buffer for a triangle matter in any way (assuming the the mapping vertex-uv-etc is correct) excepting optimisation?
2. If I want to optimise for vertex cache I need to render front to back objects, traingles or vertices ? Assuming that I prefer rendering huge buffers (seems that improves dramtically the performance) intead of small buffers does the vertice order matter ?
If I have a SINGLE huge vertex buffer the GPU automatically cuts unseen vertices with CullFaces and I dont need any kind of optimisation ? Optimisations are for sorting separated vertex buffers ?
3. Is there any advantage using index buffer and split in more buffer, one for vertices, one for UVs, one for normals ? If yes how can I detect offline algoritmicaly on my mesh if is a fps boost ?
4. What tools is best for debugging low level GPU performance with those kind of optimisation? (Im using Visual Studio 2010, DirectX 11 SDK, SM 5.0)
Advertisement
1) That entirely depends on your primitive topology. http://msdn.microsof...4(v=vs.85).aspx
Assuming you're referring to an indexed triangle list, which is the most sensitive to vertex ordering (in terms of vertex cache performance), then the answer is no. As long as your indices are in the correct order, the vertex buffer can be in any order. That's why optimization is important. If you're sending in indices like (1, 1049, 2, 510, 16, 53), the vertex cache isn't going to do you much good.

2) Like I said above, the vertex cache only helps you if you're taking advantage of temporal locality with your indexing. More simply put, make sure your index buffer references specific indices as much as possible before moving on in the buffer. It doesn't matter what your object rendering order is. Although the GPU will cull triangles eventually, it's not until late in the pipeline. It's much better to use coarse-grained methods like frustum culling for entire objects.

3) According to the MSDN docs, using multiple streams is a bit slower, in the usual case, but it can be a huge advantage in certain situations. For example, if you're rendering a depth pass for a shadow map or for deferred rendering, you don't want to pass in the entire interleaved vertex to a shader that only cares about the position. Using multiple streams in this situation allows you to just bind the position stream and use that, saving tons of bandwidth.

4. I use PIX, which is ok. I haven't delved much into the vendor specific tools yet.
So in a "common" mesh rendering if separate buffers is slow I never need Index Buffers as I use vertices buffers that has UV, normal maps etc ?
I dont see a case where a vertice is identical to another by vertex position, uv map, etc.

Nevermind, I fot the idea. Indexing vertices is not for skiping identical vertices but for reusing vertices in the vertex cache.


LE:
http://fgiesen.wordp...ne-2011-part-3/

If I understand correctly, I just use batches of vertices meaning Ill reorder the vertices in groups of 32 vertices maximum but in only big buffer? I really dont understand what a batch is. Is a render call with a different buffer or a potion of vertices in a vertex buffer?
Im reading a file and I'm having some problmes reading some variables

text file is like that:



chars count=191
char id=32 x=72 y=77 width=1 height=1 xoffset=0 yoffset=26 xadvance=8 page=0 chnl=15
etc..



Code in my program:



while ( fontFile.good() ) {


getline (fontFile,line);

//search for number of characters variables
//

string toFind = "chars count="; // what sould I search in the current line
found = line.find(toFind); // where the text to fond is located

if(found != -1) {

int count = toFind.size() + found; // Where the variable starts
// So far so good, it seems it founds the correct location where the number is starting



// Here goes the problems
// I dont know hot to find out when the number is finished. I guess that should work with newline character but it doesnt
//


// Assertion failed here
// Seems it doesnt find newline as I resize line string and also gives me asserion failed
while (line[count] != '\n') {
count = count+1;

}



}
If I were you, I'd use the extraction operator with the ifstream (>>) and something like
[source lang="cpp"]while (c != '=') {
fontFile.get( c ); //Read until the last char read was the (=)-sign
}

//At this point "191" should be first in the ifstream buffer

fontFile >> count; //Read the integer to a variable[/source]

Of course, c is of type char, and count of type int.

Hope this works!
I'd advise using either a binary file or some well-formatted text format (like XML) for which you can just download and use a parser library instead. Plain text formats are - IMO - hugely overrated and can often add unneeded complexity and make your program more error prone. Yes, they do have an advantage of being human-readable and human-editable, but that does need to be balanced against the cost. Defining your own plain text formats is even worse as you have a high risk of needing to add another text parser to your program each time you create another file type. Plain text formats in general are much slower to read and parse than binary files (this can become very significant when you start getting to large files) and using a parser library for something like XML will at least mean that you have a chance that the library is reasonably well-optimized. If it's a well-rated library and you get a bug you can have stronger certainty of where the bug is (i.e. in your code) too.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

Ok, going binary mode still having some problems:
Here is some binary mode documentation for Bitmap Font Generator http://bobcat-games....format.html#bin

I dont know how to read the first variable



HANDLE hFile;
hFile = CreateFile (L"media\\fonts\\binary.fnt",
GENERIC_READ,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
if (hFile == INVALID_HANDLE_VALUE)
{
MessageBox(NULL,L"Failed opening the binary file",L"error",NULL);
CloseHandle (hFile);
return;
}

DWORD dwBytesRead;
int fontsize=0;
ReadFile (hFile, &fontsize, 2, &dwBytesRead, NULL);
// I dont get the font size;

CloseHandle (hFile);
I managed to load the binary file but no matter how hard I try it seems that the font is blurry. I unchecked "Font Smoothing" from Bitmap font generator but it seems it goes to the other extreme. I exported the font in a big size (40) do I'll have more pixel information and after that I've created triangles sized by UV coordonated and it seems I'm mapping 1:1 to the quad. When I create the quads the values of UVs are multyplied woth 0.002f. Then I use a matrix multiplication for scaling again regarding my need. Also without the scaling the font is still kind of blurry.
Any sugestion for sharpening the font?
font2.jpg



FONt.jpg
I use D3D11_FILTER_MIN_MAG_MIP_LINEAR for Filter in the sampler state desc. Try it!
Looks the same with any filter in the sample.



D3D11_SAMPLER_DESC samplerDesc;
samplerDesc.Filter = D3D11_FILTER_MIN_MAG_MIP_LINEAR;
samplerDesc.AddressU = D3D11_TEXTURE_ADDRESS_WRAP;
samplerDesc.AddressV = D3D11_TEXTURE_ADDRESS_WRAP;
samplerDesc.AddressW = D3D11_TEXTURE_ADDRESS_WRAP;
samplerDesc.MipLODBias = 0.0f;
samplerDesc.MaxAnisotropy = 0;
samplerDesc.ComparisonFunc = D3D11_COMPARISON_ALWAYS;
samplerDesc.BorderColor[0] = 0;
samplerDesc.BorderColor[1] = 0;
samplerDesc.BorderColor[2] = 0;
samplerDesc.BorderColor[3] = 0;
samplerDesc.MinLOD = 0;
samplerDesc.MaxLOD = D3D11_FLOAT32_MAX;

This topic is closed to new replies.

Advertisement