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 s
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 ma
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 transp
Sven Luther wrote:
On Thu, Feb 27, 2003 at 02:01:22PM -0800, Jon Smirl wrote:
--- Sven Luther <[EMAIL PROTECTED]> wrote:
Notice that the DRI drivers don't do anything like
mode setting and
such, they depend on the X drivers for that. So if
you take away the X
driver, you will not be able to get a
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 col
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_HEL
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 flic
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
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
Linus Torvalds wrote:
On Sat, 1 Mar 2003, Keith Whitwell 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
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 mak
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 whatno
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
hardw
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 in a
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 typing:
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
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
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 w
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&#x
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
--
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 nec
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
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
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
kille
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 /usr/X11R6/lib/modules/dri/radeo
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 lig
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 with
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 poweri
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 sf.net
Excellent.
Can someone commit this? Does this fix *all* the problems? I don't know if
it would.
Keith
Felix Kühling wrote:
Hi,
I found the source of some vertex data corruption with software TCL. In
radeon_run_render tnl->Driver.Render.Start (points to radeonRenderStart)
is called after inde
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 te
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
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
radeon
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
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.
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 c
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 the
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
Keith Whitwell wrote:
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
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/:
r2
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 o
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 there
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
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:
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 bein
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 of
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 up
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 do
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 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 lo
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
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
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
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
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, I'
-#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 ); \
+ RADEON_WRITE
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 sou
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 for
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 --
Arkadi Shishlov wrote:
Hi.
Recently I posted my problem with i845G/GL chipset to dri-users@.
http://sourceforge.net/mailarchive/forum.php?thread_id=1551204&forum_id=6511
Should I file bug report for this issue to be notified by developers
or there just no time/man-power/chipset docs/input from ven
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
ftp://ftp.retinalburn.
Adam K Kirchhoff wrote:
I'm curious how tied the DRI is to XFree86 vs. Mesa? BeOS has a
relatively up-to-date port of Mesa, and I'm trying to determine how
difficult it would be to port the DRI to BeOS. Does anyone know of any
projects to get the DRI working without X?
Have a look at the embed
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: r200_state
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 XLock
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 I
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 conso
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
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)
Keith
--
Michel Dänzer wrote:
On Son, 2002-12-29 at 12:04, Keith Whitwell wrote:
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 happ
Dieter Nützel wrote:
Am Samstag, 11. Januar 2003 02:59 schrieb Michel Dänzer:
On Fre, 2003-01-10 at 19:40, Dieter Nützel wrote:
[...]
Benchmark: 3
ZSmooth Tex Blend Triangles
Current size: 480
Elapsed time for the calibration test (148): 3.763000
Selected number of benchmark iterations: 196
Oh, my bad. Too many people to keep track of. :) It seems that Keith has
already extended the isosurf demo to trigger the failure condition, though,
so hopefully I can stop pretending to be someone who has any idea what's
going on with this. :)
Hmm, actually it was just my screwup in isosurf
Jens Owen wrote:
Keith wrote:
Jens wrote:
Michel wrote:
>>> This doesn't help mixed OpenGL and X11 rendering in the same
>>> window, but that supposedly doesn't work with the traditional
>>> method of drawing to the back buffer and then copying it over
>>> the front buffer either, so en
Dieter Nützel wrote:
Am Mittwoch, 8. Januar 2003 17:04 schrieb Keith Whitwell:
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 "b
Michel Dänzer wrote:
On Mit, 2003-01-08 at 17:04, Keith Whitwell wrote:
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 "
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,
w
Then there's a problem with glArrayElement() in the R200 driver while
recording a displaylist.
The specific piece of code that it's running is this (while a displaylist
is being recorded in GL_COMPILE_AND_EXECUTE mode):
glEnableClientState(GL_VERTEX_ARRAY);
glVe
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
...
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, cr
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 i
Ian Romanick wrote:
I believe that there is a bug in radeon_state.c in radeonRecaclScissorRects.
If it is a bug, then it also appears in the corresponding R200 driver. At
line 447 there is this code block:
rmesa->state.scissor.pClipRects =
MALLOC( rmesa->state.scissor.numAllocedClipRect
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
David Dawes wrote:
On Tue, Dec 17, 2002 at 01:02:45AM +, Keith Whitwell wrote:
David Dawes wrote:
On Mon, Dec 16, 2002 at 12:44:15PM -0500, David Dawes wrote:
On Sat, Dec 14, 2002 at 07:02:50PM +0100, Michel Dänzer wrote:
On Sam, 2002-12-14 at 18:42, Michel Daenzer wrote:
CVSROOT
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 thi
David Dawes wrote:
On Mon, Dec 16, 2002 at 12:44:15PM -0500, David Dawes wrote:
On Sat, Dec 14, 2002 at 07:02:50PM +0100, Michel Dänzer wrote:
On Sam, 2002-12-14 at 18:42, Michel Daenzer wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/sha
Both drivers get terribly confused if the other one touches the card
first. I typically have to do a hard reset before changing X servers
or else the machine chokes (sometimes it's a hard lockup, other times
the X server just enters an infinite loop and I can reboot the machine
over the netwo
Andy Ross wrote:
I finally got a chance over the weekend to try out the current DRI
code on my new 8500 card and compare it with the offering from ATI.
The following is a cheers & jeers style review. Hopefully someone
will find it helpful.
My setup: 950MHz Athlon (early/pre-thunderbird), KT133 m
José Fonseca wrote:
This a proposal to give a more flexible approach to the current DRM's
generic DMA engine.
The current engine is described at
http://dri.sourceforge.net/doc/drm_low_level.html, section 2, item 3,
which I include here for your convenience:
1. The X server can specify multiple
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
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 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 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
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
Dave Airlie wrote:
This takes some of the stuff that was recently submitted to the
xfree86.org for the i830 and tries to move the i810 along similiar
lines...
is all cosmetic apart from a new define for the FRONTBUFFER command this
is what they call it in the i815 spec anyways.
I'm submitting th
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 yo
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.
:::
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
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 D
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 + XF8
901 - 1000 of 1643 matches
Mail list logo
