Re: [Dri-devel] voodoo5500 & dri/gl bug?

[<ra...@ra...>]

On 28 Nov, Brian Paul scribbled:
-> ra...@ra... wrote:
->> 
->> I'm just trying out the latest CVS (as of last friday) of rDRI on a
->> voodoo5500 board
-> 
-> The trunk or a branch?

trunk (whatever i get when I cvs -z3 co xc)

->> - first I'm asking why dithering isn't enabled?
-> 
-> I just checked the trunk and it's dithering for me.  On the tdfx-3-0
-> branch it was also dithering, but trying to disable dither wasn't
-> working.  I've fixed that.

hmm - very odd - my code exlicitly enables dithering and that works on
nvidia and software mesa.... hmmmm odd - voodoo 5500 - no dithering..
there isnt some special compile flags or host.def options or XF86Config
options?

->> My
->> application explicitly enables dithering in GL but the output does not
->> dither in 16bpp - it's rather ugly :) (and a bit slow - my own software
->> renderign gets 16 frames per second in one of my tests and hardware GL
->> gets only 21 frames per second - and the software also does dithering) -
->> any ideas on the state of the acceleration as far as speed goes?
-> 
-> Dithering is completely done in hardware.
-> 
-> 
->> I do
->> use GL_BLEND (as in for alpha blending) and according to the DRI page it
->> falls back to software... is this still correct?
->> I do:
->>         glEnable(GL_BLEND);
->>         glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
->> 
->> does this imply falling back to software?
-> 
-> No.  Voodoo3 doesn't support a few of the lesser-used blend modes.
-> I haven't documented which ones at this time.  I will.

ok - so its some of the mroe exotic blend modes that aren't accelerated.
good :) I don't use them :)

->> otherwise I don't use any of the "list" of software fallbacks.
->> 
->> I have managed to get interesting/wierd artifacts to happen with text
->> rending if i have both 3D and 2D drawign happening at once - textures
->> get half-cut off and shifted to the left (anyone seen this?)
-> 
-> What do you mean by "at once"?

my program is printf()'ing to the terminal as it turns. the terminal
program si rendering text/scrolling - if a lot fo text is being printed
out (at least a line or 3 per frame) i get strange partial-texture
shifts. printfs off and it's fine :)

-> I have seen a problem with cut-off textures in the tdfx-3-0 branch
-> but haven't investigated yet.

hmm might be the same one - try adding pritnf's around in yoru code and
print stuff out lots... might help :)

->> also I got dri to segv... :) oddly nvidia and mesa also segv at the same
->> spot. It could be my code doing somehtng wrong - i've looked over it but
->> either way making it segv doesn't bode good :) especially considering
->> where its segv'ing :) I'm not sure why it segv's...  i've been checkign
->> my code over thouroughly and can't figure it out.
->> 
->> see as follows:
->> 
->> (gdb) bt
->> #0  XMesaUpdateState (fxMesa=0x40261c08) at tdfx_xmesa.c:429
->> #1  0x4066054f in XMesaSwapBuffers (driDrawPriv=0x8392f28) at tdfx_xmesa.c:267
->> #2  0x405669a2 in driMesaSwapBuffers (dpy=0x80665c0, private=0x8392f28)
->>     at dri_mesa.c:489
->> #3  0x40116262 in glXSwapBuffers (dpy=0x80665c0, drawable=29360351)
->>     at glxcmds.c:557
->> #4  0x805895d in evas_render (e=0x817c858) at evas_render.c:907
->> #5  0x804f27b in handle_events () at evas_test.c:1509
->> #6  0x40165a2c in __libc_start_main (main=0x804f980 <main>, argc=1,
->>     ubp_av=0xbffff634, init=0x804a72c <_init>, fini=0x80619ec <_fini>,
->>     rtld_fini=0x4000d3c8 <_dl_fini>, stack_end=0xbffff62c)
->>     at ../sysdeps/generic/libc-start.c:111
->> (gdb) frame 0
->> #0  XMesaUpdateState (fxMesa=0x40261c08) at tdfx_xmesa.c:429
->> 429    __DRIdrawablePrivate *dPriv = cPriv->driDrawablePriv;
-> 
-> 
-> Hmmm, I've never seen that.
-> 
-> Jens sent me one of your test programs to try out but I haven't
-> gotten to it yet.

i'd suggest using the code form cvs - it's a bit more up-to-date. I can
make a tarball for you if you want?

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    ra...@ra...     ra...@va...
                                    ra...@en... ra...@li...
				    ra...@zi...