D3D11 Frametrim Backend #872
Conversation
Signed-off-by: Louis-Francis Ratté-Boulianne <[email protected]>
Signed-off-by: Louis-Francis Ratté-Boulianne <[email protected]>
Signed-off-by: Louis-Francis Ratté-Boulianne <[email protected]>
Signed-off-by: Louis-Francis Ratté-Boulianne <[email protected]>
|
@jrfonseca do you have any idea who would be good to review D3D11? |
@fooishbar , I'm familiar with the D3D11 API, so I can and will comment from that perspective. But I only have a superficial understanding of |
There was a problem hiding this comment.
This looks pretty good overall!
The approach taken is the best.
There are a quite a few corner cases glossed over here (comments inline) but this is a good starting point.
The only suggestion I make for future is to be defensive: either err on the side of caution (ie, not trim unless sure), or, when making assumption, explcitly check for those assumptions and throw a loud warning. This way the user is more likely to get something that works, or at least guidance on what needs to be improved.
| void | ||
| D3D11View::clear(const trace::Call& call) | ||
| { | ||
| m_resource->clear(); |
There was a problem hiding this comment.
Clearing a view only clears the subresources on the view. Ideally we should be tracking resource content dependencies on a per-subresource basis.
This is quite common when rendering to mipmaps and/or cube faces.
It's fine to defer fine grained tracking, but I'd recommend emitting a warning when clearing a view which does not comprehend the whole resource, so the user can quickly diagnose what needs to be improved in frametrim.
|
So I've had a look at the code, but since I have zero understanding about how DX11 works I can't really comment on the implementation. |
|
I've asked @okias whether he can give more insights, after all he might be using it the most currently. |
Signed-off-by: Louis-Francis Ratté-Boulianne <[email protected]>
Add a D3D11 backend for
frametrimmer