I've had a week away, plus evolution melted down and ate my mail, so I'm catching up on old threads that need followup.
On Mon, 2010-01-18 at 13:24 -0800, Corbin Simpson wrote: > So, with half-float vert attribs looming on the horizon, I want to > address, hopefully with some finality, vertex attrib formats. > > Basically, should drivers be expected to use aux/translate on > pipe_vertex_buffers that have pipe_vertex_elements not supported in > HW? This is a difficult question. Certainly for formats which are not optional in the GL spec, the answer is yes. For new formats that aren't exposed by default in GL, there is more wiggle room. For instance for half-float, it makes sense to not advertise this to applications if it is really a slow path for the driver, so we'd want a query/cap-bit to tell the state-tracker whether to expose it. > If so, then there's probably a bit more code that can be built up to > automate the process. Also it kind of sucks because we can't translate > on bind (the st could remap and change VBO data behind our backs) and > so we must translate on every single draw. Agree that translate on draw is poor. Translate on bind is better, but best of all would be to translate on *first* bind. > Obviously there's ways to > alleviate this, but they all require a tad more typing than I'm going > to commit to right now. > > If not, then can we add a new target/usage/whatever to > is_format_supported, or rename it to is_texture_format_supported and > add is_vertex_format_supported? Let the state tracker worry about this > nonsense. This sounds again like the sort of task that we don't want to do in either all state trackers or in all drivers - ie. something which would be most conveniently handled in an intermediate layer between the two. This is something which has been discussed before, and I'm happy with the idea providing it is something pulled in by the driver and the overall entity continues to expose the existing pipe_screen/pipe_context interfaces to the state-tracker. That said, it's not hugely difficult to get this to work in any driver with access the draw module with basically zero effort. I know you'd prefer to avoid the draw module, but solving this type of problem is one of the reasons it exists. > Either way, I anticipate having to build a function that, given a > pipe_vertex_element and pipe_vertex_buffer, and a list of acceptable > pipe_formats, internally magically modifies things inside so that all > resulting VBOs are safe for HW. This sounds like a useful utility. Keith ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
