Philip Brown wrote:
How about moving
os-support/{linux,bsd}/drm/kernel/drm.h
into
os-support/shared/drm/kernel/drm.h
After all, it defines the core drm IOCTLS and data structures. It should be
common, not in OS-specific directories.
There are trivial differences between the two versions
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, like tracking state
Brian Paul wrote:
Felix Kühling wrote:
On Mon, 2 Dec 2002 18:43:25 -0800
Allen Akin [EMAIL PROTECTED] wrote:
On Mon, Dec 02, 2002 at 02:00:49PM +0100, Felix Kühling wrote:
| So if we agree on this, I would make this
| controlled by an environment variable. ...
The
I'm not sure that statement is accurate. On SGI, AIX, and Windows there are
various tools to tune the operation of the OpenGL driver. On Linux we don't
have any of that. Instead we've been using an ad-hoc collection of
environment variables to control debug output, HW TCL operation, page
Felix Kühling wrote:
On Mon, 2 Dec 2002 00:59:34 +0100
Felix Kühling [EMAIL PROTECTED] wrote:
Hi,
I reported a DMA buffer allocation problem earlier today with glean. It
terminated with Error: Could not get dma buffer ... exiting. I looked
into it a bit more now. I made a glean run with
Felix Kühling wrote:
Hi,
my digging is starting to pay off ;)
I had reported that weird problem, that the global ambient light is not
correct using hardware TCL if I specify anything other than 1.0 as alpha
component. Now I found out that the trigger for this problem is actually
to specify the
Felix Kühling wrote:
Hi,
I made two small modifications to the radeon driver to make OpenGL look
much nicer with 16bpp. The first thing is to enable dithering, the
second is to use 32bpp textures even in 16bpp mode, if the application
requests them. A patch is attached.
I've turned it on
Felix Kühling wrote:
Hi,
while I was trying to understand the vtxfmt mesa code and poking around
with gdb I noticed that the neutral vtxfmt wrapper gets restored quite
often. I tracked it to radeonFlushVertices where
_mesa_install_exec_vtxfmt( ctx, rmesa-vb.vtxfmt ) is called if the
Felix Kühling wrote:
Hi,
I made two small modifications to the radeon driver to make OpenGL look
much nicer with 16bpp. The first thing is to enable dithering, the
second is to use 32bpp textures even in 16bpp mode, if the application
requests them. A patch is attached.
Maybe the texture color
Adam K Kirchhoff wrote:
Hello all,
I recently upraded from an SMP VIA PIII motherboard to a UP Intel
I845 P4 motherboard. So far, things have gone pretty smoothly (I've
needed to upgrade to 2.4.20 to support the new ICH4 IDE controller).
There are a few remaining issues I'm facing, and one
Felix Kühling wrote:
On Fri, 29 Nov 2002 07:55:52 -0700
Brian Paul [EMAIL PROTECTED] wrote:
[snip]
Implementing a true threaded pipeline could be very compilicated. State
changes are the big issue. If you stall/flush the pipeline for every
state change you wouldn't gain anything. The
Michel Dänzer wrote:
On Mit, 2002-11-27 at 08:32, Dieter Nützel wrote:
TaskParallelismWithPorts
The colors of the polyhedron in the middle are missing.
With LIBGL_ALWAYS_INDIRECT or R200_NO_TCL they are fine.
Some small screenshots could be find in the archive.
Sounds like a problem I'm
Ian Romanick wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/lib/GL/mesa/src/drv/r128/
Changes by: idr@sc8-pr-cvs1. 02/11/27 12:47:44
Log message:
Initial pass at adding texmem support to Rage128 driver. These
changes have not yet been tested as I don't have access to Rage128
Keith Whitwell wrote:
Ian Romanick wrote:
CVSROOT:/cvsroot/dri
Module name:xc
Repository:xc/xc/lib/GL/mesa/src/drv/r128/
Changes by:idr@sc8-pr-cvs1.02/11/27 12:47:44
Log message:
Initial pass at adding texmem support to Rage128 driver. These
changes have not yet been
Michel Dänzer wrote:
First of all, thanks Keith for sharing your insights ( and Jens for the
URL about locking ).
On Don, 2002-11-28 at 13:31, Keith Whitwell wrote:
gloss: artifacts with the initial highlight, goes away with SW TCL,
seems to be the same problem as the ice in tuxracer
Brian Paul wrote:
Michel Dänzer wrote:
First of all, thanks Keith for sharing your insights ( and Jens for the
URL about locking ).
On Don, 2002-11-28 at 13:31, Keith Whitwell wrote:
gloss: artifacts with the initial highlight, goes away with SW TCL,
seems to be the same problem as the ice
Keith Whitwell wrote:
Ian Romanick wrote:
CVSROOT:/cvsroot/dri
Module name:xc
Repository:xc/xc/lib/GL/mesa/src/drv/r128/
Changes by:idr@sc8-pr-cvs1.02/11/27 12:47:44
Log message:
Initial pass at adding texmem support to Rage128 driver. These
changes have not yet been
Dieter Nützel wrote:
1. start X or system start (init 5)
2. rcxdm stop
3. rrmod radeon
4. restart X (rcxdm start)
What happens:
* Screen corruption in several upper lines (the KDE panel)
* a copy of the graphical screen on console 1, 2, 3, etc. but without mouse or
anything else but the
Felix Kühling wrote:
Hi,
clipping of lines at the edges of the viewing volume doesn't seem to
work. The problem occurs both with RADEON_TCL_FORCE_DISABLE and with
LIBGL_ALWAYS_INDIRECT. If I use a glOrtho (-1.0, 1.0, -1.0, 1.0, -1.0,
1.0) projection this works:
glBegin(GL_LINES);
but... heres something that shows info about the error from yesterday:
(please also see attached file, this is only an extract:)
Nov 23 20:18:13 buche kernel: [drm:radeon_irq_emit] *ERROR*
radeon_irq_emit called without lock held
Nov 23 20:18:13 buche kernel: [drm:radeon_lock_take] *ERROR* 6
Michel Dänzer wrote:
On Son, 2002-11-24 at 18:39, Andreas Stenglein wrote:
Nov 23 20:18:13 buche kernel: [drm:radeon_irq_emit] *ERROR*
radeon_irq_emit called without lock held
Nov 23 20:18:13 buche kernel: [drm:radeon_lock_take] *ERROR* 6 holds
heavyweight lock
A friend of mine reported
I think I found the problem. usleep() gets defined as a macro to xf86usleep()
in xf86_ansi.h (via radeon_regs.h) and needs to be #undefined.
Do we know why xf86_ansi.h is getting included in the client-side module?
It's only intended for X server modules. It'd be better to not include
it in
Roman Stepanov wrote:
On 24 Nov 2002 18:19, you wrote:
The meaning of this post, just a simple bug report.
Sure it could be a leocad bug, but since the r200 drivers are highly in
development i figured this is the place that's mostly interested.
The r200 driver is basically done; it's not
Brian Paul wrote:
Andreas Stenglein wrote:
Here is a backtrace from gdb, its almost the same for the
app is dieing and xserver freezes.
when running xmms in gdb, the xserver doesnt freeze, only
the app. If you continue, one thread is dead, the other
keeps going!
But I had another thing: after
Brian Paul wrote:
Michel Dänzer wrote:
On Mon, 2002-11-25 at 23:21, Brian Paul wrote:
There are two places in radeon_ioctl.c where the INREG() macro is
used to
read register values (RADEON_LAST_FRAME_REG and RADEON_LAST_CLEAR_REG).
It looks like these have been superceeded by
Michel Dänzer wrote:
On Mon, 2002-11-25 at 23:21, Brian Paul wrote:
There are two places in radeon_ioctl.c where the INREG() macro is used to
read register values (RADEON_LAST_FRAME_REG and RADEON_LAST_CLEAR_REG).
It looks like these have been superceeded by drmCommandWriteRead() calls
(since
Its a known issue for me, thats why i do prefer the GLUT demos.
I made it to bring the Mesa demos to life on DRI by just editing
the libGL and other references to the systems defaults rather than
to the libs in the project. As far as i do remember, it all turned
out to be rather static in
Brian Paul wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/lib/GL/mesa/src/drv/tdfx/
Changes by: brianp@usw-pr-cvs1. 02/11/15 16:13:59
Log message:
Modified functions in __DriverAPIRec to remove unneeded Display *
parameters, etc. Generally try to reduce number of X
Ian Molton wrote:
On Fri, 15 Nov 2002 11:39:55 +0100 (CET)
Martin Spott [EMAIL PROTECTED] wrote:
Im awaiting a PCI Voodoo3 at the moment...
Sorry, I didn't make it this week. It will get shipped on monday,
No rush - I wasnt criticising, just making the statement so people would
know I
If I do that, in glxinfo it only shows up in the 'client glx extensions',
which makes sense given the way I'm doing it. In the Nvidia driver, it
shows up in both 'client glx extnesions' and 'GLX extensions'.
Evidently, NVIDIA supports the extension for indirect rendering too.
NVIDIA's
Ian Romanick wrote:
On Tue, Nov 12, 2002 at 09:34:38AM -0800, Ian Romanick wrote:
I was monkeying around with DOT3 bumpmapping in SW Mesa and in the Radeon
driver. In both cases, when a scale (either 2x or 4x) is applied, the
resulting colors wrap. However, I noticed that in the Nvidia driver
Ian Romanick wrote:
On Thu, Nov 07, 2002 at 09:09:06AM -0800, Ian Romanick wrote:
On Thu, Nov 07, 2002 at 07:48:55AM -0800, Ian Romanick wrote:
On Wed, Nov 06, 2002 at 11:41:00PM +0100, Dieter Nützel wrote:
Am Mittwoch, 6. November 2002 23:23 schrieb Adam K Kirchhoff:
Hello all,
These
D. Hageman wrote:
I have a solution to why I was running into problems with getting my
Radeon 9000 in my laptop working. One of those things that when you
realize what is going on - you feel really silly ;-)
The issue was that it wasn't using the r200 driver, but rather the
standard radeon
Michel Dänzer wrote:
On Die, 2002-11-05 at 09:41, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mon, 2002-11-04 at 21:11, Ian Romanick wrote:
On Sun, Nov 03, 2002 at 04:58:23PM +0100, Michel Dänzer wrote:
http://penguinppc.org/~daenzer/DRI/bzflag.png
http://penguinppc.org/~daenzer/DRI
Michel Dänzer wrote:
On Mon, 2002-11-04 at 21:11, Ian Romanick wrote:
On Sun, Nov 03, 2002 at 04:58:23PM +0100, Michel Dänzer wrote:
Just tried it for the first time because I hoped it would help with the
texture problems seen in
http://penguinppc.org/~daenzer/DRI/bzflag.png
Missed the meeting last night. Can anyone summarize or post a log?
Keith
---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
Michel Dänzer wrote:
On Son, 2002-11-03 at 17:06, Keith Whitwell wrote:
Michel Dänzer wrote:
Just tried it for the first time because I hoped it would help with the
texture problems seen in
http://penguinppc.org/~daenzer/DRI/bzflag.png
http://penguinppc.org/~daenzer/DRI/tuxracer.png
Well
Michel Dänzer wrote:
On Mon, 2002-11-04 at 13:06, Keith Whitwell wrote:
Michel Dänzer wrote:
On Son, 2002-11-03 at 17:06, Keith Whitwell wrote:
Michel Dänzer wrote:
Just tried it for the first time because I hoped it would help with the
texture problems seen in
http://penguinppc.org
D. Hageman wrote:
I have a solution to why I was running into problems with getting my
Radeon 9000 in my laptop working. One of those things that when you
realize what is going on - you feel really silly ;-)
The issue was that it wasn't using the r200 driver, but rather the
standard radeon
Ian Romanick wrote:
On Sun, Nov 03, 2002 at 04:58:23PM +0100, Michel Dänzer wrote:
Just tried it for the first time because I hoped it would help with the
texture problems seen in
http://penguinppc.org/~daenzer/DRI/bzflag.png
http://penguinppc.org/~daenzer/DRI/tuxracer.png
Well, it does seem
Sorry Ian, work gets in the way sometimes. I haven't had much time at all lately.
Yeah, I know. It just sucks for me because I know pretty much exactly what
needs to be done, but I can't really do it because I don't have access to
all the different hardware. Not to worry, I have plenty of
Michel Dänzer wrote:
Just tried it for the first time because I hoped it would help with the
texture problems seen in
http://penguinppc.org/~daenzer/DRI/bzflag.png
http://penguinppc.org/~daenzer/DRI/tuxracer.png
Well, it does seem to change the behaviour, but not only for the good.
While the
Ian Romanick wrote:
I'm running Viewperf for the first time. The drv-08 test doesn't look right
to me using the R100 driver. For most of the test, the screen is totally
black. When there is something on the screen, it looks like the far
clip-plane isn't set quite right. It does NOT look like
Alan Cox wrote:
On Thu, 2002-10-31 at 15:58, José Fonseca wrote:
I don't know much about SIS 6326. I know that there is some deprecated
(it hasn't been updated for the architectural changes) support for SIS
630 chips on the CVS.
6326 is much older than 630 and 315 etc. Its in the PIO with
Felix,
I've cleaned up the WaitForFrameCompletion function a bit committed. The
logic is slightly different, but a lot easier to read/understand, I think.
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
Felix Kühling wrote:
On Tue, 29 Oct 2002 13:23:22 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix,
I've cleaned up the WaitForFrameCompletion function a bit committed. The
logic is slightly different, but a lot easier to read/understand, I think.
Ok, I just think that the name rmesa
I've created a stable-1-0-branch as a tag from alan's pre-xf4.3-merge tag
'trunk-20021022'.
This will be the site for the first stable binary snapshot, and will target
XFree86 4.2.x installations.
I haven't done anything more than create the branch at this stage. Before
releasing the binary,
Felix Kühling wrote:
Hi,
here is a new set of frame throttling patches for the radeon and r200
drivers. It implements a second chance strategy to avoid ping-ponging
between busy waiting and IRQ waiting with very high frame rates.
Felix, do you have versions of these that apply cleanly to the
Michel Dänzer wrote:
http://penguinppc.org/~daenzer/DRI/radeon-pageflip.diff
is an attempt to fix the following pageflipping issues:
* the 2D driver clobbers the CRTC{,2}_OFFSET_CNTL registers when
switching modes; as a consequence, flips only take place on the
next vertical
Ian Romanick wrote:
On Fri, Oct 25, 2002 at 10:39:23AM -0600, Jens Owen wrote:
I've heard you and others talk about triple buffering a few times, and
I'm wondering if you can fill me in on a few details. Is the primary
motivation for a 3rd buffer to aliviate delays associated with vertical
Ian Romanick wrote:
On Fri, Oct 25, 2002 at 06:19:14PM +0100, Keith Whitwell wrote:
Ian Romanick wrote:
On Fri, Oct 25, 2002 at 10:39:23AM -0600, Jens Owen wrote:
I've heard you and others talk about triple buffering a few times, and
I'm wondering if you can fill me in on a few details
Malte Cornils wrote:
On Thu, Oct 24, 2002 at 01:31:14AM +0200, Malte Cornils wrote:
Is there any way I could help in a different way, maybe you could guess
something after looking at a screenshot? If you supply a patch, I promise
I'll test it, of course. With TCL it's way faster :-)
BTW,
I just tried this with RADEON_TCL_FORCE_DISABLE=1, RADEON_NO_VTXFMT=1 and
RADEON_NO_CODEGEN=1 and I can still reproduce the bug. Are any other bells
ringing?
No, now there's just hard work...
Keith
---
This sf.net email is sponsored by:
Ian Romanick wrote:
On Wed, Oct 23, 2002 at 12:27:57AM +0200, Charl P. Botha wrote:
On Tue, Oct 22, 2002 at 03:12:52PM -0700, Ian Romanick wrote:
On Tue, Oct 22, 2002 at 12:46:27AM +0200, Charl P. Botha wrote:
Run glthreads with something like: glthreads -n 5
Here's an additional data
Malte Cornils wrote:
Hi,
I'm having a visual problem with an application (NWN under Wine) - it works
fine with LIBGL_ALWAYS_INDIRECT=true but displays the problem (some textures
flicker and show wrong colours) with hardware-accelerated r200.
How can I selectively disable/enable hardware
Michel Dänzer wrote:
On Son, 2002-10-13 at 17:54, Michel Dänzer wrote:
I've done some more clueless digging into the problem visible in
http://penguinppc.org/~daenzer/DRI/evas_test.jpeg and
http://penguinppc.org/~daenzer/DRI/celestia.jpeg . My first suspicion
was an off-by-one error in the
This comes up so often (once a week?) that I think we should change the name
of the function to
gl_test_os_katmai_exception_support_SIGFPE_is_expected_just_ignore_it().
And we should rename radeon_cp_get_buffer while we're at it.
Keith
Ian Romanick wrote:
Over the past year an issue of OpenGL versioning has come up a few times.
Basically, we have conflicting goals of wanting to advertise OpenGL 1.3 or
1.4 but not wanting to advertise extensions that aren't hardware accelerated
(cube textures and shadow maps come to mind).
I
Ian Romanick wrote:
From what I have been told, this is how it works on the Nvidia drivers. I
have not verified this first hand.
if ( extension string contains GL_EXT_texture3D )
3D textures are hardware accelerated
else if ( advertised OpenGL version = 1.2 )
3D
Alexander Stohr wrote:
From what I have been told, this is how it works on the
Nvidia drivers. I
have not verified this first hand.
if ( extension string contains GL_EXT_texture3D )
3D textures are hardware accelerated
else if ( advertised OpenGL version = 1.2 )
James Fung wrote:
Thanks.
The PCI radeon seems to work fairly well actually:
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI Radeon 20020611 AGP 1x x86/MMX/3DNow! TCL
OpenGL version string: 1.2 Mesa 4.0.4
glxgears gives 1000 frames in 5.0 seconds = 200.000 FPS
Philip Brown wrote:
I note that the apparent sole purpose for drm_write_string() is to
record context switches in a buffer, which can be read by processes
doing userland read() calls on the drm dev.
Is this for debug purposes only?
Probably. I didn't know it was there...
Keith
Russ Dill wrote:
On Tue, 2002-10-15 at 10:01, Stefan Lange wrote:
Q3A: stable (at least for the time I tested), but not very fast. In fact
it shows the same symptoms I got with earlier versions of DRI-trunk
(before around 2002-10-11): poor overall speed, and a framerate that
maxes out at
hmm, that's odd. I still get floating point exceptions for almost every
GL-app. with TCL disabled.
Demos that _do_ work with TCL disabled include:
clearspd, drawpix, gamma, glinfo, lodbias, readpix, winpos
Maybe this can give you a clue, why some are working and some aren't?
Could I
Michel Dänzer wrote:
On Fre, 2002-10-11 at 18:52, Felix Kühling wrote:
On 11 Oct 2002 18:15:08 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
I was looking into the lighting issues Felix reported with the
xscreensaver pulsar hack (when running it with the -light option).
[...]
One
A. H. Gee wrote:
Hi everyone,
Hopefully a useful data point: the radeon nightly snapshots now work
for me as long as I use Jose's libxaa.a. Without the new libxaa.a, I
get the much reported blank screen. Looks like we need to bundle
libxaa.a with the nightly backups.
The radeon driver works
Adam Duck wrote:
Joe == Joe Mackay [EMAIL PROTECTED] writes:
Joe On Thu, 10 Oct 2002, Frank Van Damme wrote:
www.student.kuleuven.ac.be/~m9917684/r200-20020920-linux.i386.tar.bz2 should
work.
Joe Brilliant... thanks, you're a star!
Joe Working fairly well now,
I've tested the radeon, r200 and tdfx drivers and they seem OK.
I can't test the i810, i830, r128, mga, etc drivers (either because I don't
have the right hardware or mine's broke). Some of the other drivers (like
sis, ffb, etc) aren't enabled in the build process and haven't been ported.
Felix Kühling wrote:
On 11 Oct 2002 18:15:08 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
I was looking into the lighting issues Felix reported with the
xscreensaver pulsar hack (when running it with the -light option). One
side of the planes looks good, the other one is black, so I thought
José Fonseca wrote:
The current mach64 (mesa 4.x) driver doesn't seem to be doing z depth
test. After assuring that the mach64's z control register was being set
properly I realized that the vertex buffers had the z in a [0,1] scale
while the primitive drawing functions expected them in a
José Fonseca wrote:
Keith,
I'm curious to know how you reminded after so long (7 months)! Did you
actually writed it now or was it stuck in a mail queue all this time?
By now I got to more or less to those answers, but thanks anyway. As
saying goes: it's better late than never!
Oh.
Tom Hosiawa wrote:
What exactly is drm_radeon_depth_clear_t storing; is it registers on the card having
something to do with the way depth buffers get used???
If you look at where it's used, you get a clue that these are register values:
OUT_RING_REG( RADEON_RB3D_ZSTENCILCNTL,
Brian Paul wrote:
Dieter Nützel wrote:
cvs update
M xc/config/cf/host.def
M xc/config/cf/xf86site.def
M xc/config/cf/xfree86.cf
P xc/lib/GL/mesa/src/drv/r200/r200_ioctl.c
cvs server: [16:53:25] waiting for anoncvs_dri's lock in
/cvsroot/dri/xc/xc/lib/GLw
cvs server: [16:53:55] waiting
Keith Whitwell wrote:
Brian Paul wrote:
Dieter Nützel wrote:
cvs update
M xc/config/cf/host.def
M xc/config/cf/xf86site.def
M xc/config/cf/xfree86.cf
P xc/lib/GL/mesa/src/drv/r200/r200_ioctl.c
cvs server: [16:53:25] waiting for anoncvs_dri's lock in
/cvsroot/dri/xc/xc/lib/GLw
cvs
Ian Romanick wrote:
On Wed, Oct 09, 2002 at 07:57:18AM -0600, Brian Paul wrote:
I've whipped up an HTML table which summarizes the features of the DRI drivers.
Maybe one of the web masters can incorporate it into the website.
Couple quick corrections. I don't think R200 supports
Brian Paul wrote:
in drm_os_linux.h in the DRM_WAIT_ON macro there's:
schedule_timeout(max(HZ/100,1)); \
Where is max() supposed to be defined? It's undefined when I compile here.
Replacing it with:
schedule_timeout((HZ/100 1) ? HZ/100 : 1);\
Sounds
Felix Kühling wrote:
Hi Keith,
I attached a new r100 waiting patch against the latest trunk. I assume
that you have the most up-to-date r200 waiting code in your tree. I
added EAGAIN to conditions handled gracefully. But I couldn't find any
situation in which the DRM_RADEON_IRQ_WAIT ioctl
Felix Kühling wrote:
Hi Keith,
I attached a new r100 waiting patch against the latest trunk. I assume
that you have the most up-to-date r200 waiting code in your tree. I
added EAGAIN to conditions handled gracefully. But I couldn't find any
situation in which the DRM_RADEON_IRQ_WAIT ioctl
Brian Paul wrote:
Keith Whitwell wrote:
Ti Leggett wrote:
There seems to be a 512x512 OpenGL texture size limit for ATI 7500
Mobility. There's a game I'm helping test and it uses textures over
1024x1024 and they work on a regular ATI 7500 but don't on a 7500
Mobility. 512x512 textures do
Ian Romanick wrote:
On Fri, Sep 27, 2002 at 07:53:22PM +0100, Keith Whitwell wrote:
One option is to have the kernel actually do the fixup of the buffers when
they are submitted by the client, so the driver never knows really where it's
textures are, but talks about them via. some
Andy Dustman wrote:
I managed to get the r200 driver working again by doing a complete CVS
install. Some notes:
* The card does now seem to generate interrupts at about the same
frequency as the current mode's vertical refresh.
* Surprisingly (for me, at least), glxgears is now running
Felix Kühling wrote:
On 03 Oct 2002 11:01:57 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
On Don, 2002-10-03 at 01:52, thork wrote:
about the aperture thing, he told me those 8Mb where from system memory
not from the video card memory, I found this thing in the log:
(--) RADEON(0):
Ian Romanick wrote:
On Thu, Sep 26, 2002 at 07:20:58AM +0100, Keith Whitwell wrote:
Ian Romanick wrote:
- Do we really need the 3 in radeon_vtxfmt_c.c:
static void radeon_MultiTexCoord1fARB( GLenum target, GLfloat s )
{
- GLfloat *dest = vb.texcoordptr[(target - GL_TEXTURE0_ARB)1
Could it be that the AGP bus is the limiting factor and pushing TCL
vertices requires more bandwidth than just pushing rasterization info?
Maybe, but the difference Felix reports (1%) might as well be noise.
Sorry, I know we shouldn't even get into it regarding gears...it's not a
Karl Rasche wrote:
Attached is a patch to attempt to duplicate the r200 agp allocator,
independant of any one particular drivers' code.
Also, is a quick implementation for the mga driver.
Hopefully I went about this in a somewhat correct mannor. If not, please
let me know...
Felix Kühling wrote:
Keith,
you got the condition for waiting for an interrupt wrong.
r200_ioctl.c, line 330
...
/* if there was a previous frame, wait for its IRQ */
- if (iw-irq_seq != -1 sarea-last_frame r200GetLastFrame( rmesa ) ) {
+ if (iw-irq_seq != -1
I definitely running this on my dual Athlon with latest ACPI for 2.4.19 and
irq's routing enabled, I think.
With procinfo -f I see ~980 irq/sec during gears.
Same with r200 code from yesterday. But it was much faster.
I think I may have fixed your problem (thanks to Felix), can you try
Karl Rasche wrote:
My first question, I haven't looked at the code properly yet, is about ioctl
numbers. Where are they coming from? How do we avoid overlapping with the
driver-specific ioctl numbers?
From what I gather from drm.h, the driver specific ioctls are supposed to
begin at
Felix Kühling wrote:
Hi r200'ers,
here is the improved frame throttling for r200. It compiles on my
system. Time for testing ...
I still get a lot of busy waiting with this patch. I assume the behaviour is
the same on the radeon. Run it against 'multiarb' from the mesa demos. Every
Dieter Nützel wrote:
Keith,
after your latest r200 IRQ merge setenv R200_NO_USLEEPS 1 is badly needed,
again?
gears is lower than ever
Mesa/demos ./gears
r200CreateScreen
550 frames in 5.019 seconds = 109.584 FPS
566 frames in 5.016 seconds = 112.839 FPS
574 frames in 5.004
Felix Kühling wrote:
Hello,
Modifying the frame throttling code in r200_ioctl.c I removed
R200_MAX_OUTSTANDING which is no longer needed there. It is, however,
still used in r200Clear:
if ( rmesa-sarea-last_clear - clear = R200_MAX_OUTSTANDING+1 ) {
break;
}
The
Brian Paul wrote:
Felix Kühling wrote:
Hello,
Modifying the frame throttling code in r200_ioctl.c I removed
R200_MAX_OUTSTANDING which is no longer needed there. It is, however,
still used in r200Clear:
if ( rmesa-sarea-last_clear - clear = R200_MAX_OUTSTANDING+1 ) {
break;
Felix Kühling wrote:
On Sun, 29 Sep 2002 23:25:03 +0200
Dieter Nützel [EMAIL PROTECTED] wrote:
Am Sonntag, 29. September 2002 22:57 schrieb Felix Kühling:
On Sun, 29 Sep 2002 22:47:47 +0200
Felix Kühling [EMAIL PROTECTED] wrote:
On Sun, 29 Sep 2002 13:22:44 -0700
Keith Whitwell [EMAIL
Felix Kühling wrote:
Hi,
I was able to reduce CPU usage of applications which use glFinish by
emitting and waiting for an IRQ in radeonFinish before
radeonWaitForIdle. I'm not sure whether radeonWaitForIdle is still
needed after waiting for the IRQ, but keeping it does at least not hurt.
Should we stop producing snapshots temporarily until the
xaa/compiler/who-knows-what problems are resolved?
There seem to be a lot of complaints about the ones up there now...
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome
Felix Kühling wrote:
On Sat, 28 Sep 2002 14:56:38 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
I was able to reduce CPU usage of applications which use glFinish by
emitting and waiting for an IRQ in radeonFinish before
radeonWaitForIdle. I'm not sure whether
Felix Kühling wrote:
On Sat, 28 Sep 2002 16:31:56 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
[snip]
Using a static variable doesn't cut it -- that should go into the
radeonContext struct in radeon_context.h.
Beyond that, it would be *nice* if the irq never happened unless we thought
Michel Dänzer wrote:
On Don, 2002-09-26 at 18:17, Keith Whitwell wrote:
Michel Dänzer wrote:
Something else I've been thinking about is that relying on the
swi_emitted and swi_received counters being in sync is pretty fragile.
It might be better to use a scratch register instead.
Yes
Stephane Chauveau wrote:
Hi,
The r200 dri drivers are working fine on my system but I noticed
something strange in my logs:
(**) RADEON(0): Using AGP 4x mode
(II) RADEON(0): AGP Fast Write disabled by default
My bios says that AGP Fast Write is enabled.
Is there an issue with AGP
It's a big hack to be doing this. I'd really like to know why this happens,
So would I. I suspect it's a workaround for some problem, it worked fine
here without. (as I said on IRC yesterday: but then I have sane hardware
:)
but in the mean time I'm ok to see it go in.
Okay,
901 - 1000 of 1368 matches
Mail list logo
