Hi, I'm trying to get the Frame Profiler running with my new card but I have not luck.
I want to profile our custom game engine to get more performance out of AMD cards.
Every time I try to open the Frame Profiler with any OpenGL program I get:
Error: Unable to enable selected counters: failed
If I try the Frame Debugger I get this warning:
The GPU timing information for the draw calls in this frame cannot be found. The GPU timings displayed will be incorrect, and profiling of draw calls has been disabled.
With the Forward Plus DX11 demo by AMD I get:
Error: Unable to enable selected counters: Hardware not supported
Is it really necessary to update to a new version of GPU PerfStudio or do I have to use different options?
Our engine is based on the C4 Engine version 4.5 by Terathon. I really need some help to speed up our game on AMD cards.
Thanks in advance.
Having the same problem here. And all I can say is:
OMG!!! How on earth is this still going on? How can rx 580 still be unsupported on GPU PerfStudio? Why does AMD simply not giving a damn about it's products? Hey AMD don't you WANT developers using and developing your hardware?!?! We can move along, just say so (or just keep ignoring us, we're starting to get the hint).
Based on feedback from many of the game developers who were using GPU PerfStudio, AMD made the decision to stop future development of GPU PerfStudio (which was a closed-source, AMD-only tool) - and instead focus on improving the existing open-source tool RenderDoc. With the recent release of RenderDoc V1.0 which includes support for profiling using the AMD GPU HW counters, RenderDoc now offers all the functionality that was previously in GPU PerfStudio. We would recommend that any GPU PerfStudio user, try RenderDoc and let us know if it works for you.
Thank you for taking the time to answer. Unfortunately this is really really bad for us. These kind of changes translate to cost for developers. At least we're not wondering anymore. Tried RenderDoc, won't work. Doesn't capture anything. It needs an OpenGL core 3.2+ context, which we don't use for compatibility reasons. I know we are in 2018, but we are a small company without resources to waste, so we're working with the smallest common denominator here to achieve compatibility. Don't have days to waste on learning how to appease the new tool into doing what the old one did effortlessly. Figuring out the new convoluted way opengl core contexts are created cannot be considered moving forward at this point in our project. Needless to say touching old, distant code is a good way to guarantee introducing bugs. Is AMD really improving the tool or waiting for the community to do it for them anyway? GPU Open seems more like a way for AMD to ditch responsibility for any type of software support. Whatever, seems like we 're just screwed. Thanks anyway, you did shed light on this horrible situation!
At least we're not wondering anymore. Tried RenderDoc, won't work. Doesn't capture anything. It needs an OpenGL core 3.2+ context, which we don't use for compatibility reasons. I know we are in 2018, but we are a small company without resources to waste
OpenGL 3.x is better and simple than OpenGL 2.0. In the present time a lot of vendors and software companies have at least OpenGL 3.x compatibility. Try to upgrade your product, OpenGL 2.0 is very old, I think any vendors will not fix any driver problem.
I'm afraid you misunderstood. There is no argument that OpenGL 3.x is better than OpenGL 2.0. Our engine works with many new features, a complete programmable pipeline, VAOs, deferred rendering, the works (we are also compatible with GL ES 2.0). To achieve the level of cross-platform compatibility we wanted we initially used a Compatibility profile, not a Core one. Which is incompatible with RenderDoc. Our long term strategy would surely be to move away from a compatibility profile BUT in order to do that in a non excruciating way we need a working debugger/profiler. RenderDoc seems to be in it's infancy right now. Even with using a 3.2+ core profile capturing a single frame and attempting to browse through the command list (Event Browser) leads to an immediate crash of RenderDoc. Utterly useless. This is a catch 22. In order to get what we don't have we need what we don't have. Sadly this situation doesn't seem resolvable and these talks do not seem to lead anywhere. I guess it's time to take a few steps back and crack open some OpenGL books aka dig a hole in the wall using our heads as hammers. I guess that's life.