On Sat, 30 Nov 2002 19:52:50 +0000
José Fonseca <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 30, 2002 at 08:04:55PM +0100, Felix Kühling wrote:
[snip]
> >
> > Vertex formats are the real problem. Driver functions are called
> > directly from the GL application and modify the driver state bypassing
> > the pipeline.
>
> Could you please give an example?
I am referring to the GLvertexformat structure which is defined in dd.h.
It contains driver callbacks which are installed directly into a
glapi_table. This happens in xc/xc/extras/Mesa/src/vtxfmt.c. Reading the
comments in vtxfmt.c and dd.h this really seems to be TCL related.
An example is radeon_Materialfv in radeon_vtxfmt.c. A backtrace from
radeon_Materialfv looks like this:
#0 radeon_Materialfv (face=1032, pname=4609, params=0xbffff22c)
at radeon_vtxfmt.c:764
#1 0x404b627c in neutral_Materialfv (face=134605728, pname=134605728,
v=0x805eba0) at ../../../../extras/Mesa/src/vtxfmt_tmp.h:162
#2 0x0804ce29 in draw_stairs_internal (mi=0xbffff388) at stairs.c:318
#3 0x0804d580 in draw_stairs (mi=0xbffff388) at stairs.c:555
#4 0x0804fb19 in xlockmore_screenhack (dpy=0x80664d8, window=48234497,
want_writable_colors=0, want_uniform_colors=0, want_smooth_colors=0,
want_bright_colors=0, event_mask=0, hack_init=0x804d380 <init_stairs>,
hack_draw=0x804d454 <draw_stairs>,
hack_reshape=0x804cf9c <reshape_stairs>, hack_handle_events=0, hack_free=0)
at xlockmore.c:385
#5 0x0804c78e in screenhack (dpy=0x80664d8, window=48234497)
at ../xlockmore.h:154
#6 0x0804e6d0 in main (argc=1, argv=0xbffff7d4) at ./../screenhack.c:638
There is that neutral_* wrapper layer in between. So there may still be
hope ;-)
> > Would it be worth sacrificing for a multi-threaded pipeline on an SMP
> > system? In the radeon driver vtxfmt seems to be only enabled with TCL.
> > But I remember some mails about vertex formats and the mach64 driver.
> > Are vertex formats widely used with non-TCL drivers?
>
> All drivers have a vertex format. One of the last stages of the Mesa
> pipeline on a DRI driver is to build vertex buffers, which are nothing
> more than a big array of vertices using that vertex format. What happens
> is that most drivers use the D3D vertex format. While in newer cards
> that format usually corresponds to the card native vertex format, on
> older cards (such as Mach64, and 3DFX) it doesn't.
>
> In summary, the vertex format it's like a C structure of how the card
> expects to see a vertex when reading the system memory by DMA.
Ok. This seems to be something different from what I described above.
>
> Now, returning to the main issue here, I'm not seeing what state changes
> happen during the vertex buffer construction... besides the vertex
> buffer itself, which would had to be thread specific.
>
> José Fonseca
Felix
__\|/__ ___ ___ ___
__Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____
[EMAIL PROTECTED] >o<__/ \___/ \___/ at the same time!
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
