What's the explanation for this Xenosaga performance?
#11
Driver what? Tongue2
I'm no D3D guy btw, I don't know the basics of rendering Tongue2
Reply

Sponsored links

#12
its a command buffer for deferred object creation and execution.

Nvidia has semi supported it since last year in just Civ 5, but have enabled it globally in the Release 270 drivers.

However, i expect the PS2 draw call emulation would be "immediate processing" so the command list wouldn't even help :\

Hmm, gamedev posts on the topic of MTD3D seem to conclude that with the use of Deffered context command lists and MTD3D seems to improve the Draw call scaling

Quote:Plus your engine has to do a lot of CPU work anyway to make draw calls. It has to build matrix transformations, sort objects and draw calls, make all sorts of decisions on what to draw and how to draw it. All of this could be done in parallel with big wins -- provided that your app actually has enough work to do that these things become bottle necks.

But it seems to be DX10.1 minimum, so D3D10 devices just won't cut it.

Quote:The DX10.1 feature level supports hardware multithreading. This means that there is a reasonable sized slice of hardware out there already that can support this stuff once drivers arrive.

Though DX10 parts support D3D11 command lists when using feature sets via D3D11 device context creation. (or i read the MSDN article wrong).

Would it be wrong to assume PCSX2 is currently doing something like
Quote:There has been some multithreading support in earlier DirectX versions for a while now by using the multithreaded flag when creating the device. Typically though, the pattern has been to run a dedicated rendering thread and submit objects to be rendered to that thread. This allows the device to stay in single threaded mode where it is faster.

Whilst D3D11 is more like
Quote:The basic idea behind multithreading in Direct3D 11 is that you create an immediate device context on the main thread. Then, for each thread on which you’d like to be able to render, you create a deferred context. As you can probably guess from the names, commands executed on the immediate context get executed immediately, but those on the deferred context just get saved off into a command list. You then execute the deferred command lists on the main thread using the immediate device context. Sounds easy enough.
Reply




Users browsing this thread: 1 Guest(s)