• 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
Tispe

DX12
DX12 - Documentation / Tutorials?

34 posts in this topic

Haven't heard of any releases for DX12 yet, hints are for an early access preview later this year. You can apply for the early access from a link down the page here. That same page gives a good overview of what is changing - I think the main thing is lower level of hardware abstraction. It looks like it builds upon the approach used in DX11 (e.g. still supports command lists and so on), so I think you will be safe to start with DX 11.1 or 11.2

Edited by spazzarama
0

Share this post


Link to post
Share on other sites

If you're a professional developer you can apply for their early access program, which has documentation/samples/SDK available. If not...then you'll unfortunately have to wait until the public release.

0

Share this post


Link to post
Share on other sites

So DirectX12 is it going to be like DX10. where thery get you started then they just drop it in no time and replace it with 11 wtf. Is it Is it going to be like that.

-5

Share this post


Link to post
Share on other sites

 

 

D3D12 will be the same, except will perform much better (D3D11 deferred context do not actually provide good performance increases in practice... or this is the excuse of AMD and Intel which do not support driver command lists).

Fixed cool.png

 

AMD support them on Mantle and multiple game console APIs. It's a back end D3D (Microsoft code) issue, forcing a single-thread in the kernel mode driver be responsible for kickoff. The D3D12 presentations have pointed out this flaw themselves.

 

 
I know that D3D11 command lists are far away from be perfect, but AMD was the first IHV to sell DX11 GPUs (Radeon HD5000 Series) claiming "multi-threading support" as one of the big features of theirs graphics cards.
 
Here what AMD proclaims: 
 
http://www.amd.com/en-us/products/graphics/desktop/5000/5970
 

  • Full DirectX® 11 support
    • Shader Model 5.0
    • DirectCompute 11
    • Programmable hardware tessellation unit
    • Accelerated multi-threading
    • HDR texture compression
    • Order-independent transparency

 

They also claimed the same thing with DX 11.1 GPUs when WDDM 1.2 drivers came out. 

 

Yes, their driver is itself "multi-threaded" (I remember few years ago it scaled well on two cores with half CPU driver overhead), and you can always use deferred context in different "app-threads" (since they are emulated by the D3D runtime, more CPU overhead yeah!), but that's not the same thing.

 

Graphics Mafia.. ehm NVIDIA supports driver command lists, and where used in the correct they work just fine (big example: civilization 5). Yes, they also "cheat" consumers  on feature level 11.1 support (as AMD "cheated" consumers.. and developers! on tier-2 tiled resources support) and they really like to break old application and games compatibility (especially old OpenGL games), but those are other stories.

Edited by Alessio1989
0

Share this post


Link to post
Share on other sites

The DX12 overview indicates that the "unlimited memory" that the managed pool offers will be replaceable with costum memory management.

 

Say your typical low end graphics card has 512MB - 1GB of memory. Is it realistic to say that the total data required to draw a complete frame is 2GB, would that mean that the GPU memory would have to be refreshed 2-5+ times every frame?

 

Do I need to start batching based on buffer sizes? 

0

Share this post


Link to post
Share on other sites

Is it realistic to say that the total data required to draw a complete frame is 2GB

Unless you have another idea, this is completely unrealistic. The amount of data required for one frame should be somewhere in the order of megabytes...  And DX11.2 minimizes the memory requirement with "tiled resources".

 

 


would that mean that the GPU memory would have to be refreshed 2-5+ times every frame?

This is not the case, but even if it was... The article is not very clear on this. It says that the driver will tell the operating system to copy resources into GPU memory (from system memory) as required, but only the application can free those resources once all of the queued commands using those resources have been processed by the GPU. It's not clear if the resources can also be released (from GPU memory, by the OS) during the processing of already queued commands, to make room for the next 512MB (or 1GB, or whatever size) of your 2GB data. But my guess is that this is not possible. This would imply that the application's "swap resource" request could somehow be plugged-into the driver/GPU's queue of commands, to release unused resource memory intermediately, which is probably not possible, since (also according to the article), the application has to wait for all of the queued commands in a frame to be executed, before it knows which resources are no longer needed. Also, "the game already knows that a sequence of rendering commands refers to a set of resources" - this also implies that the application (not even the OS) can only change resource residency in-between frames (sequence of rendering commands), not during a single frame. Also, DX12 is only a driver/application-side improvement over DX11. Adding memory management capabilities to the GPU itself would also require a hardware-side redesign.

 

 


Do I need to start batching based on buffer sizes?

If you think that you'll need to use 2GB (or more than the recommended/available resource limits) of data per frame, then yes. Otherwise, no.

Edited by tonemgub
0

Share this post


Link to post
Share on other sites

It's always been the case that you shouldn't use more memory than the GPU actually has, because it results in terrible performance. So, assuming that you've always followed this advice, you don't have to do much work in the future 

 

So in essence, a game rated to have minimum 512MB VRAM (does DX have memory requirements?) never uses more then that for any single frame/scene?

 

You would think that AAA-games that require tens of gigabytes of disk space would at some point use more memory in a scene then what is available on the GPU. Is this just artist trickery to keep any scene below rated gpu memory? 

Edited by Tispe
0

Share this post


Link to post
Share on other sites


Tiled resources tie in with the virtual address space stuff. Say you've got a texture that exists in an allocation from pointer 0x10000 to 0x90000 (a 512KB range) -- you can think of this allocation being made up of 8 individual 64KB pages.
Tiled resources are a fancy way of saying that the entire range of this allocation doesn't necessarily need to be 'mapped' / has to actually translate to a physical allocation.
It's possible that 0x10000 - 0x20000 is actually backed by physical memory, but 0x20000 - 0x90000 aren't actually valid pointers (much like a null pointer), and they don't correspond to any physical location.
This isn't actually new stuff -- at the OS level, allocating a range of the virtual address space (allocating yourself a new pointer value) is actually a separate operation to allocating some physical memory, and then creating a link between the two. The new part that makes this extremely useful is a new bit of shader hardware -- When a shader tries to sample a texel from this texture, it now gets an additional return value indicating whether the texture-fetch actually suceeded or not (i.e. whether the resource pointer was actually valid or not). With older hardware, fetching from an invalid resource pointer would just crash (like they do on the CPU), but now we get error flags.
 
This means you can create absolutely huge resources, but then on the granularity of 64KB pages, you can determine whether those pages are physically actually allocated or not. You can use this so that the application can appear simple, and just use huge textures, but then the engine/driver/whatever can intelligently allocate/deallocate parts of those textures as required.

 

So what you are saying is that we CAN have 2GB+ of game resources allocated on the GPU VRAM using virtual addresses just fine. But only when we need them we need to tell the driver to actually page things in to VRAM?

 

Assume now that a modern computer has atleast 16GB of system memory. And a game has 8GB of resources and the GPU has 2GB VRAM. So in this situation a DX12 game would just copy all game data from disk to system memory (8GB), then allocate those 8GB to the VRAM and create 8GB of resources, even though the physical limit is 2GB. Command queues would then tell the driver what parts of those 8GB to page in and out? But is that not just what managed pool does anyway?

0

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 hiya83
      Hi, I tried searching for this but either I failed or couldn't find anything. I know there's D11/D12 interop and there are extensions for GL/D11 (though not very efficient). I was wondering if there's any Vulkan/D11 or Vulkan/D12 interop?
      Thanks!
    • By VietNN
      Hi everyone,
      I am new to DX12, I download sample project from MSDN and it can run and draw triangles successfully.
      But when I create new project and copy code from MSDN sample (Hello Triangles Project). I do not know why it could not render anything to screen except clearing the screen with blue color.
      Could you have a look at my code to see what problem is... I got stuck here for 2 days.
       
      TestD3D12.7z
    • By piluve
      Hey guys,
      I started working on a port from dx11 to dx12. The first thing, was to setup everything to work with Dx11On12. Right now I've got that done. Basically, the render frame goes as follows:
       
      D3D12Prepare(); // setups the command list and command allocators (as well as basic clear and set render targets) GetWrappedResources(); // Dx11on12 step to adquire resources Render(); // Basically all the Dx11 rendering code etc D3D12End(); // On D3D12Prepare we left the command list opened so we can add aditional // commands, now close and execute it ReleaseWrappedResources(); Flush(); // Flush all the dx11 code Dx12Sync(); // Wait for fence Dx12Present();  
      That setup is working and I changed some commands inside Render() from dx11 to dx12. (Basic stuff like setviewport)
      I want to start porting more stuff inside the Render(), for example, we have a simple method to draw a quad (without vertex or index buffers, we use the vertex_id inside the shader).
      Basically, it should translate to this:
       
      mCmdList->IASetPrimitiveTopology(D3D_PRIMITIVE_TOPOLOGY_TRIANGLESTRIP); mCmdList->DrawInstanced(4, 1, 0, 0); But even that simple piece of code is just not working. I would like to get some advice from someone that has done a similar process (using dx11on12), what are the limitations, things that wont work etc
      My main concern right now, is that if I want to start setting up commands that touch the IA, I would have to also create the PSO, root signatures etc etc.
       
      Thanks.
       
       
       
    • By AxeGuywithanAxe
      So I wanted to ask a question pertaining to rendering thread architecture. I currently know of two main designs.
      One approach is where visibility , drawcall logic, and gpu submission are all done on the rendering thread and render related game data is sent to the rendering thread at the end of the frame. 
      The second approach is where the sole responsibility of the rendering thread is to send gpu commands to the api. Engine abstacted Command Buffers will be generated in parallel or on the game thread, and sent to the rendering thread to be translated into gpu commands.
      I know that Engines such as Unreal Engine use the first approach, while Unity / Source use the second approach , and Cryengine uses a hybrid of both. I wanted to see if anyone could give some advice, I know some of the benefits of both approaches , but wanted to get more incite on the architecture.
    • By nbertoa
      Hi, community.
      BRE is a rendering framework or engine (under development) which purpose is to have a codebase on which develop techniques related to computer graphics and also to apply the stuff I learn about DirectX 12. I just write a series of articles about its architecture, problems, limitations, techniques, passes, scene format, etc.
      Its main page is located at https://nbertoa.wordpress.com/bre/
      You can access the different articles I wrote about it in the following list
      BRE ARCHITECTURE SERIES PART 1 - OVERVIEW
      BRE ARCHITECTURE SERIES PART 2 - MANAGERS
      BRE ARCHITECTURE SERIES PART 3 - HELPERS
      BRE ARCHITECTURE SERIES PART 4 - SCENE FORMAT
      BRE ARCHITECTURE SERIES PART 5 - SCENE GENERATION
      BRE ARCHITECTURE SERIES PART 6 - RENDER MANAGER AND COMMAND LIST EXECUTOR
      BRE ARCHITECTURE SERIES PART 7 - GEOMETRY PASS
      BRE ARCHITECTURE SERIES PART 8 - ENVIRONMENT LIGHT PASS
      BRE ARCHITECTURE SERIES PART 9 - SKYBOX PASS
      BRE ARCHITECTURE SERIES PART 10 - TONE MAPPING PASS AND POST PROCESS PASS
      BRE ARCHITECTURE SERIES PART 11 - AMBIENT OCCLUSION PASS
      My intention is to share my knowledge and also receive feedback/improvements.
      Thanks! And hope you find it useful
  • Popular Now