Re: [Chromium-dev] Dropping unneeded glDrawElements calls?

[James S. <arr...@gm...>]

> The tilesort SPU broadcasts VBO drawing commands to all crservers.
> The tilesort SPU's state tracker keeps a client-side copy of the VBO
> data but does not analyze VBO drawing commands to compute the bounding
> box (which would be used for bucketing).
>
> The cost of computing the bounding boxes in these cases could be more
> than just broadcasting the command.
>
> If you want to optimize things, you'll have to add new
> glDrawArrays/glDrawElements code to the tilesort SPU that computes
> bounding boxes.
>
> Unfortunately, you can't just look at a VBO to determine bounds since
> there's no way to interpret the VBO's data; you need the glVertexArray
> parameters, etc. which can vary from one draw to the next.

I am not talking about anything that advanced. Most of the time the
rendering window will not be on both of the ATI monitors. Methinks a
simple way to filter out unneeded glDraw* commands is to check:
(thread->currentContext->currentWindow->server+index)->num_extents
If the server does not have any extents, than it isn't really doing
much? We should be able to drop a lot of commands?

I tried checking this in a for loop, and using
crPackSetBuffer(thread->packer,&(thread->buffer[index]));
when it did not equal zero and I set it back to what it was before
after the loop ended.

I think I am now putting the unrolled draw elements call into the
server specific buffers?
Performance has gone up a lot, but there are some strange visual
errors. It looks as if some coordinate data is being truncated?


Obviously, putting the data into the server specific buffer doesn't
have the same effect as putting it into the global buffer. What is the
correct way to send a command to a single server?

I think the thread->buffer buffers are for the exclusive use of the
state tracker?

Should I try to find a way to use the state tracker for sending the
data to the servers as needed? Or maybe add new buffers and add code
to the flush mechanism for this purpose?

Thank you for your time,
James Steven Supancic III