iTranslated by AI
Notes on API Tracing for OpenGL ES on Windows (at this Late Stage)
EDIT: As I wrote in a scrap, by setting RENDERDOC_HOOK_EGL=0, I was able to use RenderDoc normally on PVRVFrame, so there might not be much motivation to go out of the way to use PVRCarbon...
(The shaders are converted to Desktop OpenGL, but other parts have an almost 1-to-1 correspondence.)
Due to some circumstances, I am implementing WebGL1, so I want to prepare a debug environment for OpenGL ES2, which is its basis. So, here is a memo on how to use PVRVFrame, the API emulator for IMG (PowerVR), and PVRCarbon, its API tracer.
PVRVFrame: OpenGL ES Emulator
After installation, the DLLs are installed in C:\Imagination Technologies\PowerVR_Graphics\PowerVR_Tools\PVRVFrame\Library\Windows_x86_64, so you can just use those.
For the headers corresponding to the DLLs, the standard Khronos ones can be used as they are.
While you can run applications directly using these DLLs, in order to perform API tracing, you need to replace the DLLs with the ones for the recorder.
PVRCarbon: API Tracer
PVRCarbon is an API tracer compatible with OpenGL ES and Vulkan, and it can be said to replace the conventional PVRTrace. While it is likely intended for tracing apps running on mobile devices, it can also trace applications on a PC as if it were its natural right.
The PVRCarbon tracer is located at C:\Imagination Technologies\PowerVR_Graphics\PowerVR_Tools\PVRCarbon\Recorder\GLES\Windows_x86_64.
Since tracing won't work as is, you need to place a configuration JSON file named pvrcarbon.json in the application's directory.
{
"recording":
{
"hostLibrary":
{
"egl": "C:/Imagination Technologies/PowerVR_Graphics/PowerVR_Tools/PVRVFrame/Library/Windows_x86_64/libEGL.dll",
"glesv2": "C:/Imagination Technologies/PowerVR_Graphics/PowerVR_Tools/PVRVFrame/Library/Windows_x86_64/libGLESv2.dll"
},
"network":
{
"enable": true
}
}
}
This network.enable = true causes the launched application to wait for a connection from PVRCarbon.
By launching PVRCarbon while the application is paused waiting for a connection and performing a capture, you can view the API trace.
(↓ I tried capturing a PowerVR SDK sample)
Impressions
It was truly simple.
PVRCarbon as a GPU Debugger
It's tough (to be blunt). It lacks texture or buffer dumps and is generally unfriendly; it is so austere that it truly only provides API call history and validation features. Considering this is a new release that started in 2020 and not 2010...
I'm not sure if it can be called good news, but the fact that new tools are being released means that investment in GPUs is continuing for now, so I want to look forward to the future of the surviving GPU vendors.
OpenGL ES 2
As I wrote in the scrap, with WebGPU approaching next year, the question of whether there's any meaning in investing in WebGL1 or GLES2 now is a difficult one.
The universality of WebGL is also the universality of ANGLE as an OpenGL ES implementation, and in fact, I suspect that GLES implementations other than ANGLE will eventually die out.
- GLOVE ( https://github.com/stjordanis/GLOVE-1 ) has disappeared from the official Think-Silicon site.
- Apple has made GLES a deprecated API.
- The software renderer SwiftShader has repeatedly warned that it will remove its GLES implementation (as an implementation, it focuses on Vulkan, with GLES supported via ANGLE).
In terms of the evolution of GPU SDKs, Qualcomm's SDK hasn't had a major update since around 2016, and instead, the SDKs on the Android side are becoming more robust (this might be due to the fact that Android's Vulkan development environment is also being repurposed for Google's Stadia...).
...So, I wondered what would happen to things like TAKUMI ( http://www.gshark.com ), which only has implemented products up to OpenGL ES 2, but it turns out they passed the OpenVG conformance ( https://www.khronos.org/conformance/adopters/conformant-products/openvg ) just this year... What exactly does that mean?
Discussion