• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
BornToCode

DX11
DirectX 11 Buffer Headache

7 posts in this topic

The topic says it all. In DirectX 9 you can create a Vertex/Index buffer and then when you map it you give it an hint to tell it how you are going to access the buffer, easy to use. In DirectX 11 on the other hand we can no longer specify the map type unless CPUAccessResource is set to either Read,Write or Read/Write which is ok. But the problem comes from whenever you have a READ/WRITE resource the resource cannot be bind to anything. DX11 Provide different Access flags, but there is no flags that I can set where I can access the resource as a Read/Write on the CPU and at the same time have it bind to an vertex or index buffer. So how in DirectX11 are you supposed to create a buffer that you want to READ/Write from on the CPU side and be able to use that same buffer to render onto the screen. The buffer system in DirectX11 is definitely a step backward. If anyone has any idea, please let me know. Because right now the only way I can see to do that is to create an Staging resource and a Dynamic resource. Then copy staging resource data to the dynamic resource using an map. Doing that would force me to duplicate buffers, so I know there has to be a better way to do this.

Edited by BornToCode
0

Share this post


Link to post
Share on other sites

The topic says it all. In DirectX 9 you can create a Vertex/Index buffer and then when you map it you give it an hint to tell it how you are going to access the buffer, easy to use. In DirectX 11 on the other hand we can no longer specify the map type unless CPUAccessResource is set to either Read,Write or Read/Write which is ok. But the problem comes from whenever you have a READ/WRITE resource the resource cannot be bind to anything. DX11 Provide different Access flags, but there is no flags that I can set where I can access the resource as a Read/Write on the CPU and at the same time have it bind to an vertex or index buffer. So how in DirectX11 are you supposed to create a buffer that you want to READ/Write from on the CPU side and be able to use that same buffer to render onto the screen. The buffer system in DirectX11 is definitely a step backward. If anyone has any idea, please let me know. Because right now the only way I can see to do that is to create an Staging resource and a Dynamic resource. Then copy staging resource data to the dynamic resource using an map. Doing that would force me to duplicate buffers, so I know there has to be a better way to do this.

It'd be helpful if we knew why you're reading back data from the buffer on the CPU?  That sounds a little counterproductive to me.

0

Share this post


Link to post
Share on other sites

Are you saying that the issue is that you can't map the buffer while it is bound to the pipeline?  If so, why don't you just un-bind it by setting a null to that buffer slot?

 

Vertex and index buffers most certainly can be mapped and directly used, so I'm not really sure what the issue is that you are facing...

0

Share this post


Link to post
Share on other sites

The old D9D9 way of dealing with resources was completely broken in terms of how GPU's actually work. When you put a resource in GPU memory it's no longer accessible to the CPU, since it's a completely different memory pool that's not accessible to userspace code. In order to support the old (broken) D3D9 semantics drivers had to do crazy things behind the scenes, and the D3D runtime usually had to keep a separate copy of the resource contents in CPU memory. Starting with D3D10 they cleaned all of this up in order to better reflect the way CPU's work, and to also force programs to use the "fast path" by default by not giving them traps to fall into that would cause performance degradation or excessive memory allocation by the runtime or driver. Part of this is that you can no longer just grab GPU resources on the CPU, and you have explicitly specify up-front what behavior you want from a resource.

That said, why would you ever need to read back vertex buffer data? If you've provided the data, then you surely already have access to that data and you can keep it around for later. You wouldn't be wasting any memory compared to the old D3D9 behavior or using a staging buffer, and it would be more efficient to boot.

2

Share this post


Link to post
Share on other sites

Are you saying that the issue is that you can't map the buffer while it is bound to the pipeline?  If so, why don't you just un-bind it by setting a null to that buffer slot?

 

Vertex and index buffers most certainly can be mapped and directly used, so I'm not really sure what the issue is that you are facing...

I am not talking about when I am binding it through the binding stage. I mean at creation time when setting the Bind Flags stages the buffer will mapped to. The Bind

Flag stage can only be set if the buffer will not be read from the CPU which means staging. Therefore preventing me from creating any type of resource view using the buffer.

 

The old D9D9 way of dealing with resources was completely broken in terms of how GPU's actually work. When you put a resource in GPU memory it's no longer accessible to the CPU, since it's a completely different memory pool that's not accessible to userspace code. In order to support the old (broken) D3D9 semantics drivers had to do crazy things behind the scenes, and the D3D runtime usually had to keep a separate copy of the resource contents in CPU memory. Starting with D3D10 they cleaned all of this up in order to better reflect the way CPU's work, and to also force programs to use the "fast path" by default by not giving them traps to fall into that would cause performance degradation or excessive memory allocation by the runtime or driver. Part of this is that you can no longer just grab GPU resources on the CPU, and you have explicitly specify up-front what behavior you want from a resource.

That said, why would you ever need to read back vertex buffer data? If you've provided the data, then you surely already have access to that data and you can keep it around for later. You wouldn't be wasting any memory compared to the old D3D9 behavior or using a staging buffer, and it would be more efficient to boot.

I know that CPUVM cannot see GPUVM, but that does not matter in that case. Currently the drivers just copies the GPU memory over to the CPU memory whenever you do an map, then copy it back to GPUVM whenever you do Unmap. So those flags are just bogus, all they do is give the driver some hint of which memory pool to put it in.. Even with the implementation of this new system. The driver side has not change on how the buffers are handle today, because CPU still cannot see GPUVM. The only reason they are those restriction is because Microsoft introduced them in the spec. The reason I know about the how the driver works is because last year I work on them. So the two copy in memory in D3D9 like you said is a false statement.

 

Now to answer your other question, the reason why I want to access it. Let's say I have a buffer X that has been updated and outputted in an OuputStream. How do I read that output stream back on the CPU if I want to that since the CPU cannot read the resource.

Edited by BornToCode
0

Share this post


Link to post
Share on other sites

Now to answer your other question, the reason why I want to access it. Let's say I have a buffer X that has been updated and outputted in an OuputStream. How do I read that output stream back on the CPU if I want to that since the CPU cannot read the resource.

You use a staging buffer - that is its whole purpose for existing, just to give  you CPU read access to the GPU based resource objects.  You can write to buffers directly with the appropriate flags, but reading requires a separate buffer.  If you don't like hassling with the copy, then just write a small wrapper for your buffers that handles the copying and mirroring of the buffer data for you.

 

However, I would invest in a technique that could just directly use the stream output buffers without CPU intervention.  That will make the whole thing much faster, reducing bandwidth requirements, and eliminating the need for a staging buffer altogether.  This of course assumes that you don't need to store the data for whatever reason, but if you are only going to consume the contents then it would be far better just to use it directly.

0

Share this post


Link to post
Share on other sites

Now to answer your other question, the reason why I want to access it. Let's say I have a buffer X that has been updated and outputted in an OuputStream. How do I read that output stream back on the CPU if I want to that since the CPU cannot read the resource.

You use a staging buffer - that is its whole purpose for existing, just to give  you CPU read access to the GPU based resource objects.  You can write to buffers directly with the appropriate flags, but reading requires a separate buffer.  If you don't like hassling with the copy, then just write a small wrapper for your buffers that handles the copying and mirroring of the buffer data for you.

 

However, I would invest in a technique that could just directly use the stream output buffers without CPU intervention.  That will make the whole thing much faster, reducing bandwidth requirements, and eliminating the need for a staging buffer altogether.  This of course assumes that you don't need to store the data for whatever reason, but if you are only going to consume the contents then it would be far better just to use it directly.

That is what i meant in my first post. I would need to have a staging buffer and and dynamic buffer. Why do i need t o create two buffers. If i did not care about reading the ouput stream, then what you mention would have work and i would not have posted this in the first place. But i want to be able to access the buffer on the CPU for Read Access with a Bind Flag, without having to duplicate anything similar to how DirectX9 works. But it seems like there is no way to do what i want to do in DX11 without having the darn staging buffer. I need to read that buffer on the CPU because after the ouputStream is filled up i am doing something with it on the CPU side. For now i will just do the two buffer route just to get this working. Thanks everyone for the help.

Edited by BornToCode
0

Share this post


Link to post
Share on other sites

I'm not sure if you saw it yet or not, but in the new features for Direct3D 11.2 there is a new feature which allows mapping of default usage buffers.  This fits what you are talking about, and bypasses the staging buffer require in between.

 

I don't know if Windows 8.1 is a target system for you, but it seems to be in the cards to have this ability.  They mentioned in the BUILD presentation that it only works for buffers right now (due to considerations in using the compute shader) but one could foresee this coming to all resources eventually (that's my guess anyways).

2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Similar Content

    • By lonewolff
      Hi Guys,
      I am just wondering if it is possible to acquire the address of the backbuffer if an API (based on DX11) only exposes the 'device' and 'context' pointers?
      Any advice would be greatly appreciated
    • By MarcusAseth
      bool InitDirect3D::Init() { if (!D3DApp::Init()) { return false; } //Additional Initialization //Disable Alt+Enter Fullscreen Toggle shortkey IDXGIFactory* factory; CreateDXGIFactory(__uuidof(IDXGIFactory), reinterpret_cast<void**>(&factory)); factory->MakeWindowAssociation(mhWindow, DXGI_MWA_NO_WINDOW_CHANGES); factory->Release(); return true; }  
      As stated on the title and displayed on the code above, regardless of it Alt+Enter still takes effect...
      I recall something from the book during the swapChain creation, where in order to create it one has to use the same factory used to create the ID3D11Device, therefore I tested and indeed using that same factory indeed it work.
      How is that one particular factory related to my window and how come the MakeWindowAssociation won't take effect with a newly created factory?
      Also what's even the point of being able to create this Factories if they won't work,?(except from that one associated with the ID3D11Device) 
    • By ProfL
      Can anyone recommend a wrapper for Direct3D 11 that is similarly simple to use as SFML? I don't need all the image formats etc. BUT I want a simple way to open a window, allocate a texture, buffer, shader.
    • By lucky6969b
      Q1:
      Since there is no more fixed pipeline rendering in DX11, for every part of rendering in DX11, do I need to create a brand-new vertex shader and pixel shader... or at least I have to find one relevant online. If you work on skinned meshes and other effects originally worked in DX9 fixed pipeline, do I have to rework everything by now?
       
      Q2:
      For assimp, if it originally was designed for DX9, like it is coupled to a DX9 device for creating meshes and materials etc. Do I have to add in the DX11 device in the assimp, or can I just leave the assimp to remain in DX9 and after the meshes are loaded, I just convert the vertex buffers and index buffers into DX11 buffers?
      Thanks
      Jack
    • By MarcusAseth
      This header is mentioned in the book I'm reading but there is no documentation on msdn... Is it like an... outdated and abandoned header?
      If so, what's the current default/recomended library for handling errors with directX?
  • Popular Now