Jump to content

  • Log In with Google      Sign In   
  • Create Account

phantom

Member Since 15 Dec 2001
Offline Last Active Private

#5250157 What is latest version of DXSDK

Posted by phantom on 01 September 2015 - 01:12 PM

The DirectX SDK is now part of the Windows SDK - if you have that installed (which should be the case with VS2015) then you have the latest version.


#5247595 [D3D12] SetDescriptorHeaps

Posted by phantom on 19 August 2015 - 03:17 AM

Conceptually, that makes sense to me. The confusing part is that Set*RootDescriptorTable already takes a GPU descriptor handle, which defines the GPU pointer to the heap (is that correct?). Is there not enough information in the D3D12_GPU_DESCRIPTOR_HANDLE to identify the heap? I suppose I could see it as a way to simplify the backend by requiring the user to specify the exact set of buffers instead of gathering a list from descriptor handles (which would be more expensive). Secondly, can I provide the heaps in arbitrary order? Do they have to match up somehow with the way I've organized the root parameters?


I suspect it is done that way to let the driver decide what to do.
Given a heap base address and two pointers into that heap you can store the latter as offsets into the former, potentially taking up less register space vs a full blown reference. A look at the GCN docs would probably give a good reason for this, at least for that bit of hardware.

As for the order; seems not to matter.
I only did a simple test on this (D3D12DynamicIndexing example; swapped order of heaps @ Ln93 in FrameResource.cpp), but it worked fine so I'm willing to assume this holds true of all resources... until I find a situation which breaks it ;)


#5247353 Vulkan is Next-Gen OpenGL

Posted by phantom on 18 August 2015 - 04:28 AM

This might be of some interest to people, I've only just started looking at it myself however; Siggraph; An Overview of Next Gen Graphics APIs.

I bring it up because it mentions Vulkan, not that I've got to that slide deck yet biggrin.png


#5247128 DX12 SkyBox

Posted by phantom on 17 August 2015 - 10:26 AM

There is a better way to do things in general; don't do the sky first.

You just end up wasting overdraw on pixels which will never be seen.


#5247071 Vulkan is Next-Gen OpenGL

Posted by phantom on 17 August 2015 - 03:12 AM

1) You are making assumptions about Vulkan driver availability - I don't recall seeing anything stating you'll be able to use Vulkan back to Win7
1a) There are also hardware assumptions being made. No one has said what hardware Vulkan will cover on the PC. I suspect the same as DX12 is most likely. So you'll probably need to keep your existing DX11/OpenGL renderer around to cover older hardware.

2) You assume Win10 doesn't have a decent uptake rate. Before release it was sitting at 2.3% of the Windows market, 0.6% behind 32bit XP, from data provided by the Steam Hardware Survey. As I said this was before release, so only testers.

In short; DX12 and Vulkan will likely fill the same gap, hardware wise, so you'll need the old renderer still. Those tend to be DX11.

The other factor forgotten here is that DX12 also covers the Xbox One so the API hits two targets.
Vulkan will get you Win and Linux, but the former will likely be covered by DX11/12 due to 12 hitting first so it'll be down to any Linux support people want to throw out.

By not coming out first Vulkan has lost mindshare, interest and technically relevance. Much like latter GL versions, which finally after years of lagging behind produced functions DX11 didn't have, any functionality is unlikely to be adopted due to a bedding in of DX12 focused systems.

Of course there might well not be any real difference in ability, everyone is targeting the same hardware after all and the APIs reflect that hardware pretty well, so aside from platform specific extensions/features I'm not sure what Vulkan could offer that DX12 wouldn't already cover.

All of which, of course, if speculation as months on from GDC we simply don't know anything beyond the API looking very much like DX12s.


#5246915 DX12 Multithreaded Rendering Architecture

Posted by phantom on 16 August 2015 - 09:29 AM

1) Basically, yes. You'll want to build everything up front (command lists, update any buffers from the CPU side/setup copy operations) before pushing them to the GPU to execute allowing the GPU to chew on that data while you setup the next things for it to render. You can overlap things of course, so it doesn't have to be a case of [generate everything][push everything to gpu], you could execute draw commands as things finish up. So you could generate say all the shadow map command lists, then push those to the gpu before generating the colour passes. (in fact you could dedicate one 'task' to pushing while at the same time starting to generate the colour pass lists.)

2) Yes and no.
Generally its accepted to mean the first bit, that draw calls are generated across multiple threads and queued as work by a single thread (or task) to ensure correct ordering.
That said if you could keep your dependencies in order then there is nothing stopping you queuing work from multiple threads, although I'd have to check the thread safety of the various command queues to see what locks/protection you might need.

However your 'render to various textures' thing brings up a second part; the GPU is itself highly threaded so even if you have one thread pushing execute commands the GPU itself can have multiple commands in flight at once (dependencies allowing) so regardless of what method you use to queue work to the device it can be doing multiple things at the same time.


#5245788 D3D 12: Using fence objects

Posted by phantom on 11 August 2015 - 12:09 PM

1. There is no direct link between the two. Links are 'created' simply by calling 'signal' after 'execute command list' on a queue.

2. 'From the GPU side' simply means doing it in the GPU's time frame. So calling 'signal' will insert a command into the command stream to have the GPU execute which sets the signal to a value. This would happen inside the command processor of the GPU.

3. The command queue wait stalls the GPU's command processor until the fence is signalled. The Win32 API function stalls the CPU until the fence is signalled.

From a practical stand point;
- CommandQueue::Wait() causes the GPU's command processor to wait for the fence to be signalled. Lets say you have a command list which is running a compute shader and a graphics command list which is going to do some graphics commands which depends on the output of that compute work. You can submit both lists to separate queues and have the graphics queue wait on the fence from the compute queue before executing the graphics commands. Without this the two commands could execute at the same time if the GPU in question has separate graphics and compute queue hardware. (Maxwell 2 and GCN are both examples of this).

A second example would be doing a texture upload via a copy queue; you'd want to make sure the copy was complete before allowing any work which depended on it to reference it, so again you'd put a 'signal' in the copy queue and 'wait' on it in the graphics queue.

- Win32 wait would be used when you want to cause a CPU thread to sleep until the GPU has done some work. A simple example of this is waiting for all of a scene to be drawn before submitting the next batch of work.

A good example of all of this is the ExecuteIndirect example in the DirectX Graphics GitHub examples; https://github.com/Microsoft/DirectX-Graphics-Samples


#5245456 Backface culling in geometry shader?

Posted by phantom on 10 August 2015 - 07:37 AM

What are you trying to do which makes you think you need to use the GS?
Generally there is likely to be a way of doing it which will perform better.


#5245447 Backface culling in geometry shader?

Posted by phantom on 10 August 2015 - 07:06 AM

You don't improve the performance by adding an extra stage, and certainly not the geometry shader stage which is a known performance sinkhole.

Turn on back face culling on the API and let the hardware do its thing.


#5245400 [D3D12] Multi-threading: Command Queue, Allocator, List

Posted by phantom on 10 August 2015 - 02:43 AM

You are correct on the queue front.

AMD GCN hardware has 1 gfx queue, at least 2 compute pipes (GCN1.0, the 290X I have at home has 8) and, iirc, 2 DMA engines. The 'compute pipes' are referred to a Async Compute Engines, or ACE, and each can handle multiple command queues and keep more than one job in flight.

NV is a bit more complex, before Maxwell 2 you basically couldn't have a Gfx pipe and a compute pipe active at once. Maxwell 2 removes this restriction, giving you 1 gfx pipe and 31 compute pipes. However NV aren't forthcoming with details so it is unknown how those pipes match up to queues.

Intel don't have any speciality hardware and, due to how it is design, show little improvement with D3D12 in the first place. Still worth using however as it will still reduce CPU overhead.

(Queue = memory address we are reading commands from, pipe = hardware consuming said queue.)

And yes, multiple queues allow work to be dealt with independently in an optimal fashion.
For example, if you had a copy, a gfx and a compute work which is independent you could put that all into the graphics queue BUT it would take time for the graphics command processor to chew all that and distribute it. You also have the serial nature of pushing each command into a single queue to execute it.

By contrast by using a separate queue for each piece of work the GPU can dispatch it at the same time as each queue will be directed at the correct bit of hardware. Front end pressure on the graphics command processor is dropped by 2/3rds as instead of dealing with 3 commands it is now dealing with 1, and the hardware can be utilised fuller faster. (You can also setup and dispatch each piece of work independently on the CPU side so a win there too).

This is, of course, a simple example, but when you start throwing loads of copies and more gfx and compute work into the mix you can see the win.

How you split things up is, of course, up to you and finding the right balance is key.


#5245208 [D3D12] Multidraw, Resource binding

Posted by phantom on 09 August 2015 - 03:21 AM

HOWEVER, as you aren't wandering off into user mode driver town every time you do a draw call, because you are recording them into a client side buffer, this isn't a bad thing.

MultiDraw, and its ilk, are pretty much there as an optimisation and would allow the driver to hit some faster paths because it knows, between draw calls, that you aren't changing state.

Useful in a client-server setup.
Useful in a high overhead setup.
Less useful in a thin API.

In fact with the executeindirect functionality of D3D12 (which gives you the ability to change some root signature constants, and indeed vertex and index buffer locations based on a buffer input) you can do practically more things with better functionality. (One thread writes a command list with N indirect calls, one thread (or the GPU!) writes a buffer with draw call information, bit of fence sync magics, and bam! loads of draws!).


#5244803 Vulkan is Next-Gen OpenGL

Posted by phantom on 06 August 2015 - 06:33 AM

I'm pretty sure it's a whole new system; although as with most things Vulkan the details are low on the ground ;)

Quickly looking over a GDC presentation (clicky) it seems like you create an instance of a Vulkan interface and go from there.

The back buffer looks to be a special texture which can be drawn to the screen; if you are familiar with DX's DXGI stuff it seems to be a bit like that.

As a side note, having recently started getting up to speed with DX12 and now having looked back at that presentation I would say if you want to start getting a handle on this stuff then go and look at/play with DX12.
While the API is a little different the overall shape is the same; buffers, pipelines, barriers.. it all looks very much alike in application, so even if you don't plan to stick with DX12 for the long haul its still a good starting point right now.


#5244662 Vulkan is Next-Gen OpenGL

Posted by phantom on 05 August 2015 - 09:10 AM

They only said that it's coming this year. I'm also curious about who will support it. PS4, Apple etc. or will they insist on their proprietary solutions?

Apple might, but they're already doing Metal on iOS/OSX now, and they've always been slow on the OpenGL front, so I wouldn't hold my breath.

Sony already have the best API of the current offerings... They could make a Vulkan wrapper around it, to make porting easier for PC developers... But in that situation, Vulkan would be a wasteful high level API that's blocking you from low-level efficiencies laugh.png
I doubt many developers would prefer that.


Yeah, I honestly don't see buy in from anyone who already has a low overhead API happening.

Vulkan is likely to cover Windows, Linux (and related) and, as pointed out above, Android - although like OpenGL/OpenGL|ES before it I wouldn'e expect 'one code path to rule them all'.

Future landscape is likely to be;
MS platforms; DX12/DX11(legacy)
PS4; GNM
iOS/OSX; Metal
Linux; Vulkan/OGL
Android; Vulkan/OGL|ES

I'm intrigued, in a vague way, to see what happens with WebGL. It remains behind the times on features with everyone else in the GL ecosystem (iirc WebGL2 is still very much WIP) but exists in a world where Vulkan-like low level APIs don't really fit.

Although it's still very much a matter of 'when it happens...'; the other day the official VulkanAPI twitter feed posted a picture saying Vulkan was 'forged by industry', to which I replied along the lines of "forged by industry and AWOL. Less marketing BS, more specs/libs/drivers." because, for all the pretty slides, right now all we have to look at is marketing and one alpha Android driver.

(By contrast I've had a look over some D3D12 docs/examples, got a handle on the whole 'root signature' stuff and I'm making plans to write some D3D12 code on my Win10 system probably this weekend...)


#5239746 54x50 tiles map searching for neighbours - takes extremely long

Posted by phantom on 11 July 2015 - 09:55 AM

looks like this is your problem right here. you're storing a 2D array as a 1D array, then trying to do adjacency tests.  doable, but god awful ugly, slow, and complex compared to a 2D array.
 
store in a 2d array such as my2Darray[x][y].  adjacent squares to the square at x,y are then: x-1,y;   x+1,y;   x,y-1;   x,y+1;  x-1,y-1;   etc.


Errm... wut?

A 1D array is perfectly suited for 2D data; the look up is a simple case of id = y * width + x; which is practically the same lookup as you are doing for a 2D array.

Depending on array size, allocation strategy and walking method the 2D array could end up performing worse if it is implemented, under the hood, as T** as you have a double indirection to Whatever bit of memory.

TLDR; using a 1D array to store 2D data is perfectly sane and easy to work with.


#5239729 Help in creating a game engine.

Posted by phantom on 11 July 2015 - 07:13 AM

You need to concretely define your requirements.


This.

The term 'game engine' is simply too broad; a few years back as part of my degree I wrote in a week or two a system which interfaced Lua with Java (course requirement on the latter) which could play sounds, draw sprites, do basic collision and have a 'game loop'.

That is technically an 'engine' - a simple, 2D engine, but with a change of graphics and a change of Lua logic it could drive another game type.




PARTNERS