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.
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
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.
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 softwar
Title: (:**get out today**:)
GET
OUT OF *-DEBT-*
TODAY
FEELING
TRAPED WITH
NO WAY
OUT
WE CAN HELP
YOU
*REDUCE*
*CONSOLIDATE*
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 glutD
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
> > radeonDestr
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 th
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 app
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 -fno-
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 cha
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 unconditionally
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 glXDest
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 thi
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 t
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.
> > >
> > >
> > >
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 gle
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
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 trea
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 av
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
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 well
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
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 {
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 i
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. T
-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 scri
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 d
28 matches
Mail list logo
