On Fri, Aug 13, 2010 at 11:09 PM, Chia-I Wu <olva...@gmail.com> wrote: > On Fri, Aug 13, 2010 at 10:51 PM, Keith Whitwell <kei...@vmware.com> wrote: >> On Fri, 2010-08-13 at 07:46 -0700, Chia-I Wu wrote: >>> 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. >> >> OK. >> >>> > 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. >> >> I guess I'm wondering how it does this. If the middle end says it >> supports 64k vertices, and the vertex element looks like >> >> [0, 128k, 64k, 32k, 96k, 16k, 1, ... ] >> >> what gets sent? (Sorry, I still haven't looked at the code, you could >> well have addressed this). > I see. The frontend would set > > fetch_elts = [0, 128k, 64k, 32k, 96k, 16k, 1, ... ] > draw_elts = [0, 1, 2, 3, 4, 5, 6, ...] > > fetch_elts is processed by the middle end and it will fetch the given > vertices. draw_elts will be passed to draw_emit or the pipeline. It > is the new index buffer, which indexes into the fetched vertices. > > It is actual the same as vcache. So when fetch_elts is Should be: So when the index buffer looks like > [0, 128k, 64k, 64k, 128k, 16k, ...],
fetch_elts would be set to [0, 128k, 64k, 16k, ...] and > draw_elts would be set to > > [0, 1, 2, 2, 1, 3, ...] > > The number of elements to fetch (and shade) is minimized. > > -- > o...@lunarg.com > -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
