In a different thread someone told me AMD drivers ultimately convert vertex buffers to texture resource and attach it to shader stage. So I said what the heck why should I make different resources too.

Nope. The fundamental data types on AMD are images, buffers, samplers (which tell the hardware how to read from images), and "memory" (which is a raw buffer with less safety).

how does performance difference do D3D11_USAGE_DEFAULT, D3D11_USAGE_IMMUTABLE, D3D11_USAGE_DYNAMIC have.
Should I just hard code D3D11_USAGE_DEFAULT everywhere?

The perf difference between DEFAULT/IMMUTABLE probably isn't that great. You should use IMMUTABLE wherever you can (textures loaded from files, which don't change afterwards) just to be friendly to the driver, but it's not that much of a big deal if you don't.

DYNAMIC is very important for textures which are streamed from the CPU->GPU once per frame. It will tell the GPU to optimize the memory location, and/or pre-allocate a triple-buffered version, etc... To test this, do a perf-test where you generate a procedural texturing using the CPU once per frame, comparing between DYNAMIC and DEFAULT.

One more thing. How much difference is there in terms of performance in UpdateSubresource() and Map()

Depends what you're using them for - they can be quite different semantically. e.g. Map with NO_OVERWRITE lets you stream to the GPU with zero driver synchronization, instead taking responsibility for GPU synch yourself, as in D3D12.

One more thing. Is there a performance difference between Draw() and DrawIndexed()

Yes. Indexed draws generally achieve better vertex shader performance. However, Draw with triangle-strip primitives are similar (but harder to author).

Using only textures seems a nice idea to me. It makes my engine so small, simple, efficient and cool in design. So I ask why are there so many different resources. Are the any performance benefits of using vertex buffer or constant buffers.

Yes. A lot of GPUs have specialized hardware for constant-buffers, as it's assumed that EVERY vertex/pixel/etc in the draw call will require ALL of the constants -- so it's smart for a GPU to download all the cbuffers into a local cache before starting the draw-call, and leaving them present in that local cache for the entire duration of the draw-call.
On the other hand, each pixel/vertex usually fetches only a small part of a texture/buffer, so this data is fetched on demand and dynamically cached in L2.

Also, textures are more complex than buffers -- more dimensions, cube-map support, filtering options, addressing modes, etc... On some GPUs it might be significantly more expensive to fetch from a texture rather than from a buffer. Also, texture-descriptors are generally much larger than buffer descriptors (and usually require an accompanying sampler descriptor), meaning your shaders must allocate more SGPR's per draw-call -- basically, the driver has to create an invisible "cbuffer" that contains your texture/buffer descriptors (or you have to do this yourself via a descriptor heap on D3D12).

Older GPUs have specialized hardware for the Input Assembler stage -- that's the fixed funciton hardware which fetches vertices from buffers immediately prior to vertex shading.

Even on newer hardware though, buffers can allow for more complex data layouts (i.e. structures) than textures allow for.

Can you tell me more about it. Or somewhere I can read about it. I would like to know what actually goes under the directx API. May be this way I can learn what to use and how to use.

The CPU and GPU work best when there is a decent latency between the two of them. Typically GL/D3D will store all of your commands (draw/etc) into a command buffer, which the GPU consumes about 1 frame after you've made the calls. This buffering helps the GPU maintain maximal throughput.
However, it causes inconvenience when the CPU decides that it wants to modify a resource.

If you tell the GPU to draw an object using a green texture, then you modify that texture to be pink and tell the GPU to draw a second, you expect to see one green object and one pink object... and that's what D3D will do for you. But D3D has to pull off some magic to make this work.
Those draw commands are enqueued for a long period of time, so if D3D didn't do any resource synchronization, you'd end up seeing two pink objects, due to a race condition!

D3D has two main options:
1) When you ask to modify a resource, D3D stalls the CPU until the GPU has finished (at least until it has finished any draw-commands which will use that resource). After waiting for the GPU, then it lets you modify the resource.
In the example, that ends up with:
Draw using texture. Modify texture -- D3D magic sync point: wait dozens of milliseconds until the GPU has actually drawn the green object. Draw using texture.

2) Perform "resource orphaning" aka "resource renaming".
When you ask to modify a resource, D3D actually allocates you a brand new resource and marks the old one for garbage collection in a few frames time!
In the example, you end up with:
Draw using texture (D3D uses version #1). Modify texture -- D3D magic allocation: your 'texture' handle now points to version #2. Draw using texture (D3D uses version #2).

The DYNAMIC resource flag, and the DISCARD map flag, are hints that you want it to use strategy #2 (orphaning). This causes some overhead (garbage collection of resources, the fact that resource handles can be backed by multiple versions, extra memory usage) but avoids the performance-killing sync points of strategy #1. Typically I think that constant-buffers are generally treated as "dynamic" data by drivers too.

The NO_OVERWRITE map flag does neither of these strategies, so it's pretty dangerous. It's up to you to invent your own strategy to avoid race conditions. Game engines often use this to implement ring-buffers, where you record which section of your buffer are in use by data from each frame. You can use events to tell which frames the GPU has finished rendering, which lets you know that it's now safe to reuse those sections of your buffer.

Check this out: https://developer.nvidia.com/sites/default/files/akamai/gamedev/files/gdc12/Efficient_Buffer_Management_McDonald.pdf

I did not know GPU's cache constant buffer. This changes a lot of things.

It certainly used to be the case that cbuffers were cached differently. I think NVidia might still do that. AMD no longer do, but, IIRC they do fetch cbuffer variables differently. AMD GPUs always operate on 64 pixels/vertices at a time, so when any one of those pixels requires a cbuffer value, it is fetched once and then used by all 64 pixels, which means that it's basically 1/64th the cost.
If values are per-object or per-material, try to put them into a constant buffer. If they change per-vertex or per-pixel, then put them into a regular buffer or a texture.

I see. But this only means they are more feature-full. So are you sure the goodness of a better feature set weighs down the fetching speed from texture.

It's up to you. If buffers had no use, they would no longer be HW accelerated, and the HW itself would just treat everything as a texture!
The HW designers have decided (for now) to still support buffers/textures differently, and let us choose when to use each type.

You said it correctly. I heard new hardware don't have designated hardware for input assembler. So shouldn't putting vertices in vertex buffer or putting vertices in a 1D texture fetch similar performance.

No - it means that putting vertices into a buffer that is bound to the (no-longer-HW-accelerated) "input assembler" stage should have similar performance to putting vertices into a buffer that is bound directly to the vertex shader via a shader-resource-view, and fetched manually in the VS.
Doing this via a texture instead of a buffer may still incur extra overhead.

In fact putting vertices in texture seems better. You even have access to other vertices if needed in some application. Also you could make a 1D UAV texture for on the go vertex modification.

You can do that with buffer resources as well as texture resources -- i.e. you can make shader-resource-views and unordered-access-views of both resource types.

Also you have any good links about how to up your performance? These all dos and donts. I see including you many people on this forum have this knowledge which I can't find a source to acquire it. Up till now I think you all get it by shear experience

Yeah a lot of it just comes down to experience. When doing it as a full-time job, you'll often be required to read documents like this, which explain exactly how a particular GPU works. When doing it for consoles, you also get access to non-public documents :|

For the shader side of things, these two presentations are really helpful :)

The first starts with prev-gen GPUs, and the second then extends that to current ones.

http://www.humus.name/Articles/Persson_LowLevelThinking.pdf

http://www.humus.name/Articles/Persson_LowlevelShaderOptimization.pdf

Posted these in another thread a few minutes ago but you might be interested in them as well so:

https://developer.nvidia.com/content/life-triangle-nvidias-logical-pipeline

https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/

If you want to peek behind the veil a little the above are good reading.

One more thing. Is there a performance difference between Draw() and DrawIndexed().

Hodgman already answered this but I'd add that it speeds up vertex performance by enabling the post transform vertex cache thus saving the gpu from vertex shader invocations.

Infinisearch, on 03 Sept 2015 - 10:53 PM, said:

speeds up vertex performance by enabling the post transform vertex cache
What do you mean? And how do I do it?

Using indexed primitives automatically enables the post transform vertex cache. This cache caches vertexes after the vertex shader has been run on it so when a vertex in a mesh is reused it doesn't need to be transformed again. more on this later in the post.

Also you have any good links about how to up your performance? These all dos and donts. I see including you many people on this forum have this knowledge which I can't find a source to acquire it. Up till now I think you all get it by shear experience

There was a pretty good post by L.spiro IIRC on performance don't remember what thread though, I'll do my best though to help.

0. I assume you know about frustum culling and BSP, quad, oct trees, and Bounding volume hierarchies. aka send less to the gpu.

1.vertex data

a. smaller vertexes, see how small you can get away with.

b. vertex stream sizes that are cache aligned (pre-transform cache), add padding if necessary.

c. minimize vertex streams.

d. use indexing and optimize ordering for post transform vertex cache and potentially visibility. look here for both http://gfx.cs.princeton.edu/pubs/Sander_2007_>TR/tipsy.pdf

edit - use 16bit indexes.

2.batch to minimize state changes an old document called batch,batch,batch IIRC by nvidia

a.common advice nowadays is sort by shader, then texture, then distance then other state. (although in some cases i think sort by texture first might be appropriate)

b.the less state changes between draw calls the more calls you get IIRC. (D3D11 and below)

c.consider an occluder pass that breaks batching for a the first section of rendering then after you've filled the zbuffer with major occluders batched rendering.

d.minimize state changes by putting like data into same buffer, all vertexes of a type in a single vertex buffer, texture atlases...

e. look at this common link:http://realtimecollisiondetection.net/blog/?p=86

3. What kind of renderer are you using?

a. forward or two pass forward (z or id pass)

b. deferred (google for presentations on killzone 2 and http://download.nvidia.com/developer/presentations/2004/6800_Leagues/6800_Leagues_Deferred_Shading.pdf

c. light prepass

d. tile deferred http://www.slideshare.net/DICEStudio/directx-11-rendering-in-battlefield-3

e. forward+ http://developer.amd.com/tools-and-sdks/graphics-development/amd-radeon-sdk/

f. clustered forward+ http://www.humus.name/index.php?page=Articles (practical clustered shading)

this has a review of most of the above:

http://dl.acm.org/citation.cfm?id=2776880.2792712&coll=DL&dl=GUIDE

4. assorted stuff

a. tiled alpha blending to take advantage of on chip memory look for gpu particles here:http://developer.amd.com/tools-and-sdks/graphics-development/amd-radeon-sdk/

b. post process AA.

c. http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Vertex-Shader-Tricks-Bill-Bilodeau.ppsx

d. http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/04/DX11PerformanceReloaded.ppsx

e. gpu driven rendering... here http://advances.realtimerendering.com/s2015/index.html

edit - also play nice with the api and driver, do everything you're supposed to do. For example use the right resource type and creation flags, they give hints to the driver that can impact performance.

edit - found L. Spiro 's post : http://www.gamedev.net/topic/660883-best-way-to-make-game-render-most-efficient/#entry5179755

This is an awesome technique. Damn why didn't I think of this before. This seems a classical DAA's dynamic programming problem. I am not yet sure of the way how I might implement. I might use DrawIndexed() or might manually reuse the already transformed vertex data by manual indexing.

What do you mean by manual indexing? You need to use drawindexed() or the post transform cache won't be enabled.

This says:
"Alignment matters! (16-byte, please) Aligned copies can be ~30x faster"
So what does mean,in what context? I saw 30 times faster and I was like, Wow interesting.

If I'm not mistaken it means if you are uploading data to a buffer make sure the source buffer is aligned to a 16byte interval. This will allow for fast data uploads.

It also says to avoid CPU-GPU sync points.
My main thread has only graphics calls. Every other think I have multi-threaded.
I have minimized all CPU-GPU data transfers. Resource updation and state changes only occurs when necessary.
Any more thoughts?

Hodgman explains here the CPU-GPU sync point in 1., 2. is the alternative.

D3D has two main options:
1) When you ask to modify a resource, D3D stalls the CPU until the GPU has finished (at least until it has finished any draw-commands which will use that resource). After waiting for the GPU, then it lets you modify the resource.
In the example, that ends up with:
Draw using texture. Modify texture -- D3D magic sync point: wait dozens of milliseconds until the GPU has actually drawn the green object. Draw using texture.

2) Perform "resource orphaning" aka "resource renaming".
When you ask to modify a resource, D3D actually allocates you a brand new resource and marks the old one for garbage collection in a few frames time!
In the example, you end up with:
Draw using texture (D3D uses version #1). Modify texture -- D3D magic allocation: your 'texture' handle now points to version #2. Draw using texture (D3D uses version #2).

Is this the batch batch batch you are talking about: http://www.nvidia.com/docs/IO/8230/BatchBatchBatch.pdf

Yes that is the document, but it is really old read it get what you can from it then read the link to L. Spiro's post I gave you he basically gives you the same but updated advice.

http://www.gamedev.net/topic/660883-best-way-to-make-game-render-most-efficient/#entry5179755

This thing is SUPER!:
Infinisearch, on 04 Sept 2015 - 6:10 PM, said:

http://gfx.cs.princeton.edu/pubs/Sander_2007_>TR/tipsy.pdf
Although I gave a look at the ordering in which 3DS Max already exports index orders. This is a sample:

That one and this (https://home.comcast.net/~tom_forsyth/papers/fast_vert_cache_opt.html) one are the common ones you will come across but there are others. Your modeling software will not always output vertices/indices in optimal order, use one of the above or some other. Remember it's for indexed drawing.

struct Vertex
{
float pos[3];
float normal[3];
float tex[2];
};
It never changes ever. I have no idea how much large GPU caches are. Does it look adequate for post transform vertex cache?

Vertex size is relevent for the pre-transform vertex cache and in reducing the bandwidth the input stream requires (there isn't one in modern GPU's its cached by the standard GPU cache instead), you don't really worry about the vertex size output by the vertex shader (as long as you're being reasonable). As far as what you posted, do you really need floats for any of those values?

5.)I use deferred, and btw this is very nice:
Infinisearch, on 04 Sept 2015 - 6:10 PM, said:

http://download.nvidia.com/developer/presentations/2004/6800_Leagues/6800_Leagues_Deferred_Shading.pdf

That is a very old document, you should at least lookup the killzone 2 presentation on deferred. Also if speed is your goal tiled deferred and clustered tiled deferred are faster options especially with more lights.

a.common advice nowadays is sort by shader, then texture, then distance then other state. (although in some cases i think sort by texture first might be appropriate)

BTW for opaque's sort front to back, front to back rendering of opaques is important but not really possible (to sort depth first, read batch batch batch) on DX11 (unless you do virtual texturing, and maybe if DX11 has drawindirect don't know). see here why front to back is important: http://developer.amd.com/wordpress/media/2012/10/Depth_in-depth.pdf

edit - for deferred rendering you don't need to store position you can reconstruct it from depth making your Gbuffer thinner which helps performance.

https://mynameismjp.wordpress.com/2009/03/10/reconstructing-position-from-depth/

https://mynameismjp.wordpress.com/2010/03/22/attack-of-the-depth-buffer/