David Dawes dixit:
Another useful data point might be a delay loop in place of the usleep().
I was going to try that today, replacing the call usleep in the .s
file with a simple delay loop, but checked first if it still failed
without, and it worked without the usleep workaround.
What did I
On Tue, Apr 26, 2005 at 02:19:33PM +, Thorsten Glaser wrote:
David Dawes dixit:
Another useful data point might be a delay loop in place of the usleep().
I was going to try that today, replacing the call usleep in the .s
file with a simple delay loop, but checked first if it still failed
David Dawes dixit:
Does replacing the fprintf with sleep(1) make a difference?
Even with usleep(1), glxgears still works. I've committed that
as a temporary workaround now, till we discover the real problem.
//mirabile
--
Hi, does anyone sell openbsd stickers by themselves and not packaged
On Fri, Apr 22, 2005 at 08:30:55PM +, Thorsten Glaser wrote:
David Dawes dixit:
Does replacing the fprintf with sleep(1) make a difference?
Even with usleep(1), glxgears still works. I've committed that
as a temporary workaround now, till we discover the real problem.
This points to an
David Dawes dixit:
I still wonder if there is an issue related to libpthread.
Also possible. And we don't have the get*_r() functions (yet).
Does replacing the fprintf with sleep(1) make a difference?
I will try that ASAP.
See my other mail - removing just the call insn from the .s
does make
David Dawes dixit:
Does replacing the fprintf with sleep(1) make a difference?
sleep(1); is enough and even usleep(1000); but it makes a huge
USABILITY difference - while all the printfs were merely disturbing,
I now experience real lag even when just starting up an xterm.
Still 115.200 fps, as
On Sat, Apr 16, 2005 at 10:46:46PM +, Thorsten Glaser wrote:
This one goes deep into i386 interna...
I still wonder if there is an issue related to libpthread.
Dixi:
Looks like a compiler bug to me.
Okay, it doesn't.
I have generated two assembly files, x1 and x2, to be the
output of the
David Dawes dixit:
Try editing xc/lib/Xtrans/Xtransint.h and changing the definition of
XTRANSDEBUG to 5, rebuilding libX11, and running glxgears against that.
glxgears weirdly enough works now. I'll rebuild without XTRANSDEBUG
and look if it still works... if so, strange.
This will enable more
Dixi:
David Dawes dixit:
Try editing xc/lib/Xtrans/Xtransint.h and changing the definition of
XTRANSDEBUG to 5, rebuilding libX11, and running glxgears against that.
glxgears weirdly enough works now. I'll rebuild without XTRANSDEBUG
and look if it still works... if so, strange.
Only
Dixi:
XTRANSDEBUG=2: works
XTRANSDEBUG=1: does not work
It gets worse.
Compiling with XTRANSDEBUG=1, if I change in xc/lib/xtrans/Xtrans.c
either line 427:
|static XtransConnInfo
|TRANS(Open) (int type, char *address)
|
|{
|char*protocol = NULL, *host = NULL, *port = NULL;
This one goes deep into i386 interna...
Dixi:
Looks like a compiler bug to me.
Okay, it doesn't.
I have generated two assembly files, x1 and x2, to be the
output of the normal compiler command for xc/lib/X11/x11trans.c
with the -S option added.
The difference is that, before compiling x2, I
David Dawes dixit:
Try editing xc/lib/Xtrans/Xtransint.h and changing the definition of
XTRANSDEBUG to 5, rebuilding libX11, and running glxgears against that.
This will enable more of the xtrans messages and may help narrow down
the failure point.
I will do so soonish, got to work for my dayjob
On Wed, Mar 30, 2005 at 05:35:17PM +, Thorsten Glaser wrote:
David Dawes dixit:
Can you try running glxgears with ktrace or truss (or something like that),
and see how that compares with apps that work OK?
Sure.
Here's the ktrace and systrace -A output for glxgears (does not work
natively,
13 matches
Mail list logo
