Ben Skeggs wrote: > Am Freitag, den 23.11.2007, 10:21 +0000 schrieb Keith Whitwell: >> Ben Skeggs wrote: >>> Hey, >>> >>> Attached is a patch which adds driver hooks to update the status of a >>> query object (both to core mesa, and the gallium state tracker). There >>> is currently an issue with applications that spin waiting for >>> GL_QUERY_RESULT_AVAILABLE_ARB to be true (eg. arbocclude). The current >>> code will simply check return q->Ready, and doesn't give the driver a >>> chance to actually update this field, so the application will end up >>> spinning forever. >>> >>> The workaround in nouveau (current git, and nv4x gallium driver) >>> currently forces the application to block until a query result is >>> available when it calls glEndQuery(). Obviously this isn't a nice >>> solution! >> I think I'm going to rejig the pipe query interface. I'm not really >> happy with the pipe_query_object struct, I think it can just go away and >> become an opaque handle to a structure private to the driver, so we get >> an interface more like this: >> >> struct pipe_query_object *(*create_query)( struct pipe_context *pipe, >> unsigned query_type ); >> >> void (*destroy_query)(struct pipe_context *pipe, >> struct pipe_query_object *q); >> >> void (*begin_query)(struct pipe_context *pipe, >> struct pipe_query_object *q); >> >> void (*end_query)(struct pipe_context *pipe, >> struct pipe_query_object *q); >> >> boolean (*get_query_result)(struct pipe_context *pipe, >> struct pipe_query_object *q, >> boolean wait, >> uint64_t *result); >> > This looks much better. In the nv4x gallium driver I currently store > pointers to the pipe_query_objects in an array and use that to lookup > the driver private info. The above interface would do away with that > hack :) > >> Even this is probably too constrained as future query types may provide >> some more elaborate structure as a result, eg multiple hardware counters >> in a struct or similar. > Perhaps something like the current struct pipe_query_object, but keep > the driver's create_query() call so it can allocate the pipe object as a > subclass of its own query object struct. And have the driver maintain > the fields of pipe_query_object it supports?
I think I'll stick with this for now. When we get to do more fancy queries, we can reexamine it. It's pretty easy to go wrong guessing about interfaces for things you don't currently need. Keith ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
