[EMAIL PROTECTED] wrote:
I am developing a new DRI driver based on XFree86 4.3.0,Mesa 4.0.4,and redhat9.0.
You might be better off basing your driver on a more recent Mesa tree. Right now, the open-source drivers live in src/mesa/drivers/dri in the Mesa tree, and they will work with older version of XFree86. There have been a lot of new features added and bugs fixed in Mesa since 4.0.4!
Because my hardware can do TCL,I hook my "tcl render" stage into mesa's pipe,and make it as the first stage,just like r200 driver.
In my "run_tcl_render", I don't use mesa's template file t_dd_dmatmp2.h to generate my tcl render table. My code looks like(for vertices,not elements):
for (i = VB->FirstPrimitive ; !(flags & PRIM_LAST) ; i += length) { flags = VB->Primitive[i]; length = VB->PrimitiveLength[i];
if (!length) continue;
if (flags & PRIM_BEGIN) {
start_prim(flags,current_vertex_counter);
}
copy_vertex_data(ctx,inputs,i,length);
if (flags & PRIM_END) { end_prim(flags,current_vertex_counter); } }
But I find PRIM_BEGIN and PRIM_END don't always pairs for a single display list call or a vertex array drawing. Then sometimes I meet with a non-ended primitive,and when I flush these primtives,I will lose some primitives.
That's interesting. Keith or Brian would probably be the best ones to answer that, and they're both away on vacation.
I know r200 works well, but I don't know why my method meets this problem.
I seem to recall there being a bug once in the R200 driver where a GLUT sphere was only partially rendered. I looked through the bug database, but I couldn't find it.
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
