[Mesa-dev] [PATCH-RFC] draw: Rewrite primitive decomposer
Chia-I Wu
olvaffe at gmail.com
Tue Aug 3 09:56:41 PDT 2010
On Wed, Aug 4, 2010 at 12:03 AM, Zack Rusin <zackr at vmware.com> wrote:
> On Tuesday 03 August 2010 11:41:02 Chia-I Wu wrote:
>> On Tue, Aug 3, 2010 at 9:40 PM, Zack Rusin <zackr at vmware.com> wrote:
>> > I'm not sure if should, if adjacency primitives are set there should
>> > always be a gs and if not we should set a pass-through gs should which
>> > just emits triangles.
>>
>> There is no pass-through GS right now, but it is something I'd like to look
>> into after this change (and some tuning work).
>
> Great.
>
>> It should be required by
>> the non-pipeline path. Besides, as GS may output more vertices than its
>> input, it may be a problem if the number of output vertices exceeds
>> vbuf_render's limit. I'd like to see if they can be solved altogether.
>
> Sounds good.
>
>> I don't think the current behavior is correct for D3D, if I understand the
>> diagram correctly.
>
> It is for data vertices. The question is, as I mentioned in the first email,
> whether the two following adjacency vertices need to be swapped. I had a
> testcase for this stuff but I don't remember if I tested adjacency vertex
> placement or whether that was a typo.
>
>> The difference between D3D and OpenGL seems to be only
>> in the provoking conventions. In the diagram, there are 14 vertices which
>> will generate 5 triangles
>>
>> vertices adjacent verts
>> i=0 0,2,4 1,6,3
> or 1,5,3
> or 1,3,5
>> i=1 2,4,6 0,8,5
> or 5,7,3
> or 5,3,7
I see your point. There are more than one way to interpret the diagram. Now I
am curious if the diagram is all the D3D documents have for triangle strip with
adjacency?
> and so on. If you have a testcase that shows which way it is, great, lets
> change it (aka fix it). Otherwise I'm just not too excited about changing code
> that was working with the (corny) testcases it had for something without any.
Sure. Where can I find the test cases, if they are public?
--
olv at LunarG.com
More information about the mesa-dev
mailing list