[Mesa-dev] Gallium u_gen_mipmap problem with queries

Marek Olšák maraeo at gmail.com
Wed Mar 12 17:55:05 PDT 2014


I don't think there is a disable bit for all queries in our hardware.

We disable queries by "ending" them and resuming is like starting a
new one. We have to do that for context switches and blitting and
resource_copy_region anyway. Conditional rendering can be predicated
by an array of query results, so it's a natural thing to do.

To me, I think the 4th option is the best one, because it doesn't need
changes to the gallium interface.

Marek

On Wed, Mar 12, 2014 at 7:12 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 12.03.2014 15:00, schrieb Marek Olšák:
>> Hi everybody,
>>
>> u_gen_mipmap doesn't disable queries, so all active queries are
>> incremented, even though mipmap generation shouldn't have any effect
>> on queries. Hardware drivers can disable queries, but this feature is
>> not exposed via the gallium interface. Generally, we want to disable
>> all queries except for the time_elapsed query for u_gen_mipmap. I
>> propose the following solutions to this problem:
>>
>> 1) Add pipe_context::pause_all_queries(pipe) and
>> resume_all_queries(pipe). It's self-explanatory.
>>
>> 2) Add pipe_context::pause_query(pipe, query) and resume_query(pipe,
>> query). This has the disadvantage of having to enumerate all active
>> queries in u_gen_mipmap.
>>
>> 3) Add pipe_rasterizer_state::disable_all_queries:1, or separate bits
>> disable_occlusion_queries:1 and disable_streamout_queries:1 (this
>> includes the primitives_generated query too).
>>
>> 4) Rewrite u_gen_mipmap to use pipe->blit.
>>
>> Please comment.
>>
>> Thanks.
>>
>> Marek
>
> No idea what's best here. Though if you go for pause/resume query (or
> all queries) wouldn't it be better to just have one function and pass in
> some SUSPEND_QUERIES/RESUME_QUERIES bit?
> Other than that, I guess if hw really can suspend just all queries
> gathering with a single bit then an interface to disable all of them
> at once would be preferable.
>
> Roland


More information about the mesa-dev mailing list