On Wed, Apr 11, 2012 at 9:38 AM, Marek Olšák <[email protected]> wrote: > Hi everyone, > > This series adds these optional features to st/mesa: > - uploading user vertex buffers > - translating unsupported vertex formats into floats > - vertex data with unaligned buffer_offset, src_offset, or stride is > transformed such that it's aligned > > These vertex formats are automatically translated into float if the driver > doesn't expose them through is_format_supported(PIPE_BIND_VERTEX_BUFFER): > - PIPE_FORMAT_*16_FLOAT > - PIPE_FORMAT_*64_FLOAT > - PIPE_FORMAT_*32_FIXED > - PIPE_FORMAT_*32_UNORM > - PIPE_FORMAT_*32_SNORM > - PIPE_FORMAT_*32_USCALED > - PIPE_FORMAT_*32_SSCALED > > This series doesn't deal with uploads of: > - user index buffers > - user constant buffers > > It's all done by moving the u_vbuf module out of the radeon drivers and into > the Mesa state tracker. u_vbuf is installed into cso_context, where it > overrides a few functions. The installation is done only when the driver > doesn't support a certain feature (a vertex format or user buffers or has > buffer alignment restrictions). That's pretty much it. > > There are new CAPs for vertex buffer alignment and, of course, user vertex > buffers. I had to add "uint8_t *user_ptr" into pipe_resource, so that I could > access the user buffer pointer in the state tracker. > > 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. > > There is also a lot of refactoring code in r300g and r600g, but nothing > significant. > > Please review & comment.
I looked over the rest of the series and it looks good to me. -Brian _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
