No subject

passed through the Gallium interface and are well-defined from what I=20
can see. They might be owned by the application (e.g. set via=20
glVertexPointer etc.), therefore using the transfer functions on user=20
buffers is invalid per se. Moreover, the application may change the=20
content of user buffers any time, meaning that drivers should convert=20
the user buffers to real buffers in the draw_vbo function, then draw=20
vertices, and then forget the real buffers, keeping the user buffers=20
bound for the next draw operation. Drivers should not upload user=20
buffers anywhere else, because the application may change the contents betw=
een glDraw* calls. If they are bound as vertex buffers, we don't=20
need to know their size and sometimes we even can't (again,=20
glVertexPointer etc.). Instead, we can use pipe_draw_info::min_index and
 max_index and upload only that range. This has proved to be a great=20
optimization and it&#39;s how r300g and r600g work now.<br>
<br>
In theory,=20
doing user buffer uploads at the state tracker side using inline transfers =
might work and should remove some burden from=20
drivers. In practice, inline transfers may have a very large=20
overhead compared to how things work now. In transfer_inline_write, you=20
usually want to map the buffer, do a memcpy, and unmap it. The map/unmap
 overhead can be really significant. There are applications that use=20
glDrawElements to draw one triangle at a time, and they draw hundreds of
 triangles with user buffers in this way (yes, applications really do this)=
. We can&#39;t afford doing any more=20
work than is absolutely necessary. When you get 10000 or more draw_vbo=20
calls per second, everything matters.<br>

<br>
Currently, the radeon drivers have one upload buffer for vertices and it
 stays mapped until the command stream is flushed. When they get a user=20
buffer, they do one memcpy and that&#39;s all. They don&#39;t touch winsys =
unless the upload buffer is full.<br>
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0p=
t 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
And user-buffers tend not to stay user-buffers - they can be promoted to<br=
>
regular buffers behind the scenes by the driver. =C2=A0Would that be<br>
reflected in this interface somehow?<br></blockquote><div><br>I don&#39;t t=
hink it&#39;s needed. The pipe_resource fields can stay immutable and drive=
rs can internally replace vertex buffers with their private pipe_resources.=
 The state trackers don&#39;t need to know about it.<br>

<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0p=
t 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>