Hello all, I've got some questions and I would appreciate if anyone could help me out. Here goes:
I've been digging through brw_try_draw_prims(), and trying to figure out what it is doing, so far this is what I see: 1) it is essentially called each time a non-degenerate "real drawing" glDrawFoo() is called 2) it appends to the current batch buffer the necessary commands to the GPU to execute the draw call. This includes state change upload is essentially handled by brw_upload_state() which essentially walks atoms. 3) if the batch buffer gets full enough it is flushed. Now bits that confuse me: 1) When I look at intel_batch_buffer_flush() I see that it adds a marker MI_BATCH_BUFFER_END (and possible a no-op marker to keep the size even) and then makes the DRM call, drm_intel_bo_subdata() and then unreferences the upload data. What I do not understand is where/how is the signal to kernel made to say the buffer should be processed.. is is just by uploading the data? 2) I admit that I have not gone through the VBO module super fine-like, but when and where is nr_prims not one? The calls I have looked at have that value being one. What calls, if any, have that argument not as one? 3) It appears that a batch buffer gets flushed if blorp is used, glFlush is called or if it gets too full. Is there anything to say if the command looks heavy so that it should trigger a flush to make sure the GPU command queue is full-ish usually? 4) Going further, is there any mechanism (and if so what is it) to say a batch has made its way through the gfx pipeline? Going further, fine details of making its way through. For example, if a memory region, say for attributes, is no longer read so it can be modified. I am looking at glBufferSubData and glTexSubImage calls on buffer and texture objects used by previous draw calls. Also, what is the tangle for seeing if a query is ready? For example, an application can ask if a query is ready and if it is then get the value otherwise not ask for the value. Doing so can avoid a pipeline flush. Thanks in advance! -Kevin _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
