Jump to content
  • Advertisement

Search the Community

Showing results for tags 'DX12'.

The search index is currently processing. Current results may not be complete.


More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Audio
    • Music and Sound FX
  • Business
    • Business and Law
    • Career Development
    • Production and Management
  • Game Design
    • Game Design and Theory
    • Writing for Games
    • UX for Games
  • Industry
    • Interviews
    • Event Coverage
  • Programming
    • Artificial Intelligence
    • General and Gameplay Programming
    • Graphics and GPU Programming
    • Engines and Middleware
    • Math and Physics
    • Networking and Multiplayer
  • Visual Arts
  • Archive

Categories

  • Audio
  • Visual Arts
  • Programming
  • Writing

Categories

  • Game Dev Loadout
  • Game Dev Unchained

Categories

  • Game Developers Conference
    • GDC 2017
    • GDC 2018
  • Power-Up Digital Games Conference
    • PDGC I: Words of Wisdom
    • PDGC II: The Devs Strike Back
    • PDGC III: Syntax Error

Forums

  • Audio
    • Music and Sound FX
  • Business
    • Games Career Development
    • Production and Management
    • Games Business and Law
  • Game Design
    • Game Design and Theory
    • Writing for Games
  • Programming
    • Artificial Intelligence
    • Engines and Middleware
    • General and Gameplay Programming
    • Graphics and GPU Programming
    • Math and Physics
    • Networking and Multiplayer
  • Visual Arts
    • 2D and 3D Art
    • Art Critique and Feedback
  • Community
    • GameDev Challenges
    • GDNet+ Member Forum
    • GDNet Lounge
    • GDNet Comments, Suggestions, and Ideas
    • Coding Horrors
    • Your Announcements
    • Hobby Project Classifieds
    • Indie Showcase
    • Article Writing
  • Affiliates
    • NeHe Productions
    • AngelCode
  • Topical
    • Virtual and Augmented Reality
    • News
  • Workshops
    • C# Workshop
    • CPP Workshop
    • Freehand Drawing Workshop
    • Hands-On Interactive Game Development
    • SICP Workshop
    • XNA 4.0 Workshop
  • Archive
    • Topical
    • Affiliates
    • Contests
    • Technical
  • GameDev Challenges's Topics
  • For Beginners's Forum
  • Unreal Engine Users's Unreal Engine Group Forum
  • Unity Developers's Forum
  • Unity Developers's Asset Share

Calendars

  • Community Calendar
  • Games Industry Events
  • Game Jams
  • GameDev Challenges's Schedule

Blogs

There are no results to display.

There are no results to display.

Product Groups

  • Advertisements
  • GameDev Gear

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me


Website


Role


Twitter


Github


Twitch


Steam

Found 264 results

  1. When ever another window gains focus (the most simple way is to press Alt + Tab) on the same monitor, the game window will be forced into windowed mode. I already called MakeWindowAssociation with DXGI_MWA_NO_WINDOW_CHANGES and DXGI_MWA_NO_ALT_ENTER. And it returned success. No Alt + Enter works as expected, the default handler is gone. But the forced fullscreen state change seems can't be turned off completely. Does anyone have any better idea about this issue?
  2. The latest release of Diligent Engine combines a number of recent updates (Vulkan on iOS, GLTF2.0 support, shadows), significantly improves performance of OpenGL backend, updates API, adds integration with Dear Imgui and implements new samples and tutorials. Some of the new features in this release: GLTF2.0 support (loader, PBR renderer and sample viewer) Shadowing Component and Shadows Sample Integration with Dear Imgui library and Dear Imgui demo Tutorial13 - Shadow Map Tutorial14 - Compute Shader Tutorial15 - Multiple Windows Check it out on GitHub.
  3. Hello! I need some guidance on CommandQueue/CommandAllocator/CommandList management. In my current project I have a few "systems" that need to execute graphical commands, such as rendering terrain, rendering water, rendering particles etc. Right now my project is very simple so I'm not even using command lists during initialization. However, that's starting to be required. Currently I'm just using a single command queue with a ring buffer of 2 command allocators that get recorded by a single command list. Each time I render the scene, a command allocator and a command list is being reset and then recorded. After all commands has been recorded, the list is executed and the swap chain is flipped. Here's some pseudo-code: void Initialize() { [...] device->CreateCommandQueue(...); device->CreateCommandAllocator(...); // commandAllocator[0] device->CreateCommandAllocator(...); // commandAllocator[1] device->CreateCommandList(...); commandList->Close(); [...] } void Render() { WaitForPreviousFrame(); commandAllocator[i]->Reset(); // i = swapChain->GetCurrentBackBufferIndex() commandList->Reset(...); RecordAllCommands(); commandList->Close(); commandQueue->ExecuteCommandLists(...); Signal(...); swapChain->Present(...); } The issue with this is that I cannot record commands during initialization, and with this design it's also quite cumbersome to execute command lists multiple times during one frame since the command allocator ring buffer is tied together with the swap chain buffer index. So I started to think about how I should redesign this, preferably also with future support for threading. And I've thought about it for quite some time now and can't come up with a good solution. One idea is that each system should have their own command list with a ring buffer of 2 command allocators, and then record it and just use a global command queue to execute the list. This works well from a parallel point of view, but the issue is that now each system need to check individually if the GPU is done with the commands before resetting the command allocator. This feels like a huge CPU waste. Another idea is that there is only one global command list, that is aviable already during initialization of other systems, and after the initialization this command list gets executed, before entering the game loop. During the game loop, the global command list gets executed once per frame as I do it now. However, there are 2 issues with this. First of all, some systems might want to execute their commands earlier than at the end of each frame. Secondly, if multiple threads record into the same command list, then we might get a situation like this: commandList->SetPipelineState(pipelineState1); // Thread 1 wants pipelineState1. commandList->SetPipelineState(pipelineState2); // Thread 2 wants pipelineState2. [...] commandList->DrawInstanced(...); // Thread 1 expects pipelineState1 to be set... I'm out of ideas of how to implement this in a simple and elegant way. Or maybe I'm doing this entirely wrong. Basically what I need is: Systems should be able to record commands already during initialization. Atleast during initialization, it should be possible to execute commands in multiple steps and even wait for the GPU to complete them. When rendering the scene, it would be nice if multiple threads could record commands in parallel. Does any of you have a good solution to this problem? What is the AAA game engine way of dealing with this?
  4. Here is my code snip: ID3D12DescriptorHeap* DescHeaps[] = { SRVHeapCache.GetDescriptorHeap() };// I want to bind Different RTV to this heap cache between Draw Calls CommandList->SetDescriptorHeaps(1, DescHeaps); CommandList->SetGraphicsRootSignature(RootSignature.Get()); CommandList->SetGraphicsRootConstantBufferView(2, PerPassConstants.GetResource()->GetGPUVirtualAddress()); CommandList->SetGraphicsRootConstantBufferView(1, PerObjectConstants.GetResource()->GetGPUVirtualAddress()); CommandList->IASetPrimitiveTopology(D3D_PRIMITIVE_TOPOLOGY_TRIANGLELIST); for (auto Actor : TheScene.Actors) { CommandList->SetGraphicsRootDescriptorTable(0, SRVHeapCache.GetGPUHandleStart()); Actor->Draw(D3dDevice.Get(), CommandList.Get(), SRVHeapCache.GetDescriptorHeap()); } And in Actor's Draw, I use CopyDescriptorsSimple: Device->CopyDescriptorsSimple(1, hDescriptor, Mgr->Textures[DiffTextureID].Texture.GetCPUHandle(), D3D12_DESCRIPTOR_HEAP_TYPE_CBV_SRV_UAV); But this doesn't work. The content of HeapCache seems to never change in the runtime.
  5. Good day. I am find for information on how to create texture arrays in d3d12. In d3d11, I calmly figured out how to create a texture array from several textures: I upload several dds - textures of the same resolution in the engine I create ID3D11Texture2D* and map date into it all loaded textures in shader I use texture2darray in pixel shader: Texture2DArray textures : register(t0); Now I am looking for something like that for d3d12. For load the textures, I use DDSTextureLoader.h/.cpp from microsoft. So I'm loading a few textures. How can I create a texture array from them and pass it to a pixel shader? I will be glad to some example. Thank. PS: I searched the forum, but I didn’t find anything.
  6. Hello, I should say I'm new to DX12 and I have the following use case. I'm making a "simple" font rendering library that caches glyphs from DirectWrite into 2D textures/atlases as they're being requested by the user on the fly. I create multiple textures with fixed sizes so that I don't have to resize them if there's not enough space for a font's glyphs. A new texture is created if there's not enough space. Now, the problem is that there can be a command list being executed that is sampling these textures (because of a previous text render) while I need to insert some glyph to the atlas(es) (write to a texture region). Obviously, it is guaranteed that the texture data read by the previous render will not be modified since the glyph insert process only writes to free space. So my question is, is it possible to write to a texture while it's being read in this case, and how? If not, what's the best way to do what I want (or some good alternatives)? And another question: using this method I might end up having to use multiple textures for a draw call. How do I make the shader choose which texture to sample from depending on input data? There can be a dynamic number of textures in this case, but they're all the same size. Or is it better to split this into multiple draw calls and change resources between them?
  7. By looking at Microsoft's working code samples and people's posts on forums, it seems that people are doing double buffering in the following way: fence 0 frame 0: | submit command | execute command ..................................................... | frame 1: | submit command | execute command .....|......................................... It seems that, people tend to submit and execute their commands for the current frame first, _then_ fence and wait for previous frame to finish. This seems counter-intuitive to me, since this potential overlap means duplicating temporary per-frame data. My question is why not just do it this way instead: fence 0 frame 0: | submit command | execute command ..........................................| frame 1: | submit command | execute command .....|......................................... This way, CPU work still overlaps with GPU work, but no duplication needs to happen. Yes, de-overlapping frame 0 and frame 1 seems to be bad for performance, but can it be that bad? I feel like if frames are finished on time, this overlap should never occur in the first place? So I'm wondering why the majority prefers the first approach to the second approach, even though the second approach is simpler and seems more natural to me. Thanks.
  8. Hello! I am trying to implement the d3d12 window resizing function. First, I delete all the buffers referenced by SwapChain, and then run SwapChain :: ResizeBuffers. At this point I get the error: This is the code of the procedure for changing sizes of window: I put together a minimal self sufficient example for modeling the problem that described above: Tell me how to fix this problem. P.S.: I set my RTV names and text error replace: RTV number is always random.
  9. Hello, I am working on a DX12 renderer which is utilizing multiple threads to build command lists. I am currently trying to figure out a proper way to handle fencing and synchronization between the threads. My problem is that for some reason my waits seem to be passing through even if the fence hasn't yet been signaled. This is my structure: Render Thread: Supplies render data from scene and launches several render tasks on worker threads. Lastly uses GPU&CPU waits to check if all tasks are ready before executing Present. Worker threads: Builds command list for specified task. Uses cpu-waits if there are dependencies. Queues itself into Queue-thread for GPU-submission. Queue-thread: Runs continously, checking if any cmd list has been queued. Inserts gpu-waits if needed. Executes the cmd list and lastly signals fence. As noted, the fences seem to act as if they are signaled when Render thread reaches present. Am I missing something trivial? /Baemz
  10. I am running an Nvidia 1080 Ti with the latest drivers, and it seems as though even if I make a barebones application (creates a swapchain and just clears and fences between two frames), I have a perpetual, linear rise in memory usage when I use the DX Debug layer. Without the debug layer, I'm stable for hours at the same amount of memory used. Does anyone else see anything like this?
  11. Hey guys, My battle with DXR still goes one 🙂 This time I am trying to render three triangles and encounter flickering artifacts on two of them. For the sake of the test, each triangle represents a separate mesh. Their vertex and index data are stored in a global vertex and index buffers. For each of the meshes, I create a dedicated D3D12_RAYTRACING_GEOMETRY_DESC, specifying corresponding offsets in the vertex and index buffers. D3D12_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_INPUTS BLASBuildInputs; BLASBuildInputs.Type = D3D12_RAYTRACING_ACCELERATION_STRUCTURE_TYPE_BOTTOM_LEVEL; BLASBuildInputs.Flags = D3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_PREFER_FAST_TRACE; BLASBuildInputs.DescsLayout = D3D12_ELEMENTS_LAYOUT_ARRAY; BLASBuildInputs.NumDescs = (UINT)geometryDescs.size(); // 3 descs BLASBuildInputs.pGeometryDescs = geometryDescs.data(); If I specify only one geometry desc on D3D12_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_INPUTS, it works fine for all of them. That is, BLASBuildInputs.NumDescs = 1; BLASBuildInputs.pGeometryDescs = &geometryDescs[0]; // works also with 1 and 2 But will not work, if I use three of them. My closest hit shader interpolates vertex colors and outputs the result in the payload. I also tried to output hardcoded "red" color to exclude interpolation issue, but did not help. Any ideas what could be upsetting it so much? 🙂 Thanks!
  12. Hey guys, I am working on my very first DXR "hello triangle" and hitting "DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of time to execute its commands, or the hardware crashed/hung" in Present call. My program consists of ray generation, closest hit and miss shaders. I noticed that if I remove TraceRay call and write the result to output texture it works OK. I have checked twice all the setup and everything seems to be OK and debug layer does not complain. I have no more ideas what I could check. I am on GTX 1070 with the latest driver version. Any suggestions? Thanks!
  13. Hi, I have more of a broad abstraction design question that probably won't have one ultimate answer. In many D3D12 samples (also in UE4), a buffer/texture is usually wrapped by a class that contains data about the width, height, stride, element count, .... and when the resource is created, a set of descriptors (SRV, UAV per mip, CBV, ...) are usually created depending on how the resource is going to be used (Rendertarget, Shader resource, Unordered Access, ...) and these descriptors are owned by that class. To give an example of the pattern that you usually come across (pseudo-code) class Texture { void CreateTexture(int width, int height, int mipLevels) { CreateResource(width, height, ....); m_Uav = AllocateDescriptors(mipLevels) for each mip: CreateUAV(m_Uav.offset(i)); CreateSRV(); CreateRTV(); .... } int Width, Height, more properties ... D3D12_CPU_DESCRIPTOR_HANDLE m_Rtv = {}; D3D12_CPU_DESCRIPTOR_HANDLE m_Uav = {}; D3D12_CPU_DESCRIPTOR_HANDLE m_Srv = {}; }; However, I find myself in a situation where I need different types of views for the resource and there is not a catch-all solution for it. For example, I create a TextureCube and a SRV for it. You could create a TextureCube SRV a Texture2DArray SRV Several Texture2D SRVs This all depends on use and more than one view could be needed for the same resource. Same for a depth buffer, if you want a depth buffer to be used for both writing and read_only, you need 2 separate descriptors (one with a READ_ONLY flag set). I believe what makes views/descriptors so powerful, is that they provide you with different ways to interpret read the same data. Having this "class wrapper" pretty much breaks this flexibility because all descriptors are created the same for the different types of resources you define in your abstraction and it is impossible to cover all uses. Obviously, the solution would be to decouple the resource from the view but I wonder, how is this usually done? Is a solution creating these descriptors on-the-fly, possibly even every single frame? I suppose this is not specific to DirectX 12 and pretty much applies to any Graphics API Thanks, Simon
  14. Diligent Engine now implements some shadow rendering BKMs: - Cascaded shadow maps with cascade stabilization - PCF - Variance shadow maps - Two and four-component exponential variance shadow maps - Optimized fixed-size or world-sized filter kernels - Best cascade search based on projection into light space - Filtering across cascades - Various artifact removal techniques The main goal is to create a plug-and-play shadowing component that can be easily integrated into applications. The component consists of a shadow map manager and few shader functions. A Shadows sample demonstrates how to integrate Diligent shadows into an application. Check it out on GitHub: https://github.com/DiligentGraphics/DiligentEngine#high-level-rendering-components-1 I am planning to add exponential shadow maps and moment shadow maps later. Are there any state-of-the-art shadowing techniques that I should also take a look at? Credits: Variance Shadow Maps Shadow sample update by MJP Shadow Explorer sample from Intel Cascaded Shadow Maps technical article by Microsoft
  15. Hello, I have come across a strange problem in D3D12. I am creating a render target with the start state in CreateCommittedResource as D3D12_RESOURCE_STATE_RENDER_TARGET. After that, I create an SRV for the render target and use that as the source handle in a CopyDescriptors call. This is all done during initialization. When doing the first draw call, I get this validation error. This happens only during the first frame. This makes me think, CopyDescriptors is doing an implicit state transition because I create the resource in D3D12_RESOURCE_STATE_RENDER_TARGET and after that, the only time it is used before the draw call is in the CopyDescriptors call.
  16. Hey guys, I would like to check with you about D3D12_SUBOBJECT_TO_EXPORTS_ASSOCIATION in relation to hit groups. In the list of exports for the association are you supposed to specify the hit group name? Are you allowed to list a shader from the hit group instead of the whole group? I am going through Introduction to DirectX Raytracing chapter from Ray Tracing Gems book and the authors seem to use always the compete hit group in the export list. Thank you!
  17. This article uses material originally posted on Diligent Graphics web site. Introduction Graphics APIs have come a long way from small set of basic commands allowing limited control of configurable stages of early 3D accelerators to very low-level programming interfaces exposing almost every aspect of the underlying graphics hardware. Next-generation APIs, Direct3D12 by Microsoft and Vulkan by Khronos are relatively new and have only started getting widespread adoption and support from hardware vendors, while Direct3D11 and OpenGL are still considered industry standard. New APIs can provide substantial performance and functional improvements, but may not be supported by older hardware. An application targeting wide range of platforms needs to support Direct3D11 and OpenGL. New APIs will not give any advantage when used with old paradigms. It is totally possible to add Direct3D12 support to an existing renderer by implementing Direct3D11 interface through Direct3D12, but this will give zero benefits. Instead, new approaches and rendering architectures that leverage flexibility provided by the next-generation APIs are expected to be developed. There are at least four APIs (Direct3D11, Direct3D12, OpenGL/GLES, Vulkan, plus Apple's Metal for iOS and osX platforms) that a cross-platform 3D application may need to support. Writing separate code paths for all APIs is clearly not an option for any real-world application and the need for a cross-platform graphics abstraction layer is evident. The following is the list of requirements that I believe such layer needs to satisfy: Lightweight abstractions: the API should be as close to the underlying native APIs as possible to allow an application leverage all available low-level functionality. In many cases this requirement is difficult to achieve because specific features exposed by different APIs may vary considerably. Low performance overhead: the abstraction layer needs to be efficient from performance point of view. If it introduces considerable amount of overhead, there is no point in using it. Convenience: the API needs to be convenient to use. It needs to assist developers in achieving their goals not limiting their control of the graphics hardware. Multithreading: ability to efficiently parallelize work is in the core of Direct3D12 and Vulkan and one of the main selling points of the new APIs. Support for multithreading in a cross-platform layer is a must. Extensibility: no matter how well the API is designed, it still introduces some level of abstraction. In some cases the most efficient way to implement certain functionality is to directly use native API. The abstraction layer needs to provide seamless interoperability with the underlying native APIs to provide a way for the app to add features that may be missing. Diligent Engine is designed to solve these problems. Its main goal is to take advantages of the next-generation APIs such as Direct3D12 and Vulkan, but at the same time provide support for older platforms via Direct3D11, OpenGL and OpenGLES. Diligent Engine exposes common C++ front-end for all supported platforms and provides interoperability with underlying native APIs. It also supports integration with Unity and is designed to be used as graphics subsystem in a standalone game engine, Unity native plugin or any other 3D application. Full source code is available for download at GitHub and is free to use. Overview Diligent Engine API takes some features from Direct3D11 and Direct3D12 as well as introduces new concepts to hide certain platform-specific details and make the system easy to use. It contains the following main components: Render device (IRenderDevice interface) is responsible for creating all other objects (textures, buffers, shaders, pipeline states, etc.). Device context (IDeviceContext interface) is the main interface for recording rendering commands. Similar to Direct3D11, there are immediate context and deferred contexts (which in Direct3D11 implementation map directly to the corresponding context types). Immediate context combines command queue and command list recording functionality. It records commands and submits the command list for execution when it contains sufficient number of commands. Deferred contexts are designed to only record command lists that can be submitted for execution through the immediate context. An alternative way to design the API would be to expose command queue and command lists directly. This approach however does not map well to Direct3D11 and OpenGL. Besides, some functionality (such as dynamic descriptor allocation) can be much more efficiently implemented when it is known that a command list is recorded by a certain deferred context from some thread. The approach taken in the engine does not limit scalability as the application is expected to create one deferred context per thread, and internally every deferred context records a command list in lock-free fashion. At the same time this approach maps well to older APIs. In current implementation, only one immediate context that uses default graphics command queue is created. To support multiple GPUs or multiple command queue types (compute, copy, etc.), it is natural to have one immediate contexts per queue. Cross-context synchronization utilities will be necessary. Swap Chain (ISwapChain interface). Swap chain interface represents a chain of back buffers and is responsible for showing the final rendered image on the screen. Render device, device contexts and swap chain are created during the engine initialization. Resources (ITexture and IBuffer interfaces). There are two types of resources - textures and buffers. There are many different texture types (2D textures, 3D textures, texture array, cubmepas, etc.) that can all be represented by ITexture interface. Resources Views (ITextureView and IBufferView interfaces). While textures and buffers are mere data containers, texture views and buffer views describe how the data should be interpreted. For instance, a 2D texture can be used as a render target for rendering commands or as a shader resource. Pipeline State (IPipelineState interface). GPU pipeline contains many configurable stages (depth-stencil, rasterizer and blend states, different shader stage, etc.). Direct3D11 uses coarse-grain objects to set all stage parameters at once (for instance, a rasterizer object encompasses all rasterizer attributes), while OpenGL contains myriad functions to fine-grain control every individual attribute of every stage. Both methods do not map very well to modern graphics hardware that combines all states into one monolithic state under the hood. Direct3D12 directly exposes pipeline state object in the API, and Diligent Engine uses the same approach. Shader Resource Binding (IShaderResourceBinding interface). Shaders are programs that run on the GPU. Shaders may access various resources (textures and buffers), and setting correspondence between shader variables and actual resources is called resource binding. Resource binding implementation varies considerably between different API. Diligent E