On 2003.02.02 19:29 Keith Whitwell wrote:
Pawel Salek wrote:
No. Probably the most helpful thing you can do is binary search to
try find the change which introduced your problem. So try a date
half-way between now september, check out that version see if the
problem is there, etc.
I did
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
So i have tryed. Updated to last patch (2186).
It crashes... i tryed with:
1) last snapshot found on dri.sf.net
2) plain XFree86 4.2.0 tree recompiled
but always crashes.
(i have a Rage128)
Alle 13:45, lunedì 3 febbraio 2003, Stefan Lange ha
Attached is the patch with the modifications you suggested.
--Leif
On Mon, 3 Feb 2003, Ian Romanick wrote:
Leif Delgass wrote:
It this looks OK, I will apply it to the branch.
I've poked around with the patch, and it looks good. There are only two
things that I would change. There
Hi
The drm code uses 'struct mtx' as DRM_SPINTYPE on FreeBSD 5.x. The
kernel expects such mutices to be freed after use by calling
mtx_destroy(), which the current code fails to do. Quitting X and
restarting it thus results in this kernel panic:
%%
[...]
panic: mutex vblsig 0xc65fa234 already
On Mon, 2003-02-03 at 18:09, Benjamin Herrenschmidt wrote:
On Mon, 2003-02-03 at 17:05, Michel Dänzer wrote:
On Mon, 2003-02-03 at 17:34, Alan Cox wrote:
On Mon, 2003-02-03 at 15:02, Keith Whitwell wrote:
-#define COMMIT_RING() do { \
-
On Die, 2003-02-04 at 19:06, Michel Dänzer wrote:
After various tests, it looks like all of this is indeed necessary even
with AGP.
Also, I think at least the r128 driver could use the same treatment, but
we probably want to split COMMIT_RING() off ADVANCE_RING() as well for
that, and I'm not
Michel Dänzer wrote:
On Die, 2003-02-04 at 19:06, Michel Dänzer wrote:
After various tests, it looks like all of this is indeed necessary even
with AGP.
Also, I think at least the r128 driver could use the same treatment, but
we probably want to split COMMIT_RING() off ADVANCE_RING() as
On Die, 2003-02-04 at 19:36, Keith Whitwell wrote:
Michel Dänzer wrote:
On Die, 2003-02-04 at 19:06, Michel Dänzer wrote:
After various tests, it looks like all of this is indeed necessary even
with AGP.
Also, I think at least the r128 driver could use the same treatment, but
Alexandr Andreev wrote:
Is there any verification tests for OpenGL (like xsuite for Xlib)?
It looks like this is not a big problem to test the performance but
what about verification? Can such tests exist in principle?
The OpenGL ARB has a test suite called conform, but it is not
publicly
Michel Dänzer wrote:
On Die, 2003-02-04 at 19:36, Keith Whitwell wrote:
Michel Dänzer wrote:
On Die, 2003-02-04 at 19:06, Michel Dänzer wrote:
After various tests, it looks like all of this is indeed necessary even
with AGP.
Also, I think at least the r128 driver could use the same
Arkadi Shishlov wrote:
The DRI tree no longer contains all the X stuff it needs (hasn't for a
long time, actually) to build but instead relies on it to be installed
on the system.
There is a small glitch with current DRI compilation setup.
If ProjectRoot in (otherwise default) host.def is
On Tue, Feb 04, 2003 at 10:44:45AM -0800, Ian Romanick wrote:
| The OpenGL ARB has a test suite called conform, but it is not
| publicly available. The open-source test suite is Glean.
| http://glean.sf.net/. Both glean and conform have fallen a bit behind
| the times. Writing some new
On 4 Feb 2003, Michel Dänzer wrote:
On Die, 2003-02-04 at 19:36, Keith Whitwell wrote:
Michel Dänzer wrote:
On Die, 2003-02-04 at 19:06, Michel Dänzer wrote:
After various tests, it looks like all of this is indeed necessary even
with AGP.
Also, I think at least the
On Die, 2003-02-04 at 20:09, Leif Delgass wrote:
On 4 Feb 2003, Michel Dänzer wrote:
On Die, 2003-02-04 at 19:36, Keith Whitwell wrote:
Michel Dänzer wrote:
On Die, 2003-02-04 at 19:06, Michel Dänzer wrote:
After various tests, it looks like all of this is indeed necessary
On Tue, 2003-02-04 at 10:04, Stefan Farfeleder wrote:
Hi
The drm code uses 'struct mtx' as DRM_SPINTYPE on FreeBSD 5.x. The
kernel expects such mutices to be freed after use by calling
mtx_destroy(), which the current code fails to do. Quitting X and
restarting it thus results in this
I investigated why radeonDestroyContext wasn't being called for many of
the Mesa demos. It turns out that only a few of the demos actually
destroy the window and/or context before exit()-ing on a key press event.
So if a glut app doesn't call glutDestroyWindow() or a glx app doesn't
call
On 2003.02.04 19:06 Michel Dänzer wrote:
And there's even more: newer compilers seem to optimize away some of
the
reads with strict aliasing. I thought I'd steal some code from the
kernel to detect if the compiler supports -fno-strict-aliasing, but it
looks like it just uses that
Currently in bsd-4-0-0-branch we have most of the changes for NetBSD
support. There is just a little left to get all the FreeBSD drivers
compiling on NetBSD, too. Right now I'm getting panics on loading the
modules with NetBSD-current, but I expect we can fix that soon (I'll
have to see if my
On Tue, 2003-02-04 at 21:25, Pawel Salek wrote:
On 2003.02.04 19:06 Michel Dänzer wrote:
And there's even more: newer compilers seem to optimize away some of
the
reads with strict aliasing. I thought I'd steal some code from the
kernel to detect if the compiler supports
Leif Delgass wrote:
I investigated why radeonDestroyContext wasn't being called for many of
the Mesa demos. It turns out that only a few of the demos actually
destroy the window and/or context before exit()-ing on a key press event.
So if a glut app doesn't call glutDestroyWindow() or a glx
Yes, I ran into this too when the DMA buffer is flushed in
radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE
macro in the lock function, so that makes sense. Where is the drawable
destroyed?
That's the one. I haven't looked at it deeply yet (which app did you see
It was with the texobj Mesa demo, which appears to call
glDeleteTextures and then glutDestroyWindow on ESC. I haven't looked at
the implementation of glutDestroyWindow yet.
On Tue, 4 Feb 2003, Keith Whitwell wrote:
Yes, I ran into this too when the DMA buffer is flushed in
Yes, it seems to segfault while trying to deal with the error returned from
the X server. It's correct that there should be an error, but it's not clear
why the segfault occurs...
Keith
Leif Delgass wrote:
It was with the texobj Mesa demo, which appears to call
glDeleteTextures and then
Title: (:**get out today**:)
GET
OUT OF *-DEBT-*
TODAY
FEELING
TRAPED WITH
NO WAY
OUT
WE CAN HELP
YOU
*REDUCE*
*CONSOLIDATE*
On Tue, Jan 28, 2003 at 11:01:53PM -0500, Leif Delgass wrote:
On Wed, 29 Jan 2003, Arkadi Shishlov wrote:
- 'Texture environment modes: GL_BLEND is done in software..' - mean
glTexEnv(GL_BLEND) is software. GL_DECAL is hw accelerated.
GL_MODULATE with GL_LUMINANCE_ALPHA is software.
On Tue, 4 Feb 2003, Keith Whitwell wrote:
Yes, I ran into this too when the DMA buffer is flushed in
radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE
macro in the lock function, so that makes sense. Where is the drawable
destroyed?
That's the one. I
Leif Delgass wrote:
On Tue, 4 Feb 2003, Keith Whitwell wrote:
Yes, I ran into this too when the DMA buffer is flushed in
radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE
macro in the lock function, so that makes sense. Where is the drawable
destroyed?
That's the
On Wed, 5 Feb 2003, Arkadi Shishlov wrote:
On Tue, Jan 28, 2003 at 11:01:53PM -0500, Leif Delgass wrote:
On Wed, 29 Jan 2003, Arkadi Shishlov wrote:
- 'Texture environment modes: GL_BLEND is done in software..' - mean
glTexEnv(GL_BLEND) is software. GL_DECAL is hw accelerated.
28 matches
Mail list logo
