Comments (3)
This is something I've wanted to add for a long time, and never got around to, partly because I'm not sure the names are going to be available most of the time - I thought that depended on the DX debug layer being enabled, though perhaps I'm mistaken if it just uses Set/GetPrivateData APIs for this (I could have sworn the debug layer had a dedicated API for this through a different COM interface, but I can't find doco on that now so perhaps I'm mistaken). Unfortunately, those APIs are ones that we have previously identified as being extremely slow - we've previously had a contributor use them to implement some new features, but the performance regressions that were reported against that release forced us to revert that change and find other solutions.
We do actively use those APIs for some things today, and as long as they aren't added to any hot paths or kept strictly in code that is only run in frame analysis / shaderusage dumps (or at the very least only used when hunting is enabled) it might be ok.
ShaderUsage is kind of meant to be a historical record of what resources have been seen used together - the resources it records have been seen in the past, but may not exist at present, which I think is where your reliability issues trying to look up those hashes in mResources are probably coming from, since they may not exist by the time you try to find them.
It might make sense to add these to is G->mResourceInfo since that is a map from hash to info about the resources (but not the resources themselves), but that is mostly filled out when the resource is created, and AFAIK the debug names are set in a separate call after that point. We could potentially set them in that data structure when they are encountered during HackerContext::RecordGraphicsShaderStats(), as that is where we record most of the stats that end up in ShaderUsage.txt, and is only active while hunting is on with the OSD displayed, and when DumpUsage is enabled as a compromise for performance. That call can already noticeably drop fps in some games when active, and if getting the names here adds too much additional overhead we might need to also gate them on some other setting, or add caching to avoid the call any more than needed.
Alternatively, we could hook the SetPrivateData() API and use that to record the names into G->mResourceInfo when they are set. I guess doing it that way would make an already slow call even slower, and it's not like we can do GUID comparisons much faster than Microsoft... hard to say whether it's a better or worse option than recording the name when we see it used :-/
Whatever you go with, it's worth keeping in mind that many distinct resources with different names might end up all sharing the same hash. In fact, I don't think this will be rare at all - I actually expect to see this quite frequently (think - multiple GBuffers that all share the same size, format, etc, but are used for different purposes). So, we might end up needing to add an std::(unordered?)set to mResourceInfo/struct ResourceHashInfo to store multiple names for each hash... This might complicate any caching strategies we try though...
In the case of adding the names to frame analysis log files you should have access to the resource so shouldn't need to look it up by hash - in some ways this might be the best place to add these names without having to be concerned about performance, and there won't ever be any ambiguity with hashes mapping to more than one name since you are working with the specific resource directly. My biggest concern here is not so much the performance as it is inadvertently breaking tools that other modding communities have written that make use of the frame analysis data (like my blender_3dmigoto.py script, which now has been forked by multiple modding communities to adapt to the needs of the specific games they are interested in). Changing the log file is probably going to be mostly ok (and would be a very welcome addition), but changing the filenames could well break things.
The overlay would also be a nice place to display these names, though it might be hard to avoid taking a performance hit to achieve this.
If you can get this working is it something you might consider submitting a pull request for? I think it would definitely be a welcome addition if we can find a good way to integrate it and keep any performance issues under control.
from 3dmigoto.
Actually, thinking about this some more I think the possibility of having multiple resources with different names sharing the same hash is probably a good reason to avoid looking these up by hash since you might end up recording the name of an irrelevant resource that happened to have the same hash as the actual resource that was used.
For the hunting overlay it may still make sense to look these up by hash since it cycles through hashes and doesn't differentiate between multiple buffers that have the same hash, but perhaps if we add it here it should be stored alongside the mVisited*** and mSelected*** globals...
For ShaderUsage.txt it might be better to store them in the ResourceSnapshot struct I think, since that is already there to sort out issues with resources being freed before dumping out ShaderUsage.txt
from 3dmigoto.
ShaderUsage is kind of meant to be a historical record of what resources have been seen used together - the resources it records have been seen in the past, but may not exist at present, which I think is where your reliability issues trying to look up those hashes in mResources are probably coming from, since they may not exist by the time you try to find them.
i think more or less why , if the call itself is slow and there are too many resources only noticed this since copying with dump_usage
enabled would create ShaderUsage and it was beyond slow 5-10 seconds
In the case of adding the names to frame analysis log files you should have access to the resource so shouldn't need to look it up by hash - in some ways this might be the best place to add these names without having to be concerned about performance, and there won't ever be any ambiguity with hashes mapping to more than one name since you are working with the specific resource directly.
this probably best place to add , i only needed to look up via hash in shader dump WriteHLSL
and overlay
but despite that i really didnt notice much performance hit on overlay even when i was going through all mResources/mShaders to find the current selected one resource and show name if it existed
If you can get this working is it something you might consider submitting a pull request for? I think it would definitely be a welcome addition if we can find a good way to integrate it and keep any performance issues under control.
sadly not really , much of what i did was testing to see how feasible the idea is and i really didnt test many games (few unity games like PGR) not sure how often those names are kept to justify being added (even if optional) or how useful it would be
and that probably means it is limited to unity games
from 3dmigoto.
Related Issues (20)
- help my lumine is a little broken HOT 14
- BUG: Unwrapped ID3D11Device! (Linux/WINE) HOT 17
- Unable to load 3DMigoto "d3d11.dll" HOT 2
- 3dmigoto no more working in VR with last DCS beta version
- 3dmigoto is crashing/giving me errors for Watch_Dogs HOT 6
- Maybe there's a lack of vertex data HOT 10
- 3DMIGOTO crashing with DCS world OB and WMR (with doc. to reproduce without VR Helmet) HOT 5
- Missing d3d11 static exports like D3D11On12CreateDevice can prevent d3d11.dll from loading. HOT 5
- Apply shaderfixes on specific objects HOT 7
- how can i run this successfully? HOT 2
- How do I tune d3dx.ini for playing? HOT 4
- Incorrect Vertex data in GF2 Elixium HOT 7
- Why use 3Dmigoto in game will lead to GPU usage decrease and result in a huge decrease in FPS. HOT 10
- Nioh 2, Shader Overwrite ambiguous HOT 9
- Crash with SK. Tried everything. Is there anything that I can do? HOT 4
- 3DMigoto Crashes Granblue Fantasy Relink HOT 7
- CommandList Parameters (thoughts) HOT 2
- Which type of draw call is correct after compute shader slot replace in a TextureOverride? HOT 1
- [override_resource_desc] function crushed UE engine game, does not have access for virtual memory address.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from 3dmigoto.