Thanks for the reply. It's good to know that you don't mind accepting this work.
Though I still have to finish some parts and look into the feedback
before I prepare the actual commits.
I've tried it with llvmpipe. It works pretty well on my machine, the
performance is reasonable until you have too much data on the screen.
So I'd say it works as expected.
Btw, I'm concerned with diverging the codebase. I've done it once
already with profiling counters (old options are still there) last
year and now I'm likely to do the same again with this profiling view.
What do you think can be done about it?
2016-10-14 9:54 GMT+03:00 José Fonseca <jose.r.fons...@gmail.com>:
> Hi Alex,
> Sorry for the delay. James Benton wrote the Qt graph display for profiling.
> I was hoping he could comment, but forgot to star this ended up forgetting
> to reply myself.
> I didn't look at the code, but from what I can see from the screenshots it
> looks great and I'm happy to get it commited.
> Requiring Qt 5.3 is not an issue. Visual Studio 2015 requires Qt 5.6
> Generally, I'd prefer to avoid depending on OpenGL, to avoid hitting issues
> when debugging OpenGL drivers. But profiling view is OK -- were not
> searhcing for bugs when using it. And there's always the possibility of
> falling back to llvmpipe for qapitrace. Do you know if it works reasonably
> well with llvmpipe?
> On Wed, Aug 10, 2016 at 11:02 PM, Alex Tru <alx...@gmail.com> wrote:
>> I’m developing a new OpenGL profiling view for QApitrace. I’m pursuing
>> several goals with that:
>> 1) Support new profiling counters. Currently we have only CPU/GPU
>> time histograms in the view. Last year, I contributed an abstraction
>> for different OpenGL profiling backends which got merged, I’ve also
>> added support for both the INTEL_perfquery and AMD_perfmon GL
>> extensions. This allowed us to output CSV files containing the
>> performance counters’ metrics when replaying traces with glretrace.
>> The plan for this year’s project is to integrate it in QApitrace to
>> make it easier to use and visualize the data.
>> 2) Since I’m planning to display a lot of data in the view,
>> there’s a need to provide graphing tools with reasonable performance.
>> I’ve chosen to use a combination of raw OpenGL and QML for that. The
>> performance is better than that of QPainter based, especially for
>> large amounts of data (but it still can be laggy on some HW).
>> 3) Improve user experience. Well, currently I haven’t improved a
>> lot (if not anything). But I would like to collect opinions on this
>> My development tree is here: https://github.com/trtt/apitrace/tree/guiwip2
>> I had to increase requirements up to Qt 5.3 and OpenGL 3.2. Do you
>> think this is acceptable?
>> Here are some screenshots, just in case:
>> It’s in a quite early state at the moment, but you can generally
>> estimate what to expect. Compiling glretrace and qapitrace should be
>> enough. New profiling view can be found in the menu (Trace -> Profile
>> with backends). Old metrics are all available, new ones are most
>> likely to be found on Mesa for Intel gen 5-8 and for some in Nouveau,
>> also proprietary AMD drivers can feature some. You can expect to see
>> timelines and plots for metrics chosen for different shader programs.
>> Controls are a bit awkward now, but you can drag view to scroll and
>> use <Ctrl+Wheel> to zoom.
>> I am basically writing to know:
>> 1) Do you think this new profiling view can find its place in QApitrace?
>> 2) If yes, what features would you like to see in it?
>> If you are interested, you can also check out my TODO list:
>> apitrace mailing list
apitrace mailing list