• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By turanszkij
      Hi,
      I finally managed to get the DX11 emulating Vulkan device working but everything is flipped vertically now because Vulkan has a different clipping space. What are the best practices out there to keep these implementation consistent? I tried using a vertically flipped viewport, and while it works on Nvidia 1050, the Vulkan debug layer is throwing error messages that this is not supported in the spec so it might not work on others. There is also the possibility to flip the clip scpace position Y coordinate before writing out with vertex shader, but that requires changing and recompiling every shader. I could also bake it into the camera projection matrices, though I want to avoid that because then I need to track down for the whole engine where I upload matrices... Any chance of an easy extension or something? If not, I will probably go with changing the vertex shaders.
    • By NikiTo
      Some people say "discard" has not a positive effect on optimization. Other people say it will at least spare the fetches of textures.
       
      if (color.A < 0.1f) { //discard; clip(-1); } // tons of reads of textures following here // and loops too
      Some people say that "discard" will only mask out the output of the pixel shader, while still evaluates all the statements after the "discard" instruction.

      MSN>
      discard: Do not output the result of the current pixel.
      clip: Discards the current pixel..
      <MSN

      As usual it is unclear, but it suggests that "clip" could discard the whole pixel(maybe stopping execution too)

      I think, that at least, because of termal and energy consuming reasons, GPU should not evaluate the statements after "discard", but some people on internet say that GPU computes the statements anyways. What I am more worried about, are the texture fetches after discard/clip.

      (what if after discard, I have an expensive branch decision that makes the approved cheap branch neighbor pixels stall for nothing? this is crazy)
    • By NikiTo
      I have a problem. My shaders are huge, in the meaning that they have lot of code inside. Many of my pixels should be completely discarded. I could use in the very beginning of the shader a comparison and discard, But as far as I understand, discard statement does not save workload at all, as it has to stale until the long huge neighbor shaders complete.
      Initially I wanted to use stencil to discard pixels before the execution flow enters the shader. Even before the GPU distributes/allocates resources for this shader, avoiding stale of pixel shaders execution flow, because initially I assumed that Depth/Stencil discards pixels before the pixel shader, but I see now that it happens inside the very last Output Merger state. It seems extremely inefficient to render that way a little mirror in a scene with big viewport. Why they've put the stencil test in the output merger anyway? Handling of Stencil is so limited compared to other resources. Does people use Stencil functionality at all for games, or they prefer discard/clip?

      Will GPU stale the pixel if I issue a discard in the very beginning of the pixel shader, or GPU will already start using the freed up resources to render another pixel?!?!



       
    • By Axiverse
      I'm wondering when upload buffers are copied into the GPU. Basically I want to pool buffers and want to know when I can reuse and write new data into the buffers.
    • By NikiTo
      AMD forces me to use MipLevels in order to can read from a heap previously used as RTV. Intel's integrated GPU works fine with MipLevels = 1 inside the D3D12_RESOURCE_DESC. For AMD I have to set it to 0(or 2). MSDN says 0 means max levels. With MipLevels = 1, AMD is rendering fine to the RTV, but reading from the RTV it shows the image reordered.

      Is setting MipLevels to something other than 1 going to cost me too much memory or execution time during rendering to RTVs, because I really don't need mipmaps at all(not for the 99% of my app)?

      (I use the same 2D D3D12_RESOURCE_DESC for both the SRV and RTV sharing the same heap. Using 1 for MipLevels in that D3D12_RESOURCE_DESC gives me results like in the photos attached below. Using 0 or 2 makes AMD read fine from the RTV. I wish I could sort this somehow, but in the last two days I've tried almost anything to sort this problem, and this is the only way it works on my machine.)


  • Advertisement
  • Advertisement
Sign in to follow this  

DX12 [D3D12] What's wrong with this app design?

This topic is 762 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Here's the brief design of my d3d12 app which loads an image an displays it on screen.

 

After InitializeWindow(), I initialize D3D (InitD3D), then Render() and receive widow messages in a loop.

 

InitD3D()

debug layer
device create
create CQ
create SwapChain
RTv desc heap
point RTV to swap chainback buffers
create CA
creata and close CL
create fence per frame
create one fence event

 

 
Render()
wait for gpu to finish
reset CA
reset cL
UploadTexturedataFromFile()
resource barrier: present to RT
record CL = {get RTVhandle, OMsetrendertarget(), clearRTV}
resource barrier: RT to present
CL close()
CQ execute CL
CQ signal
swapchain->Present()
 
UploadTexturedataFromFile()
-loads an image using WIC
-copy pixels data
-created upload an default heaps.
-commandlist-copytexturearea from upload to default.

 

As you can see I haven't set up a root signature and pso. It's because I'm not calling DrawInstanced() in my render. My understanding is that if I point RTV to swap chainback buffers and call OMsetrendertarget(), I only need to call Present() to display my image.

Is this wrong? If yes, Is it necessary that I should set up a basic root signature and pso and call DrawInstanced() ?

PS: I started graphics programming recently with dx12. 

Edited by ngub05

Share this post


Link to post
Share on other sites
Advertisement

Now you only clear the screen. To see the image you need to draw it to the screen. Uploading the texture to the GPU only makes it available for the GPU to render with, it does not show it to the screen.

 

On the other hand, i just started with Dx12 myself so i do not know that much myself :). Check out my Dx12 notes at http://www.gamedevpensieve.com/graphics/graphic-api/directx12.

Share this post


Link to post
Share on other sites

Can someone expain, what exactly will be happening when i call DrawInstanced(). Should it be called before ExecuteCommandLists()? Why? I'm missing some very important concepts here..

Share this post


Link to post
Share on other sites

you use the command list to create commands, which get stored in a list, called a command list. drawinstanced is a command, so when you call that, a draw command is put into the command list. you call executecommandlists to actually execute the commands in that list. So yes, you need to call drawinstanced before you call executecommandlists

Share this post


Link to post
Share on other sites


I haven't set up a root signature and pso. It's because

 

You need a root signature/pso to draw things with a shader. If you're just copyresourceing a texture onto the swap chain I suppose you don't... but at that point you're just making an image compositor. 

Share this post


Link to post
Share on other sites

i didn't even see that part. Yeah, if you want to use the pipeline, you need at least a pso and pso's need a root signature, even if its a default empty root signature. If you want to draw something onto a render target, you need at least a vertex and pixel shader in your pso. if you are only using the pipeline up to the stream output stage, you only need a vertex shader.

 

basically the only thing you can do without a pso is clear the render target, or manage and move around resources on the gpu, since thats not actually part of the graphics pipeline. If you want to use any part of the graphics pipeline though (input assembler to output merger stage (or to stream output stage)), you do need a pso (which again needs a root signature).

Edited by iedoc

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement