On Thu, 11 Apr 2002, Jens Owen wrote:
K. Petersen wrote:
I have come upon a reproducible lockup on my system when switching from a
console virtual terminal to X. It can be produced as follows:
Begin X
Switch back to a virtual console
Switch back to X
Does this cause the
K. Petersen wrote:
I have come upon a reproducible lockup on my system when switching from a
console virtual terminal to X. It can be produced as follows:
Begin X
Switch back to a virtual console
Switch back to X
Me Too
I'd like to report that I can reproduce these symptoms
Yes I just get the same problem with RADEON m7p mobility think it'S a problem
with wakeup signal.
sergio
On Friday 12 April 2002 09:26, K. Petersen wrote:
On Thu, 11 Apr 2002, Jens Owen wrote:
K. Petersen wrote:
I have come upon a reproducible lockup on my system when switching from
a
At 12 April, 2002 Allen H. Ibara wrote:
I'd like to report that I can reproduce these symptoms on my
760MP system as well.
Thinking a little more about my last message I realize I left out a very
important fact:
Originally I had used the DRI driver with this Radeon card in a
440BX SMP P-II
Yes my screen freezes only if I load DRI module in XF86Config.
I have outcomented DRI modules and then all works perfect,
but whith the module only mouse works screen is freezed.
thx
sergio vergata
On Thursday 11 April 2002 20:47, Jens Owen wrote:
Sergio Vergata wrote:
Hi,
I'm using
On 2002.04.11 01:40 José Fonseca wrote:
...
There is still missing support for PCI operation of an AGP card when
agpgart isn't available - not much really - just a question of
book-keeping so it will be done shortly.
Done.
I'm still not sure if everything is in place for DRI on Mach64
On 2002.04.10 19:40 José Fonseca wrote:
... since the specs give some tolerance it would be nice to run the
conformance tests with different settings in mmx_blend.S, specially the
single multiply w/o rouding ...
I've started to play with glean and I tried to check this myself, but it
José Fonseca wrote:
On 2002.04.10 19:40 José Fonseca wrote:
... since the specs give some tolerance it would be nice to run the
conformance tests with different settings in mmx_blend.S, specially the
single multiply w/o rouding ...
I've started to play with glean and I tried to
On 2002.04.12 14:43 José Fonseca wrote:
On 2002.04.10 19:40 José Fonseca wrote:
... since the specs give some tolerance it would be nice to run the
conformance tests with different settings in mmx_blend.S, specially the
single multiply w/o rouding ...
I've started to play with glean
K. Petersen wrote:
I am building this myself. Unfortunately, I didn't recieve the attatched
host.def file. If you could send it again, I'd be more than happy to
rebuild with it, if it will help in diagnosing this.
My fault, I forgot to send it. Here it is.
To debug the X Server:
On Fri, Apr 12, 2002 at 08:33:17AM -0600, Brian Paul wrote:
Yes, just blendFunc is sufficient. I usually run glean like this:
glean -r res --visuals id==35 -t blendFunc
Where '35' is a typial GLX visual. Otherwise all the visuals are tested -
which is overkill if you're focused on
On Fri, Apr 12, 2002 at 02:43:00PM +0100, José Fonseca wrote:
|
| I've started to play with glean and I tried to check this myself, but it
| seems there is no effect in the results no matter what changes I make in
| mmx_blend.S. ...
The blend test only fails if an error is greater than one
On Fri, Apr 12, 2002 at 05:12:33PM +0100, Michael wrote:
|
| iirc, there's a bug in tblend.cpp, when it does the
| check, it doesn't increment ePix, aPix so some pixels aren't checked.
Yep, that's definitely a bug. Why haven't I heard a bug report before
now? :-)
Fix is checked in.
Allen
On 2002.04.12 18:26 Allen Akin wrote:
On Fri, Apr 12, 2002 at 02:43:00PM +0100, José Fonseca wrote:
|
| I've started to play with glean and I tried to check this myself, but
it
| seems there is no effect in the results no matter what changes I make
in
| mmx_blend.S. ...
The blend test
On Fri, Apr 12, 2002 at 07:01:08PM +0100, José Fonseca wrote:
| ... Although doing (p*a+q*(1-a)) 8 can
| introduce up to 1 LSB error and worst, it doesn't obey to the rule of
| 255*255 = 255 as 255*255/256 = 254. I know that in Mesa's C blending code
| this special
Hi all,
For what it's worth, I was having the exact same problem using X 4.2.0,
drm-kmod, and FreeBSD 4.5 -stable with a Radeon 7500 and Tyan S2460. I also
had lots of hard lockups when OpenGL apps were starting up. If an app did
manage to start successfully, it would run fine indefinietly.
On 2002.04.12 19:20 Allen Akin wrote:
... It might be related to deep color channels, or possibly
to glean tests other than the basic blending tests. ...
That was it. I'm really sorry for all the fuzz, I just remembered I'm
probably the last one on earth using 16bit depth! Of course the
Allen Akin wrote:
On Fri, Apr 12, 2002 at 07:01:08PM +0100, José Fonseca wrote:
| ... Although doing (p*a+q*(1-a)) 8 can
| introduce up to 1 LSB error and worst, it doesn't obey to the rule of
| 255*255 = 255 as 255*255/256 = 254. I know that in Mesa's C blending
On Mon, Apr 08, 2002 at 04:08:44PM -0700, Ian Romanick wrote:
1. dribench002.dm_67 hung on the texthrash.cfg setting. The X server
could be killed, but not restarted. System had to be rebooted. In this
case, the ultramax.cfg setting was not tested.
I am now able to reliably reproduce
Allen Akin wrote:
If the expected value is 255 and the OpenGL implementation yields 254,
that's only one LSB of error, so glean probably won't complain about it.
We could make the test more stringent, but then some reasonable
implementations (especially some hardware implementations)
On Wednesday 20 March 2002 1:56 pm, Jacek Pop?awski wrote:
After I compiled XFree86 CVS with Mesa-4.0.1 - OpenGL slowed down. I
tested it in RTCW, Quake, and my own programs. Of course acceleration is
on, but fps dropped down. So I compiled DRI from CVS, but nothing
changes - OpenGL is still
Brian,
On 2002.04.12 20:14 Brian Paul wrote:
...
I'd like to see Mesa satisfy the 255*255=255 identity. Is it hard to
implement that in the MMX code? If it is, we could let it go for now
and see if anyone complains.
I guess you didn't received my previous email yet. This is already
Jon Leech at SGI notified me that there's a bug in the GL/glext.h file
from March 22 (GL_GLEXT_VERSION=11). This is the version included with
Mesa 4.0.2 and is currently in the DRI tree.
The tokens GL_DOT3_RGB_EXT and GL_DOT3_RGBA_EXT have the wrong values.
They should _not_ have the same
José Fonseca wrote:
On 2002.04.12 20:14 Brian Paul wrote:
...
I'd like to see Mesa satisfy the 255*255=255 identity. Is it hard to
implement that in the MMX code? If it is, we could let it go for now
and see if anyone complains.
I guess you didn't received my previous email yet.
On Fri, Apr 12, 2002 at 01:14:30PM -0600, Brian Paul wrote:
|
| One might expect that the following identities be true for blending terms:
|
| 1.0 * 1.0 == 1.0
| 1.0 * x == x * 1.0 == x
| 0.0 * x == x * 0.0 == 0.0
|
| So for 8-bit channels, in fixed point:
|
| 255 *
On Fri, 12 Apr 2002, Jens Owen wrote:
K. Petersen wrote:
I am building this myself. Unfortunately, I didn't recieve the attatched
host.def file. If you could send it again, I'd be more than happy to
rebuild with it, if it will help in diagnosing this.
My fault, I forgot to send
26 matches
Mail list logo
