Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Martin Spott <[EMAIL PROTECTED]> wrote:
> Ian Romanick <[EMAIL PROTECTED]> wrote:
>> CVSROOT: /cvsroot/dri
>> Module name: xc
>> Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/
>> Changes by: [EMAIL PROTECTED] 03/08/08 13:34:08
>> Log message:
>> Removed the R{ADEON,200}_AGP_TEX_OFFSET contant as it's not really a
>> constant. Replaced it with a query of a chip configuration register
>> to get the correct value. This fixes various AGP texturing related
>> problems on R100 and cleans up a hard-coded constant in the R200 driver.
> 'Unfortunately' I'm on holiday at the moment. I'll check your changes
> against FlightGear as soon as I'm back at work,
I see, tons of updates during the last three weeks. As an owner of a
Radeon9100 I'm _really_ happy with the progress the DRI tree made and I'd
like to thank everyone who participated in this effort (Ian, Felix, Michel,
I didn't remember all the names mentioned in the changelogs),
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
---
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Ian Romanick <[EMAIL PROTECTED]> wrote:
> CVSROOT: /cvsroot/dri
> Module name: xc
> Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/
> Changes by: [EMAIL PROTECTED] 03/08/08 13:34:08
> Log message:
> Removed the R{ADEON,200}_AGP_TEX_OFFSET contant as it's not really a
> constant. Replaced it with a query of a chip configuration register
> to get the correct value. This fixes various AGP texturing related
> problems on R100 and cleans up a hard-coded constant in the R200 driver.
'Unfortunately' I'm on holiday at the moment. I'll check your changes
against FlightGear as soon as I'm back at work,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Martin Spott wrote:
> Ian Romanick <[EMAIL PROTECTED]> wrote:
>
>> Log message:
>> Removed the R{ADEON,200}_AGP_TEX_OFFSET contant as it's not really a
>> constant. Replaced it with a query of a chip configuration register
>> to get the correct value. This fixes various AGP texturing related
>> problems on R100 and cleans up a hard-coded constant in the R200
>> driver.
>
> 'Unfortunately' I'm on holiday at the moment. I'll check your changes
> against FlightGear as soon as I'm back at work,
This (I think) fixed the bad corruption problems (red flashing textures,
currupted desktop after exit) that have been plaguing the radeon driver for
quite some time now! Thinktanks looks perfect now, as does RTCW. Textures
look good in NWN too, but unfortunately the lighting is still broken (way
too dark).
Happy, happy! :-)
-n8
--
>>>-- Nathaniel Gray -- Caltech Computer Science -->
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Tue, 2003-07-29 at 14:53, Martin Spott wrote: > Michel Daenzer <[EMAIL PROTECTED]> wrote: > > CVSROOT:/cvsroot/dri > > Module name:xc > > Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/ > > Changes by: [EMAIL PROTECTED] 03/07/29 03:11:48 > > > Log message: > > * IRQ code cleanup suggested by Linus Torvalds > > * i830 build fix > > BTW, has the discussion on moving the CVS repository finally faded out ? I > can't test Michael's modification because I can't pull it from CVS, You can try the patch I posted? Are none of the suggested cvs tricks working for you? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Daenzer <[EMAIL PROTECTED]> wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/ > Changes by: [EMAIL PROTECTED] 03/07/29 03:11:48 > Log message: > * IRQ code cleanup suggested by Linus Torvalds > * i830 build fix BTW, has the discussion on moving the CVS repository finally faded out ? I can't test Michael's modification because I can't pull it from CVS, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Keith Whitwell wrote: CVSROOT:/cvsroot/dri Module name:xc Repository: xc/xc/lib/GL/mesa/src/drv/i830/ Changes by: [EMAIL PROTECTED] 03/06/13 03:49:05 Log message: Restore texture age waiting when swapping in new textures. Modified files: xc/xc/lib/GL/mesa/src/drv/i830/: i830_ioctl.c i830_tex.h i830_texmem.c Revision ChangesPath 1.10 +2 -2 xc/xc/lib/GL/mesa/src/drv/i830/i830_ioctl.c 1.6 +0 -1 xc/xc/lib/GL/mesa/src/drv/i830/i830_tex.h 1.11 +5 -12 xc/xc/lib/GL/mesa/src/drv/i830/i830_texmem.c Did you intend to add imesa as a parameter to i830UploadTexLevel? It wasn't there before and it's not used. --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Wed, Jun 11, 2003 at 05:11:06PM +, Martin Spott wrote: > Jose Fonseca <[EMAIL PROTECTED]> wrote: > > CVSROOT:/cvsroot/dri > > Module name:xc > > Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ > > Changes by: [EMAIL PROTECTED] 03/06/03 16:27:02 > > > Log message: > > Split declarations/definitions in drm_scatter.h into drm_sg.h/drm_sg_tmp.h > > respectively. Splited the work out of the ioctls and renamed (with the _ioctl > > prefix). Added some more documentation. > > Did the same for drm_sgpsupport.h. > [This change seem to have made more harm than good... ] > > As far as I can recover, this is the patch that made DRM unavailable on my > system. When I load the appropriate kernel modules (agpgart, radeon) by > starting the X server, /var/log/messages writes the following. This is from > the current CVS tree, but it read the same before the version change to > 1.9.0: > > Jun 11 18:58:22 quickstep kernel: agpgart: AGP aperture is 64M @ 0xe400 > Jun 11 18:58:22 quickstep kernel: [drm] AGP 0.99 aperture @ 0xe400 64MB > Jun 11 18:58:22 quickstep kernel: [drm] Initialized radeon 1.9.0 20020828 on minor 0 [...] > (WW) RADEON(0): [agp] AGP not available How can't see how the above two logs match. Which driver version are you using, the latest? José Fonseca --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Jose Fonseca <[EMAIL PROTECTED]> wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ > Changes by: [EMAIL PROTECTED] 03/06/03 16:27:02 > Log message: > Split declarations/definitions in drm_scatter.h into drm_sg.h/drm_sg_tmp.h > respectively. Splited the work out of the ioctls and renamed (with the _ioctl > prefix). Added some more documentation. > Did the same for drm_sgpsupport.h. > Modified files: > xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: > drmP.h drm_bufs.h drm_drv.h drm_memory.h > drm_memory_debug.h gamma_drv.c i810_drv.c i830_drv.c > mga_drv.c r128_drv.c radeon_drv.c sis_drv.c > Added files: > xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: > drm_agp.h drm_agp_tmp.h drm_sg.h drm_sg_tmp.h > Removed files: > xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: > drm_agpsupport.h drm_scatter.h As far as I can recover, this is the patch that made DRM unavailable on my system. When I load the appropriate kernel modules (agpgart, radeon) by starting the X server, /var/log/messages writes the following. This is from the current CVS tree, but it read the same before the version change to 1.9.0: Jun 11 18:58:22 quickstep kernel: agpgart: AGP aperture is 64M @ 0xe400 Jun 11 18:58:22 quickstep kernel: [drm] AGP 0.99 aperture @ 0xe400 64MB Jun 11 18:58:22 quickstep kernel: [drm] Initialized radeon 1.9.0 20020828 on minor 0 Jun 11 18:58:23 quickstep kernel: [drm] Loading R200 Microcode Jun 11 18:58:25 quickstep kernel: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held Jun 11 18:58:25 quickstep kernel: [drm:radeon_unlock] *ERROR* Process 12217 using kernel context 0 XFree86.0.log simply writes: [...] drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmGetBusid returned '' (II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:0:0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0cc5000 (II) RADEON(0): [drm] mapped SAREA 0xe0cc5000 to 0x4002 (II) RADEON(0): [drm] framebuffer handle = 0xd800 (II) RADEON(0): [drm] added 1 reserved context for kernel (WW) RADEON(0): [agp] AGP not available (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xe0cc5000 at 0x4002 (II) RADEON(0): Memory manager initialized to (0,0) (1152,8191) (II) RADEON(0): Reserved area from (0,864) to (1152,866) (II) RADEON(0): Largest offscreen area available: 1152 x 7325 (II) RADEON(0): Acceleration enabled (II) RADEON(0): Using hardware cursor (scanline 866) (II) RADEON(0): Largest offscreen area available: 1152 x 7321 (II) RADEON(0): Direct rendering disabled This is on a OEM Radeon9100. What information may I provide to you to fix this ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Mon, Jun 02, 2003 at 09:14:23AM -0600, Jens Owen wrote: > > Modified files: > > xc/xc/lib/GL/mesa/src/drv/r200/: > > Imakefile.inc > > > > Revision ChangesPath > > 1.5 +1 -1 xc/xc/lib/GL/mesa/src/drv/r200/Imakefile.inc > > After doing a little digging in the DRI and XFree86 CVS trees, it looks > like this was originally fixed 6 months ago in the XFree86 repository > and then synced 5 months ago into the mesa-4-0-4-branch of the DRI > repository, but it never made it to the DRI trunk. > > Ugh. ObPedantic: A reminder that you wouldnt have these problems, if dri was an actual true module for xfree86. Then "merging"/"syncing" to the xfree tree would never need to be done, and you wouldnt hit this sort of bug re-introduction problem. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Mon, Jun 02, 2003 at 07:02:37PM +0100, José Fonseca wrote: > On Mon, Jun 02, 2003 at 09:14:23AM -0600, Jens Owen wrote: > > Jose Fonseca wrote: > > >CVSROOT: /cvsroot/dri > > >Module name: xc > > >Repository:xc/xc/lib/GL/mesa/src/drv/r200/ > > >Changes by:[EMAIL PROTECTED] 03/05/31 15:42:18 > > > > > >Log message: > > > Add a newline at end of file - believe it or not, this was the culprit > > > for all > > > the build problems lately... > > > > > >Modified files: > > > xc/xc/lib/GL/mesa/src/drv/r200/: > > >Imakefile.inc > > > > > > Revision ChangesPath > > > 1.5 +1 -1 xc/xc/lib/GL/mesa/src/drv/r200/Imakefile.inc > > > > After doing a little digging in the DRI and XFree86 CVS trees, it looks > > like this was originally fixed 6 months ago in the XFree86 repository > > and then synced 5 months ago into the mesa-4-0-4-branch of the DRI > > repository, but it never made it to the DRI trunk. > > Jens, I confess that that comment may be totally off, but I still didn't > come around to find what exactly is causing Imake to go crazy. The > difficulty is that I have problems to accuratly reproduce the problem: > after the error first time, Imake no longer complains about mismatiching > #endif's... > > But I'm still on it. The problem was effectivly the missing newline after all. But the strange thing is that the newline is missing for a *long* time and snapshots have been built since then. So I think the sudden problem must be related with a new upstream C pre-proccessor with stricter demands. (I do 'apt-get upgrade' quite often on the machine where the builds are made which has Debian unstable, so I have no idea which version may have caused this) José Fonseca --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Mon, Jun 02, 2003 at 09:14:23AM -0600, Jens Owen wrote: > Jose Fonseca wrote: > >CVSROOT: /cvsroot/dri > >Module name: xc > >Repository: xc/xc/lib/GL/mesa/src/drv/r200/ > >Changes by: [EMAIL PROTECTED] 03/05/31 15:42:18 > > > >Log message: > > Add a newline at end of file - believe it or not, this was the culprit > > for all > > the build problems lately... > > > >Modified files: > > xc/xc/lib/GL/mesa/src/drv/r200/: > >Imakefile.inc > > > > Revision ChangesPath > > 1.5 +1 -1 xc/xc/lib/GL/mesa/src/drv/r200/Imakefile.inc > > After doing a little digging in the DRI and XFree86 CVS trees, it looks > like this was originally fixed 6 months ago in the XFree86 repository > and then synced 5 months ago into the mesa-4-0-4-branch of the DRI > repository, but it never made it to the DRI trunk. Jens, I confess that that comment may be totally off, but I still didn't come around to find what exactly is causing Imake to go crazy. The difficulty is that I have problems to accuratly reproduce the problem: after the error first time, Imake no longer complains about mismatiching #endif's... But I'm still on it. José Fonseca --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Jose Fonseca wrote: CVSROOT:/cvsroot/dri Module name:xc Repository: xc/xc/lib/GL/mesa/src/drv/r200/ Changes by: [EMAIL PROTECTED] 03/05/31 15:42:18 Log message: Add a newline at end of file - believe it or not, this was the culprit for all the build problems lately... Modified files: xc/xc/lib/GL/mesa/src/drv/r200/: Imakefile.inc Revision ChangesPath 1.5 +1 -1 xc/xc/lib/GL/mesa/src/drv/r200/Imakefile.inc After doing a little digging in the DRI and XFree86 CVS trees, it looks like this was originally fixed 6 months ago in the XFree86 repository and then synced 5 months ago into the mesa-4-0-4-branch of the DRI repository, but it never made it to the DRI trunk. Ugh. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Quoting Ian Romanick ([EMAIL PROTECTED]): > Keith Whitwell wrote: > >CVSROOT: /cvsroot/dri > >Module name: xc > >Repository: xc/xc/lib/GL/mesa/src/drv/i830/ > >Changes by: [EMAIL PROTECTED] 03/05/28 01:49:11 > > > >Log message: > > Bit more optimization > > > >Modified files: > > xc/xc/lib/GL/mesa/src/drv/i830/: > >i830_texmem.c > > This seems like a good change. I had been thinking about something > similar for other drivers. I think what we really want is to use a > pointer-to-function so that, on processors that support it, we can use > non-temporal reads /writes. I don't seen any reason to fill the CPU > caches with blocks of texture data that we're copying to AGP or on-card > memory. :) > > This might be a good task for a newbie that has assembly hacking skillz. :) DirectFB has optimized memcpy routines using MMX or SSE "mov" with non-temporal storage if supported. I've attached the pretty standalone files. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "--" Convergence GmbH /* (c) Copyright 2000-2002 convergence integrated media GmbH. (c) Copyright 2002 convergence GmbH. All rights reserved. Written by Denis Oliver Kropp <[EMAIL PROTECTED]>, Andreas Hundt <[EMAIL PROTECTED]> and Sven Neumann <[EMAIL PROTECTED]>. Fast memcpy code was taken from xine (see below). This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ /* * Copyright (C) 2001 the xine project * * This file is part of xine, a unix video player. * * xine is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * xine is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA * * These are the MMX/MMX2/SSE optimized versions of memcpy * * This code was adapted from Linux Kernel sources by Nick Kurshev to * the mplayer program. (http://mplayer.sourceforge.net) * * Miguel Freitas split the #ifdefs into several specialized functions that * are benchmarked at runtime by xine. Some original comments from Nick * have been preserved documenting some MMX/SSE oddities. * Also added kernel memcpy function that seems faster than glibc one. * */ /* Original comments from mplayer (file: aclib.c) This part of code was taken by me from Linux-2.4.3 and slightly modified for MMX, MMX2, SSE instruction set. I have done it since linux uses page aligned blocks but mplayer uses weakly ordered data and original sources can not speedup them. Only using PREFETCHNTA and MOVNTQ together have effect! From IA-32 Intel Architecture Software Developer's Manual Volume 1, Order Number 245470: "10.4.6. Cacheability Control, Prefetch, and Memory Ordering Instructions" Data referenced by a program can be temporal (data will be used again) or non-temporal (data will be referenced once and not reused in the immediate future). To make efficient use of the processor's caches, it is generally desirable to cache temporal data and not cache non-temporal data. Overloading the processor's caches with non-temporal data is sometimes referred to as "polluting the caches". The non-temporal data is written to memory with Write-Combining semantics. The PREFETCHh instructions permits a program to load data into the processor at a suggested cache level, so that it is closer to the processors load and store unit when it is needed. If the data is already present in a level of the cache hierarchy that is closer to the processor, the PREFETCHh instruction will not result in any data movement. But we should yo
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Keith Whitwell wrote: CVSROOT:/cvsroot/dri Module name:xc Repository: xc/xc/lib/GL/mesa/src/drv/i830/ Changes by: [EMAIL PROTECTED] 03/05/28 01:49:11 Log message: Bit more optimization Modified files: xc/xc/lib/GL/mesa/src/drv/i830/: i830_texmem.c This seems like a good change. I had been thinking about something similar for other drivers. I think what we really want is to use a pointer-to-function so that, on processors that support it, we can use non-temporal reads /writes. I don't seen any reason to fill the CPU caches with blocks of texture data that we're copying to AGP or on-card memory. :) This might be a good task for a newbie that has assembly hacking skillz. :) --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Leif Delgass wrote: On Thu, 27 Mar 2003, Keith Whitwell wrote: Leif Delgass wrote: I removed the alpha component from the visuals because the 32 bit span read function in i830_span.c doesn't read alpha from the framebuffer (it always returns 255). There's a comment there saying that it should work but doesn't. I think that should be fixed before advertising an alpha channel. Also, I changed the bufferSize from 32 to 24, so that should be changed back to 32 if an alpha channel is advertised. OK, I'll look into this. It's odd, because conform was working fine at 32bpp -- when did you make these changes? Keith It was back when I did a mini-audit of the visuals being exported in several drivers before 4.3.0 (beginning of Feb.). Here's my original message about i830: http://marc.theaimsgroup.com/?l=dri-devel&m=104457580107963&w=2 The thread started here where I posted my orginal list of visuals exported by some of the drivers: http://marc.theaimsgroup.com/?l=dri-devel&m=104448416328979&w=2 There were fixes committed for a few other drivers as well. Hmm. The code in the i830_span.c is definitely bogus. That's Jeff's comment, I'm pretty sure. I'll fix it, and the other issues you raised. Keith --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Thu, 27 Mar 2003, Keith Whitwell wrote: > Leif Delgass wrote: > > I removed the alpha component from the visuals because the 32 bit span > > read function in i830_span.c doesn't read alpha from the framebuffer (it > > always returns 255). There's a comment there saying that it should work > > but doesn't. I think that should be fixed before advertising an alpha > > channel. Also, I changed the bufferSize from 32 to 24, so that should be > > changed back to 32 if an alpha channel is advertised. > > OK, I'll look into this. It's odd, because conform was working fine at 32bpp > -- when did you make these changes? > > Keith It was back when I did a mini-audit of the visuals being exported in several drivers before 4.3.0 (beginning of Feb.). Here's my original message about i830: http://marc.theaimsgroup.com/?l=dri-devel&m=104457580107963&w=2 The thread started here where I posted my orginal list of visuals exported by some of the drivers: http://marc.theaimsgroup.com/?l=dri-devel&m=104448416328979&w=2 There were fixes committed for a few other drivers as well. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Leif Delgass wrote: I removed the alpha component from the visuals because the 32 bit span read function in i830_span.c doesn't read alpha from the framebuffer (it always returns 255). There's a comment there saying that it should work but doesn't. I think that should be fixed before advertising an alpha channel. Also, I changed the bufferSize from 32 to 24, so that should be changed back to 32 if an alpha channel is advertised. OK, I'll look into this. It's odd, because conform was working fine at 32bpp -- when did you make these changes? Keith --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
I removed the alpha component from the visuals because the 32 bit span read function in i830_span.c doesn't read alpha from the framebuffer (it always returns 255). There's a comment there saying that it should work but doesn't. I think that should be fixed before advertising an alpha channel. Also, I changed the bufferSize from 32 to 24, so that should be changed back to 32 if an alpha channel is advertised. On Thu, 27 Mar 2003, Keith Whitwell wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/i810/ > Changes by: [EMAIL PROTECTED] 03/03/27 00:46:48 > > Log message: > i830 wasn't reporting alpha component at 32bpp > > Modified files: > xc/xc/programs/Xserver/hw/xfree86/drivers/i810/: > i830_dri.c > > Revision ChangesPath > 1.11 +2 -2 xc/xc/programs/Xserver/hw/xfree86/drivers/i810/i830_dri.c > > > > --- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > ___ > Dri-patches mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-patches > -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Don, 2003-03-27 at 04:09, Leif Delgass wrote: > On 27 Mar 2003, Michel Dänzer wrote: > > > On Don, 2003-03-27 at 01:33, Leif Delgass wrote: > > > I just ran into a problem with this change in host.def when building the > > > trunk: > > > > > > #define UsrLibDir /usr/X11R6/lib > > > > > > This caused the build to be installed in /usr/X11R6 even though I had > > > ProjectRoot defined as /usr/X11R6-DRI. According to xc/config/cf/README, > > > UsrLibDir is the "directory in which to install libraries." > > > > Whoops. > > > > > Judging from the checkin comment, perhaps AlternateUsrLibDir was what > > > was intended? (README says "linker needs -L to find project libraries"). > > > > Yes, that looks better. Unless you beat me to it, I'll probably look > > into this tomorrow. > > > > > There is also an AlternateIncRoot for includes. > > > > I don't recall ever having problems with includes. > > I've never run into problems with includes or libs myself. Was there a > specific problem you ran into with the wrong libs being used in the build? Just the good old 'some X libs need to be present in ProjectRoot/lib'. We have gotten used to putting symlinks there, but people who change ProjectRoot for the first time usually get bitten by this. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On 27 Mar 2003, Michel Dänzer wrote: > On Don, 2003-03-27 at 01:33, Leif Delgass wrote: > > I just ran into a problem with this change in host.def when building the > > trunk: > > > > #define UsrLibDir /usr/X11R6/lib > > > > This caused the build to be installed in /usr/X11R6 even though I had > > ProjectRoot defined as /usr/X11R6-DRI. According to xc/config/cf/README, > > UsrLibDir is the "directory in which to install libraries." > > Whoops. > > > Judging from the checkin comment, perhaps AlternateUsrLibDir was what > > was intended? (README says "linker needs -L to find project libraries"). > > Yes, that looks better. Unless you beat me to it, I'll probably look > into this tomorrow. > > > There is also an AlternateIncRoot for includes. > > I don't recall ever having problems with includes. I've never run into problems with includes or libs myself. Was there a specific problem you ran into with the wrong libs being used in the build? > > Since I have symlinks in /usr/X11R6-DRI/lib to /usr/X11R6/lib for libs not > > built in the DRI tree, I got the build to work by restoring my original > > install in /usr/X11R6/lib and commenting out the UsrLibDir define. > > Glad nothing worse happened, sorry for the hiccup. No worries. Just thought I'd give a 'heads-up' for those using a non-default ProjectRoot. ;) -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Don, 2003-03-27 at 01:33, Leif Delgass wrote: > I just ran into a problem with this change in host.def when building the > trunk: > > #define UsrLibDir /usr/X11R6/lib > > This caused the build to be installed in /usr/X11R6 even though I had > ProjectRoot defined as /usr/X11R6-DRI. According to xc/config/cf/README, > UsrLibDir is the "directory in which to install libraries." Whoops. > Judging from the checkin comment, perhaps AlternateUsrLibDir was what > was intended? (README says "linker needs -L to find project libraries"). Yes, that looks better. Unless you beat me to it, I'll probably look into this tomorrow. > There is also an AlternateIncRoot for includes. I don't recall ever having problems with includes. > Since I have symlinks in /usr/X11R6-DRI/lib to /usr/X11R6/lib for libs not > built in the DRI tree, I got the build to work by restoring my original > install in /usr/X11R6/lib and commenting out the UsrLibDir define. Glad nothing worse happened, sorry for the hiccup. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
I just ran into a problem with this change in host.def when building the trunk: #define UsrLibDir /usr/X11R6/lib This caused the build to be installed in /usr/X11R6 even though I had ProjectRoot defined as /usr/X11R6-DRI. According to xc/config/cf/README, UsrLibDir is the "directory in which to install libraries." Judging from the checkin comment, perhaps AlternateUsrLibDir was what was intended? (README says "linker needs -L to find project libraries"). There is also an AlternateIncRoot for includes. Since I have symlinks in /usr/X11R6-DRI/lib to /usr/X11R6/lib for libs not built in the DRI tree, I got the build to work by restoring my original install in /usr/X11R6/lib and commenting out the UsrLibDir define. -Leif On Sat, 15 Mar 2003, Michel Daenzer wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/config/cf/ > Changes by: [EMAIL PROTECTED] 03/03/15 17:55:31 > > Log message: > define UsrLibDir so external X libraries are always found > > Modified files: > xc/xc/config/cf/: > host.def > > Revision ChangesPath > 1.50 +2 -0 xc/xc/config/cf/host.def > > > > --- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > ___ > Dri-patches mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-patches > -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Die, 2003-03-04 at 18:57, Martin Spott wrote: > Michel Daenzer <[EMAIL PROTECTED]> wrote: > > CVSROOT:/cvsroot/dri > > Module name:xc > > Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ > > Changes by: [EMAIL PROTECTED] 03/03/03 17:02:35 > > > Log message: > > Set Mesa hooks to flush vertices on state changes (Keith Whitwell) > > Whps, it appears to me that this fixes the FlightGear lockups. I did > several tries of my usually reliable 'test routine' (starting with a viev > straight out of the B747 cockpit) and it did _not_ crash the server until > now. I'll try further. > > If this proves to be real maybe someone should contribute this as a patch > against XFree86-4.3-branch ;-) I've committed this change to the mesa-4-0-4-branch as well now, so you can verify whether it fixes the problems there as well. :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Dienstag, 4. März 2003 20:17 schrieb Martin Spott: > Martin Spott <[EMAIL PROTECTED]> wrote: > > Michel Daenzer <[EMAIL PROTECTED]> wrote: > >> CVSROOT: /cvsroot/dri > >> Module name: xc > >> Repository:xc/xc/lib/GL/mesa/src/drv/radeon/ > >> Changes by:[EMAIL PROTECTED] 03/03/03 17:02:35 > >> > >> Log message: > >> Set Mesa hooks to flush vertices on state changes (Keith Whitwell) > > > > Whps, it appears to me that this fixes the FlightGear lockups. > > This definitely looks to be stable for me so far with a Radeon7500. I'll be > out of office for the rest of the week so I could not stress test this > under different conditions. I'd be happy if others could confirm the > sanitizing effect of these patches. > I forgot to mention that I currently run the DRM driver from XFree86-4.3.0, > I'll test others next week if anyone is interested. > > Thanks, > Martin. > P.S.: There's still the "dark lightning" issue with FG on Radeon ;-)) Are all your TCL colors right? VTK (e.g. TaskParallelism, TaskParallelismWithPorts) have wrong (no colors) on the (inner) object polygons. R200_NO_TCL fix it. Charl, can you reproduce? Have you ever tried with several OpenGL apps in parallel? 5 times gears (no system load at all ;-) and then only one ipers => hard lock up on my SMP system ;-( Texture vs. no texture thing? Regards, Dieter --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Martin Spott <[EMAIL PROTECTED]> wrote: > Michel Daenzer <[EMAIL PROTECTED]> wrote: >> CVSROOT: /cvsroot/dri >> Module name: xc >> Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ >> Changes by: [EMAIL PROTECTED] 03/03/03 17:02:35 >> Log message: >> Set Mesa hooks to flush vertices on state changes (Keith Whitwell) > Whps, it appears to me that this fixes the FlightGear lockups. This definitely looks to be stable for me so far with a Radeon7500. I'll be out of office for the rest of the week so I could not stress test this under different conditions. I'd be happy if others could confirm the sanitizing effect of these patches. I forgot to mention that I currently run the DRM driver from XFree86-4.3.0, I'll test others next week if anyone is interested. Thanks, Martin. P.S.: There's still the "dark lightning" issue with FG on Radeon ;-)) -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Daenzer <[EMAIL PROTECTED]> wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ > Changes by: [EMAIL PROTECTED] 03/03/03 17:02:35 > Log message: > Set Mesa hooks to flush vertices on state changes (Keith Whitwell) Whps, it appears to me that this fixes the FlightGear lockups. I did several tries of my usually reliable 'test routine' (starting with a viev straight out of the B747 cockpit) and it did _not_ crash the server until now. I'll try further. If this proves to be real maybe someone should contribute this as a patch against XFree86-4.3-branch ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Sat, 2003-02-08 at 17:46, Eric Anholt wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/dri/drm/ > Changes by: anholt@sc8-pr-cvs1. 03/02/08 17:46:32 > > Log message: > Use the right subdirs for NetBSD. > > Modified files: > xc/xc/lib/GL/dri/drm/: > Imakefile This was supposed to be on bsd-4-0-0-branch, but my checkout had only been partially updated to bsd-4-0-0-branch. It should be harmless, anyway. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Leif Delgass wrote: On Fri, 7 Feb 2003, Keith Whitwell wrote: Actually, I take that back - I don't have an r200 handy to test & the diff didn't apply cleanly enough to "wing it"... Anyone else? Here's a hand-merged diff against mesa-4-0-4-branch. How does this look? Meh. It looks like there's a couple minor issues with it. I guess I'll break down and get yet another branch on my system. :) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Fri, 7 Feb 2003, Keith Whitwell wrote:
> >> I don't have a local copy of the mesa-4.0.4 branch. Could somebody
> >> commit this change to that tree? It's a pretty easy fix & should make
> >> Linus happy. :)
> >
> >
> > I'll do it.
>
> Actually, I take that back - I don't have an r200 handy to test & the diff
> didn't apply cleanly enough to "wing it"...
>
> Anyone else?
>
> Keith
Here's a hand-merged diff against mesa-4-0-4-branch. How does this look?
--
Leif Delgass
http://www.retinalburn.net
Index: r200_texstate.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r200/r200_texstate.c,v
retrieving revision 1.7
diff -u -r1.7 r200_texstate.c
--- r200_texstate.c 5 Nov 2002 21:19:50 - 1.7
+++ r200_texstate.c 7 Feb 2003 21:41:52 -
@@ -47,6 +47,7 @@
#include "mmath.h"
#include "simple_list.h"
#include "texformat.h"
+#include "enums.h"
static void r200SetTexImages( r200ContextPtr rmesa,
@@ -702,16 +703,19 @@
{
r200ContextPtr rmesa = R200_CONTEXT(ctx);
const struct gl_texture_unit *texUnit = &ctx->Texture.Unit[unit];
+ const struct gl_texture_object *tObj = texUnit->_Current;
+ const GLenum format = tObj->Image[tObj->BaseLevel]->Format;
GLuint color_combine, alpha_combine;
GLuint color_scale = rmesa->hw.pix[unit].cmd[PIX_PP_TXCBLEND2];
GLuint alpha_scale = rmesa->hw.pix[unit].cmd[PIX_PP_TXABLEND2];
if ( R200_DEBUG & DEBUG_TEXTURE ) {
- fprintf( stderr, "%s( %p, %d )\n", __FUNCTION__, ctx, unit );
+ fprintf( stderr, "%s( %p, %d ) format=%s\n", __FUNCTION__,
+ ctx, unit, _mesa_lookup_enum_by_nr( format ) );
}
/* Set the texture environment state. Isn't this nice and clean?
-* The R200 will automagically set the texture alpha to 0xff when
+* The chip will automagically set the texture alpha to 0xff when
* the texture format does not include an alpha component. This
* reduces the amount of special-casing we have to do, alpha-only
* textures being a notable exception.
@@ -729,6 +733,8 @@
const GLenum format = tObj->Image[tObj->BaseLevel]->Format;
GLuint color_arg[3], alpha_arg[3];
GLuint i, numColorArgs = 0, numAlphaArgs = 0;
+ GLuint RGBshift = texUnit->CombineScaleShiftRGB;
+ GLuint Ashift = texUnit->CombineScaleShiftA;
switch ( texUnit->EnvMode ) {
case GL_REPLACE:
@@ -867,6 +873,8 @@
case GL_SUBTRACT:
case GL_DOT3_RGB:
case GL_DOT3_RGBA:
+case GL_DOT3_RGB_EXT:
+case GL_DOT3_RGBA_EXT:
numColorArgs = 2;
break;
case GL_INTERPOLATE:
@@ -880,10 +888,10 @@
case GL_REPLACE:
numAlphaArgs = 1;
break;
-case GL_SUBTRACT:
case GL_MODULATE:
case GL_ADD:
case GL_ADD_SIGNED:
+case GL_SUBTRACT:
numAlphaArgs = 2;
break;
case GL_INTERPOLATE:
@@ -969,14 +977,6 @@
R200_COLOR_ARG( 0, A );
R200_COLOR_ARG( 1, C );
break;
-case GL_SUBTRACT:
- color_combine = (R200_TXC_ARG_B_ZERO |
-R200_TXC_COMP_ARG_B |
-R200_TXC_NEG_ARG_C |
-R200_TXC_OP_MADD);
- R200_COLOR_ARG( 0, A );
- R200_COLOR_ARG( 1, C );
- break;
case GL_ADD_SIGNED:
color_combine = (R200_TXC_ARG_B_ZERO |
R200_TXC_COMP_ARG_B |
@@ -985,16 +985,46 @@
R200_COLOR_ARG( 0, A );
R200_COLOR_ARG( 1, C );
break;
+case GL_SUBTRACT:
+ color_combine = (R200_TXC_ARG_B_ZERO |
+R200_TXC_COMP_ARG_B |
+R200_TXC_NEG_ARG_C |
+R200_TXC_OP_MADD);
+ R200_COLOR_ARG( 0, A );
+ R200_COLOR_ARG( 1, C );
+ break;
case GL_INTERPOLATE:
color_combine = (R200_TXC_OP_LERP);
R200_COLOR_ARG( 0, B );
R200_COLOR_ARG( 1, A );
R200_COLOR_ARG( 2, C );
break;
+
+case GL_DOT3_RGB_EXT:
+case GL_DOT3_RGBA_EXT:
+ RGBshift = 0;
+ Ashift = 0;
+ /* FALLTHROUGH */
+
case GL_DOT3_RGB:
case GL_DOT3_RGBA:
+ /* DOT3 works differently on R200 than on R100. On R100, just
+* setting the DOT3 mode did everything for you. On R200, the
+* driver has to enable the biasing (the -0.5 in the combine
+* equation), and it has add the 4x scale factor. The hardware
+* only supports up to 8x in the post filter, so 2x part of it
+* happens on the inputs going into the combiner.
+*/
+
+ RGBshift++;
+
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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/src/drv/r200/: r200_texstate.c Revision ChangesPath 1.11 +74 -47 xc/xc/lib/GL/mesa/src/drv/r200/r200_texstate.c I don't have a local copy of the mesa-4.0.4 branch. Could somebody commit this change to that tree? It's a pretty easy fix & should make Linus happy. :) I'll do it. Actually, I take that back - I don't have an r200 handy to test & the diff didn't apply cleanly enough to "wing it"... Anyone else? Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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/: r200_texstate.c Revision ChangesPath 1.11 +74 -47xc/xc/lib/GL/mesa/src/drv/r200/r200_texstate.c I don't have a local copy of the mesa-4.0.4 branch. Could somebody commit this change to that tree? It's a pretty easy fix & should make Linus happy. :) I'll do it. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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/: r200_texstate.c Revision ChangesPath 1.11 +74 -47xc/xc/lib/GL/mesa/src/drv/r200/r200_texstate.c I don't have a local copy of the mesa-4.0.4 branch. Could somebody commit this change to that tree? It's a pretty easy fix & should make Linus happy. :) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Sam, 2003-01-11 at 22:26, Michel Daenzer wrote: > > Log message: > don't set for framebuffer aperture byte swapping on big endian machines; doesn't >work with R200 and later chips The first part is supposed to read 'don't set RADEON_SURF_TRANSLATION_DIS for framebuffer aperture byte swapping on big endian machines'. Somehow, pasting 'RADEON_SURF_TRANSLATION_DIS' didn't work but the cvs command was launched instead. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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 enable page flipping by default. >> 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. I'll clarify my statement...the traditional non-page flipping code is not broken. Consider when a diagonal line is drawn by Xlib across the active GL window, with pages flipped. --> Xlib draws in the "back buffer" It's my interpretation that this step alone doesn't comply with the GLX spec for the page flipping case, but it does work with the traditional code. True. The solution I like is -- The 2d parts of the server know to draw to the current front buffer only. Need some way to deal with XAA's addressing of the pixcache. -- Shadow copies dirty regions to the backbuffer, *except* for those intersecting the visible part of the 3d window. Only the first bit is tricky. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
magenta wrote: On Tue, Jan 07, 2003 at 03:00:10PM -0700, Jens Owen wrote: Michel Daenzer 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 enable page flipping by default. I'm a little confused here. By traditional method are you referring to not using page flipping? What doesn't work in that method? I thought that the glX spec said that mixing X11 and OpenGL within a single drawable wasn't guaranteed anyway, and only gave hints about things that might or might not work on certain implementations. AFAIK the rendering is guaranteed. GLX Version 1.3, Section 2.2, Paragraphs 3 & 4 gives a good description of how the X and OpenGL rendering pipelines are expected to interact: Issuing OpenGL commands may cause the X buffer to be flushed, In particular, calling glFlush when indirect rendering is occuring, will flush both the X and OpenGL rendering streams. Some state is shared between the OpenGL and X. The pixel values in the X frame buffer are shared. The X double buffer extension (DBE) has a definition for which buffer is currently the displayed buffer. This information is shared with GLX. The state of which buffer is displayed tracks in both extensions, independent of which extension initiates a buffer swap. There is a description of the synchronization expectations in Section 2.7, paragraph 5: Synchronization is in the hands of the client. If can be maintained with moderate cost with the judicious use of the glFinish, glXWaitGL, glXWaitX, and XSync commands. OpenGL and X rendering can be done in parallel as long as the client does not preclude it with explicit synchronization calls. This is true even when the rendering is being done by the X server. and again in Section 3.3.10, paragraph 3: All GLX rendering context share the same notion of which are front buffers and which are back buffers for a given drawable. This notion is also shared with the X double buffer extension (DBE). This last section really tweaked my memory. I had forgotten, but indirect rendering in our "traditional" implementation isn't compliant. For indirect contexts, we're not sharing the contents of the back buffer with direct rendering contexts. There's some real interesting work that still needs to be done for indirect rendering, DBE and page flipping. If anyone's interested in improving this stuff, just speak up. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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 enable page flipping by default. >> 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. I'll clarify my statement...the traditional non-page flipping code is not broken. Consider when a diagonal line is drawn by Xlib across the active GL window, with pages flipped. --> Xlib draws in the "back buffer" It's my interpretation that this step alone doesn't comply with the GLX spec for the page flipping case, but it does work with the traditional code. Assuming the active GL window is double buffered, the X server should render to *only* the front buffer (unless DBE is being used). --> Shadow copies the bounding box of the line to the front buffer, including *all* of the backbuffer. What you really want is just a line to be drawn in the front buffer, but in fact you get a whole lot of garbage with it. Right. Just a line in the front buffer and no rendering in the back buffer (for the double buffered GLX window). A common place things like this occur is in opaque window moves -- if you move the 3d window when pages are flipped, its contents are replaced with whatever's in the backbuffer. A solution to this is to get Xlib and GL to agree which is the front buffer and always have Xlib draw into that & copy to the backbuffer. I'll add that we should only copy to the backbuffer if it's not being used by OpenGL or DBE as a double buffered window. Based on Keith's insights and other follow ups to this thread, it looks like there is more work to be done before page flipping will work correctly. Michel, I suggest you turn off page flipping by default until these issues are resolved. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Mittwoch, 8. Januar 2003 16:09 schrieb Michel Dänzer: > [ Why don't you CC: dri-devel? ] Because of the included image. Sorry for the double post, forgotten dri-devel in the first one, again. > On Mit, 2003-01-08 at 02:40, Dieter Nützel wrote: > > On Die, 2003-01-07 at 22:35, Michel Daenzer wrote: > > > On Die, 2003-01-07 at 23:00, Jens Owen wrote: > > > > Michel Daenzer wrote: > > > > > CVSROOT:/cvsroot/dri > > > > > Module name:xc > > > > > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ > > > > > Changes by: mdaenzer@sc8-pr-cvs1. 03/01/07 13:21:52 > > > > > > > > > > Log message: > > > > > Use shadowfb instead of mi shadow to fix 2D corruption when page > > > > > flipping is enabled. > > [...] > > > Now I get a little texture corruption in the Q3A menue (see screen shot). > > That doesn't happen if you revert this change? Ugh, after switching the machine on today it is _gone_. Additional CON: The mouse _works_ again in Q3A! Found that yesterday too but have forgotten to mention. > > The intro and cinematic stuttering and then end (intro) and stop > > (cinematic). I have to press the ESC key to stop/reset the cinematic. > > I don't follow here, sorry. OK. After the stuttering in Q3A I got the below in the log file: Q3A 1.32: Sys_QueEvent: overflow And here comes the UT output: UT 436: dri-trunk/xc> ut& [1] 11085 dri-trunk/xc> r200AgeTextures 0 r200AgeTextures 1 fcntl: Invalid argument fcntl: Invalid argument [1]Fertigut What does the fcntl thing mean? Good work as far as I can see! -Dieter --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Mittwoch, 8. Januar 2003 17:46 schrieb Keith Whitwell: > 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 "broken". > >> > >>This isn't true. > >> > >>Consider when a diagonal line is drawn by Xlib across the active GL > >> window, with pages flipped. > >> > >>--> Xlib draws in the "back buffer" > >>--> Shadow copies the bounding box of the line to the front buffer, > >>including *all* of the backbuffer. > >> > >>What you really want is just a line to be drawn in the front buffer, but > >> in fact you get a whole lot of garbage with it. > >> > >>A common place things like this occur is in opaque window moves -- if you > >>move the 3d window when pages are flipped, its contents are replaced with > >>whatever's in the backbuffer. > >> > >>A solution to this is to get Xlib and GL to agree which is the front > >> buffer and always have Xlib draw into that & copy to the backbuffer. > > > > Then this must be the culprit for the massive 3D window flickring (mixing > > front and back buffer, but only when textures are involved, ipers but not > > gears) when I move the window around? > > Yes, though nothing to do with textures -- gears is just too fast to see it > flickering, whereas ipers is quite slow. Gears is fast but not as fast as before on my dual Athlon SMP like several other 3D apps. Some interference with the great new native AMD 76x power management stuff. I have to disable it for further testing. U160: 2376 RPM (min = 1500 RPM, div = 4) CPU 0:4115 RPM (min = 3000 RPM, div = 2) CPU 1:4090 RPM (min = 3000 RPM, div = 2) System: +28.0°C (limit = +40°C, hysteresis = +37°C) sensor = thermistor CPU 1:+20.5°C (limit = +52°C, hysteresis = +47°C) sensor = 3904 transistor CPU 0:+23.5°C (limit = +52°C, hysteresis = +47°C) sensor = 3904 transistor -Dieter --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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 "broken". This isn't true. Consider when a diagonal line is drawn by Xlib across the active GL window, with pages flipped. --> Xlib draws in the "back buffer" --> Shadow copies the bounding box of the line to the front buffer, including *all* of the backbuffer. What you really want is just a line to be drawn in the front buffer, but in fact you get a whole lot of garbage with it. A common place things like this occur is in opaque window moves -- if you move the 3d window when pages are flipped, its contents are replaced with whatever's in the backbuffer. A solution to this is to get Xlib and GL to agree which is the front buffer and always have Xlib draw into that & copy to the backbuffer. Then this must be the culprit for the massive 3D window flickring (mixing front and back buffer, but only when textures are involved, ipers but not gears) when I move the window around? Yes, though nothing to do with textures -- gears is just too fast to see it flickering, whereas ipers is quite slow. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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 "broken". > > This isn't true. > > Consider when a diagonal line is drawn by Xlib across the active GL window, > with pages flipped. > > --> Xlib draws in the "back buffer" > --> Shadow copies the bounding box of the line to the front buffer, > including *all* of the backbuffer. > > What you really want is just a line to be drawn in the front buffer, but in > fact you get a whole lot of garbage with it. > > A common place things like this occur is in opaque window moves -- if you > move the 3d window when pages are flipped, its contents are replaced with > whatever's in the backbuffer. > > A solution to this is to get Xlib and GL to agree which is the front buffer > and always have Xlib draw into that & copy to the backbuffer. Then this must be the culprit for the massive 3D window flickring (mixing front and back buffer, but only when textures are involved, ipers but not gears) when I move the window around? -Dieter --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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 "broken". This isn't true. Consider when a diagonal line is drawn by Xlib across the active GL window, with pages flipped. --> Xlib draws in the "back buffer" --> Shadow copies the bounding box of the line to the front buffer, including *all* of the backbuffer. What you really want is just a line to be drawn in the front buffer, but in fact you get a whole lot of garbage with it. A common place things like this occur is in opaque window moves -- if you move the 3d window when pages are flipped, its contents are replaced with whatever's in the backbuffer. That only affects the 3D window though, right? The problem I'm trying to solve here is the permanent 2D corruption outside the 3D window. It's fixed in my testing, but I may well not have tried hard enough to break it, more testing is always appreciated. As for inside the 3D window, I'd like to know if this breaks things that work without page flipping but are supposed to work. If so, I'll revert page flipping to be disabled by default. Oh, and we still don't exclude the 3D window in the shadowfb copies, do you think that would be any help? It would cover up some of the worst problems - basically the Xlib drawing to a glX window would only show up every second frame... I don't know how many apps mix xlib and glx -- probably not a huge number. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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 "broken". > > This isn't true. > > Consider when a diagonal line is drawn by Xlib across the active GL window, > with pages flipped. > > --> Xlib draws in the "back buffer" > --> Shadow copies the bounding box of the line to the front buffer, including > *all* of the backbuffer. > > What you really want is just a line to be drawn in the front buffer, but in > fact you get a whole lot of garbage with it. > > A common place things like this occur is in opaque window moves -- if you move > the 3d window when pages are flipped, its contents are replaced with > whatever's in the backbuffer. That only affects the 3D window though, right? The problem I'm trying to solve here is the permanent 2D corruption outside the 3D window. It's fixed in my testing, but I may well not have tried hard enough to break it, more testing is always appreciated. As for inside the 3D window, I'd like to know if this breaks things that work without page flipping but are supposed to work. If so, I'll revert page flipping to be disabled by default. Oh, and we still don't exclude the 3D window in the shadowfb copies, do you think that would be any help? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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 pages flipped. --> Xlib draws in the "back buffer" --> Shadow copies the bounding box of the line to the front buffer, including *all* of the backbuffer. What you really want is just a line to be drawn in the front buffer, but in fact you get a whole lot of garbage with it. A common place things like this occur is in opaque window moves -- if you move the 3d window when pages are flipped, its contents are replaced with whatever's in the backbuffer. A solution to this is to get Xlib and GL to agree which is the front buffer and always have Xlib draw into that & copy to the backbuffer. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Dänzer wrote: On Die, 2003-01-07 at 23:00, Jens Owen wrote: Michel Daenzer wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ Changes by: mdaenzer@sc8-pr-cvs1. 03/01/07 13:21:52 Log message: Use shadowfb instead of mi shadow to fix 2D corruption when page flipping is enabled. Wow, you found the source of the corruption? That's worthy of a posting to dri-devel... True, I posted about it on December 14th and asked for testing, sadly I didn't receive any reports. 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 enable page flipping by default. I'm a little confused here. By traditional method are you referring to not using page flipping? Yes. What doesn't work in that method? The X server always renders to the front buffer, so when you mix OpenGL and X11 rendering, the former clobbers the latter when rendering to the back buffer. 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". Now, if you want to include DBE, then the current "traditional" implementation is technically broken. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Tue, Jan 07, 2003 at 03:00:10PM -0700, Jens Owen wrote: > Michel Daenzer 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 enable page flipping by default. > > I'm a little confused here. By traditional method are you referring to > not using page flipping? What doesn't work in that method? I thought that the glX spec said that mixing X11 and OpenGL within a single drawable wasn't guaranteed anyway, and only gave hints about things that might or might not work on certain implementations. -- http://trikuare.cx --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Mittwoch, 8. Januar 2003 00:06 schrieb Dieter Nützel: > Am Dienstag, 7. Januar 2003 23:35 schrieb Michel Dänzer: > > On Die, 2003-01-07 at 23:00, Jens Owen wrote: > > > Michel Daenzer wrote: > > > > CVSROOT:/cvsroot/dri > > > > Module name:xc > > > > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ > > > > Changes by: mdaenzer@sc8-pr-cvs1. 03/01/07 13:21:52 > > > > > > > > Log message: > > > > Use shadowfb instead of mi shadow to fix 2D corruption when page > > > > flipping is enabled. > > > > > > Wow, you found the source of the corruption? That's worthy of a > > > posting to dri-devel... > > > > True, I posted about it on December 14th and asked for testing, sadly I > > didn't receive any reports. > > I had if you had send both for r100 and r200;-) Oh, shit. Ignore me. I shot to fast. Regards, Dieter PS Compiling, now. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Dienstag, 7. Januar 2003 23:35 schrieb Michel Dänzer: > On Die, 2003-01-07 at 23:00, Jens Owen wrote: > > Michel Daenzer wrote: > > > CVSROOT: /cvsroot/dri > > > Module name: xc > > > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ > > > Changes by: mdaenzer@sc8-pr-cvs1. 03/01/07 13:21:52 > > > > > > Log message: > > > Use shadowfb instead of mi shadow to fix 2D corruption when page > > > flipping is enabled. > > > > Wow, you found the source of the corruption? That's worthy of a posting > > to dri-devel... > > True, I posted about it on December 14th and asked for testing, sadly I > didn't receive any reports. I had if you had send both for r100 and r200;-) Cheers, Dieter --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Die, 2003-01-07 at 23:00, Jens Owen wrote: > Michel Daenzer wrote: > > CVSROOT:/cvsroot/dri > > Module name:xc > > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ > > Changes by: mdaenzer@sc8-pr-cvs1. 03/01/07 13:21:52 > > > > Log message: > > Use shadowfb instead of mi shadow to fix 2D corruption when page flipping > > is enabled. > > Wow, you found the source of the corruption? That's worthy of a posting > to dri-devel... True, I posted about it on December 14th and asked for testing, sadly I didn't receive any reports. > > 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 enable page flipping by default. > > I'm a little confused here. By traditional method are you referring to > not using page flipping? Yes. > What doesn't work in that method? The X server always renders to the front buffer, so when you mix OpenGL and X11 rendering, the former clobbers the latter when rendering to the back buffer. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Daenzer wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ Changes by: mdaenzer@sc8-pr-cvs1. 03/01/07 13:21:52 Log message: Use shadowfb instead of mi shadow to fix 2D corruption when page flipping is enabled. Wow, you found the source of the corruption? That's worthy of a posting to dri-devel... 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 enable page flipping by default. I'm a little confused here. By traditional method are you referring to not using page flipping? What doesn't work in that method? Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: radeon_dri.c radeon_driver.c Revision ChangesPath 1.41 +23 -29xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c 1.53 +9 -9 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Alan Hourihane wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/extras/ogl-sample/main/gfx/lib/glu/libnurbs/nurbtess/ Changes by: alanh@usw-pr-cvs1. 02/10/24 01:43:56 Log message: remove duplicate of swap() Modified files: xc/xc/extras/ogl-sample/main/gfx/lib/glu/libnurbs/nurbtess/: quicksort.cc Revision ChangesPath 1.6 +1 -8 xc/xc/extras/ogl-sample/main/gfx/lib/glu/libnurbs/nurbtess/quicksort.cc This was already fixed in the Mesa CVS tree, along with a few other tiny changes. When I finish up the mesa-4-1 branch in DRI I'll make sure GLU is synced-up too. -Brian --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
> > But Q3A get best (~136 fps) only with "setenv R200_NO_USLEEPS 1". > > Stefan Lange reported that Quake3 gives him max 50FPS which sounds like > a usleep limit. I saw that usleep is used in several places in > r200_ioctl.c. I'm afraid that my change in r200Clear may be causing > trouble. > > I could actually reproduce the 50FPS limit on my Radeon7500 by changing > radeonClear to behave like r200Clear (set RADEON_MAX_CLEAR to 1 and put > in a usleep instead of busy waiting). With RADEON_MAX_CLEAR == 2 > everything seems fine. But maybe it wouldn't hurt increasing the limit a > bit further, just to be sure. I've noticed in q3a, that if I'm following someone, it'll often (but not always) stick at 50fps. If I free fly, I see 2, and often 3's in the third fps column (if I look at the floor, I can get 4's, and occasionly 5's) this is with a radeon 8500 and AMD 2000XP+ (no enviromental variables set) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Sat, 5 Oct 2002 03:50:38 +0200 Dieter Nützel <[EMAIL PROTECTED]> wrote: > Am Mittwoch, 2. Oktober 2002 09:58 schrieb Keith Whitwell: > > > 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 again? > > I think you have. > > 2.4.19-ck5 (O(1) + -AA + preemption) > > gears: > ~2380 fps > System load ~25-26% > > But Q3A get best (~136 fps) only with "setenv R200_NO_USLEEPS 1". Stefan Lange reported that Quake3 gives him max 50FPS which sounds like a usleep limit. I saw that usleep is used in several places in r200_ioctl.c. I'm afraid that my change in r200Clear may be causing trouble. I could actually reproduce the 50FPS limit on my Radeon7500 by changing radeonClear to behave like r200Clear (set RADEON_MAX_CLEAR to 1 and put in a usleep instead of busy waiting). With RADEON_MAX_CLEAR == 2 everything seems fine. But maybe it wouldn't hurt increasing the limit a bit further, just to be sure. Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Mittwoch, 2. Oktober 2002 09:58 schrieb Keith Whitwell: > > 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 again? I think you have. 2.4.19-ck5 (O(1) + -AA + preemption) gears: ~2380 fps System load ~25-26% But Q3A get best (~136 fps) only with "setenv R200_NO_USLEEPS 1". -Dieter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Thu, 3 Oct 2002, Keith Whitwell wrote: > > Would the appropriate place to call 'pci_enable_device' be just after a > successful call to (deprecated) pci_find_slot() ? That should work (but you should check for failure on the find, instead of potentially trying to pass in a NULL pointer to pci_enable_device()). In the long run it would be even better to not try to "find" the device by hand, but just tell the system what kind of device you want to drive, and the system will enumerate each and every such device for you regardless of where they are (and then you can obviously try to match it against whatever info X gave you). That way the code should actually work correctly even if the graphics card is somewhere unexpected. Linus --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Linus Torvalds wrote:
> On Tue, 1 Oct 2002, Keith Whitwell wrote:
>
>>Sounds like you aren't getting irq's, for some reason, and it is falling back
>>to busy waiting.
>>
>>The question is why aren't you getting irq's?
>>
>
> Keith, are you even asking the kernel to look up (and possibly enable) the
> irq for you?
>
> The magic word isn't "please", it's "pci_enable_device(dev)", which will
> check that all resources are allocated and enabled, including things like
> trying to route irq's using the PIRQ table (or ACPI, or whatever).
>
> Doing a quick grep through the drm stuff doesn't show a single caller..
>
> Btw, I'd like to also point out that some of DRI PCI bus handling seems
> fundamentally broken. Like the notion that you can specify the device by
> bus number, device and fn. Those days are past, I'm afraid, and were never
> true on some other platforms. It can be a much more complicated tree, with
> multiple independent PCI segments. You don't see that yet on regular PC's,
> but get ready (and X in general should probably stop thinking that it can
> do things like PCI configuration from user space).
>
Sorry for the delay replying. This is well outside any area I claim to know
anything about, so I'm kind of groping around at the moment.
Would the appropriate place to call 'pci_enable_device' be just after a
successful call to (deprecated) pci_find_slot() ?
ie, something like this?
Keith
--- drm_ioctl.h 25 Sep 2001 09:32:15 - 1.9
+++ drm_ioctl.h 3 Oct 2002 09:50:36 -
@@ -32,6 +32,7 @@
#define __NO_VERSION__
#include "drmP.h"
+
int DRM(irq_busid)(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg)
{
@@ -41,6 +42,11 @@
if (copy_from_user(&p, (drm_irq_busid_t *)arg, sizeof(p)))
return -EFAULT;
dev = pci_find_slot(p.busnum, PCI_DEVFN(p.devnum, p.funcnum));
+
if (!pci_enable_device(dev)) {
+
DRM_ERROR("pci_enable_device failed for %d:%d:%d\n",
+
p.busnum, p.devnum, p.funcnum);
+
return -EBUSY;
+
}
if (dev) p.irq = dev->irq;
else p.irq = 0;
DRM_DEBUG("%d:%d:%d => IRQ %d\n",
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
> > I'm getting quite similar results: > with xmms running in background: ~150 FPS > with xmms paused: ~130 FPS > after i unpause xmms, FPS will drop down very low (~10 FPS or s.th.) for > about 1 or 2 seconds (system load is almost 100% during that period), > and then go up to 150 again (with low sys-load) > after updating today, gears is up at 2200-2300 FPS again. Pausing/unpausing an xmms running in the background, or also changing volume still gives me massive slowdowns for about 1 s, after that performance goes up to normal again. I'm using a CMedia-PCI-Sound-card (CM8738), with kernel oss driver, if that matters. > performance in q3a is also very poor for me at the moment (but it seems > fairly stable (played for about 20 min. without lockup/crash, which is > better than i used to get with earlier driver builds) q3a-performance is still as low as yesterday. one thing that might be interesting: framerate in q3a seems to never get above 50. it's mostly around 20-40 (all settings at maximum, 1280x1024). com_maxfps is at the default value of 85, and monitor vsync is 75 Hz. So I'm wondering why the framerate doesn't go beyond 50? anyway, keep up the nice work, driver are getting better every day, thanks ;-) > system: 8500 LE, XP1800+, KT266A-mobo, dri-cvs (trunk) from 30 min ago, > linux-2.4.19 (vanilla), debian unstable > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Dänzer wrote: > On Mit, 2002-10-02 at 14:41, Keith Whitwell wrote: > >>Michel Daenzer wrote: >> >> >>> * environment variables are checked every time instead of just once on >>>context setup >>> >>What's the logic behind this? >> > > You can change behaviour during runtime by changing the environment > variables, without having to create a new context. This sounds like it should be a GL extension, if it's intended as a programmatic interface. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Mit, 2002-10-02 at 14:41, Keith Whitwell wrote: > Michel Daenzer wrote: > > > * environment variables are checked every time instead of just once on > > context setup > > What's the logic behind this? You can change behaviour during runtime by changing the environment variables, without having to create a new context. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Daenzer wrote: > * environment variables are checked every time instead of just once on > context setup What's the logic behind this? Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
> 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 again? Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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 && r200GetLastFrame( rmesa ) < sarea->last_frame ) {
> UNLOCK_HARDWARE( rmesa );
> ret = drmCommandWrite( fd, DRM_RADEON_IRQ_WAIT, iw, sizeof(*iw) );
>...
OK, fixed.
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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 && r200GetLastFrame( rmesa ) < sarea->last_frame ) {
UNLOCK_HARDWARE( rmesa );
ret = drmCommandWrite( fd, DRM_RADEON_IRQ_WAIT, iw, sizeof(*iw) );
...
Compare with my original patch.
Felix
On Tue, 01 Oct 2002 03:58:03 -0700
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> CVSROOT: /cvsroot/dri
> Module name: xc
> Repository: xc/xc/lib/GL/mesa/src/drv/r200/
> Changes by: keithw@usw-pr-cvs1. 02/10/01 03:58:03
>
> Log message:
> A version of Felix's irq-wait patch
>
> Modified files:
> xc/xc/lib/GL/mesa/src/drv/r200/:
> r200_context.c r200_context.h r200_ioctl.c
>
> Revision ChangesPath
> 1.8 +1 -0 xc/xc/lib/GL/mesa/src/drv/r200/r200_context.c
> 1.5 +1 -0 xc/xc/lib/GL/mesa/src/drv/r200/r200_context.h
> 1.6 +43 -49xc/xc/lib/GL/mesa/src/drv/r200/r200_ioctl.c
>
>
>
> ---
> This sf.net email is sponsored by: DEDICATED SERVERS only $89!
> Linux or FreeBSD, FREE setup, FAST network. Get your own server
> today at http://www.ServePath.com/indexfm.htm
> ___
> Dri-patches mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-patches
>
>
__\|/_____ ___ ___
__Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_Felix___\Ä/\ \_\ \_\ \__U___just not everything
[EMAIL PROTECTED]>o<__/ \___/ \___/at the same time!
---
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server
today at http://www.ServePath.com/indexfm.htm
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Dienstag, 1. Oktober 2002 20:12 schrieb Linus Torvalds: > On Tue, 1 Oct 2002, Keith Whitwell wrote: > > Sounds like you aren't getting irq's, for some reason, and it is falling > > back to busy waiting. > > > > The question is why aren't you getting irq's? > > Keith, are you even asking the kernel to look up (and possibly enable) the > irq for you? > > The magic word isn't "please", it's "pci_enable_device(dev)", which will > check that all resources are allocated and enabled, including things like > trying to route irq's using the PIRQ table (or ACPI, or whatever). > > Doing a quick grep through the drm stuff doesn't show a single caller.. > > Btw, I'd like to also point out that some of DRI PCI bus handling seems > fundamentally broken. Like the notion that you can specify the device by > bus number, device and fn. Those days are past, I'm afraid, and were never > true on some other platforms. It can be a much more complicated tree, with > multiple independent PCI segments. You don't see that yet on regular PC's, > but get ready (and X in general should probably stop thinking that it can > do things like PCI configuration from user space). Ah, thanks Linus. 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. Should I try with ACPI disabled? I'll try 2.5.40 in a few seconds. -Dieter BTW radeonfb.c is broken in 2.5.40 at least. --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Tue, 1 Oct 2002, Keith Whitwell wrote: > > Sounds like you aren't getting irq's, for some reason, and it is falling back > to busy waiting. > > The question is why aren't you getting irq's? Keith, are you even asking the kernel to look up (and possibly enable) the irq for you? The magic word isn't "please", it's "pci_enable_device(dev)", which will check that all resources are allocated and enabled, including things like trying to route irq's using the PIRQ table (or ACPI, or whatever). Doing a quick grep through the drm stuff doesn't show a single caller.. Btw, I'd like to also point out that some of DRI PCI bus handling seems fundamentally broken. Like the notion that you can specify the device by bus number, device and fn. Those days are past, I'm afraid, and were never true on some other platforms. It can be a much more complicated tree, with multiple independent PCI segments. You don't see that yet on regular PC's, but get ready (and X in general should probably stop thinking that it can do things like PCI configuration from user space). Linus --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Keith Whitwell wrote: > 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 seconds = 114.708 FPS >> 590 frames in 5.006 seconds = 117.859 FPS > > I'm getting quite similar results: with xmms running in background: ~150 FPS with xmms paused: ~130 FPS after i unpause xmms, FPS will drop down very low (~10 FPS or s.th.) for about 1 or 2 seconds (system load is almost 100% during that period), and then go up to 150 again (with low sys-load) performance in q3a is also very poor for me at the moment (but it seems fairly stable (played for about 20 min. without lockup/crash, which is better than i used to get with earlier driver builds) wolfenstein sig11-ed after some minutes, however (no hardlock though, just the game crashed) system: 8500 LE, XP1800+, KT266A-mobo, dri-cvs (trunk) from 30 min ago, linux-2.4.19 (vanilla), debian unstable --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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 seconds = 114.708 FPS > 590 frames in 5.006 seconds = 117.859 FPS Sounds like you aren't getting irq's, for some reason, and it is falling back to busy waiting. The question is why aren't you getting irq's? Keith --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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 seconds = 114.708 FPS 590 frames in 5.006 seconds = 117.859 FPS Mesa/demos> ./isosurf 7179 vertices, 7177 triangles r200CreateScreen Nr unique vertex/normal pairs: 2723 num_tri_verts: 21531 primitive (0x1): GL_TRIANGLE_STRIP, render style (0x20): glVertex, enabling normal arrays new flags (0x8a92c29): glVertex, GL_TRIANGLE_STRIP, lit, r200_makeX86Normal3fv/197 CVAL 0 OFFSET 14 VAL 40666ee0 r200_makeX86Normal3fv/198 CVAL 4 OFFSET 20 VAL 40666ee4 r200_makeX86Normal3fv/199 CVAL 8 OFFSET 25 VAL 40666ee8 r200_makeX86Normal3fv done Benchmarking... Result: triangles/sec: 1.07841e+06 fps: 150.259 With setenv R200_NO_USLEEPS 1 Mesa/demos> ./gears r200CreateScreen 8847 frames in 5.000 seconds = 1769.400 FPS 11948 frames in 5.000 seconds = 2389.600 FPS 11960 frames in 5.000 seconds = 2392.000 FPS 11954 frames in 5.000 seconds = 2390.800 FPS 7179 vertices, 7177 triangles r200CreateScreen Nr unique vertex/normal pairs: 2723 num_tri_verts: 21531 primitive (0x1): GL_TRIANGLE_STRIP, render style (0x20): glVertex, enabling normal arrays new flags (0x8a92c29): glVertex, GL_TRIANGLE_STRIP, lit, r200_makeX86Normal3fv/197 CVAL 0 OFFSET 14 VAL 40666ee0 r200_makeX86Normal3fv/198 CVAL 4 OFFSET 20 VAL 40666ee4 r200_makeX86Normal3fv/199 CVAL 8 OFFSET 25 VAL 40666ee8 r200_makeX86Normal3fv done Benchmarking... Result: triangles/sec: 7.39662e+06 fps: 1030.6 Q3A With "R200_NO_USLEEPS 1" and without sound (quake3 +set s_initsound 0) it drops from 135.6 fps down to 107 fps. Without "R200_NO_USLEEPS 1" (normal DRI mode) and without sound it is running at poorly 38.1 fps! With sound it was 40,3/40,7/36,7 (three runs) fps. CPU load dropped dramatically from 99% (one CPU) down to expected 0,5-12,5% (whole system, SMP 2). -Dieter --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Felix Kühling wrote:
> On Sun, 29 Sep 2002 22:37:36 +0100
> Keith Whitwell <[EMAIL PROTECTED]> wrote:
>
>
>>Felix Kühling wrote:
>>
>>>On Sun, 29 Sep 2002 23:25:03 +0200
>>>Dieter Nützel <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>
> [snip]
>
Is r100/r200 a completely different thing?
If not why not a patch against both?
Then the testing audience should be much "wider".
>>>Sure. As far as I could see the code is very similar. However, this:
>>> rmesa->do_irqs = (0 &&
>>> rmesa->dri.drmMinor >= 6 &&
>>> !getenv("R200_NO_IRQS") &&
>>> rmesa->r200Screen->irq);
>>>looks like IRQs are turned off by default on R200. So my code wouldn't
>>>be used. Is the reason for IRQs being disabled that the frame throttling
>>>is not implemented properly or are there lower level problems with IRQs?
>>>
>>No, this is a hangover from the bugs last week. It can be removed now.
>>
>
> Ok, I just saw your commit. I'm working on it now. It will take a while,
> though. The code is ready but I want to compile it at least and I havn't
> enabled compiling the r200 driver. Is there a faster way than doing a
> make world after changing config.cf?
>
cd lib/GL/mesa/src/drv
make Makefile
make Makefiles
make depend
make
make install
Should work...
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Montag, 30. September 2002 01:45 schrieb Dieter Nützel:
> Am Montag, 30. September 2002 00:41 schrieb Dieter Nützel:
> > Am Sonntag, 29. September 2002 23:48 schrieb Felix Kühling:
> > > On Sun, 29 Sep 2002 22:37:36 +0100
> > >
> > > Keith Whitwell <[EMAIL PROTECTED]> wrote:
> > > > Felix Kühling wrote:
> > > > > On Sun, 29 Sep 2002 23:25:03 +0200
> > > > > Dieter Nützel <[EMAIL PROTECTED]> wrote:
> > >
> > > [snip]
> > >
> > > > >>Is r100/r200 a completely different thing?
> > > > >>If not why not a patch against both?
> > > > >>Then the testing audience should be much "wider".
> > > > >
> > > > > Sure. As far as I could see the code is very similar. However,
> > > > > this: rmesa->do_irqs = (0 &&
> > > > >rmesa->dri.drmMinor >= 6 &&
> > > > >!getenv("R200_NO_IRQS") &&
> > > > >rmesa->r200Screen->irq);
> > > > > looks like IRQs are turned off by default on R200. So my code
> > > > > wouldn't be used. Is the reason for IRQs being disabled that the
> > > > > frame throttling is not implemented properly or are there lower
> > > > > level problems with IRQs?
> > > >
> > > > No, this is a hangover from the bugs last week. It can be removed
> > > > now.
>
> GREAT.
> Even without Felix new stuff coming soon for the r200, CPU load drops from
> 100% (gears took 99%, the other CPU was 100% idle) down to 25% for gears on
> my dual Athlon MP 1900+.
>
> 1:28am up 10 min, 1 user, load average: 0.26, 0.28, 0.18
> 108 processes: 105 sleeping, 3 running, 0 zombie, 0 stopped
> CPU0 states: 8.0% user, 3.0% system, 0.0% nice, 88.3% idle
> CPU1 states: 11.0% user, 3.0% system, 0.0% nice, 85.3% idle
> Mem: 1032728K av, 594820K used, 437908K free, 0K shrd, 311180K
> buff Swap: 1028120K av, 0K used, 1028120K free
> 78272K cached
>
> PID USER PRI NI SIZE RSS SHARE WCHAN STAT %CPU %MEM TIME
> COMMAND
> 3422 nuetzel 15 0 77448 4356 1708 R24.6 0.4 1:21
> gears 3442 nuetzel 15 0 1448 1448 1212 R 0.5 0.1
> 0:02 top 1 root 15 0 212 212 176 schedule_ S 0.0 0.0
> 0:00 init 2 root 0K 0 00 0 migration SW0.0 0.0
> 0:00 migration_CPU0
> 3 root 0K 0 00 0 migration SW0.0 0.0 0:00
> migration_CPU1
> 4 root 15 0 00 0 context_t SW0.0 0.0 0:00
> keventd
>
>
> gears is a little bit slower
>
> Mesa/demos> ./gears
> r200CreateScreen
> 4000 frames in 5.001 seconds = 799.840 FPS
> 11608 frames in 5.000 seconds = 2321.600 FPS
> 11642 frames in 5.000 seconds = 2328.400 FPS
> 11612 frames in 5.001 seconds = 2321.936 FPS
> 11630 frames in 5.000 seconds = 2326.000 FPS
>
> then with "setenv R200_NO_USLEEPS 1" before
>
> Mesa/demos> ./gears
> r200CreateScreen
> 6465 frames in 5.000 seconds = 1293.000 FPS
> 11955 frames in 5.000 seconds = 2391.000 FPS
> 11954 frames in 5.000 seconds = 2390.800 FPS
> 11955 frames in 5.000 seconds = 2391.000 FPS
> 11954 frames in 5.000 seconds = 2390.800 FPS
Addition:
Q3A only run at full speed (135.6 fps @ 640x480x32) with "setenv
R200_NO_USLEEPS 1".
Without it Q3A is running at 66-76 fps (very shakily).
-Dieter
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Montag, 30. September 2002 00:41 schrieb Dieter Nützel:
> Am Sonntag, 29. September 2002 23:48 schrieb Felix Kühling:
> > On Sun, 29 Sep 2002 22:37:36 +0100
> >
> > Keith Whitwell <[EMAIL PROTECTED]> wrote:
> > > Felix Kühling wrote:
> > > > On Sun, 29 Sep 2002 23:25:03 +0200
> > > > Dieter Nützel <[EMAIL PROTECTED]> wrote:
> >
> > [snip]
> >
> > > >>Is r100/r200 a completely different thing?
> > > >>If not why not a patch against both?
> > > >>Then the testing audience should be much "wider".
> > > >
> > > > Sure. As far as I could see the code is very similar. However, this:
> > > >rmesa->do_irqs = (0 &&
> > > > rmesa->dri.drmMinor >= 6 &&
> > > > !getenv("R200_NO_IRQS") &&
> > > > rmesa->r200Screen->irq);
> > > > looks like IRQs are turned off by default on R200. So my code
> > > > wouldn't be used. Is the reason for IRQs being disabled that the
> > > > frame throttling is not implemented properly or are there lower level
> > > > problems with IRQs?
> > >
> > > No, this is a hangover from the bugs last week. It can be removed now.
GREAT.
Even without Felix new stuff coming soon for the r200, CPU load drops from
100% (gears took 99%, the other CPU was 100% idle) down to 25% for gears on
my dual Athlon MP 1900+.
1:28am up 10 min, 1 user, load average: 0.26, 0.28, 0.18
108 processes: 105 sleeping, 3 running, 0 zombie, 0 stopped
CPU0 states: 8.0% user, 3.0% system, 0.0% nice, 88.3% idle
CPU1 states: 11.0% user, 3.0% system, 0.0% nice, 85.3% idle
Mem: 1032728K av, 594820K used, 437908K free, 0K shrd, 311180K buff
Swap: 1028120K av, 0K used, 1028120K free 78272K
cached
PID USER PRI NI SIZE RSS SHARE WCHAN STAT %CPU %MEM TIME
COMMAND
3422 nuetzel 15 0 77448 4356 1708 R24.6 0.4 1:21 gears
3442 nuetzel 15 0 1448 1448 1212 R 0.5 0.1 0:02 top
1 root 15 0 212 212 176 schedule_ S 0.0 0.0 0:00 init
2 root 0K 0 00 0 migration SW0.0 0.0 0:00
migration_CPU0
3 root 0K 0 00 0 migration SW0.0 0.0 0:00
migration_CPU1
4 root 15 0 00 0 context_t SW0.0 0.0 0:00
keventd
gears is a little bit slower
Mesa/demos> ./gears
r200CreateScreen
4000 frames in 5.001 seconds = 799.840 FPS
11608 frames in 5.000 seconds = 2321.600 FPS
11642 frames in 5.000 seconds = 2328.400 FPS
11612 frames in 5.001 seconds = 2321.936 FPS
11630 frames in 5.000 seconds = 2326.000 FPS
then with "setenv R200_NO_USLEEPS 1" before
Mesa/demos> ./gears
r200CreateScreen
6465 frames in 5.000 seconds = 1293.000 FPS
11955 frames in 5.000 seconds = 2391.000 FPS
11954 frames in 5.000 seconds = 2390.800 FPS
11955 frames in 5.000 seconds = 2391.000 FPS
11954 frames in 5.000 seconds = 2390.800 FPS
Sleep well.
-Dieter
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Sonntag, 29. September 2002 23:48 schrieb Felix Kühling:
> On Sun, 29 Sep 2002 22:37:36 +0100
>
> Keith Whitwell <[EMAIL PROTECTED]> wrote:
> > Felix Kühling wrote:
> > > On Sun, 29 Sep 2002 23:25:03 +0200
> > > Dieter Nützel <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
> > >>Is r100/r200 a completely different thing?
> > >>If not why not a patch against both?
> > >>Then the testing audience should be much "wider".
> > >
> > > Sure. As far as I could see the code is very similar. However, this:
> > >rmesa->do_irqs = (0 &&
> > >rmesa->dri.drmMinor >= 6 &&
> > >!getenv("R200_NO_IRQS") &&
> > >rmesa->r200Screen->irq);
> > > looks like IRQs are turned off by default on R200. So my code wouldn't
> > > be used. Is the reason for IRQs being disabled that the frame
> > > throttling is not implemented properly or are there lower level
> > > problems with IRQs?
> >
> > No, this is a hangover from the bugs last week. It can be removed now.
>
> Ok, I just saw your commit. I'm working on it now. It will take a while,
> though. The code is ready but I want to compile it at least and I havn't
> enabled compiling the r200 driver. Is there a faster way than doing a
> make world after changing config.cf?
Is "make Everything" enough?
But on my dual Athlon MP 1900+ a whole DRI CVS compilation takes ~9 min;-)
xc/xc> time nice +19 make -j3 World >& world.log
484.570u 64.300s 9:09.37 99.9% 0+0k 0+0io 6244578pf+0w
That's why I'm offering my CPU time... Not every DRI developer has a SMP
system as I remember and so I think testing on SMP is needed.
Cheers,
Dieter
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Sun, 29 Sep 2002 22:37:36 +0100
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote:
> > On Sun, 29 Sep 2002 23:25:03 +0200
> > Dieter Nützel <[EMAIL PROTECTED]> wrote:
> >
> >
[snip]
> >>Is r100/r200 a completely different thing?
> >>If not why not a patch against both?
> >>Then the testing audience should be much "wider".
> >>
> >
> > Sure. As far as I could see the code is very similar. However, this:
> >rmesa->do_irqs = (0 &&
> > rmesa->dri.drmMinor >= 6 &&
> > !getenv("R200_NO_IRQS") &&
> > rmesa->r200Screen->irq);
> > looks like IRQs are turned off by default on R200. So my code wouldn't
> > be used. Is the reason for IRQs being disabled that the frame throttling
> > is not implemented properly or are there lower level problems with IRQs?
>
> No, this is a hangover from the bugs last week. It can be removed now.
Ok, I just saw your commit. I'm working on it now. It will take a while,
though. The code is ready but I want to compile it at least and I havn't
enabled compiling the r200 driver. Is there a faster way than doing a
make world after changing config.cf?
>
> Keith
>
Felix
__\|/_____ ___ ___
__Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_Felix___\Ä/\ \_\ \_\ \__U___just not everything
[EMAIL PROTECTED]>o<__/ \___/ \___/at the same time!
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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 PROTECTED]> wrote:
>CVSROOT: /cvsroot/dri
>Module name: xc
>Repository:xc/xc/lib/GL/mesa/src/drv/radeon/
>Changes by:keithw@usw-pr-cvs1. 02/09/29 13:22:44
>
>Log message:
> irqwait patch from felix
>
>Modified files:
> xc/xc/lib/GL/mesa/src/drv/radeon/:
>radeon_context.c radeon_context.h radeon_ioctl.c
>
> Revision ChangesPath
> 1.19 +1 -0
>xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c 1.15 +1 -0
> xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.h 1.27 +54
>-49xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c
>
Thanks for applying. However, this was yesterday's patch ;-). Just cvs
updated my tree and made a patch of my NEW waiting code against the
latest trunk. See "[patch] smart irq/busy wait in
radeonWaitForFrameCompletion" on dri-devel. I just realized that I
forgot to include radeon_context.[ch] in the patch posted with that
mail. :-| This one is complete.
>>>Oops, forgot one debug message. Could you remove
>>> fprintf (stderr, "Waited %d.\r", wait);
>>>from radeon_ioctl.c line 692 manually? I don't want to spam the list
>>>with patches.
>>>
>>Is r100/r200 a completely different thing?
>>If not why not a patch against both?
>>Then the testing audience should be much "wider".
>>
>
> Sure. As far as I could see the code is very similar. However, this:
>rmesa->do_irqs = (0 &&
>rmesa->dri.drmMinor >= 6 &&
>!getenv("R200_NO_IRQS") &&
>rmesa->r200Screen->irq);
> looks like IRQs are turned off by default on R200. So my code wouldn't
> be used. Is the reason for IRQs being disabled that the frame throttling
> is not implemented properly or are there lower level problems with IRQs?
No, this is a hangover from the bugs last week. It can be removed now.
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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 PROTECTED]> wrote:
> > > > CVSROOT:/cvsroot/dri
> > > > Module name:xc
> > > > Repository: xc/xc/lib/GL/mesa/src/drv/radeon/
> > > > Changes by: keithw@usw-pr-cvs1. 02/09/29 13:22:44
> > > >
> > > > Log message:
> > > > irqwait patch from felix
> > > >
> > > > Modified files:
> > > > xc/xc/lib/GL/mesa/src/drv/radeon/:
> > > > radeon_context.c radeon_context.h radeon_ioctl.c
> > > >
> > > > Revision ChangesPath
> > > > 1.19 +1 -0
> > > > xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c 1.15 +1 -0
> > > >xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.h 1.27 +54
> > > > -49xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c
> > >
> > > Thanks for applying. However, this was yesterday's patch ;-). Just cvs
> > > updated my tree and made a patch of my NEW waiting code against the
> > > latest trunk. See "[patch] smart irq/busy wait in
> > > radeonWaitForFrameCompletion" on dri-devel. I just realized that I
> > > forgot to include radeon_context.[ch] in the patch posted with that
> > > mail. :-| This one is complete.
> >
> > Oops, forgot one debug message. Could you remove
> >fprintf (stderr, "Waited %d.\r", wait);
> > from radeon_ioctl.c line 692 manually? I don't want to spam the list
> > with patches.
>
> Is r100/r200 a completely different thing?
> If not why not a patch against both?
> Then the testing audience should be much "wider".
Sure. As far as I could see the code is very similar. However, this:
rmesa->do_irqs = (0 &&
rmesa->dri.drmMinor >= 6 &&
!getenv("R200_NO_IRQS") &&
rmesa->r200Screen->irq);
looks like IRQs are turned off by default on R200. So my code wouldn't
be used. Is the reason for IRQs being disabled that the frame throttling
is not implemented properly or are there lower level problems with IRQs?
> Thanks,
> Dieter
Felix
__\|/_____ ___ ___
__Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_Felix___\Ä/\ \_\ \_\ \__U___just not everything
[EMAIL PROTECTED]>o<__/ \___/ \___/at the same time!
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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 PROTECTED]> wrote: > > > CVSROOT: /cvsroot/dri > > > Module name: xc > > > Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ > > > Changes by: keithw@usw-pr-cvs1. 02/09/29 13:22:44 > > > > > > Log message: > > > irqwait patch from felix > > > > > > Modified files: > > > xc/xc/lib/GL/mesa/src/drv/radeon/: > > > radeon_context.c radeon_context.h radeon_ioctl.c > > > > > > Revision ChangesPath > > > 1.19 +1 -0 > > > xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c 1.15 +1 -0 > > >xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.h 1.27 +54 > > > -49xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c > > > > Thanks for applying. However, this was yesterday's patch ;-). Just cvs > > updated my tree and made a patch of my NEW waiting code against the > > latest trunk. See "[patch] smart irq/busy wait in > > radeonWaitForFrameCompletion" on dri-devel. I just realized that I > > forgot to include radeon_context.[ch] in the patch posted with that > > mail. :-| This one is complete. > > Oops, forgot one debug message. Could you remove >fprintf (stderr, "Waited %d.\r", wait); > from radeon_ioctl.c line 692 manually? I don't want to spam the list > with patches. Is r100/r200 a completely different thing? If not why not a patch against both? Then the testing audience should be much "wider". Thanks, Dieter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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 PROTECTED]> wrote: > > > CVSROOT:/cvsroot/dri > > Module name:xc > > Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ > > Changes by: keithw@usw-pr-cvs1. 02/09/29 13:22:44 > > > > Log message: > > irqwait patch from felix > > > > Modified files: > > xc/xc/lib/GL/mesa/src/drv/radeon/: > > radeon_context.c radeon_context.h radeon_ioctl.c > > > > Revision ChangesPath > > 1.19 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c > > 1.15 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.h > > 1.27 +54 -49xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c > > Thanks for applying. However, this was yesterday's patch ;-). Just cvs > updated my tree and made a patch of my NEW waiting code against the > latest trunk. See "[patch] smart irq/busy wait in > radeonWaitForFrameCompletion" on dri-devel. I just realized that I > forgot to include radeon_context.[ch] in the patch posted with that > mail. :-| This one is complete. Oops, forgot one debug message. Could you remove fprintf (stderr, "Waited %d.\r", wait); from radeon_ioctl.c line 692 manually? I don't want to spam the list with patches. Thanks, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Sun, 29 Sep 2002 13:22:44 -0700 Keith Whitwell <[EMAIL PROTECTED]> wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ > Changes by: keithw@usw-pr-cvs1. 02/09/29 13:22:44 > > Log message: > irqwait patch from felix > > Modified files: > xc/xc/lib/GL/mesa/src/drv/radeon/: > radeon_context.c radeon_context.h radeon_ioctl.c > > Revision ChangesPath > 1.19 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c > 1.15 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.h > 1.27 +54 -49xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c Thanks for applying. However, this was yesterday's patch ;-). Just cvs updated my tree and made a patch of my NEW waiting code against the latest trunk. See "[patch] smart irq/busy wait in radeonWaitForFrameCompletion" on dri-devel. I just realized that I forgot to include radeon_context.[ch] in the patch posted with that mail. :-| This one is complete. Best regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! radeon_smartwait.patch Description: Binary data
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Fre, 2002-09-27 at 22:42, Keith Whitwell wrote: > Michel Dänzer wrote: > > On Fre, 2002-09-27 at 18:51, Keith Whitwell wrote: > > > It's a big hack to be doing this. > > > > > BTW it also seems to work for him without writing to GEN_INT_CNTL all > > the time, i.e. only acknowledging the bits in GEN_INT_STATUS. Would that > > make it slightly less hackish? :) > > > > A small hack is better than a big one... True. Patch updated and committed. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Dänzer wrote: > On Fre, 2002-09-27 at 18:51, Keith Whitwell wrote: > It's a big hack to be doing this. > > BTW it also seems to work for him without writing to GEN_INT_CNTL all > the time, i.e. only acknowledging the bits in GEN_INT_STATUS. Would that > make it slightly less hackish? :) > A small hack is better than a big one... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Fre, 2002-09-27 at 18:51, Keith Whitwell wrote: > > >> > >>It's a big hack to be doing this. BTW it also seems to work for him without writing to GEN_INT_CNTL all the time, i.e. only acknowledging the bits in GEN_INT_STATUS. Would that make it slightly less hackish? :) > >> 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, I'll commit it later tonight. > > > > > > > >>Maybe I should be more pedantic about things... > >> > > > > Well, I'd rather you wouldn't be speaking in riddles. > > Just about committing code that is a hack-around without really understanding > what's going on. I think it's more or less inevitable, however, with all the > different bits of hardware interacting with each other & us in the middle > trying to sort it out. Yeah, this is pretty complex stuff we're dealing with. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On 27 Sep 2002 18:46:20 +0200 Michel Dänzer <[EMAIL PROTECTED]> wrote: > > > (BTW it would have been a pain in the neck for him to debug this without > > > reinit) I agree ! > > OK, I see it now. > > > > 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 > :) Why not simply re-enabling IRQ, and wait to see if I'm the only one which have this problem? (do we have more reports than me for this?) Perhaps it's my hardware somewhere which lost somes interrupts some times (about 1500 interupts per seconds isn't it high?) My hardware is: Motherboard k7s5a (chipset sis 735) Processor: Athlon Thunderbird @ 1000Mhz The tests was done with shared irq (IO-APIC), and without (just the card with it's irq) -> should I investigate more here? The radeon card is a 8500 "powered by ATI". I also notified network and/or sound stoping working while playing with 3D (irq enabled). Stoping playing with 3D re-enable network and/or sound. With the patch of Michel, it doesn't seem to arrive again, but i need to do more testings to be sure. - nicolas (nicod) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Fri, 2002-09-27 at 17:01, Michel Dänzer wrote: > > Yep, but I guess you have to worry about then going to sleep *after* the > > interrupt has arrived, if there is a delay in getting the scratch write across > > the bus, compared to the irq, which should be instantaneous. > > Is that really an issue? The scratch register is written to before the > interrupt is triggered, so I'd expect a register read to yield the > correct value when the interrupt has arrived. Interrupt delivery on x86 is extremely asynchronous on some systems - especially Pentium II/Pentium III SMP boxes. You can sometimes see situations like IRQ raised driver clear irq allowed flag driver reads PCI bus to force posting driver free some resources IRQ arruves driver explodes In almost all cases PCI/IRQ synchronization isnt quite what you might intuitively wish for or expect. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
>> >>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, I'll commit it later tonight. > > > >>Maybe I should be more pedantic about things... >> > > Well, I'd rather you wouldn't be speaking in riddles. Just about committing code that is a hack-around without really understanding what's going on. I think it's more or less inevitable, however, with all the different bits of hardware interacting with each other & us in the middle trying to sort it out. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Fre, 2002-09-27 at 18:11, Keith Whitwell wrote: > Michel Dänzer wrote: > > On Fre, 2002-09-27 at 16:47, Keith Whitwell wrote: > > > >>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, it could be made more robust. > > > >>>Do you think the approach with a scratch register is good? > >>> > >>Yep, but I guess you have to worry about then going to sleep *after* the > >>interrupt has arrived, if there is a delay in getting the scratch write across > >>the bus, compared to the irq, which should be instantaneous. > >> > > > > Is that really an issue? The scratch register is written to before the > > interrupt is triggered, so I'd expect a register read to yield the > > correct value when the interrupt has arrived. > > I was under the understanding that the scratch registers were actually > 'shadows' in main memory, updated by the card across the agp bus. If so, I > don't think there's any guarantee of synchronization with the irq delivery. > Maybe it's not a real risk, but certainly worthwhile to keep it in mind. That's one reason why I don't use writeback for this one. It should normally only be read once or twice per interrupt anyway. > We shoudl add diagnostics to the -EBUSY case in wait_irq to try and figure out > what has happened -- particularly have the interrupts been disabled? > > > >>>Turns out they haven't. GEN_INT_CNTL looks exactly like it should. > >>>Interestingly, the GEN_INT_STATUS bits are set as well, and > >>>acknowledging them helps. So it seems that somehow, the service routine > >>>didn't get called for an interrupt, or the acknowledgement got lost. > >>> > >>>If the updated patch works for you as well, I'll commit it. > >>> > >>The patch doesn't seem to do anything about this case, just print something out... > >> > > > > Are we talking about the same patch, > > http://penguinppc.org/~daenzer/DRI/radeon-swi-scratch.diff with md5sum > > 6abf27a2a1d6a4e57a8c36b19ef0e17b? It worked fine for nicod yesterday... > > (BTW it would have been a pain in the neck for him to debug this without > > reinit) > > OK, I see it now. > > 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, I'll commit it later tonight. > Maybe I should be more pedantic about things... Well, I'd rather you wouldn't be speaking in riddles. ;) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Dänzer wrote: > On Fre, 2002-09-27 at 16:47, Keith Whitwell wrote: > >>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, it could be made more robust. >>>Do you think the approach with a scratch register is good? >>> >>Yep, but I guess you have to worry about then going to sleep *after* the >>interrupt has arrived, if there is a delay in getting the scratch write across >>the bus, compared to the irq, which should be instantaneous. >> > > Is that really an issue? The scratch register is written to before the > interrupt is triggered, so I'd expect a register read to yield the > correct value when the interrupt has arrived. I was under the understanding that the scratch registers were actually 'shadows' in main memory, updated by the card across the agp bus. If so, I don't think there's any guarantee of synchronization with the irq delivery. Maybe it's not a real risk, but certainly worthwhile to keep it in mind. > > >>... >> >> We shoudl add diagnostics to the -EBUSY case in wait_irq to try and figure out what has happened -- particularly have the interrupts been disabled? >>>Turns out they haven't. GEN_INT_CNTL looks exactly like it should. >>>Interestingly, the GEN_INT_STATUS bits are set as well, and >>>acknowledging them helps. So it seems that somehow, the service routine >>>didn't get called for an interrupt, or the acknowledgement got lost. >>> >>>If the updated patch works for you as well, I'll commit it. >>> >>The patch doesn't seem to do anything about this case, just print something out... >> > > Are we talking about the same patch, > http://penguinppc.org/~daenzer/DRI/radeon-swi-scratch.diff with md5sum > 6abf27a2a1d6a4e57a8c36b19ef0e17b? It worked fine for nicod yesterday... > (BTW it would have been a pain in the neck for him to debug this without > reinit) OK, I see it now. It's a big hack to be doing this. I'd really like to know why this happens, but in the mean time I'm ok to see it go in. Maybe I should be more pedantic about things... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Fre, 2002-09-27 at 16:47, Keith Whitwell wrote: > 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, it could be made more robust. > >> > > > > Do you think the approach with a scratch register is good? > > Yep, but I guess you have to worry about then going to sleep *after* the > interrupt has arrived, if there is a delay in getting the scratch write across > the bus, compared to the irq, which should be instantaneous. Is that really an issue? The scratch register is written to before the interrupt is triggered, so I'd expect a register read to yield the correct value when the interrupt has arrived. > ... > > >>We shoudl add diagnostics to the -EBUSY case in wait_irq to try and figure out > >>what has happened -- particularly have the interrupts been disabled? > >> > > > > Turns out they haven't. GEN_INT_CNTL looks exactly like it should. > > Interestingly, the GEN_INT_STATUS bits are set as well, and > > acknowledging them helps. So it seems that somehow, the service routine > > didn't get called for an interrupt, or the acknowledgement got lost. > > > > If the updated patch works for you as well, I'll commit it. > > The patch doesn't seem to do anything about this case, just print something out... Are we talking about the same patch, http://penguinppc.org/~daenzer/DRI/radeon-swi-scratch.diff with md5sum 6abf27a2a1d6a4e57a8c36b19ef0e17b? It worked fine for nicod yesterday... (BTW it would have been a pain in the neck for him to debug this without reinit) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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, it could be made more robust. >> > > Do you think the approach with a scratch register is good? Yep, but I guess you have to worry about then going to sleep *after* the interrupt has arrived, if there is a delay in getting the scratch write across the bus, compared to the irq, which should be instantaneous. ... >>We shoudl add diagnostics to the -EBUSY case in wait_irq to try and figure out >>what has happened -- particularly have the interrupts been disabled? >> > > Turns out they haven't. GEN_INT_CNTL looks exactly like it should. > Interestingly, the GEN_INT_STATUS bits are set as well, and > acknowledging them helps. So it seems that somehow, the service routine > didn't get called for an interrupt, or the acknowledgement got lost. > > If the updated patch works for you as well, I'll commit it. The patch doesn't seem to do anything about this case, just print something out... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
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, it could be made more robust. Do you think the approach with a scratch register is good? > > Moreover, nicod on IRC reports that IRQs stop working for him in the > > middle of glxgears running. So I thought let's make really really sure > > they are enabled in the DRM instead of doing it in the 2D driver and > > praying. The result is > > > > http://penguinppc.org/~daenzer/DRI/radeon-swi-scratch.diff > > > > but unfortunately, it doesn't seem to really help with the second issue. > > Can anyone think of a way how the IRQs can get disabled in the chip with > > this? Could writing to GEN_INT_CNTL too often actually hurt? Works fine > > here though... > > > > At least, with this patch it keeps running at about the same speed as > > with usleeps when the IRQs go nuts. > > We shoudl add diagnostics to the -EBUSY case in wait_irq to try and figure out > what has happened -- particularly have the interrupts been disabled? Turns out they haven't. GEN_INT_CNTL looks exactly like it should. Interestingly, the GEN_INT_STATUS bits are set as well, and acknowledging them helps. So it seems that somehow, the service routine didn't get called for an interrupt, or the acknowledgement got lost. If the updated patch works for you as well, I'll commit it. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Dänzer wrote: > On Don, 2002-09-26 at 10:24, Eric Anholt wrote: > >>On Thu, 2002-09-26 at 00:58, Eric Anholt wrote: >> >>>CVSROOT: /cvsroot/dri >>>Module name: xc >>>Repository: xc/xc/lib/GL/mesa/src/drv/r200/ >>>Changes by: anholt@usw-pr-cvs1. 02/09/26 00:58:14 >>> >>>Log message: >>> R200 sync-to-vblank support (set LIBGL_THROTTLE_REFRESH=1) >>> >>Okay, that concludes things for tonight. It's building and running >>nicely on my end but I've got some more patches here, so yell if I broke >>something. >> >>I've got the mga patches, but I'm missing one versioning check, I'm not >>sure about what to do with the radeon stuff in drm_dma.h, >> > > Mea culpa, moved back to radeon_irq.c. > > >>and I'm tired. They sync to vsync rather than vblank, though vblank >>should be possible with some work. It survived vtswitch on BSD >>without any extra reg-saving code in the 2d, but I would like to make >>sure the reg-saving is correct before committing that. >> > > Maybe the mga 2D driver simply doesn't mess with the IRQ control > register(s). > > > 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, it could be made more robust. > Moreover, nicod on IRC reports that IRQs stop working for him in the > middle of glxgears running. So I thought let's make really really sure > they are enabled in the DRM instead of doing it in the 2D driver and > praying. The result is > > http://penguinppc.org/~daenzer/DRI/radeon-swi-scratch.diff > > but unfortunately, it doesn't seem to really help with the second issue. > Can anyone think of a way how the IRQs can get disabled in the chip with > this? Could writing to GEN_INT_CNTL too often actually hurt? Works fine > here though... > > At least, with this patch it keeps running at about the same speed as > with usleeps when the IRQs go nuts. We shoudl add diagnostics to the -EBUSY case in wait_irq to try and figure out what has happened -- particularly have the interrupts been disabled? The other thing that I have floating around in my head is the idea that someone out there, kernel, motherboard, I don't know who, is blocking them defensively -- too many interrupts, stops processing them. I don't know if this is realistic. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Don, 2002-09-26 at 10:24, Eric Anholt wrote: > On Thu, 2002-09-26 at 00:58, Eric Anholt wrote: > > CVSROOT:/cvsroot/dri > > Module name:xc > > Repository: xc/xc/lib/GL/mesa/src/drv/r200/ > > Changes by: anholt@usw-pr-cvs1. 02/09/26 00:58:14 > > > > Log message: > > R200 sync-to-vblank support (set LIBGL_THROTTLE_REFRESH=1) > > Okay, that concludes things for tonight. It's building and running > nicely on my end but I've got some more patches here, so yell if I broke > something. > > I've got the mga patches, but I'm missing one versioning check, I'm not > sure about what to do with the radeon stuff in drm_dma.h, Mea culpa, moved back to radeon_irq.c. > and I'm tired. They sync to vsync rather than vblank, though vblank > should be possible with some work. It survived vtswitch on BSD > without any extra reg-saving code in the 2d, but I would like to make > sure the reg-saving is correct before committing that. Maybe the mga 2D driver simply doesn't mess with the IRQ control register(s). 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. Moreover, nicod on IRC reports that IRQs stop working for him in the middle of glxgears running. So I thought let's make really really sure they are enabled in the DRM instead of doing it in the 2D driver and praying. The result is http://penguinppc.org/~daenzer/DRI/radeon-swi-scratch.diff but unfortunately, it doesn't seem to really help with the second issue. Can anyone think of a way how the IRQs can get disabled in the chip with this? Could writing to GEN_INT_CNTL too often actually hurt? Works fine here though... At least, with this patch it keeps running at about the same speed as with usleeps when the IRQs go nuts. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Eric Anholt wrote: > On Thu, 2002-09-26 at 00:58, Eric Anholt wrote: > >>CVSROOT: /cvsroot/dri >>Module name: xc >>Repository: xc/xc/lib/GL/mesa/src/drv/r200/ >>Changes by: anholt@usw-pr-cvs1. 02/09/26 00:58:14 >> >>Log message: >> R200 sync-to-vblank support (set LIBGL_THROTTLE_REFRESH=1) >> > > Okay, that concludes things for tonight. It's building and running > nicely on my end but I've got some more patches here, so yell if I broke > something. > > I've got the mga patches, but I'm missing one versioning check, I'm not > sure about what to do with the radeon stuff in drm_dma.h, and I'm > tired. They sync to vsync rather than vblank, though vblank should be > possible with some work. It survived vtswitch on BSD without any extra > reg-saving code in the 2d, but I would like to make sure the reg-saving > is correct before committing that. I just tried to build & run this on freebsd. Have you tried turning the original interrupt code back on? See Line 422 in radeon_context.c. I got an immediate failure when running gears on freebsd -- same behaviour, looks like it isn't getting an irq back after requesting one. The difference is now you don't have to run quake first, so it looks like there's been a regression. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Thu, 2002-09-26 at 00:58, Eric Anholt wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/src/drv/r200/ > Changes by: anholt@usw-pr-cvs1. 02/09/26 00:58:14 > > Log message: > R200 sync-to-vblank support (set LIBGL_THROTTLE_REFRESH=1) Okay, that concludes things for tonight. It's building and running nicely on my end but I've got some more patches here, so yell if I broke something. I've got the mga patches, but I'm missing one versioning check, I'm not sure about what to do with the radeon stuff in drm_dma.h, and I'm tired. They sync to vsync rather than vblank, though vblank should be possible with some work. It survived vtswitch on BSD without any extra reg-saving code in the 2d, but I would like to make sure the reg-saving is correct before committing that. -- Eric Anholt <[EMAIL PROTECTED]> http://people.freebsd.org/~anholt/dri/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Daenzer wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ > Changes by: mdaenzer@usw-pr-cvs1. 02/09/25 10:17:37 > > Log message: > IRQ related fixes > > Modified files: > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > radeon.h radeon_dri.c radeon_driver.c > > Revision ChangesPath > 1.29 +2 -0 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.h > 1.33 +8 -0 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c > 1.30 +5 -0 >xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c Michel, Have you seen the bug discussed earlier where the irq code seems to stop generating irq's after a period running eg. the q3 menu screen? Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Fri, Jul 05, 2002 at 02:23:49PM +0100, Alan Hourihane wrote: >On Fri, Jul 05, 2002 at 01:51:50PM +0100, José Fonseca wrote: [...] >> >> Yes, that seems cleaner, since I won't have to bother eliminating the >> compiled stuff away. > >Yep. > >> >What does 'uname -s' return on NetBSD and FreeBSD ? >> >> On the FreeBSD of SF compiler farm it return 'FreeBSD'. > >Just massage the scripts for these cases and copy from the bsd directory >instead. All done. Ok. I've updated the scripts for both things, but I got a lot of errors (missing defines etc) when trying to build the DRM on a machine, and only the most simple DRM got built (tdfx and glint if I'm not mistaken). Is there any missing or did I do something wrong? I also tried to run the script on CF FreeBSD server but it seems that I've been using some GNU specific features of some programs (make -C failed) so it will take a little more massages. I also don't know how the BSD kernel modules(?) works (and the scripts neither!) I don't know what's the demand for BSD binary snapshots, but if someone more keen on BSD wants to give it a try take a look on the http://dri.sf.net/snapshots/scripts/README for an updated description and information on how to use this scripts. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Dänzer wrote: > On Wed, 2002-06-26 at 10:32, Keith Whitwell wrote: > >>CVSROOT: /cvsroot/dri >>Module name: xc >>Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ >>Changes by: keithw@usw-pr-cvs1. 02/06/26 01:32:32 >> >>Log message: >> Fog correction >> > > Out of curiosity, what was the problem? A typo -- a malformed statement like rmesa->hw.ctx.cmd[VTX_FOO] which should have been rmesa->hw.vtx.cmd[VTX_FOO] Picked this up in the r200 driver because it was causing a malformed packet there. Keith --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Wed, 2002-06-26 at 10:32, Keith Whitwell wrote: > CVSROOT: /cvsroot/dri > Module name: xc > Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ > Changes by: keithw@usw-pr-cvs1. 02/06/26 01:32:32 > > Log message: > Fog correction Out of curiosity, what was the problem? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Dänzer wrote: > > On Mon, 2001-11-26 at 14:28, Keith Whitwell wrote: > > > Log message: > > Put drm version back from 3.0 to 2.2; XFree86 4.1 is the baseline for > > versioning information. > > > > Modified files: > > xc/xc/lib/GL/mesa/src/drv/r128/: > > r128_xmesa.c > > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > > r128_dri.c > > xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: > > r128_drv.c > > > > Revision ChangesPath > > 1.25 +3 -3 xc/xc/lib/GL/mesa/src/drv/r128/r128_xmesa.c > > 1.27 +3 -3 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/r128_dri.c > > 1.42 +2 -2 >xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128_drv.c > > But you're aware that the major should have been bumped for 4.1 already? > It doesn't work with 4.0.x DRM and vice versa. Yes. That's life. What's important is compatibility of future versions with 4.1. 4.0 is a lost cause. Bumping the version number now doesn't make up for not doing it earlier, and even worse, we've promised not to bump the version numbers from the 4.1 base line without *extremely* good reason. Keith _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Mon, Nov 26, 2001 at 02:51:18PM +0100, Michel Dänzer wrote: >On Mon, 2001-11-26 at 14:28, Keith Whitwell wrote: > >> Log message: >> Put drm version back from 3.0 to 2.2; XFree86 4.1 is the baseline for >> versioning information. >> >> Modified files: >> xc/xc/lib/GL/mesa/src/drv/r128/: >> r128_xmesa.c >> xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: >> r128_dri.c >> xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: >> r128_drv.c >> >> Revision ChangesPath >> 1.25 +3 -3 xc/xc/lib/GL/mesa/src/drv/r128/r128_xmesa.c >> 1.27 +3 -3 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/r128_dri.c >> 1.42 +2 -2 >xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128_drv.c > >But you're aware that the major should have been bumped for 4.1 already? >It doesn't work with 4.0.x DRM and vice versa. It should have been bumped for 4.1, but wasn't. Bumping it after 4.1 will just cause an unnecessary incompatibility for the 4.1 -> 4.2 step while still not resolving the 4.0.x -> 4.1 incompatibility. I think the best thing is to use the versioning in 4.1 as the baseline. David -- David Dawes Email: [EMAIL PROTECTED] Founder/President, Release Engineer Phone: +1 570 764 0288 The XFree86 Project, Inc http://www.xfree86.org/~dawes ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Mon, 2001-11-26 at 14:28, Keith Whitwell wrote: > Log message: > Put drm version back from 3.0 to 2.2; XFree86 4.1 is the baseline for > versioning information. > > Modified files: > xc/xc/lib/GL/mesa/src/drv/r128/: > r128_xmesa.c > xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: > r128_dri.c > xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: > r128_drv.c > > Revision ChangesPath > 1.25 +3 -3 xc/xc/lib/GL/mesa/src/drv/r128/r128_xmesa.c > 1.27 +3 -3 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/r128_dri.c > 1.42 +2 -2 >xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128_drv.c But you're aware that the major should have been bumped for 4.1 already? It doesn't work with 4.0.x DRM and vice versa. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Tue, Sep 11, 2001 at 09:19:42AM -0700, Eric Anholt wrote: > Well, trunk kernel modules won't compile, but bsd-2-0-0-branch will usually > compile and run most of the cards (rage128 is really slow, and i810 is not > supported). I have patches for compiling the kernel modules, and a port of > them, up at my webpage: http://gladstone.uoregon.edu/~eanholt/dri/ Unfortunately I'm compiling under -current and the bsd-2-0-0-branch doesn't support that yet. I'm happy to help out, but at this point I don't even understand which modules I need to use to get DRI to run. Joe PGP signature
