Re: [Dri-devel] Parallelizing MESA's pipeline?

[Felix <fx...@gm...>]

On Sat, 30 Nov 2002 19:52:50 +0000
José Fonseca <j_r...@ya...> 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____
  fx...@gm...    >o<__/   \___/   \___/        at the same time!