Hi,
I plan to commit this series this weekend. I've made minor
improvements to u_vbuf and addressed all concerns, and I have tested
r300g and r600g, and made sure that softpipe and llvmpipe don't use
this code. Here are the updated patches (starting with the cso
commit):
http://cgit.freedesktop.org/~mareko/mesa/log/?h=st-mesa-user-buf
What's missing:
1) Some drivers should handle PIPE_BIND_VERTEX_BUFFER in
is_format_supported and the new CAPs too. I can't do it, because I
don't know what the drivers are capable of.
2) The radeonsi driver hasn't been adapted yet. I don't have LLVM 3.1
at the moment, therefore I can't even compile the driver. I'll try to
take look at it this weekend unless someone else beats me to it.
Marek
On Wed, Apr 11, 2012 at 5:38 PM, Marek Olšák <mar...@gmail.com> wrote:
> A couple of problems may arise with this:
>
> 1) r300g and r600g rely on what u_vbuf does, so other state trackers should
> either use u_vbuf too or be very careful about how they setup vertex buffers
> and vertex elements. Not every combination of states works and u_vbuf is good
> at not letting through what doesn't.
>
> 2) Drivers should properly handle PIPE_BIND_VERTEX_BUFFER in
> is_format_supported.
>
> 3) u_vbuf always and unconditionally uploads user vertex buffers if it's
> active. For example, if you only don't support PIPE_FORMAT_R64G64B64A64_FLOAT
> as a vertex format, but otherwise support user vertex buffers, then u_vbuf
> gets installed into cso_context and takes control. Drivers using the Draw
> module should expose all vertex formats, the user-vertex-buffer CAP, and not
> expose the buffer-alignment-restriction CAPs in order to avoid u_vbuf kicking
> in.
>
> 4) Drivers should not crash when receiving NULL vertex buffers via
> set_vertex_buffers. Such buffer are always unused by the vertex element
> state. The thing is one of the codepaths in u_vbuf is using the translate
> module, which usually takes a new vertex buffer slot. If you receive this in
> set_vertex_buffers: count=4, buffers={NULL, NULL, NULL, buffer}, it means the
> last buffer probably comes from translate and the other 3 were originally
> user buffers, which u_vbuf never lets through, so they end up being NULL.
>
> (2) must be fixed in some drivers, (3) can be fixed in u_vbuf if needed. I
> prefer (4) to be fixed in drivers.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
