On 5/17/06, <b class="gmail_sendername">B. Bogart</b> <<a href="mailto:ben@ekran.org">ben@ekran.org</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>20 instances of the same abstraction:<br>(these are counts of the totals for the whole patch)<br>40 gemheads<br>100 pix_texture<br>120 rectangle<br>20 pix_buffer<br>60 pix_buffer_read<br>20 pix_buffer_write<br>160 translate
<br>80 scale<br>20 color<br>40 alpha<br>160 separator</blockquote><div><br>
That many separators will likely stall the GPU quite a bit since that
basically resets the rendering pipeline. That many pix_texture
objects constantly uploading textures will also stall in the driver on
Linux and Windows (your patch would probably go like 0.2 fps on
Windows).<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I really have no idea how the nv driver works, what your saying tells me<br>that each gem GL function should execute a function in the nvidia driver.
<br>But since the driver is closed source without symbols would there be any<br>way of getting those calls?</blockquote><div><br>
The profiler will take note of any memory location in the driver that
takes time and then it should also keep track of what calls lead up to
it. So if you do a glColor4f() in GEM that will make the driver
do something with that call.<br>
<br>
The symbols in the driver aren't all that important unless there is a bug to alert Nvidia about.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">attached is the patch, though it depends on pix_video uses in a weird way,<br>and my serial control camera
</blockquote><div><br>
A Pan/Tilt/Zoom camera?<br>
<br>
cgc <br>
</div><br></div><br>