Re: [Mesa-dev] [PATCH 00/15] GL_AMD_performance_monitor
On 04/14/2015 11:02 PM, Robert Bragg wrote: Hi Samuel, On Tue, Mar 31, 2015 at 5:56 PM, Samuel Pitoiset samuel.pitoi...@gmail.com wrote: Hello Robert, Sorry for the delay, I just saw your message few days ago, and I probably removed the mail by mistake too... And then I was on holiday; so more delay :-) I have never heard about your work on this area, happy to know right now. :) Well, regarding the backend stuff, I would prefer to keep the same for both GL_AMD_performance_monitor and INTEL_performance_query. My experience with the Intel backend where I initially aimed to update both extensions behind one backend is that it was quite a hindrance and there wasn't a clear benefit to it when there isn't really any substantial code to speak of in the core infrastructure to share between the extensions. We should be careful not to talk cross purposes here though. In my mind having orthogonal frontends and even different backend interfaces wouldn't preclude a driver implementing both extensions with a unified backend if desirable, there would just be two separate sets of entry points for the frontend to interact with that unified backend. Some of the issues I came across were: The current design expects a common description of counters and their types, but the current implementation doesn't fully support INTEL_performance_query semantic types. Fixing this is awkward because neither extension has data/semantic types that are a strict subset of the other so to support all the types I imagine we'd also need to introduce some mechanism for black/white listing counters for each extension if we want to keep a common description. Then if we wanted to utilize the full range of types for both extensions I have a feeling a lot of the counters would end up being exclusively declared for one extension or the other which would negate some of the benefit of having a common structure. The current infrastructure seems somewhat biased towards implementing AMD_performance_monitor with the concept of groups and counter selection which doesn't exist in the INTEL_performance_query extension and that seems unfortunate when the selection mechanism looks to make the allocation and tracking of query objects more costly/complex if we don't need it for the INTEL_performance_query extension. There's no substantial utility code associated with the core infrastructure that the backends benefit from to help justify sharing a backend for multiple extensions. The core support just does simple frontend validation of user arguments to normalize things and handle gl errors consistently before interacting with the backend so in practice the INTEL_performance_query and AMD_performance_monitor code is rather orthogonal. I think the only things that connect the two extensions currently are the shared declaration of counters and a tiny amount of utility code for allocating/freeing monitor objects. Given the issue with the counter types I found things became simpler if the counter descriptions were instead moved into the backend. Given that INTEL_performance_query doesn't need any active group/counter state per object, the common object allocator also isn't ideal. So making both of these changes (which seem to make sense even without the goal of separating the extension) is enough to make the frontends completely orthogonal. I also really like that with the counter declarations in the backend that it's free to use whatever data structures are appropriate for the various counters. As opposed to statically declared arrays describing our counters, I needed to update our backend to programatically build up the lists of available counters and counter descriptions also necessarily became more detailed so it was nice that this work could be self contained in the backend and we can describe our Observation Architecture counters differently from our pipeline statistics counters. My thinking a.t.m is that if the current AMD_perfmon backend architecture seems to be ok for your needs then it could be for the best that the extensions can be easily made orthogonal so we can develop support for both extensions without stepping on each other's toes. Later if it's desirable to support both extensions in any driver we can always evaluate what opportunities there are to have a common backend interface if that could simplify things. Currently, I'm trying to implement GL_AMD_perfmon as a state tracker which is based on the query interface of Gallium and this looks quite good. Only minor changes in the current interface are required to do that. At this time, most of hardware performance counters are *only* exposed through the Gallium HUD and I think it's not very helpful for a large number of applications. I'm pretty sure that GL_AMD_perfmon will be very useful for exposing GPU counters and this is also a requirement for a GSoC project this year. So, with respect to your work, my question is : why do you want to get rid of AMD_perfmon in favour of
Re: [Mesa-dev] [PATCH 00/15] GL_AMD_performance_monitor
On Tuesday, March 31, 2015 01:56:32 PM Alex Deucher wrote: I would prefer to keep support for AMD_performance_monitor in mesa. We may implement more extensive support for this extension in our radeon open source drivers and it would be nice to be compatible with our closed source drivers on both Linux and other OSes. Alex I would prefer that as well. FWIW, the core Mesa code I wrote for GL_AMD_performance_monitor may be pretty poor for Radeon - it uses bitsets for a lot of things, which made sense on i965 since I had 64 counters to expose. The last time I looked at the closed source AMD driver, it exposed over 6,000 counters. So you may need some better data structures... --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/15] GL_AMD_performance_monitor
Hi Samuel, On Tue, Mar 31, 2015 at 5:56 PM, Samuel Pitoiset samuel.pitoi...@gmail.com wrote: Hello Robert, Sorry for the delay, I just saw your message few days ago, and I probably removed the mail by mistake too... And then I was on holiday; so more delay :-) I have never heard about your work on this area, happy to know right now. :) Well, regarding the backend stuff, I would prefer to keep the same for both GL_AMD_performance_monitor and INTEL_performance_query. My experience with the Intel backend where I initially aimed to update both extensions behind one backend is that it was quite a hindrance and there wasn't a clear benefit to it when there isn't really any substantial code to speak of in the core infrastructure to share between the extensions. We should be careful not to talk cross purposes here though. In my mind having orthogonal frontends and even different backend interfaces wouldn't preclude a driver implementing both extensions with a unified backend if desirable, there would just be two separate sets of entry points for the frontend to interact with that unified backend. Some of the issues I came across were: The current design expects a common description of counters and their types, but the current implementation doesn't fully support INTEL_performance_query semantic types. Fixing this is awkward because neither extension has data/semantic types that are a strict subset of the other so to support all the types I imagine we'd also need to introduce some mechanism for black/white listing counters for each extension if we want to keep a common description. Then if we wanted to utilize the full range of types for both extensions I have a feeling a lot of the counters would end up being exclusively declared for one extension or the other which would negate some of the benefit of having a common structure. The current infrastructure seems somewhat biased towards implementing AMD_performance_monitor with the concept of groups and counter selection which doesn't exist in the INTEL_performance_query extension and that seems unfortunate when the selection mechanism looks to make the allocation and tracking of query objects more costly/complex if we don't need it for the INTEL_performance_query extension. There's no substantial utility code associated with the core infrastructure that the backends benefit from to help justify sharing a backend for multiple extensions. The core support just does simple frontend validation of user arguments to normalize things and handle gl errors consistently before interacting with the backend so in practice the INTEL_performance_query and AMD_performance_monitor code is rather orthogonal. I think the only things that connect the two extensions currently are the shared declaration of counters and a tiny amount of utility code for allocating/freeing monitor objects. Given the issue with the counter types I found things became simpler if the counter descriptions were instead moved into the backend. Given that INTEL_performance_query doesn't need any active group/counter state per object, the common object allocator also isn't ideal. So making both of these changes (which seem to make sense even without the goal of separating the extension) is enough to make the frontends completely orthogonal. I also really like that with the counter declarations in the backend that it's free to use whatever data structures are appropriate for the various counters. As opposed to statically declared arrays describing our counters, I needed to update our backend to programatically build up the lists of available counters and counter descriptions also necessarily became more detailed so it was nice that this work could be self contained in the backend and we can describe our Observation Architecture counters differently from our pipeline statistics counters. My thinking a.t.m is that if the current AMD_perfmon backend architecture seems to be ok for your needs then it could be for the best that the extensions can be easily made orthogonal so we can develop support for both extensions without stepping on each other's toes. Later if it's desirable to support both extensions in any driver we can always evaluate what opportunities there are to have a common backend interface if that could simplify things. Currently, I'm trying to implement GL_AMD_perfmon as a state tracker which is based on the query interface of Gallium and this looks quite good. Only minor changes in the current interface are required to do that. At this time, most of hardware performance counters are *only* exposed through the Gallium HUD and I think it's not very helpful for a large number of applications. I'm pretty sure that GL_AMD_perfmon will be very useful for exposing GPU counters and this is also a requirement for a GSoC project this year. So, with respect to your work, my question is : why do you want to get rid of AMD_perfmon in favour of INTEL_perf_query ? From my pov, the
Re: [Mesa-dev] [PATCH 00/15] GL_AMD_performance_monitor
On Tue, Mar 31, 2015 at 6:56 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Mar 19, 2015 at 6:40 PM, Robert Bragg rob...@sixbynine.org wrote: Hi Samuel, I thought I should let you and others know of some related changes I've been playing around with to try and improve our support for the INTEL_performance_query extension in the i965 dri driver, since it's quite related to your work. Some of my work-in-progress changes can currently be seen on github here: https://github.com/rib/mesa/commits/wip/rib/i915_oa_perf I've only recently scrubbed up these mesa changes enough for reviewing to make much sense, so sorry I haven't sent out an RFC to the list before now about this. What I was finding is that it's not very helpful in practice to support the AMD_performance_monitor + INTEL_performance query extensions via the same core infrastructure and so since there weren't previously any other drivers implementing AMD_performance_monitor, my series currently just drops the combined infrastructure in favour of core support for just INTEL_performance_query. The main thing here that might be interesting to think about with respect to your work, is whether you might like to do anything differently with the main/performance_monitor.c support if you were the only user and if it strictly only dealt with the AMD_performance_monitor extension? I don't guess it would be controversial for us to look at removing the current i965 backend for both AMD_performance_monitor and INTEL_performance_query for an interim if that might be convenient for you to evolve the backend interface. (Currently the i965 backend doesn't report many usable metrics unfortunately - mainly just the pipeline statistics that are also accessible via query objects.) Ken and Petri who did much of the work here are already aware that I've been taking this approach as I ran it by them some time ago and their work still carries forward in the series I have but instead focused only on INTEL_performance_query for now. Anyway, I just thought I should throw that out there as a possibility to consider in case it might be helpful. I would prefer to keep support for AMD_performance_monitor in mesa. We may implement more extensive support for this extension in our radeon open source drivers and it would be nice to be compatible with our closed source drivers on both Linux and other OSes. Right, especially given that Samuel has implemented a backend now, I assume the core support will be staying. I just deleted it in my own series where I was also removing the only backend for it but I'll be rebasing my series without the patch to drop the AMD_performance_monitor infrastructure. To clarify; what I was suggesting above was also based on the assumption that the core AMD_performance_monitor support is being kept. I was talking about removing the intel backend if that might make Samuel's life easier in case he has some ideas for changing the backend interface. Such changes would be less effort if he doesn't have to worry about updating the intel backend too. I know we'd need to make some changes to the backend interface if we were to look at updating the intel AMD_performance_monitor support so I wouldn't really want the current backend lending weight to keeping the interface as is. I hope that provides some reassurance. Regards, - Robert Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/15] GL_AMD_performance_monitor
Hello Robert, Sorry for the delay, I just saw your message few days ago, and I probably removed the mail by mistake too... I have never heard about your work on this area, happy to know right now. :) Well, regarding the backend stuff, I would prefer to keep the same for both GL_AMD_performance_monitor and INTEL_performance_query. Currently, I'm trying to implement GL_AMD_perfmon as a state tracker which is based on the query interface of Gallium and this looks quite good. Only minor changes in the current interface are required to do that. At this time, most of hardware performance counters are *only* exposed through the Gallium HUD and I think it's not very helpful for a large number of applications. I'm pretty sure that GL_AMD_perfmon will be very useful for exposing GPU counters and this is also a requirement for a GSoC project this year. So, with respect to your work, my question is : why do you want to get rid of AMD_perfmon in favour of INTEL_perf_query ? Don't you think that the AMD extension is also useful as the INTEL one? Best regards, Samuel Pitoiset. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/15] GL_AMD_performance_monitor
On Thu, Mar 19, 2015 at 6:40 PM, Robert Bragg rob...@sixbynine.org wrote: Hi Samuel, I thought I should let you and others know of some related changes I've been playing around with to try and improve our support for the INTEL_performance_query extension in the i965 dri driver, since it's quite related to your work. Some of my work-in-progress changes can currently be seen on github here: https://github.com/rib/mesa/commits/wip/rib/i915_oa_perf I've only recently scrubbed up these mesa changes enough for reviewing to make much sense, so sorry I haven't sent out an RFC to the list before now about this. What I was finding is that it's not very helpful in practice to support the AMD_performance_monitor + INTEL_performance query extensions via the same core infrastructure and so since there weren't previously any other drivers implementing AMD_performance_monitor, my series currently just drops the combined infrastructure in favour of core support for just INTEL_performance_query. The main thing here that might be interesting to think about with respect to your work, is whether you might like to do anything differently with the main/performance_monitor.c support if you were the only user and if it strictly only dealt with the AMD_performance_monitor extension? I don't guess it would be controversial for us to look at removing the current i965 backend for both AMD_performance_monitor and INTEL_performance_query for an interim if that might be convenient for you to evolve the backend interface. (Currently the i965 backend doesn't report many usable metrics unfortunately - mainly just the pipeline statistics that are also accessible via query objects.) Ken and Petri who did much of the work here are already aware that I've been taking this approach as I ran it by them some time ago and their work still carries forward in the series I have but instead focused only on INTEL_performance_query for now. Anyway, I just thought I should throw that out there as a possibility to consider in case it might be helpful. I would prefer to keep support for AMD_performance_monitor in mesa. We may implement more extensive support for this extension in our radeon open source drivers and it would be nice to be compatible with our closed source drivers on both Linux and other OSes. Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/15] GL_AMD_performance_monitor
Hi Samuel, I thought I should let you and others know of some related changes I've been playing around with to try and improve our support for the INTEL_performance_query extension in the i965 dri driver, since it's quite related to your work. Some of my work-in-progress changes can currently be seen on github here: https://github.com/rib/mesa/commits/wip/rib/i915_oa_perf I've only recently scrubbed up these mesa changes enough for reviewing to make much sense, so sorry I haven't sent out an RFC to the list before now about this. What I was finding is that it's not very helpful in practice to support the AMD_performance_monitor + INTEL_performance query extensions via the same core infrastructure and so since there weren't previously any other drivers implementing AMD_performance_monitor, my series currently just drops the combined infrastructure in favour of core support for just INTEL_performance_query. The main thing here that might be interesting to think about with respect to your work, is whether you might like to do anything differently with the main/performance_monitor.c support if you were the only user and if it strictly only dealt with the AMD_performance_monitor extension? I don't guess it would be controversial for us to look at removing the current i965 backend for both AMD_performance_monitor and INTEL_performance_query for an interim if that might be convenient for you to evolve the backend interface. (Currently the i965 backend doesn't report many usable metrics unfortunately - mainly just the pipeline statistics that are also accessible via query objects.) Ken and Petri who did much of the work here are already aware that I've been taking this approach as I ran it by them some time ago and their work still carries forward in the series I have but instead focused only on INTEL_performance_query for now. Anyway, I just thought I should throw that out there as a possibility to consider in case it might be helpful. Kind regards, - Robert On Wed, Mar 18, 2015 at 4:00 PM, Samuel Pitoiset samuel.pitoi...@gmail.com wrote: Bump, is someone want to make a review of this patch set ? Especially the core stuff... On 03/09/2015 10:09 PM, Samuel Pitoiset wrote: Hello, A series I have waited too long to re-submit, but I recently refactored the code and fixed some minor issues. This patchset enables GL_AMD_performance_monitor for svga, freedreno, r600, radeonsi and nvc0 drivers. This code has been tested with Nouveau (NVD9 and NVE7) but it should also work with other drivers. All piglit tests, including API and measurement tests are okay. Feel free to make a review. Christoph Bumiller (1): st/mesa: implement GL_AMD_performance_monitor Samuel Pitoiset (14): gallium: add pipe_screen::get_driver_query_group_info gallium: add new fields to pipe_driver_query_info gallium: add new numeric types to pipe_query_result gallium: replace pipe_driver_query_info::max_value by a union gallium: make pipe_context::begin_query return a boolean gallium: add util_get_driver_query_group_info svga: implement pipe_screen::get_driver_query_group_info freedreno: implement pipe_screen::get_driver_query_group_info radeon: implement pipe_screen::get_driver_query_group_info nvc0: implement pipe_screen::get_driver_query_group_info docs: mark GL_AMD_performance_monitor for the 10.6.0 release nvc0: expose more driver-specific query groups nvc0: make begin_query return false when all MP counters are used nvc0: all queries use an unsigned 64-bits integer by default docs/relnotes/10.6.0.html | 1 + src/gallium/auxiliary/Makefile.sources | 1 + src/gallium/auxiliary/hud/hud_driver_query.c | 2 +- src/gallium/auxiliary/util/u_query.c | 50 +++ src/gallium/auxiliary/util/u_query.h | 45 ++ src/gallium/docs/source/screen.rst | 10 + src/gallium/drivers/freedreno/freedreno_query.c| 25 +- src/gallium/drivers/freedreno/freedreno_query.h| 3 +- src/gallium/drivers/freedreno/freedreno_query_hw.c | 3 +- src/gallium/drivers/freedreno/freedreno_query_sw.c | 3 +- src/gallium/drivers/galahad/glhd_context.c | 6 +- src/gallium/drivers/i915/i915_query.c | 3 +- src/gallium/drivers/ilo/ilo_query.c| 3 +- src/gallium/drivers/llvmpipe/lp_query.c| 3 +- src/gallium/drivers/noop/noop_pipe.c | 3 +- src/gallium/drivers/nouveau/nv30/nv30_query.c | 5 +- src/gallium/drivers/nouveau/nv50/nv50_query.c | 3 +- src/gallium/drivers/nouveau/nvc0/nvc0_query.c | 98 - src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.h | 14 + src/gallium/drivers/r300/r300_query.c | 9 +- src/gallium/drivers/radeon/r600_pipe_common.c | 25 +-
Re: [Mesa-dev] [PATCH 00/15] GL_AMD_performance_monitor
On 03/18/2015 06:13 PM, Marek Olšák wrote: The Gallium interface looked good to me (except where I replied). Sorry, I probably won't have time to review the st/mesa patch. Ok, thank you. I'll submit a v2 for that. Marek On Wed, Mar 18, 2015 at 5:00 PM, Samuel Pitoiset samuel.pitoi...@gmail.com wrote: Bump, is someone want to make a review of this patch set ? Especially the core stuff... On 03/09/2015 10:09 PM, Samuel Pitoiset wrote: Hello, A series I have waited too long to re-submit, but I recently refactored the code and fixed some minor issues. This patchset enables GL_AMD_performance_monitor for svga, freedreno, r600, radeonsi and nvc0 drivers. This code has been tested with Nouveau (NVD9 and NVE7) but it should also work with other drivers. All piglit tests, including API and measurement tests are okay. Feel free to make a review. Christoph Bumiller (1): st/mesa: implement GL_AMD_performance_monitor Samuel Pitoiset (14): gallium: add pipe_screen::get_driver_query_group_info gallium: add new fields to pipe_driver_query_info gallium: add new numeric types to pipe_query_result gallium: replace pipe_driver_query_info::max_value by a union gallium: make pipe_context::begin_query return a boolean gallium: add util_get_driver_query_group_info svga: implement pipe_screen::get_driver_query_group_info freedreno: implement pipe_screen::get_driver_query_group_info radeon: implement pipe_screen::get_driver_query_group_info nvc0: implement pipe_screen::get_driver_query_group_info docs: mark GL_AMD_performance_monitor for the 10.6.0 release nvc0: expose more driver-specific query groups nvc0: make begin_query return false when all MP counters are used nvc0: all queries use an unsigned 64-bits integer by default docs/relnotes/10.6.0.html | 1 + src/gallium/auxiliary/Makefile.sources | 1 + src/gallium/auxiliary/hud/hud_driver_query.c | 2 +- src/gallium/auxiliary/util/u_query.c | 50 +++ src/gallium/auxiliary/util/u_query.h | 45 ++ src/gallium/docs/source/screen.rst | 10 + src/gallium/drivers/freedreno/freedreno_query.c| 25 +- src/gallium/drivers/freedreno/freedreno_query.h| 3 +- src/gallium/drivers/freedreno/freedreno_query_hw.c | 3 +- src/gallium/drivers/freedreno/freedreno_query_sw.c | 3 +- src/gallium/drivers/galahad/glhd_context.c | 6 +- src/gallium/drivers/i915/i915_query.c | 3 +- src/gallium/drivers/ilo/ilo_query.c| 3 +- src/gallium/drivers/llvmpipe/lp_query.c| 3 +- src/gallium/drivers/noop/noop_pipe.c | 3 +- src/gallium/drivers/nouveau/nv30/nv30_query.c | 5 +- src/gallium/drivers/nouveau/nv50/nv50_query.c | 3 +- src/gallium/drivers/nouveau/nvc0/nvc0_query.c | 98 - src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.h | 14 + src/gallium/drivers/r300/r300_query.c | 9 +- src/gallium/drivers/radeon/r600_pipe_common.c | 25 +- src/gallium/drivers/radeon/r600_pipe_common.h | 1 + src/gallium/drivers/radeon/r600_query.c| 16 +- src/gallium/drivers/rbug/rbug_context.c| 8 +- src/gallium/drivers/softpipe/sp_query.c| 3 +- src/gallium/drivers/svga/svga_context.h| 1 + src/gallium/drivers/svga/svga_pipe_query.c | 3 +- src/gallium/drivers/svga/svga_screen.c | 17 +- src/gallium/drivers/trace/tr_context.c | 6 +- src/gallium/include/pipe/p_context.h | 2 +- src/gallium/include/pipe/p_defines.h | 34 +- src/gallium/include/pipe/p_screen.h| 11 + src/mesa/Makefile.sources | 2 + src/mesa/state_tracker/st_cb_perfmon.c | 455 + src/mesa/state_tracker/st_cb_perfmon.h | 70 src/mesa/state_tracker/st_context.c| 4 + src/mesa/state_tracker/st_extensions.c | 3 + 38 files changed, 885 insertions(+), 67 deletions(-) create mode 100644 src/gallium/auxiliary/util/u_query.c create mode 100644 src/gallium/auxiliary/util/u_query.h create mode 100644 src/mesa/state_tracker/st_cb_perfmon.c create mode 100644 src/mesa/state_tracker/st_cb_perfmon.h ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/15] GL_AMD_performance_monitor
Bump, is someone want to make a review of this patch set ? Especially the core stuff... On 03/09/2015 10:09 PM, Samuel Pitoiset wrote: Hello, A series I have waited too long to re-submit, but I recently refactored the code and fixed some minor issues. This patchset enables GL_AMD_performance_monitor for svga, freedreno, r600, radeonsi and nvc0 drivers. This code has been tested with Nouveau (NVD9 and NVE7) but it should also work with other drivers. All piglit tests, including API and measurement tests are okay. Feel free to make a review. Christoph Bumiller (1): st/mesa: implement GL_AMD_performance_monitor Samuel Pitoiset (14): gallium: add pipe_screen::get_driver_query_group_info gallium: add new fields to pipe_driver_query_info gallium: add new numeric types to pipe_query_result gallium: replace pipe_driver_query_info::max_value by a union gallium: make pipe_context::begin_query return a boolean gallium: add util_get_driver_query_group_info svga: implement pipe_screen::get_driver_query_group_info freedreno: implement pipe_screen::get_driver_query_group_info radeon: implement pipe_screen::get_driver_query_group_info nvc0: implement pipe_screen::get_driver_query_group_info docs: mark GL_AMD_performance_monitor for the 10.6.0 release nvc0: expose more driver-specific query groups nvc0: make begin_query return false when all MP counters are used nvc0: all queries use an unsigned 64-bits integer by default docs/relnotes/10.6.0.html | 1 + src/gallium/auxiliary/Makefile.sources | 1 + src/gallium/auxiliary/hud/hud_driver_query.c | 2 +- src/gallium/auxiliary/util/u_query.c | 50 +++ src/gallium/auxiliary/util/u_query.h | 45 ++ src/gallium/docs/source/screen.rst | 10 + src/gallium/drivers/freedreno/freedreno_query.c| 25 +- src/gallium/drivers/freedreno/freedreno_query.h| 3 +- src/gallium/drivers/freedreno/freedreno_query_hw.c | 3 +- src/gallium/drivers/freedreno/freedreno_query_sw.c | 3 +- src/gallium/drivers/galahad/glhd_context.c | 6 +- src/gallium/drivers/i915/i915_query.c | 3 +- src/gallium/drivers/ilo/ilo_query.c| 3 +- src/gallium/drivers/llvmpipe/lp_query.c| 3 +- src/gallium/drivers/noop/noop_pipe.c | 3 +- src/gallium/drivers/nouveau/nv30/nv30_query.c | 5 +- src/gallium/drivers/nouveau/nv50/nv50_query.c | 3 +- src/gallium/drivers/nouveau/nvc0/nvc0_query.c | 98 - src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.h | 14 + src/gallium/drivers/r300/r300_query.c | 9 +- src/gallium/drivers/radeon/r600_pipe_common.c | 25 +- src/gallium/drivers/radeon/r600_pipe_common.h | 1 + src/gallium/drivers/radeon/r600_query.c| 16 +- src/gallium/drivers/rbug/rbug_context.c| 8 +- src/gallium/drivers/softpipe/sp_query.c| 3 +- src/gallium/drivers/svga/svga_context.h| 1 + src/gallium/drivers/svga/svga_pipe_query.c | 3 +- src/gallium/drivers/svga/svga_screen.c | 17 +- src/gallium/drivers/trace/tr_context.c | 6 +- src/gallium/include/pipe/p_context.h | 2 +- src/gallium/include/pipe/p_defines.h | 34 +- src/gallium/include/pipe/p_screen.h| 11 + src/mesa/Makefile.sources | 2 + src/mesa/state_tracker/st_cb_perfmon.c | 455 + src/mesa/state_tracker/st_cb_perfmon.h | 70 src/mesa/state_tracker/st_context.c| 4 + src/mesa/state_tracker/st_extensions.c | 3 + 38 files changed, 885 insertions(+), 67 deletions(-) create mode 100644 src/gallium/auxiliary/util/u_query.c create mode 100644 src/gallium/auxiliary/util/u_query.h create mode 100644 src/mesa/state_tracker/st_cb_perfmon.c create mode 100644 src/mesa/state_tracker/st_cb_perfmon.h ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/15] GL_AMD_performance_monitor
The Gallium interface looked good to me (except where I replied). Sorry, I probably won't have time to review the st/mesa patch. Marek On Wed, Mar 18, 2015 at 5:00 PM, Samuel Pitoiset samuel.pitoi...@gmail.com wrote: Bump, is someone want to make a review of this patch set ? Especially the core stuff... On 03/09/2015 10:09 PM, Samuel Pitoiset wrote: Hello, A series I have waited too long to re-submit, but I recently refactored the code and fixed some minor issues. This patchset enables GL_AMD_performance_monitor for svga, freedreno, r600, radeonsi and nvc0 drivers. This code has been tested with Nouveau (NVD9 and NVE7) but it should also work with other drivers. All piglit tests, including API and measurement tests are okay. Feel free to make a review. Christoph Bumiller (1): st/mesa: implement GL_AMD_performance_monitor Samuel Pitoiset (14): gallium: add pipe_screen::get_driver_query_group_info gallium: add new fields to pipe_driver_query_info gallium: add new numeric types to pipe_query_result gallium: replace pipe_driver_query_info::max_value by a union gallium: make pipe_context::begin_query return a boolean gallium: add util_get_driver_query_group_info svga: implement pipe_screen::get_driver_query_group_info freedreno: implement pipe_screen::get_driver_query_group_info radeon: implement pipe_screen::get_driver_query_group_info nvc0: implement pipe_screen::get_driver_query_group_info docs: mark GL_AMD_performance_monitor for the 10.6.0 release nvc0: expose more driver-specific query groups nvc0: make begin_query return false when all MP counters are used nvc0: all queries use an unsigned 64-bits integer by default docs/relnotes/10.6.0.html | 1 + src/gallium/auxiliary/Makefile.sources | 1 + src/gallium/auxiliary/hud/hud_driver_query.c | 2 +- src/gallium/auxiliary/util/u_query.c | 50 +++ src/gallium/auxiliary/util/u_query.h | 45 ++ src/gallium/docs/source/screen.rst | 10 + src/gallium/drivers/freedreno/freedreno_query.c| 25 +- src/gallium/drivers/freedreno/freedreno_query.h| 3 +- src/gallium/drivers/freedreno/freedreno_query_hw.c | 3 +- src/gallium/drivers/freedreno/freedreno_query_sw.c | 3 +- src/gallium/drivers/galahad/glhd_context.c | 6 +- src/gallium/drivers/i915/i915_query.c | 3 +- src/gallium/drivers/ilo/ilo_query.c| 3 +- src/gallium/drivers/llvmpipe/lp_query.c| 3 +- src/gallium/drivers/noop/noop_pipe.c | 3 +- src/gallium/drivers/nouveau/nv30/nv30_query.c | 5 +- src/gallium/drivers/nouveau/nv50/nv50_query.c | 3 +- src/gallium/drivers/nouveau/nvc0/nvc0_query.c | 98 - src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.h | 14 + src/gallium/drivers/r300/r300_query.c | 9 +- src/gallium/drivers/radeon/r600_pipe_common.c | 25 +- src/gallium/drivers/radeon/r600_pipe_common.h | 1 + src/gallium/drivers/radeon/r600_query.c| 16 +- src/gallium/drivers/rbug/rbug_context.c| 8 +- src/gallium/drivers/softpipe/sp_query.c| 3 +- src/gallium/drivers/svga/svga_context.h| 1 + src/gallium/drivers/svga/svga_pipe_query.c | 3 +- src/gallium/drivers/svga/svga_screen.c | 17 +- src/gallium/drivers/trace/tr_context.c | 6 +- src/gallium/include/pipe/p_context.h | 2 +- src/gallium/include/pipe/p_defines.h | 34 +- src/gallium/include/pipe/p_screen.h| 11 + src/mesa/Makefile.sources | 2 + src/mesa/state_tracker/st_cb_perfmon.c | 455 + src/mesa/state_tracker/st_cb_perfmon.h | 70 src/mesa/state_tracker/st_context.c| 4 + src/mesa/state_tracker/st_extensions.c | 3 + 38 files changed, 885 insertions(+), 67 deletions(-) create mode 100644 src/gallium/auxiliary/util/u_query.c create mode 100644 src/gallium/auxiliary/util/u_query.h create mode 100644 src/mesa/state_tracker/st_cb_perfmon.c create mode 100644 src/mesa/state_tracker/st_cb_perfmon.h ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
