Hi,
this is referring to the a very reproducable lockup that occurred with
glaxium on r100 hardware. Several months ago I tracked it down to
emission of state changes and introduced a workaround that waits for 3D
idle before state changes. Now I had a new idea about a possible cause
of trouble: th
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=314
--- Additional Comments From [EMAIL PROTECTED] 2004-01-02 21:44 ---
Well, to answer a
I'm trying to build mach64-0-0-6-branch on my sparc. I'm building on Debian
sid/sarge. In the
mesa building I get this...
make[6]: Entering directory `/root/xfree86/xc-current/lib/GL/mesa/src/SPARC'
rm -f xform.i
/usr/bin/cpp -Dlinux -D__sparc__ -D_POSIX_C_SOURCE=199309L
Hi,
I believe I got it right this time. :) I attached three small patches
that re-enabled the vtxfmt paths in the radeon and r200 drivers. One is
for _tnl_Begin to call the driver's NotifyBegin callback again.
Alternatively, if the drivers are supposed to work correctly without
this callback, then
Well well, i just tried the patched version of the CVS tree with ut2003
and it's simply great, textures are just looking fine and the game is
far more playable than it used to be, yet i had to disable TCL to avoid
having purple textures sometimes. It really would be a shame if this
patch wasn't int
On Gwe, 2004-01-02 at 16:11, Michel DÃnzer wrote:
> On Fri, 2004-01-02 at 03:20, Alex Deucher wrote:
> MergedFB seems to be the clearly better overall approach than
> traditional Xinerama to me...
Its simple but its a lot less flexible. I'm not entirely sure the VIA
approach is the entire needed
On Fri, 2004-01-02 at 03:20, Alex Deucher wrote:
>
> This looks like a an interesting approach and perhaps a better one than
> mergedfb. Correct me if I'm wrong but it looks like the code checks to
> see what head should be rendered to and then adjusts the offsets and
> X/Y stuff accordingly.
S
On Gwe, 2004-01-02 at 02:20, Alex Deucher wrote:
> Does the via driver support 3D with dualhead? It seems to. I noticed
> the following code in via_context.c:
In theory it does. I don't know if the 4.3 based one does because VIA
also changed the core Mesa stuff to add things like pbuffer support
On Thu, Jan 01, 2004 at 07:07:34PM +, MichaelM wrote:
> I tried installing the new ati binary drivers, and every game, except Enemy
> Territory hard locks on start-up. I can, however, alt-ctrl-backspace back to
> the console, so it's not the end of the world.
> I initially though it was an is
