Re: ColorTiling issue on r420
On 8/25/05, Aapo Tahkola <[EMAIL PROTECTED]> wrote: > On Thu, 25 Aug 2005 16:19:19 +0200 > Roland Scheidegger <[EMAIL PROTECTED]> wrote: > > > Aapo Tahkola wrote: > > > That check doesnt currently seem to work because some setup(at > > > preinit) with color tiling enabled will get done earlier. > > > > > > Does this version break r200s or radeons? > > From the top of my head, I think it does. For certain 16bit resolutions, > > that is (as the resolution won't be a multiple of 2048 bits wide, which > > is the block width of those chips for color tiling - i.e. 64 pixels for > > 32bit, 128 pixels for 16bit). That said, I think the use of > > info->MaxSurfaceWidth doesn't make any sense there, it is pure > > coincidence that "2048" is the same (in pixels) for the max width as it > > is (in bits) for the pitch increment. Isn't the block width of the r300 > > based chips 2048 bits too? > > It seems to be. > Should be fixed in cvs. Alex > -- > Aapo Tahkola > > --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300/ppc] lockups
On Thu, 2005-08-25 at 23:42 +0200, Jerome Glisse wrote: > IIRC there have been a patch to xorg for that and to DRM > too. Give it a try :) For whatever reason, I can't seem to build xorg right now. I'll have a try another time, but thanks for the heads-up. johannes signature.asc Description: This is a digitally signed message part
Re: [r300/ppc] lockups
On Thu, 2005-08-25 at 23:26 +0200, Johannes Berg wrote: > On Wed, 2005-06-22 at 18:36 +1000, Benjamin Herrenschmidt wrote: > > > The problem is simple: when setting up the AGP aperture, it's putting it > > after the framebuffer + CONFIG_APER_SIZE, which is wrong. On that guy, > > CONFIG_APER_SIZE might only be _half_ of the mapped vram space (as the > > card can be setup for 2 contiguous apertures). > > > > We need to make sure the DRM uses what is in MC_FB_LOCATION "top", and > > that itself should be set ideally to > > max(CONFIG_APER_SIZE*2,CONFIG_MEMSIZE) to avoid any possible kind of > > overlap. > > Has this been changed by now? i.e. should I try again? Not sure my patch got merged, I'll have to dig into that again. Ben. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300/ppc] lockups
On 8/25/05, Johannes Berg <[EMAIL PROTECTED]> wrote: > On Wed, 2005-06-22 at 18:36 +1000, Benjamin Herrenschmidt wrote: > > > The problem is simple: when setting up the AGP aperture, it's putting it > > after the framebuffer + CONFIG_APER_SIZE, which is wrong. On that guy, > > CONFIG_APER_SIZE might only be _half_ of the mapped vram space (as the > > card can be setup for 2 contiguous apertures). > > > > We need to make sure the DRM uses what is in MC_FB_LOCATION "top", and > > that itself should be set ideally to > > max(CONFIG_APER_SIZE*2,CONFIG_MEMSIZE) to avoid any possible kind of > > overlap. > > Has this been changed by now? i.e. should I try again? > > johannes > IIRC there have been a patch to xorg for that and to DRM too. Give it a try :) Jerome Glisse --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R280 texture pipe bug still there [PATCH]
On 8/25/05, Philipp Klaus Krause <[EMAIL PROTECTED]> wrote: > > > > > > > believe it or not pkgconfig actually makes your life easier...once you > > get to know it ;) It's the unix way. It basically tells you where to > > find header information for various packages. You copy the package's > > .pc file to the pkgconfig directory (often /usr/lib/pkgconfig). then > > try and build again. > > > > Alex > > > To someone just wanting to get DRI working the libdrm stuff makes things > more complicated. I think libdrm just just install itself to some > location where it is found by pkgconfig by default, so that one > doesn't have to learn about pkgconfig just to compile Mesa. > well, once libdrm becomes standard in distributions, that will be the case. You are using development code you must remember. Alex > Philipp > --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R280 texture pipe bug still there [PATCH]
> > > believe it or not pkgconfig actually makes your life easier...once you > get to know it ;) It's the unix way. It basically tells you where to > find header information for various packages. You copy the package's > .pc file to the pkgconfig directory (often /usr/lib/pkgconfig). then > try and build again. > > Alex To someone just wanting to get DRI working the libdrm stuff makes things more complicated. I think libdrm just just install itself to some location where it is found by pkgconfig by default, so that one doesn't have to learn about pkgconfig just to compile Mesa. Philipp --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300/ppc] lockups
On Wed, 2005-06-22 at 18:36 +1000, Benjamin Herrenschmidt wrote: > The problem is simple: when setting up the AGP aperture, it's putting it > after the framebuffer + CONFIG_APER_SIZE, which is wrong. On that guy, > CONFIG_APER_SIZE might only be _half_ of the mapped vram space (as the > card can be setup for 2 contiguous apertures). > > We need to make sure the DRM uses what is in MC_FB_LOCATION "top", and > that itself should be set ideally to > max(CONFIG_APER_SIZE*2,CONFIG_MEMSIZE) to avoid any possible kind of > overlap. Has this been changed by now? i.e. should I try again? johannes signature.asc Description: This is a digitally signed message part
Re: 'OcclusionTest' is missing (r200, i915, etc.), since last checkin
Am Donnerstag, 25. August 2005 21:37 schrieb Brian Paul: > Dieter Nützel wrote: > > i830_metaops.c: In function `i830TryTextureDrawPixels': > > i830_metaops.c:628: error: structure has no member named `OcclusionTest' > > make[6]: *** [i830_metaops.o] Fehler 1 > > make[6]: Leaving directory `/opt/Mesa/src/mesa/drivers/dri/i915' > > > > -DGLX_DIRECT_RENDERING -DHAVE_ALIAS r200_pixel.c -o r200_pixel.o > > r200_pixel.c: In function `check_color_per_fragment_ops': > > r200_pixel.c:97: error: structure has no member named `OcclusionTest' > > make[6]: *** [r200_pixel.o] Fehler 1 > > Fixed. Thanks. SMP (quake3-smp) is broken for several months, now. futex problem. @ Ian. I thought you had something (occlusion) in the pipe. > > Now, with wife AND daughter! ;-))) > > Congratulations! You read very 'carefully' ;-) Thank you very much! -Dieter With even fewer sleep --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R430 (Radeon X800 XL AGP)
On Thu, 2005-08-25 at 11:55 -0500, Mac Michaels wrote: > > I think this means I only need 2D so I tried the ATI binary > driver version 8.14.13. I have given up on the ATI binary > driver because it doesn't allocate enough DRI buffers (100 > buffers) to hold an HDTV frame (1920x1080 pixels). No one > at ATI is able to tell me how to increase the number of DRI > buffers. These things are unrelated. The inability to play HD video has been fixed in fglrx 8.16.20. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4242] libGLcore.a is unresolved!
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=4242 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-25 12:47 --- The undefined frexpf problem was fixed in Mesa 6.3.2. I just fixed the undefined rand problem in CVS now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 'OcclusionTest' is missing (r200, i915, etc.), since last checkin
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dieter Nützel wrote: i830_metaops.c: In function `i830TryTextureDrawPixels': i830_metaops.c:628: error: structure has no member named `OcclusionTest' make[6]: *** [i830_metaops.o] Fehler 1 make[6]: Leaving directory `/opt/Mesa/src/mesa/drivers/dri/i915' -DGLX_DIRECT_RENDERING -DHAVE_ALIAS r200_pixel.c -o r200_pixel.o r200_pixel.c: In function `check_color_per_fragment_ops': r200_pixel.c:97: error: structure has no member named `OcclusionTest' make[6]: *** [r200_pixel.o] Fehler 1 Try the attached patch. If GL_ARB_occlusion_query is already supported in those drivers (I didn't think it was) or it's planned to be supported, your patch is better, Ian. -Brian --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 'OcclusionTest' is missing (r200, i915, etc.), since last checkin
Dieter Nützel wrote: i830_metaops.c: In function `i830TryTextureDrawPixels': i830_metaops.c:628: error: structure has no member named `OcclusionTest' make[6]: *** [i830_metaops.o] Fehler 1 make[6]: Leaving directory `/opt/Mesa/src/mesa/drivers/dri/i915' -DGLX_DIRECT_RENDERING -DHAVE_ALIAS r200_pixel.c -o r200_pixel.o r200_pixel.c: In function `check_color_per_fragment_ops': r200_pixel.c:97: error: structure has no member named `OcclusionTest' make[6]: *** [r200_pixel.o] Fehler 1 Fixed. Now, with wife AND daughter! ;-))) Congratulations! -Brian --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 'OcclusionTest' is missing (r200, i915, etc.), since last checkin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dieter Nützel wrote:
> i830_metaops.c: In function `i830TryTextureDrawPixels':
> i830_metaops.c:628: error: structure has no member named `OcclusionTest'
> make[6]: *** [i830_metaops.o] Fehler 1
> make[6]: Leaving directory `/opt/Mesa/src/mesa/drivers/dri/i915'
>
> -DGLX_DIRECT_RENDERING -DHAVE_ALIAS r200_pixel.c -o r200_pixel.o
> r200_pixel.c: In function `check_color_per_fragment_ops':
> r200_pixel.c:97: error: structure has no member named `OcclusionTest'
> make[6]: *** [r200_pixel.o] Fehler 1
Try the attached patch.
985408c07ede00d7bd062b59c953d322 occlusion-01.patch
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDDhwqX1gOwKyEAw8RAsrLAJ0QcraWtAF7OB+Y3NMg3GEh1RXCHwCgmH+d
jhQF9Aqqq6exb1xN4HeIVkg=
=NYOo
-END PGP SIGNATURE-
Index: src/mesa/drivers/dri/i915/i830_metaops.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/i915/i830_metaops.c,v
retrieving revision 1.4
diff -u -d -r1.4 i830_metaops.c
--- src/mesa/drivers/dri/i915/i830_metaops.c 4 May 2005 20:11:37 - 1.4
+++ src/mesa/drivers/dri/i915/i830_metaops.c 25 Aug 2005 19:28:02 -
@@ -625,7 +625,7 @@
!ctx->Color.ColorMask[3] ||
ctx->Color.ColorLogicOpEnabled ||
ctx->Texture._EnabledUnits ||
- ctx->Depth.OcclusionTest) {
+ ctx->Occlusion.Active) {
fprintf(stderr, "%s: other tests failed\n", __FUNCTION__);
return GL_FALSE;
}
Index: src/mesa/drivers/dri/i915/intel_pixel.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/i915/intel_pixel.c,v
retrieving revision 1.4
diff -u -d -r1.4 intel_pixel.c
--- src/mesa/drivers/dri/i915/intel_pixel.c 9 May 2005 17:42:18 - 1.4
+++ src/mesa/drivers/dri/i915/intel_pixel.c 25 Aug 2005 19:28:02 -
@@ -87,7 +87,7 @@
!ctx->Color.ColorMask[3] ||
ctx->Color.ColorLogicOpEnabled ||
ctx->Texture._EnabledUnits ||
- ctx->Depth.OcclusionTest
+ ctx->Occlusion.Active
) &&
ctx->Current.RasterPosValid);
Index: src/mesa/drivers/dri/mga/mgapixel.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/mga/mgapixel.c,v
retrieving revision 1.8
diff -u -d -r1.8 mgapixel.c
--- src/mesa/drivers/dri/mga/mgapixel.c 12 May 2005 23:15:38 - 1.8
+++ src/mesa/drivers/dri/mga/mgapixel.c 25 Aug 2005 19:28:02 -
@@ -141,7 +141,7 @@
!ctx->Color.ColorMask[3] ||
ctx->Color.ColorLogicOpEnabled ||
ctx->Texture._EnabledUnits ||
- ctx->Depth.OcclusionTest
+ ctx->Occlusion.Active
) &&
ctx->Current.RasterPosValid &&
ctx->Pixel.ZoomX == 1.0F &&
Index: src/mesa/drivers/dri/r200/r200_pixel.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_pixel.c,v
retrieving revision 1.7
diff -u -d -r1.7 r200_pixel.c
--- src/mesa/drivers/dri/r200/r200_pixel.c 31 Jul 2004 08:14:50 - 1.7
+++ src/mesa/drivers/dri/r200/r200_pixel.c 25 Aug 2005 19:28:02 -
@@ -94,7 +94,7 @@
!ctx->Color.ColorMask[3] ||
ctx->Color.ColorLogicOpEnabled ||
ctx->Texture._EnabledUnits ||
- ctx->Depth.OcclusionTest
+ ctx->Occlusion.Active
) &&
ctx->Current.RasterPosValid);
Index: src/mesa/drivers/dri/tdfx/tdfx_pixels.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/tdfx/tdfx_pixels.c,v
retrieving revision 1.4
diff -u -d -r1.4 tdfx_pixels.c
--- src/mesa/drivers/dri/tdfx/tdfx_pixels.c 4 May 2005 20:11:39 - 1.4
+++ src/mesa/drivers/dri/tdfx/tdfx_pixels.c 25 Aug 2005 19:28:03 -
@@ -618,7 +618,7 @@
!ctx->Color.ColorMask[3] ||
ctx->Color.ColorLogicOpEnabled ||
ctx->Texture._EnabledUnits ||
- ctx->Depth.OcclusionTest ||
+ ctx->Occlusion.Active ||
fxMesa->Fallback)
{
_swrast_DrawPixels( ctx, x, y, width, height, format, type,
[Bug 4242] libGLcore.a is unresolved!
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=4242 --- Additional Comments From [EMAIL PROTECTED] 2005-08-25 12:13 --- Created an attachment (id=3032) --> (https://bugs.freedesktop.org/attachment.cgi?id=3032&action=view) Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4242] New: libGLcore.a is unresolved!
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=4242 Summary: libGLcore.a is unresolved! Product: DRI Version: XOrg CVS Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: libGLcore AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Xorg 6.9 Cvs ( 24/08/05 ) with Radeon 9700 Mobility on Mandrake Cooker (II) RADEON(0): Direct rendering enabled (==) RandR enabled Symbol frexpf from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! Symbol rand from module /usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! OpenGL renderer string: Mesa GLX Indirect -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
'OcclusionTest' is missing (r200, i915, etc.), since last checkin
i830_metaops.c: In function `i830TryTextureDrawPixels': i830_metaops.c:628: error: structure has no member named `OcclusionTest' make[6]: *** [i830_metaops.o] Fehler 1 make[6]: Leaving directory `/opt/Mesa/src/mesa/drivers/dri/i915' -DGLX_DIRECT_RENDERING -DHAVE_ALIAS r200_pixel.c -o r200_pixel.o r200_pixel.c: In function `check_color_per_fragment_ops': r200_pixel.c:97: error: structure has no member named `OcclusionTest' make[6]: *** [r200_pixel.o] Fehler 1 Thanks, Dieter Now, with wife AND daughter! ;-))) --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R280 TEST RESULTS;
Philip Armstrong wrote: On Thu, Aug 25, 2005 at 12:35:56PM +0100, Philip Armstrong wrote: On Thu, Aug 25, 2005 at 01:36:41AM -0500, Alan Grimes wrote: PPRACER: Works but has nasty texture bug affecting the ground textures.. (Problem disappears when I run it on the other, unaccelerated monitor..) Is this just the usual R2x0 GL_SPHERE_MAP texture ordering problem? Does it go away if you turn off hardware T&L with driconf? Alan has confirmed (using my .drirc -- driconf doesn't work for him for some reason) that the ppracer bug is indeed caused by the GP_SPHERE_MAP TCL fallback. That didn't solve the other problem he was seeing however. You can always use tcl_mode=0 if you don't have driconf (can be a bit hard to install depending on your distro). That said, there is no flickering with current Mesa cvs, as the fallback has been disabled again, but instead the reflection on the ice is wrong with tuxracer (though if you don't know how it should look, it looks quite normal to me). Roland --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R280 TEST RESULTS;
On Thu, Aug 25, 2005 at 12:35:56PM +0100, Philip Armstrong wrote: > On Thu, Aug 25, 2005 at 01:36:41AM -0500, Alan Grimes wrote: > > PPRACER: Works but has nasty texture bug affecting the ground textures.. > > (Problem disappears when I run it on the other, unaccelerated monitor..) > > Is this just the usual R2x0 GL_SPHERE_MAP texture ordering problem? > Does it go away if you turn off hardware T&L with driconf? Alan has confirmed (using my .drirc -- driconf doesn't work for him for some reason) that the ppracer bug is indeed caused by the GP_SPHERE_MAP TCL fallback. That didn't solve the other problem he was seeing however. cheers, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R430 (Radeon X800 XL AGP)
On 8/25/05, Mac Michaels <[EMAIL PROTECTED]> wrote: > Dave, > > I also own a Radeon X800 XL AGP 256MB and would like to use > the open source driver. Do you have a patch for the changes > you made? > > I just finished a driver for the Fusion HDTV 3/5 Gold TV > tuner cards. These cards receive both analog and digital > TV. There is no MPEG decoding on the cards so I bought a > Radeon X800 XL card to get component video output and MPEG > acceleration. > > I think this means I only need 2D so I tried the ATI binary > driver version 8.14.13. I have given up on the ATI binary > driver because it doesn't allocate enough DRI buffers (100 > buffers) to hold an HDTV frame (1920x1080 pixels). No one > at ATI is able to tell me how to increase the number of DRI > buffers. If the open source driver has this limit I should > be able to fix it. > > Although I am a driver developer, I am new to this driver > and how to intergrate it into the kernel. I run Gentoo > Linux 2.6.12 and will move to 2.6.13 as soon as it is > released. Please point me to documentation such as CVS info > and the procedure to compile and install the radeon driver > and any associated libraries. Xorg drivers (the 2d, mode/output, and overlay portions anyway) live in userspace. The only kernel part is the drm which controls access to the hardware mostly for 3d rendering (other things can use it too). There are basically 3 parts to a 3d-enabled Xorg driver: DDX - userspace, handles modes, outputs, 2D accel, video overlays, etc. DRI lib - 3D driver library drm kernel module - provides secure access to the GPU for multi-plexed access and command submission, etc. Take a look at the DRI building guide: http://dri.freedesktop.org/wiki/Building XvMC which provides MC and iDCT support for the video overlay works similarly to 3d. it has a server component that lives in the DDX and then has a XvMC lib like the DRI lib and uses the drm to access the hardware. At the moment there is no XvMC support for radeon due to lack of docs. Dave Airlie was working on it at one point however. if your interest is mostly in the DDX (overlay, component output, etc.) you can find the radeon DDX source here: http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/ Feel free to ask any questions, Alex > > -- Mac > --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ColorTiling issue on r420
On Thu, 25 Aug 2005 16:19:19 +0200 Roland Scheidegger <[EMAIL PROTECTED]> wrote: > Aapo Tahkola wrote: > > That check doesnt currently seem to work because some setup(at > > preinit) with color tiling enabled will get done earlier. > > > > Does this version break r200s or radeons? > From the top of my head, I think it does. For certain 16bit resolutions, > that is (as the resolution won't be a multiple of 2048 bits wide, which > is the block width of those chips for color tiling - i.e. 64 pixels for > 32bit, 128 pixels for 16bit). That said, I think the use of > info->MaxSurfaceWidth doesn't make any sense there, it is pure > coincidence that "2048" is the same (in pixels) for the max width as it > is (in bits) for the pitch increment. Isn't the block width of the r300 > based chips 2048 bits too? It seems to be. -- Aapo Tahkola --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R430 (Radeon X800 XL AGP)
Dave, I also own a Radeon X800 XL AGP 256MB and would like to use the open source driver. Do you have a patch for the changes you made? I just finished a driver for the Fusion HDTV 3/5 Gold TV tuner cards. These cards receive both analog and digital TV. There is no MPEG decoding on the cards so I bought a Radeon X800 XL card to get component video output and MPEG acceleration. I think this means I only need 2D so I tried the ATI binary driver version 8.14.13. I have given up on the ATI binary driver because it doesn't allocate enough DRI buffers (100 buffers) to hold an HDTV frame (1920x1080 pixels). No one at ATI is able to tell me how to increase the number of DRI buffers. If the open source driver has this limit I should be able to fix it. Although I am a driver developer, I am new to this driver and how to intergrate it into the kernel. I run Gentoo Linux 2.6.12 and will move to 2.6.13 as soon as it is released. Please point me to documentation such as CVS info and the procedure to compile and install the radeon driver and any associated libraries. -- Mac --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2919] glest segfaults on r200
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2919 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-25 08:57 --- Just tried glest on my rv250, seems to work fine with current Mesa cvs. Not sure how the OP got it to run though, it will bail out if GL_ARB_texture_env_crossbar is not supported, which so far isn't in cvs yet... maybe older versions didn't require it (1.1.0 tested). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R280 texture pipe bug still there [PATCH]
On 8/25/05, Alan Grimes <[EMAIL PROTECTED]> wrote: > Daniel Stone wrote: > > On Thu, 2005-08-25 at 00:44 -0500, Alan Grimes wrote: > > > >>>^^^ Just install libdrm from DRM CVS. It's a requirement now. > >> > >>IN FILE xf86drm.h AND include/GL/internal/dri_interface.h CHANGE > >> > >>#include > >> > >>#include > >> > > > > All that does is paper over the cracks. It's a symptom of pkg-config > > not finding libdrm. You need to find out why pkg-config isn't finding > > libdrm -- whether that be that you didn't make install it properly, but > > just copied it, or that the place you installed it to isn't in your > > PKG_CONFIG_PATH, whatever -- and fix that. > > 1. I have no idea what pkgconfig is. > 2. I successfully (relatively) installed the package without knowing > what pkgconfig is with minimial effort. > 3. The existance of pkgconfig therefore places an increased UNNECESSARY > managment/learning/fussingwith burdeon on the USER, a mortal sin for > any developer, and should therefore be removed from all *nix/*nux > systems with the most extreme prejudice. > 4. /me adds "pkgconfig" to the multi-volume list of things I hate about > unix. > 5. Unless someone starts paying me, I'm not even going to waste another > second thinking about pkgconfig. If it decides to start working FINE, if > it doesn't I DON'T CARE, I HAVE BETTER THINGS TO DO WITH MY LIFE!! > > believe it or not pkgconfig actually makes your life easier...once you get to know it ;) It's the unix way. It basically tells you where to find header information for various packages. You copy the package's .pc file to the pkgconfig directory (often /usr/lib/pkgconfig). then try and build again. Alex > -- > Friends don't let friends use GCC 3.4.4 > GCC 3.3.6 produces code that's twice as fast on x86! > > Non-sequiter item: Charleston, South Carolina > > --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
crossbar + texenv optimizer for r200
I've looked at that crossbar patch for r200 again and improved it a bit.
It will now
- disable texture sampling of units if the result is not used
- reorder tex env instructions to be always in-order on the gpu
(according to earlier tests, this can make a performance difference,
http://marc.theaimsgroup.com/?l=dri-devel&m=112308244205670&w=2, though
I've yet to find an app which doesn't enable the units in-order, the
only thing in real world I've found which doesn't was a marbleblastdemo,
and it only doesn't because it fails the texture completeness test, not
because it actually doesn't enable the unit...)
- tries to optimize away env instructions. This is not a general
optimizer, which would be very hard to do anyway and more or less
impossible due to the requirement of OpenGL to clamp the results after
each stage, but it will try to ditch the tex env if it is GL_REPLACE
(for both rgb and alpha) by replacing the args in the next tex env.
Seems to work, for instance ut2003 sometimes uses tex envs with 4 units
enabled, and the optimizer reduces this to 3 sampled textures, and 2 env
instructions. Impressive, isn't it? Unfortunately this makes absolutely
no difference in performance... (ut2003 is horribly limited by vertex
throughput with the current state of the driver, and anything which
causes more cpu cycles to be used will probably make it slower, no
matter how many gpu cycles this might save, plus I believe these tex
envs which can be optimized are only used for small parts of the screen
(powerups maybe).)
It MIGHT make more of a performance difference with radeon 8500/9100, as
those can sample more textures per pass (at least under some
circumstances afaik), but have the same amout of arithmetic resources
(afaik).
Does this look somewhat reasonable? The code is a bit ugly (especially
the GL_REPLACE env optimize stuff), I don't like that the env args have
to be parsed two times, and it does cause some more cpu cycles spent
(roughly 2.5 times as much as previously in the driver's tex env
functions according to some quick profiling, it was still only 0.2
percent or so however). But there doesn't seem to be a good way to clean
it up (without making it quite a bit slower at least).
Roland
Index: r200_context.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_context.c,v
retrieving revision 1.47
diff -u -r1.47 r200_context.c
--- r200_context.c 11 Aug 2005 19:47:06 - 1.47
+++ r200_context.c 25 Aug 2005 14:45:57 -
@@ -140,6 +140,7 @@
{ "GL_ARB_texture_env_add",NULL },
{ "GL_ARB_texture_env_combine",NULL },
{ "GL_ARB_texture_env_dot3", NULL },
+{ "GL_ARB_texture_env_crossbar", NULL },
{ "GL_ARB_texture_mirrored_repeat",NULL },
{ "GL_ARB_vertex_buffer_object",
GL_ARB_vertex_buffer_object_functions },
{ "GL_EXT_blend_minmax", GL_EXT_blend_minmax_functions },
Index: r200_context.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_context.h,v
retrieving revision 1.30
diff -u -r1.30 r200_context.h
--- r200_context.h 26 Jul 2005 02:44:02 - 1.30
+++ r200_context.h 25 Aug 2005 14:45:57 -
@@ -172,8 +172,8 @@
struct r200_texture_env_state {
r200TexObjPtr texobj;
- GLenum format;
- GLenum envMode;
+ GLuint outputreg;
+ GLuint unitneeded;
};
#define R200_MAX_TEXTURE_UNITS 6
@@ -544,6 +544,7 @@
struct r200_stencilbuffer_state stencil;
struct r200_stipple_state stipple;
struct r200_texture_state texture;
+ GLuint envneeded;
};
/* Need refcounting on dma buffers:
Index: r200_reg.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_reg.h,v
retrieving revision 1.12
diff -u -r1.12 r200_reg.h
--- r200_reg.h 15 Mar 2005 22:23:29 - 1.12
+++ r200_reg.h 25 Aug 2005 14:45:58 -
@@ -172,6 +172,8 @@
#define R200_TEX_BLEND_4_ENABLE 0x0001
#define R200_TEX_BLEND_5_ENABLE 0x0002
#define R200_TEX_BLEND_6_ENABLE 0x0004
+#define R200_TEX_BLEND_ENABLE_MASK0x0007f800
+#define R200_TEX_BLEND_0_ENABLE_SHIFT (12)
#define R200_MULTI_PASS_ENABLE0x0008
#define R200_SPECULAR_ENABLE 0x0020
#define R200_FOG_ENABLE 0x0040
@@ -1146,6 +1148,7 @@
#define R200_TXC_CLAMP_WRAP(0 << 12)
#define R200_TXC_CLAMP_0_1 (1 << 12)
#define R200_TXC_CLAMP_8_8 (2 << 12)
+#define R200_TXC_OUTPUT_REG_SHIFT 16
#define R200_TXC_OUTPUT_REG_MASK (7 << 16)
#define R200_TXC_OUTPUT_REG_NONE (0 << 16)
#define
Re: R280 texture pipe bug still there [PATCH]
Daniel Stone wrote: > On Thu, 2005-08-25 at 00:44 -0500, Alan Grimes wrote: > >>>^^^ Just install libdrm from DRM CVS. It's a requirement now. >> >>IN FILE xf86drm.h AND include/GL/internal/dri_interface.h CHANGE >> >>#include >> >>#include >> > > All that does is paper over the cracks. It's a symptom of pkg-config > not finding libdrm. You need to find out why pkg-config isn't finding > libdrm -- whether that be that you didn't make install it properly, but > just copied it, or that the place you installed it to isn't in your > PKG_CONFIG_PATH, whatever -- and fix that. 1. I have no idea what pkgconfig is. 2. I successfully (relatively) installed the package without knowing what pkgconfig is with minimial effort. 3. The existance of pkgconfig therefore places an increased UNNECESSARY managment/learning/fussingwith burdeon on the USER, a mortal sin for any developer, and should therefore be removed from all *nix/*nux systems with the most extreme prejudice. 4. /me adds "pkgconfig" to the multi-volume list of things I hate about unix. 5. Unless someone starts paying me, I'm not even going to waste another second thinking about pkgconfig. If it decides to start working FINE, if it doesn't I DON'T CARE, I HAVE BETTER THINGS TO DO WITH MY LIFE!! -- Friends don't let friends use GCC 3.4.4 GCC 3.3.6 produces code that's twice as fast on x86! Non-sequiter item: Charleston, South Carolina --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ColorTiling issue on r420
Aapo Tahkola wrote: That check doesnt currently seem to work because some setup(at preinit) with color tiling enabled will get done earlier. Does this version break r200s or radeons? From the top of my head, I think it does. For certain 16bit resolutions, that is (as the resolution won't be a multiple of 2048 bits wide, which is the block width of those chips for color tiling - i.e. 64 pixels for 32bit, 128 pixels for 16bit). That said, I think the use of info->MaxSurfaceWidth doesn't make any sense there, it is pure coincidence that "2048" is the same (in pixels) for the max width as it is (in bits) for the pitch increment. Isn't the block width of the r300 based chips 2048 bits too? Roland --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ColorTiling issue on r420
On Wed, 24 Aug 2005 16:26:58 -0400 Alex Deucher <[EMAIL PROTECTED]> wrote: > On 8/24/05, Aapo Tahkola <[EMAIL PROTECTED]> wrote: > > On Fri, 15 Jul 2005 12:04:43 +0200 > > Rune Petersen <[EMAIL PROTECTED]> wrote: > > > > > Just to add that login (KDM) is more or less fine (cursor is corrupted > > > untill its moved). > > > > Attached diff should fix this temporarily. > > Im still unsure why MaxSurfaceWidth ends up affecting piches and stuff... > > > > Odd... I never saw any problems like that. However, if you set your > virtual desktop greater than 3968, the desktop gets VERY corrupt. I > don't see why that would affect pitches either. That check doesnt currently seem to work because some setup(at preinit) with color tiling enabled will get done earlier. Does this version break r200s or radeons? -- Aapo Tahkola Index: radeon_driver.c === RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v retrieving revision 1.69 diff -u -b -B -u -r1.69 radeon_driver.c --- radeon_driver.c 8 Aug 2005 23:42:36 - 1.69 +++ radeon_driver.c 25 Aug 2005 12:53:31 - @@ -3684,7 +3684,6 @@ NULL, /* linePitches */ 8 * 64,/* minPitch */ 8 * 1024, /* maxPitch */ - info->allowColorTiling ? info->MaxSurfaceWidth : 64 * pScrn1->bitsPerPixel, /* pitchInc */ 128, /* minHeight */ 8 * 1024, /*2048,*//* maxHeight */ @@ -3747,7 +3746,6 @@ NULL, /* linePitches */ 8 * 64,/* minPitch */ 8 * 1024, /* maxPitch */ - info->allowColorTiling ? info->MaxSurfaceWidth : 64 * pScrn1->bitsPerPixel, /* pitchInc */ 128, /* minHeight */ 8 * 1024, /*2048,*//* maxHeight */ @@ -3949,7 +3947,6 @@ NULL, /* linePitches */ 8 * 64,/* minPitch */ 8 * 1024, /* maxPitch */ - info->allowColorTiling ? info->MaxSurfaceWidth : 64 * pScrn->bitsPerPixel, /* pitchInc */ 128, /* minHeight */ info->MaxLines, /* maxHeight */ @@ -4018,7 +4015,6 @@ NULL, /* linePitches */ 8 * 64,/* minPitch */ 8 * 1024, /* maxPitch */ - info->allowColorTiling ? info->MaxSurfaceWidth : 64 * pScrn->bitsPerPixel, /* pitchInc */ 128, /* minHeight */ info->MaxLines, /* maxHeight */
Re: R280 TEST RESULTS;
On Thu, Aug 25, 2005 at 01:36:41AM -0500, Alan Grimes wrote: > PPRACER: Works but has nasty texture bug affecting the ground textures.. > (Problem disappears when I run it on the other, unaccelerated monitor..) Is this just the usual R2x0 GL_SPHERE_MAP texture ordering problem? Does it go away if you turn off hardware T&L with driconf? Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R280 texture pipe bug still there [PATCH]
On Thu, 2005-08-25 at 00:44 -0500, Alan Grimes wrote: > > ^^^ Just install libdrm from DRM CVS. It's a requirement now. > > IN FILE xf86drm.h AND include/GL/internal/dri_interface.h CHANGE > > #include > > #include > All that does is paper over the cracks. It's a symptom of pkg-config not finding libdrm. You need to find out why pkg-config isn't finding libdrm -- whether that be that you didn't make install it properly, but just copied it, or that the place you installed it to isn't in your PKG_CONFIG_PATH, whatever -- and fix that. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
