Michael wrote:
>
> On Sun, Mar 10, 2002 at 04:35:31PM +0000, Keith Whitwell wrote:
> > What did you change exactly?
>
> Originally _ae_loopback_array_element called glColor4ub passing it 1 param, I
>changed that to
> call glColor4ubv (api_arrayelt.c). So original code took random values for colours
>ergo
> red snow (there is no codegen for non PKCOLOR 4ub case it just does return 0,
> so it always used the generic stuff, albeit afaict incorrectly?).
Yes, it should never have been in the 4ub path. The _ae_loopback change was
definitely correct.
> Once that was changed CHOOSE_COLOR calls radeon_makeX86Color4ubv, the
> non PKCOLOR case, which (unless there was some deep magic I missed?)
> was written like makeX86Color4ub, taking params off the stack @ 4(%esp),
> 8(%esp) etc, rather than ubv.
Are you sure? It loads *v into %ebx, then pulls it apart to %al, %cl
0x8b, 0x5c, 0x24, 0x08, /* mov 0x8(%esp,1), %ebx */
0x8b, 0x1b, /* mov (%ebx), %ebx */
0x88, 0xd8, /* mov %bl, %al */
0x88, 0xf9, /* mov %bh, %cl */
It does this twice...
> But, that aside, in CHOOSE_COLOR, in the generic case where there is no
> CODEGEN function, it checks FPALPHA (which isn't true) so it wouldn't
> call 4ubv_4f (and the semantics of makeX86Color4ubv when PKCOLOR is
> false match this 4ub_4f case).
>
> Without a codegen 4ubv function, CHOOSE_COLOR would check FPCOLOR (true)
> and conditionally call copy_to_current, _mesa_install_exec_vtxfmt and
> finally the Color4ubv_3f in radeon_vtxfmt_c.c Obviously the codegen stuff
> doesn't do any of this additional stuff.
Good point - these extra steps are skipped in the "cached codegen" case. But
they really need to be done...
> I'm assuming here, that it should check FPALPHA and return 0 if
> it's false? (or have the processing for the 3f cases?)
>
> Am I completely hatstand?
No, it sounds like you've spotted a bunch of good problems...
Keith
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
