Question about shaders and gpu graphics resources granularity

Started by
7 comments, last by JohnnyCode 3 years, 7 months ago

I'm trying to properly structure my directx 11 application. So there are all manners of shaders, and gpu resources to bind to like index vertex buffers, input layouts, primitive topology, render target view, depth stencil views, blend states, textures etc.

My question is do we assign a set of all those things per model we want to render, or can they be shared for multiple models?

For example I want to render an opaque cube with some post process material, then a transparent sphere, then 100 opaque cones. The way I'm thinking about I should go about this is create a cube, a sphere and a cone classes, on their constructors bind whatever buffers, shaders and resources they need; clearly each one gets different shaders (different vertex, geometry possibly, pixel shaders), different index/vertex/constant buffers, and different render state blend state and whatnot.

But I wonder can I reuse say the render target view and depth stencil view etc (taking them from say a Graphics class that I have them constructed) for all those 3 types of objects? On the other hand can I render one of them, then completely change DESCriptions for the rendering state of the following models by then render another one then change properties again and render another etc?

So my question basically concerns the granularity of the available gpu resources with the models that I want to render. If you can enlighten me a bit on that taking into account what I've said that would be great.

(DirectX 11, C++)

None

Advertisement

https://gamedev.net/forums/topic/708280-is-this-an-acceptable-way-to-abstract-the-pipeline-stages-in-directx/

does this link answer yr question? ?

If the pipeline call is defined as state changing, it means GPU persists that state unless call(s) is made again, and you cannot mutualy state two or more states and think of switching them only, in low-level way of understanding the switching. That is why draw calls are ordered in the manner to apply as few state changes as possible and then iniate batched draw operations. Of course, how you batch depends on bottle neck of GPU (vertex memory, raster stage writes, texture lookups, texture switching). So there are only a few general rule of thumb rules, that are still a subject to change, which is:

  • back face cull
  • order by depth from closer to further
  • field of view cull
  • Of course all this gets more complicated if you are subjected to more ordering issues (transparency) and material/resources volatility in scene

@ddlox It looks interesting. I'll check it out later today. Feel free to send me more related posts from this website.

In the meantime, I realize maybe I haven't worded my question very well, but if you can make something out of it and try to answer that would be great. If not that's fine, thank you. I'll check these sources soon.

None

@JohnnyCode I understand. Which calls are defined as state changing?

None

In dx11 API it's nearly all of them, like 95 percent. Study more draw call issuing functions, what affects them should be in documentation richer written, also, debugging of dx11 will show you state of GPU at a particular point, which is all the attached data sent to GPU for draw call and states the GPU is in.

@johnnycode Graphics Debugging? Ye, I know what you're talking about. I've done that. I thought everything was state changing but ok.

None

GPU is a state machine, only calls that goes operating on it- are the state changing ones, dx11 contains at least a few utility functions which are not GPU calls. Or maybe none, who knows, I do not contain all of it and I have used only GPU calls of the API.

This topic is closed to new replies.

Advertisement