D3D11: Implement non-blocking CPU EFB access #3652

stenzek · 2016-02-18T10:32:55Z

Trying implementing the EFB cache as a staging texture that is kept mapped until it is invalidated. Will be interesting to see what the overheads are here compared to the GL implementation which copies blocks at a time.

Should also work for MSAA and >1xIR cases.

delroth · 2016-02-18T11:00:39Z

I'd really prefer if we could have one implementation of that, however it's done.

JMC47 · 2016-02-19T08:24:05Z

Some performance numbers:

Monster Hunter Tri: Before - 4 FPS, After - 71 FPS, OGL - 3 FPS
F-Zero GX Sand Ocean: Before - 57 FPS, After - 94 FPS, OGL - 64 FPS

Fixes issue 8427 and issue 8247, one of which are regression. Thus, this should be considered for 5.0. Also, look at those perf numbers.

degasus · 2016-02-19T08:44:58Z

I don't think this should go into 5.0. It's a new feature, not a fix. As we're an emulator, of course most new features are fixes for games, but not fixes for the emulator itself.

But the byte order fix might go to 5.0, indeed.

stenzek · 2016-02-20T01:58:29Z

no need to invalidate here swap does not imply efb changes

Correct, however this is more a precaution against drivers being silly. Keeping a texture mapped while calling Present (or, submitting commands) seems like something that would never pop up during "normal" workloads and is probably an untested path.

Source/Core/VideoBackends/D3D/FramebufferManager.cpp

+		CD3D11_RECT src_rect(0, 0, m_target_width, m_target_height);
+		CD3D11_VIEWPORT vp(0.0f, 0.0f, EFB_WIDTH, EFB_HEIGHT);
+		D3D::context->RSSetViewports(1, &vp);
+		D3D::context->OMSetRenderTargets(1, &m_efb.depth_read_texture->GetRTV(), nullptr);


Tinob · 2016-02-20T23:45:59Z

if you are interested in make it work for dx12 here you have it implemented.
Tinob/Ishiiruka@d3ab000

CrossVR · 2016-02-21T01:56:04Z

Review status: 0 of 9 files reviewed at latest revision, 3 unresolved discussions.

Source/Core/VideoBackends/D3D/FramebufferManager.cpp, line 124 [r1] (raw file):
I take it you chose to remove the m_efb.slices because peeks are only done on the first layer anyway?

Comments from the review on Reviewable.io

stenzek · 2016-02-21T02:07:28Z

Review status: 0 of 9 files reviewed at latest revision, 3 unresolved discussions.

Source/Core/VideoBackends/D3D/FramebufferManager.cpp, line 124 [r1] (raw file):
Correct. It's only used as a copy destination, never drawn to. I'm not how to best handle the stereo case here, which is why I just used the left eye image.

Comments from the review on Reviewable.io

JMC47 · 2016-02-21T02:13:37Z

Huge speedup, more accurate, what's not to like?

Verified to work at > 1x IR now.

delroth · 2016-02-21T06:33:31Z

Code duplication and feature freeze? :)

lioncash · 2016-02-21T06:43:56Z

Review status: 0 of 9 files reviewed at latest revision, 7 unresolved discussions.

Source/Core/VideoBackends/D3D/FramebufferManager.cpp, line 265 [r2] (raw file):
This should be memcpying the value out of memory instead of using reinterpret_cast. The initial reinterpret_cast on pData (which is void* iirc), should be to its assumed type (first non-void type it's casted to, assuming the variable is used for memory allocation or something), or to char/unsigned char.

Source/Core/VideoBackends/D3D/FramebufferManager.cpp, line 282 [r2] (raw file):
Ditto

Source/Core/VideoBackends/D3D/FramebufferManager.cpp, line 292 [r2] (raw file):
Ditto, but into memory

Source/Core/VideoBackends/D3D/FramebufferManager.cpp, line 302 [r2] (raw file):
Ditto, but into memory

Comments from the review on Reviewable.io

lioncash · 2016-02-21T10:03:27Z

@Tinob It's not safe to typecast across pointer types like what is in your code. Consider using memcpy instead.

stenzek · 2016-02-21T10:44:49Z

I'm tempted to not call this an "EFB cache" anymore, since we're just accessing a texture that's potentially in vram, not making a copy and storing it in system memory.

A note on accuracy: For EFB pokes, should we be applying the same logic and handling 16-bit Z/16-bit color in the same way as peeks?

IRT to sharing code with GL, I'm not sure there is much that can actually be shared. The majority of the work is in FramebufferManager::MapEFB{Color,Depth}Copy, and this is all D3D-specific code. The only stuff that could be shared is in Renderer::AccessEFB, and that's just a few lines now.

I've implemented the same idea for GL using pixel buffer objects, but it seems slower when only reading a few pixels (but faster when reading pixels further apart, or a larger count than the block sizes). D3D has to go through a copy/map path always, so there isn't really a comparison here. So I'm not sure what the best option is?

RisingFog · 2016-02-26T01:43:30Z

Any update on this?

RisingFog · 2016-03-14T16:36:06Z

What's holding this PR back?

BhaaLseN · 2016-03-14T16:53:45Z

"Code duplication and feature freeze? :)"

bb010g · 2016-03-15T03:35:52Z

@BhaaLseN It fixes a regression.

This is done through a copy of the buffers that is invalidated once the next draw occurs. If multiple accesses occur inbetween draw calls, the read won't block.

bb010g · 2016-03-27T22:59:18Z

@RisingFog It looks like just fixing what lioncash and possibly Tinob have mentioned on Reviewable.

emko · 2016-06-23T02:56:59Z

for me this causes performance problems
Mario Galaxy with this i get max fps in a exact same spot 45-50FPS vs without 80fps

degasus · 2016-06-23T10:07:42Z

@emko What is "for me"? Which GPU do you have?

JMC47 · 2016-06-23T10:10:06Z

Are you sure it isn't because D3D EFB Access got fixed recently?

Tinob · 2016-06-23T10:58:14Z

just to clarify emko report: he was testing performance betwen master and ishiiruka and find out that there is a big performance diff betwen dx11 master vs dx11 ishiruka, we started to track down the source and i finish discovering that the difference was that ishiirukka have this pr already merged, i send him a link to this version to be sure and yes the speed lost for him was the same for this pr with master code. for his profile i see that he use a nvidia 970 with a intel 2600k, it seems to be a problem in that specific card because the rest of the configurations i tested have huge improvements.

emko · 2016-06-23T20:52:18Z

@degasus for me because i see others reporting improved performance, could it be my GPU GTX 970? i will test out the games JMC47 seen performance improvements in maybe its just this game

emko · 2016-06-23T21:08:03Z

High IR 4X native what i use most of the time
F-Zero GX Sand Ocean: Before - 18 FPS, After - 18 FPS

lower the resolution to 3X native i get Before - 27 FPS, After - 27FPS
no performance difference in this game for me, maybe its my hardware

RisingFog · 2016-09-16T17:53:29Z

Now that we've released 5.0 and are out of feature freeze, is there anything holding this PR back? (Other than a rebase)

lioncash added the WIP / do not merge Work in progress (do not merge) label Feb 18, 2016

Tinob reviewed Feb 20, 2016
View reviewed changes

stenzek changed the title ~~WIP: D3D11: Implement EFB peek cache (and some other minor fixes)~~ D3D11: Implement EFB peek cache (and some other minor fixes) Feb 21, 2016

RisingFog mentioned this pull request Mar 15, 2016

Partial texture updates with parts of efb copies #3266

Merged

D3D11: Implement non-blocking CPU access to EFB

0198add

This is done through a copy of the buffers that is invalidated once the next draw occurs. If multiple accesses occur inbetween draw calls, the read won't block.

stenzek changed the title ~~D3D11: Implement EFB peek cache (and some other minor fixes)~~ D3D11: Implement non-blocking CPU EFB access Mar 25, 2016

stenzek mentioned this pull request May 1, 2016

D3D11: Fix CPU EFB color reads when MSAA is enabled #3808

Merged

stenzek closed this Jun 10, 2017

stenzek deleted the d3d11-efb-cache branch February 11, 2019 14:52

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

D3D11: Implement non-blocking CPU EFB access #3652

D3D11: Implement non-blocking CPU EFB access #3652

stenzek commented Feb 18, 2016

delroth commented Feb 18, 2016

JMC47 commented Feb 19, 2016

degasus commented Feb 19, 2016

stenzek commented Feb 20, 2016

This comment was marked as off-topic.

Tinob commented Feb 20, 2016

CrossVR commented Feb 21, 2016

stenzek commented Feb 21, 2016

JMC47 commented Feb 21, 2016

delroth commented Feb 21, 2016

lioncash commented Feb 21, 2016

lioncash commented Feb 21, 2016

stenzek commented Feb 21, 2016

RisingFog commented Feb 26, 2016

RisingFog commented Mar 14, 2016

BhaaLseN commented Mar 14, 2016

bb010g commented Mar 15, 2016

bb010g commented Mar 27, 2016

emko commented Jun 23, 2016 •

edited

Loading

degasus commented Jun 23, 2016

JMC47 commented Jun 23, 2016

Tinob commented Jun 23, 2016

emko commented Jun 23, 2016

emko commented Jun 23, 2016 •

edited

Loading

RisingFog commented Sep 16, 2016

D3D11: Implement non-blocking CPU EFB access #3652

D3D11: Implement non-blocking CPU EFB access #3652

Conversation

stenzek commented Feb 18, 2016

delroth commented Feb 18, 2016

JMC47 commented Feb 19, 2016

degasus commented Feb 19, 2016

stenzek commented Feb 20, 2016

This comment was marked as off-topic.

Tinob commented Feb 20, 2016

CrossVR commented Feb 21, 2016

stenzek commented Feb 21, 2016

JMC47 commented Feb 21, 2016

delroth commented Feb 21, 2016

lioncash commented Feb 21, 2016

lioncash commented Feb 21, 2016

stenzek commented Feb 21, 2016

RisingFog commented Feb 26, 2016

RisingFog commented Mar 14, 2016

BhaaLseN commented Mar 14, 2016

bb010g commented Mar 15, 2016

bb010g commented Mar 27, 2016

emko commented Jun 23, 2016 • edited Loading

degasus commented Jun 23, 2016

JMC47 commented Jun 23, 2016

Tinob commented Jun 23, 2016

emko commented Jun 23, 2016

emko commented Jun 23, 2016 • edited Loading

RisingFog commented Sep 16, 2016

emko commented Jun 23, 2016 •

edited

Loading

emko commented Jun 23, 2016 •

edited

Loading