Denis Oliver Kropp wrote:
Quoting Keith Whitwell ([EMAIL PROTECTED]):
So it's now fairly easy to build either a regular DRI driver, or an
fbdev/miniglx driver for the classic radeon on this branch.
Check out the branch, and look in Mesa/Makefile.include for configuration
options. People
Pawel Salek wrote:
Hi,
I reported some time ago (Sat, 1 Feb 2003 22:38:44 +0100, message-id:
[EMAIL PROTECTED]) that return to Castle Wolfenstein
stutters with radeon 8500. The problem was traced to large memory usage
by the game. Back then, I did not know whether it was a problem with the
Philip Brown wrote:
If I were to spend the time to put together some portability patches
[for the kernel layer], would someone with cvs access volunteer interest to
review and put them in? I can potentially see a bunch of little ones
coming up, so rather than post every single one individually to
Nick Kurshev wrote:
Hello!
I've met this problem (see attach) a long ago but it seems
that nobody fixed that :(
This problem happens not only with this game but with quake3 too!
It looks like every odd frame contains these black squares but every
even frame is free from them that causes image
Philip Brown wrote:
On Sun, Mar 02, 2003 at 11:46:52AM +, Keith Whitwell wrote:
Philip Brown wrote:
For example, I'd like to submit a patch set to fix the issue where
there is _DRM_LOCK_IS_HELD() calls all over the place, but there really is
only one syntax for it:
_DRM_LOCK_IS_HELD(dev
Alan Cox wrote:
On Fri, 2003-02-28 at 00:04, Paul J.Y. Lahaie wrote:
There are areas where X11 doesn't fit in well. (Feel free to correct
me) but R300 and GFX level cards support 128bpp (32bpp floating point).
The X protocol has no way to display to this kind of device. Which
means that fpu
Allen Akin wrote:
On Fri, Feb 28, 2003 at 03:04:08PM +, Ian Molton wrote:
| On Thu, 27 Feb 2003 18:17:33 -0800
| Allen Akin [EMAIL PROTECTED] wrote:
|
|
| Then there are the arguments for deeper color channels based on the
| need for higher-precision intermediate results -- for
Ian Molton wrote:
On Sat, 1 Mar 2003 15:05:37 -0500 (EST)
Mike A. Harris [EMAIL PROTECTED] wrote:
Look at the
Intel i8x0 driver for example. The Intel specs are publically
available, and Intel funds development of the driver. The
hardware is readily available too. Yet there is not any major
Arkadi Shishlov wrote:
On Fri, Feb 28, 2003 at 05:33:29PM -0500, Daniel Vogel wrote:
Fragmention still isn't good, which brings me back to my original question
whether folks are talking to NVIDIA why they aren't using the DRI framework.
Probably because of theirs UDA? I suspect it is easear to
Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
Daniel Vogel wrote:
To clarify: I meant what has to be done to make
DRI (direct rendering
*infrastructure*) attractive for IHVs. I didn't
mean to imply what has to be
done to get NVIDIA or ATI to release open source
drivers and
Jon Smirl wrote:
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Interesting you mention it. This is what Brian
I've done in the Mesa
embedded branch -- layered the radeon dri driver on
top of fbdev. I can also
build regular DRI drivers from a minimal tree sane
set of makefiles.
Can I run
Jon Smirl wrote:
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Can I run standalone OpenGL on a Radeon with this?
Yes. Note that there is some hand tweaking of
makefiles to achieve a full
opengl -- we're targeting an embedded subset in the
standard build.
I pulled the embedded
Antonino Daplas wrote:
On Wed, 2003-02-26 at 22:26, Alan Cox wrote:
I have a reproducable kernel panic with different 2.4.x kernels.
I'm using XFree86-4.2.0-8 with a i810 onboard chipset. Sometimes
when I log off X the kernel panics. This can be reproduced by
loging in on a VC as root and
Charl P. Botha wrote:
On Mon, Feb 24, 2003 at 11:41:01AM -0700, Keith Whitwell wrote:
Charl P. Botha wrote:
Keith, is this related to the problems I reported a day or two back with
my/your modified glthreads.c example? I.e., will it also fix the crashes
when deleting a single glxcontext
Klaus Niederkrueger wrote:
Hi,
Sorry that I don't have a better understanding of how DRI works. Maybe my
idea is completely stupid, but I will try anyway:
I wonder, why the DRI-module linked into XFree depends on the hardware
used. Wouldn't it be possible to make only the kernel-module being
Charl P. Botha wrote:
On Mon, Feb 24, 2003 at 03:06:24PM +, Alan Hourihane wrote:
On Sun, Feb 23, 2003 at 12:59:20PM -0700, Keith Whitwell wrote:
OK, here's a patch, first attempt at doing this. It's not ready to commit
yet, unless we start a branch for this...
Things actually work pretty
Michel Dänzer wrote:
On Son, 2003-02-09 at 23:40, Keith Whitwell wrote:
Felix Kühling wrote:
On Sun, 09 Feb 2003 09:53:55 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
diff -u -r1.1.2.7 radeon_state.c
--- radeon_state.c 7 Feb 2003 20:22:16 - 1.1.2.7
+++ radeon_state.c 9 Feb
Keith Whitwell wrote:
Michel Dänzer wrote:
On Son, 2003-02-09 at 23:40, Keith Whitwell wrote:
Felix Kühling wrote:
On Sun, 09 Feb 2003 09:53:55 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
diff -u -r1.1.2.7 radeon_state.c
--- radeon_state.c7 Feb 2003 20:22:16 -1.1.2.7
Linus Torvalds wrote:
On Sat, 22 Feb 2003, Keith Whitwell wrote:
What about processes that *don't* do a close - that just use an fd and exit.
The exit does a close, and you'll see a flush() from the dying process
(and a release() if that was the last user).
In the threaded demo I'm looking
3. A good old segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1026 (LWP 712)]
0x404dd042 in _swrast_InvalidateState ()
from /usr/X11R6/lib/modules/dri/radeon_dri.so
(gdb) bt
#0 0x404dd042 in _swrast_InvalidateState ()
from
Running into a problem when killing glthreads with Ctrl-C. Normally this
would invoke the release() method and clean up buffers, locks etc.
Unfortunately this doesn't work so well with threads - the release method is
being called only once despite the 3 processes (threads) that are being
Alan Cox wrote:
On Sat, 2003-02-22 at 22:38, Keith Whitwell wrote:
Running into a problem when killing glthreads with Ctrl-C. Normally this
would invoke the release() method and clean up buffers, locks etc.
Unfortunately this doesn't work so well with threads - the release method is
being
Alan Cox wrote:
On Sat, 2003-02-22 at 22:38, Keith Whitwell wrote:
Running into a problem when killing glthreads with Ctrl-C. Normally this
would invoke the release() method and clean up buffers, locks etc.
Unfortunately this doesn't work so well with threads - the release method is
being
Linus Torvalds wrote:
On Sat, 22 Feb 2003, Keith Whitwell wrote:
So, was the gist of the fix to simply relocate the current release() stuff to
flush()? I'm going to go read the code now.
Yes, either that, or you need to not care about pid's.
release() is not necessarily called _at_all_
I'd suggest associating the struct file_struct * with the GL context,
and nothing else.
At that point you would always get the right answer by just knowing that
when the release() happens, the GL context is gone.
This is probably the only sensible solution, I think.
Keith
Philip Brown wrote:
I've been reading
http://dri.sourceforge.net/doc/hardware_locking_low_level.html
and the code, obviously... so I've seen references to the lightweight
lock. ButI have yet to figure out why there is one.
The url document mentions that one supposedly exists, and that
the
Michel Dänzer wrote:
On Fre, 2003-02-14 at 16:03, Alan Cox wrote:
On Fri, 2003-02-14 at 13:37, Michel Dänzer wrote:
That DRM is pretty old, is the 3D driver from the same date? Someone
said on an XFree86 list that the flightgear lockups went away for him
with XFree86 4.3.0rc1.
My lockup
Chris Ison wrote:
do you know the packet sizes for R200_EMIT_PP_CUBIC_FACES_* and
R200_EMIT_PP_CUBIC_OFFSET_*
Look in the drm driver (radeon_state.c) -- there is a table in there that
mimics the one in radeon_sanity.c
Keith
---
This
So, in summary, I have no idea what is going on. X internals are a bit
over my head at this point. This seems to have been triggered by a
DRI-related hardware lock, but please also note that the above (current
state of things) happens with 'radeon' even when DRI is not being
loaded!
Does
Felix Kühling wrote:
Hi,
I tracked down a problem that caused the rpm and speed meters in Torcs
to be invisible if TCL was disabled. I think it boils down to a missing
radeonEmitState. It is possible that radeonEmitState is not called after
ValidateState has updated the state atoms and before
Ian Romanick wrote:
Hello all!
Attached is the initial rough-draft of the design document for the next
generation memory manager. It is currently plain-text. When I polled
people on #dri-devel the consensus was that plain-text would be the most
useful format. I suspect at some point I may
Felix Kühling wrote:
On Sun, 09 Feb 2003 07:32:38 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
I tracked down a problem that caused the rpm and speed meters in Torcs
to be invisible if TCL was disabled. I think it boils down to a missing
radeonEmitState
Felix Kühling wrote:
On Sun, 09 Feb 2003 09:53:55 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
On Sun, 09 Feb 2003 07:32:38 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
I tracked down a problem that caused the rpm and speed meters
Felix Kühling wrote:
On Sun, 9 Feb 2003 18:43:16 +0100
Felix Kühling [EMAIL PROTECTED] wrote:
On Sun, 09 Feb 2003 09:53:55 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
[snip]
Anyway, I think I found the *real* problem, this time :). Indeed
radeonEmitVbufPrim
Andreas Stenglein wrote:
Hello!
yes, this patch helps quake3 in sw-tcl mode (no more flickering of
textures).
It looks even better than hw-tcl, because hw-tcl
shows that other flickering when looking to the
ground and turning around a bit.
But unfortunately it doesnt solve the issue with
the
Chris Ison wrote:
ok, I have a problem where when I run QuakeForge, mesa kills itself of
and invalist command packet (63). this turns out to be associated with
cube maps, and the sanity checks have cubic registers missing from the
list.
Also Quakeforge doesn't do cube maps unles you explicitly
Michel Dänzer wrote:
On Sam, 2003-02-08 at 18:56, Michel Dänzer wrote:
On Sam, 2003-02-08 at 18:45, Charl P. Botha wrote:
On Sat, Feb 08, 2003 at 06:24:28PM +0100, Felix Kühling wrote:
Found it. DRIVER_RELEASE in radeon.h has to call radeon_reclaim_buffers
as the drm_drv.h template seems to
Ian Romanick wrote:
Ian Romanick wrote:
CVSROOT:/cvsroot/dri
Module name:xc
Repository:xc/xc/lib/GL/mesa/src/drv/r200/
Changes by:idr@sc8-pr-cvs1.03/02/07 12:07:04
Log message:
Fix DOT3 texture combine env.
Modified files:
xc/xc/lib/GL/mesa/src/drv/r200/:
Ian Romanick wrote:
Keith Whitwell wrote:
Felix Kühling wrote:
On Wed, 05 Feb 2003 16:25:27 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
I attached a patch that fixes the problem. It introduces a new
TCL_FALLBACK if there are too many vertices to fit into one DMA
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar circumstances,
but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as
a magic stamp value never gets updated because the X protocol message
never succeeds -- but it doesn't
Leif Delgass wrote:
On Wed, 5 Feb 2003, Keith Whitwell wrote:
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar circumstances,
but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as
a magic stamp value never gets updated
Steven Paul Lilly wrote:
Will all this stuff about context teardown fix the problem I'm having
with my glut based program that always gives me
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 144 (XFree86-DRI)
Minor opcode
Felix Kühling wrote:
I attached a patch that fixes the problem. It introduces a new
TCL_FALLBACK if there are too many vertices to fit into one DMA buffer.
Looks kind of hackish to me. Does anyone have a better idea? Comments?
Mesa should respect ctx-Const.MaxArrayVertices, which should be
Adam K Kirchhoff wrote:
Hello all,
So there's this really great game from Garagegames called
MarbleBlast, which they've ported to Linux. Game requires TNT2 and higher
or Radeon 8500 and higher. It plays just fine on my Radeon 8500 using the
ATI FireGL drivers, but segfaults when trying to use
Felix Kühling wrote:
On Wed, 05 Feb 2003 16:25:27 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
I attached a patch that fixes the problem. It introduces a new
TCL_FALLBACK if there are too many vertices to fit into one DMA buffer.
Looks kind of hackish to me. Does anyone
Leif Delgass wrote:
Hurrah! ... this fixes the vertex data corruption in the UT2003 opening
screen. There's still vertex problems in game (though not quite as much).
The remaining problems may be because of cube mapping (I'm testing on
R100).
Hmm. Do you have an r200? I wonder whats up
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
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
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
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
radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE
macro in the lock function, so
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
-#define COMMIT_RING() do { \
- RADEON_WRITE( RADEON_CP_RB_WPTR, dev_priv-ring.tail ); \
+#define COMMIT_RING() do { \
+ /* read from PCI bus to ensure correct posting */ \
+ RADEON_READ( RADEON_CP_RB_WPTR ); \
+
Michel Dänzer wrote:
On Mon, 2003-02-03 at 15:53, Chris Ison wrote:
please find attached a complete patch that allows pci Radeon cards to
work with DRI. It was created against the DRI CVS xc branch/trunk.
Thanks, I'll commit this unless someone else comes up with a better
solution.
Well,
Michel Dänzer wrote:
On Mon, 2003-02-03 at 22:31, Chris Ison wrote:
Yeah, it works,
Great!
just a little weary of it cause remembering without the read it won't work,
but it still appears to work with the read at the end.
Well, I think Ben has given the best explanation of what's going
Pawel Salek wrote:
On 2003.02.02 04:24 Keith Whitwell wrote:
Steps to Reproduce:
1. Run RTCW with normal quality settings. Try opening a door (the
tram station, third level, is particularly good test case). The
computer can hang for a second, and the sound will stutter like on
damaged CD
Steps to Reproduce:
1. Run RTCW with normal quality settings. Try opening a door (the tram
station, third level, is particularly good test case). The computer can
hang for a second, and the sound will stutter like on damaged CD.
Actual Results: The computer can hang for a second, and the
Ian Romanick wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/lib/GL/mesa/src/drv/mga/
Changes by: idr@sc8-pr-cvs1. 03/01/27 15:47:14
Log message:
Major re-write of the texture upload code. Added support to G400 for
2048x2048 textures and use of all 12 mipmap levels.
Cool --
Ian Romanick wrote:
Keith Whitwell wrote:
Ian Romanick wrote:
CVSROOT:/cvsroot/dri
Module name:xc
Repository:xc/xc/lib/GL/mesa/src/drv/mga/
Changes by:idr@sc8-pr-cvs1.03/01/27 15:47:14
Log message:
Major re-write of the texture upload code. Added support to G400
Leif Delgass wrote:
On Wed, 22 Jan 2003, Daniel Vogel wrote:
ftp://ftp.retinalburn.net/pub/ut2k3/Shot0.bmp
ftp://ftp.retinalburn.net/pub/ut2k3/Shot1.bmp
How does rmode 7 (untextured, lighting only) look like?
rmode 5 == regular
rmode 6 == just textures
Ian Romanick wrote:
There is supposed to be an IRC meeting today at 2100UTC (1300PST,
1600EST). Typically, the I tell people that the meeting is in
#dri-devel on irc.openprojects.net.
Sometime ago openprojects.net went away, but the address still pointed
somewhere valid. As of this morning
Basically something we thought was constant is getting clobbered on mode
changes. This is a bit heavy handed, but does the trick.
It's neither of the two likely candidates in this packet of state. This
change will just emit the whole packet on any 'lost_context' event.
Keith
Index:
Michel Dänzer wrote:
[ please move this thread to the appropriate development list(s) ]
On Fre, 2003-01-17 at 16:03, Alexis Vartanian wrote:
problem : GL application hangs at starting (quake3 and a threaded)
when running a multithread application, any call to _XRead should
be done after a
José Fonseca wrote:
I've been following this thread very closely because I just order a VIA
Mini-ITX motherboard (see
http://www.viavpsd.com/products/epia_mini_itx_spec.jsp ) for making a
MP3/VCD/DVD TvOut media player + router + ...
Eventually I also want to turn it into a Linux video game
Ian Romanick wrote:
Keith Whitwell wrote:
This just started happening. Anyone else seeing the same thing?
[keithw@rover xc-trunk]$ cvs update
ssh_exchange_identification: Connection closed by remote host
cvs [update aborted]: end of file from server (consult above messages
if any)
I have
What clobbering is allowed can be inferred from the GLX specification.
If you overlook DBE for a second, I believe we are meeting the
requirements of the spec, so I wouldn't say we're broken.
This isn't true.
Consider when a diagonal line is drawn by Xlib across the active GL window,
with
Carlos O'Donell wrote:
dri,
Playing with an ATI 9700 on an AGP slot in an Alpha ES45 and trying to
get the indirect rendering support to work, I get the following, after
decoding:
(NI) RADEON(0): int 0x10(AH=0x0E) -- Write Character in Teletype Mode
(NI) RADEON(0): AL=0x70, BH=0x00, BL=0x07
...
Michel Dänzer wrote:
This patch avoids a segfault when running tuxracer with SW TCL, but I
suspect it's just a workaround, I hope someone more familiar with Mesa
sees and fixes the real problem. This didn't happen a while ago, it's
probably related to Ian's secondary color fixes?
What you want
Mark wrote:
So i've been sitting on the sidelines waiting for a fix for the rendering bugs
in the R200 driver, but it doesn't seem like anyone is tackling it. I'm
running a Radeon Mobility 9000. RTCW is playable but with significant
artifacts, half life has same. UT2003 looks totally insane,
magenta wrote:
On Sat, Dec 21, 2002 at 08:20:59AM -0500, Adam K Kirchhoff wrote:
Hey folks,
Wasn't sure if you guys were aware of this, but there's a new
patch out for ut2k that removes the requirement for an OpenGL driver which
supports S3TC.
I applied the patch and attempted to play the
Dave Airlie wrote:
Removing the
Option XvMCSurfaces 6
from my XF86Config file seems to make everyone a bit happier again...
will do some more testing tomorrow to make sure this is what was causing
it ..
and I meant glxgears from RH7.3.. hands were ahead of brain yesterday..
Well for me this
Dave Airlie wrote:
Which application is this?
my own internal application (it doesn't do much just some quad texture
mapping (About 20 quads on screen).
Would it be possible to see the source? If not, can you make a little demo
that does something similar and has the same problems that
Michel Dänzer wrote:
On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote:
The 830 page flipping code is turned off for some good reasons:
- I haven't seen it work without really visible corruption on the flip -
typically flashing and blank areas
Presumably it uses the mi shadow module
Michel Dänzer wrote:
On Mon, 2002-12-16 at 13:34, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote:
The 830 page flipping code is turned off for some good reasons:
- I haven't seen it work without really visible corruption on the flip
Michel Dänzer wrote:
On Mon, 2002-12-16 at 13:47, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mon, 2002-12-16 at 13:34, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote:
The 830 page flipping code is turned off for some good reasons
Michel Dänzer wrote:
On Mon, 2002-12-16 at 14:04, Keith Whitwell wrote:
I think maybe I decided copying was ok as long as:
- you rig XAA (or whatever) to always draw into the current front buffer.
- you use cliprects to exclude the 3d window so that the backbuffer never
gets scribbled
Dave Airlie wrote:
Just to give more information..
the first time I run my application it runs fine. I exit it and X reloads
and then I start it again .. the second time the app claims Indirect
rendering, and then X dumps out the below and crashes out..
The app works with the latest i810.o +
Sven Luther wrote:
On Thu, Dec 12, 2002 at 07:14:45PM -0800, Philip Brown wrote:
On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote:
...
It takes two to tango so its not just what I need its also what do they
need.
What I would like to see would be:
A single definitive source for the
Felix Kühling wrote:
On Thu, 12 Dec 2002 22:26:23 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
while I was messing around with my query programme I found this: if I
specify an invalid screen as argument to XF86DRIGetClientDriverName the
Xserver segfaults. I had
Ian Romanick wrote:
On Fri, Dec 13, 2002 at 03:58:12AM +0100, Michel Dänzer wrote:
On Don, 2002-12-12 at 21:55, dax wood wrote:
(WW) R128(0): Can't determine panel dimensions, and none
specified.
Disabling programming of FP registers.
Alan Cox wrote:
On Wed, 2002-12-11 at 22:11, D. Hageman wrote:
Alan,
What would you like to see be implemented to help get the job done. In
other words, what do you need from the DRI team?
It takes two to tango so its not just what I need its also what do they
need.
What I would like to
Alan Hourihane wrote:
On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote:
On Wed, 2002-12-11 at 22:11, D. Hageman wrote:
Alan,
What would you like to see be implemented to help get the job done. In
other words, what do you need from the DRI team?
It takes two to tango so its not
Sorry, but I think this is much to slow/few.
Look at the current kernel (drm) source.
There are daily changes/fixes and we should use the latest XFree (DRI)
DRM? Currently I'm under the impression that nobody (only a few) of the
XFree/DRI developers pay attention about SMP and/or latency where
Dave Jones wrote:
On Thu, Dec 12, 2002 at 02:09:18PM +, Alan Hourihane wrote:
Some apps only run smooth with 2.5.49+ kernels due to Linus latest work.
Nothing of it in XFree or DRI, yet.
Linus should submit it here for inclusion - simple. I doubt any of us
are tracking 2.5.x that
Brian Paul wrote:
Michel Dänzer wrote:
On Don, 2002-12-12 at 15:29, Martin Spott wrote:
XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time
constraints and stability concerns. [...]
I didn't notice the Mesa-5.x-based stuff is less stable than the
stuff you
chose for
Dave Jones wrote:
On Thu, Dec 12, 2002 at 12:49:37PM +, Keith Whitwell wrote:
It seems that changes get inserted to the drm code in the kernel from time to
time. Is the expectation that we monitor the kernel drm and periodically
merge (or otherwise) those random or worthy changes
Felix Kühling wrote:
Hi,
while I was messing around with my query programme I found this: if I
specify an invalid screen as argument to XF86DRIGetClientDriverName the
Xserver segfaults. I had a quick look at xc/xc/Xserver/GL/dri/xf86dri.c.
stuff-screen is used as array index without checking.
Dave Jones wrote:
On Wed, Dec 11, 2002 at 01:07:45PM +0100, Nicolas ASPERT wrote:
IIRC, the 845G is a new version of the 830MP chipset (it had been
added by Abraham vd Merwe Graeme Fisher some months ago), but acts
basically just as the 830MP. Therefore the entry is correct Or maybe
Dave Jones wrote:
On Wed, Dec 11, 2002 at 12:45:49PM +, Keith Whitwell wrote:
In any case I don't think the string in the informational is very useful --
it's a potentially inaccurate translation of state from *another* module, so
I'm just removing the lot.
Cool, that gets my vote
Charl P. Botha wrote:
On Mon, Dec 09, 2002 at 10:30:35PM +, Keith Whitwell wrote:
Charl P. Botha wrote:
On Mon, Dec 09, 2002 at 09:45:12PM +, Keith Whitwell wrote:
There's a fix for this in recent cvs:
/* Mask out highest bit, which is used by AMD for 3dnow
* Newer Intel
Charl P. Botha wrote:
Dear list,
In spite of some issues with binary snapshots, the DRI resume patches
seem to work well. They have been available and in use on several
different kinds of laptops for a few months now.
What are the chances of this patch being accepted into the DRI CVS
Philip Brown wrote:
I might have asked a varient of this many months ago.. maybe things have
changed since then...
Does anyone know of a dri Xserver-side video card module that will function
successfully, even if the card-specific IOCTLs are not available from
the kernel driver?
That is to say,
b/modules# glxgears
Radeon DRI driver:
Compatibility mode for DRM driver version 1.1.1
TCL will be disabled, expect reduced performance
(prefer DRM radeon.o 1.3.x or newer)
disabling TCL support
glxgears: radeon_ioctl.h:165: radeonAllocCmdBuf: Assertion
`rmesa-dri.drmMinor = 3' failed.
Michel Dänzer wrote:
On Die, 2002-12-10 at 06:01, Carlos O'Donell wrote:
Kernel Says:
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 565M
agpgart: Detected Intel 440BX chipset
agpgart: AGP aperture is 64M @ 0xec00
[drm] AGP
Charl P. Botha wrote:
On Mon, Dec 09, 2002 at 09:56:50PM +0100, Andreas Stenglein wrote:
(LAVA and OpenGL Spectrum Analyzer)
I think any multi-threaded OpenGL-app should trigger my
bug if it draws enough (more than a cube).
disabling VTXFMT helps: no lockups anymore, everything works fine,
but
D. Hageman wrote:
The issue has been fixed. It seems that I had the symbol xf86usleep in my
r200_dri.so. I stuck in the -DDONT_DEFINE_WRAPPERS and recompiled just
that and it works correctly now.
Next question is that is this the correct way it should be. Should the
*_dri.so drivers have
Felix Kühling wrote:
On 07 Dec 2002 02:07:03 +0100
Michel Dänzer [EMAIL PROTECTED] wrote:
On Die, 2002-12-03 at 23:17, Felix Kühling wrote:
I just tried glaxium myself. And it freezes the Xserver here too.
However, I don't have to move the window :-/ it always freezes about 3
seconds after I
Felix Kühling wrote:
On Sun, 8 Dec 2002 14:24:58 +0100
Felix Kühling [EMAIL PROTECTED] wrote:
Hi,
as I reported earlier there seems to be a race condition in the Radeon
driver when state is emitted while the card is processing vertices. Now
Keith, I just read your other message. Ok, so
Alan Hourihane wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/lib/GL/mesa/src/drv/r128/
Changes by: alanh@sc8-pr-cvs1. 02/12/05 16:22:45
Log message:
texture units are 0 and 1, not 1 and 2.
Textures are still a bit funky yet
Nice. The problem I saw but haven't fixed
Keith Whitwell wrote:
I suspect that will fix the texture problems. Somebody (that actually
has
Rage128 hardware!) should go through and eliminate the new_state field
from
r128_context altogether. I will make similar changes to the MGA
driver. It
would be nice to have fundamental things
801 - 900 of 1368 matches
Mail list logo
