On Fri, Aug 13, 2010 at 10:14 PM, Keith Whitwell <kei...@vmware.com> wrote: > On Fri, 2010-08-13 at 07:04 -0700, Chia-I Wu wrote: >> Hi, >> >> There are two primitive transformations in gallium draw module. In >> varray, primitives are "split"ted. When a primitive has more vertices >> than the middle end can handle, varray splits the primitive and calls >> the middle end multiple times. >> >> In vcache, primitives are "decompose"d. More advanced primitives are >> decomposed into one of point, line(_adj), or triangle(_adj). >> Similarly, vcache may call the middle end multiple times to flush its >> internal buffer. In some cases, vcache passes the primitves through >> without decomposing nor splitting, as can be seen in vcache_check_run. >> >> The issue with vcache is that it has to decompose a primitive >> differently depending on the provoking convention, as explained in >> >> http://lists.freedesktop.org/archives/mesa-dev/2010-August/001797.html >> >> It becomes a problem when GS is active. >> >> My proposal is to make vcache split instead of decompose. Because >> varray only splits and vcache has a pass-through path, the rest of the >> workflow already has to support all primitive types. Switching from >> decompose to split does not require a big change to the rest of the >> workflow. >> >> But then vcache will look a lot like varray, only with indexed >> primitive support. It leads me to a new frontend that replaces both >> varray and vcache: vsplit >> >> http://cgit.freedesktop.org/~olv/mesa/log/?h=draw-vsplit >> >> vsplit is based on varray. It uses some code from vcache to support >> indexed primitives. When vcache decomposes, there are flags being set >> to indicate that if the stipple counter should be reset or if some >> edge of a triangle should be omitted in unfilled mode. The segments >> of a splitted primitive have flags for similar purposes too: >> >> DRAW_SPLIT_AFTER More segments to come after this one >> DRAW_SPLIT_BEFORE There are preceding segments >> >> These flags are set by vsplit and the middle ends pass them to the >> other stages. Therefore, the run methods of middle ends are augmented >> to take the flags. >> >> To summarize, vsplit >> >> - fixes GS when (flatshade && flatshade_first) is on >> - never sends more vertices than the middle end claims to handle >> - is faster than vcache: split instead of decompose, no get_elt >> calls >> - no longer uses the higher bits of draw_elts for stipple/edge flags >> >> Suggestions? > > > Hi - I haven't looked at the patches yet, but a couple of questions: > > How does this interact with the draw_pipe_* code - which requires > decomposed primitives? draw_pipe.c decomposes the primitives. It is there before because it has to support varray and vcache_check_run which do not decompose. > How does this cope with indexed rendering where the vertex buffers > themselves are too large (for hardware or some other entity)? Eg. > imagine the hardware could cope with up to 64k vertices, and you have a > drawelements call randomly referencing vertices in range 0..128k ? Vertex fetching happens in the middle end so the range of the indices is not a problem. Though vsplit guarantees that it never calls the middle end with more vertices than the middle end claims to support (as returned by draw_pt_middle_end::prepare). The limit is usually decidied by the size of the buffer for vertex emitting.
-- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev