[Hacky tool] hsG3DDeviceDumper #1744
Conversation
dpogue
force-pushed
the
hsG3DDeviceDumper
branch
7 times, most recently
from
b910539 to
e4fcaa8
Compare
dpogue
force-pushed
the
hsG3DDeviceDumper
branch
4 times, most recently
from
f60f968 to
282c217
Compare
|
In theory this is ready (although TBD if it's worth merging the tool or just picking the various other bits into their own PR without the tool). The one thing I've not been able to test properly is Windows: In my Windows VM, epoxy wgl seems to fail to get a context, although non-epoxy wgl works. If someone is able to grab a build from CI and run it on Windows and confirm if it prints out an OpenGL driver version and display resolutions, that would be very helpful. |
|
It seems to work fine here: and then a whole pile of stuff follows. |
|
It should print an OpenGL driver name/version followed by screen resolutions, and then do the same for DirectX. I think I've seen a case where it printed multiple DX drivers. On my VM it's not printing the OpenGL driver at all. |
|
This is the full output: https://gist.github.com/Hoikas/be149dd5f80f8f850aa6b271efbd797c |
|
hmm, yeah, that looks like 2 DX drivers and |
dpogue
force-pushed
the
hsG3DDeviceDumper
branch
3 times, most recently
from
f1a58cd to
9c4004a
Compare
|
This latest revision seems to work for me in wine, but not in my Windows VM. |
|
Looks like I'm now getting an OpenGL driver: https://gist.github.com/Hoikas/e1af43129027a6e9461c6089f50a9adb |
|
I'm still unclear whether the tool itself has any long-term value and should be merged or not, but this seems like a good starting point for other Linux and OpenGL work |
dpogue
force-pushed
the
hsG3DDeviceDumper
branch
from
9c4004a to
fb2493a
Compare
|
Decision to be made here: Do we think having this tool is useful, or should I split out the device enumeration fixes into their own PR and close the tool part of this one? |
|
I think the tool functionality might be more useful long-term as a console command, but I'm not working on adding new clients/platforms so my opinion on that is not strong. |
| #include "plMetalPipeline.h" | ||
|
|
||
| void plMetalEnumerate::Enumerate(std::vector<hsG3DDeviceRecord>& records) | ||
| void plMetalEnumerate::Enumerate(std::vector<hsG3DDeviceRecord>& records, hsDisplayHndl mainDisplay) |
There was a problem hiding this comment.
Is this actually mainDisplay, or is this meant to be any display? If it's not going to always be the mainDisplay we should rename that.
There was a problem hiding this comment.
Renamed to displayHndl because it's not specifically the main display (although currently that's what it always ends up being)
Co-Authored-By: Adam Johnson <AdamJohnso@gmail.com>
This tool is a hack to facilitate debugging of pipeline device/driver init stuff, but seems potentially worth having. I'm sure it could be made less terrible, but I'm aiming for "immediately useful to me" at the moment.
This is essentially the same as the plOptionalWinCall introduced for DPI handling, except that it doesn't enforce WINAPI calling conventions and can also be used to dynamically load values as well as functions.
dpogue
force-pushed
the
hsG3DDeviceDumper
branch
from
fb2493a to
88a6a7b
Compare
4 participants
Prints out the available hsG3DDeviceRecord records along with their hsG3DDeviceMode resolutions for debugging purposes.
Incredibly hacky code 😛