[Bug 16452] New: Mipmap texture filtering broken on RS690
http://bugs.freedesktop.org/show_bug.cgi?id=16452 Summary: Mipmap texture filtering broken on RS690 Product: Mesa Version: CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Created an attachment (id=17279) --> (http://bugs.freedesktop.org/attachment.cgi?id=17279) screenshot1 mipmap texture filtering is broken on my rs690. it looks like only last mipmaps (the smallest) are wrong. If had to guess what's the problem, I would say it's uploading of small textures. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16406] bad size calculation in r200TryDrawPixels
http://bugs.freedesktop.org/show_bug.cgi?id=16406 Roland Scheidegger <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Roland Scheidegger <[EMAIL PROTECTED]> 2008-06-20 17:57:29 PST --- Thanks for spotting this. With the driver only supporting blits in combination with the special mesa allocator, this path doesn't really get hit often (==never). Fixed. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Combining Mesa3D and DRI mailing lists and/or sites? (was: Re: Wrapping up 7.4 (finally))
On Mon, Jun 16, 2008 at 8:31 AM, Timo Jyrinki <[EMAIL PROTECTED]> wrote: > 2008/6/12 Keith Whitwell <[EMAIL PROTECTED]>: >> In reality, what has happened is that most of this has already >> occurred -- whatever 3d driver-related traffic that hasn't been sucked >> into IRC is now occurring on the Mesa lists. > > Right. I now rearranged DRI wiki's mailing list page > http://dri.freedesktop.org/wiki/MailingLists by stating that fact. I > also commented out the dri-announce mailing list which hadn't been > used for 5+ years. > >> I actually think the current structure makes a lot of sense - if we >> wanted a change, we could rename dri-devel to drm-devel, but it hardly >> seems worthwhile. > > It'd be nice, but only if somehow automagic enough. Just documentation > is mostly enough, too. > > What about the dri-users mailing list? From users point of view > DRI/Mesa/DRM are mostly all the same (users want them all), and any > "users" of DRM are likely to be halfway developers anyway. While DRI > discussion has successfully migrated to mesa3d-dev list, users are > currently randomly posting either mesa3d-users or dri-users and the > discussion is not coherent. Could those two mailing lists be merged > into mesa3d-users, or do you think that mentioning dri-users is > (nowadays) for DRM discussion is enough to fix the problem from now > on? I think dri-users is certainly redundant now, likewise -announce. If those could somehow get funneled into mesa-users or an appropriate Xorg list, that would be fine with me... > Regarding wikis, I also started reorganizing the front page > http://dri.freedesktop.org/ a bit, including changing title to include > Mesa, too. I still think that it could be the wiki for both Mesa and > DRI, and that mesa3d.org could include a link to the wiki (or "DRI > wiki" because of the current status) under eg. the "Resources" title > instead of having the link to "DRI website" only in the bottom of the > navigation. What do you think? I'm also ok with this general concept. Keith - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] don't wait on page flips if none are pending
Michel, can you take a look at this? vblank wait is working really well for
me with the latest bits, but I found what I think is a page flip related bug
on 965. I've been testing with the attached pre- & post-modeset ioctl patch
to the 2D driver. Changing modes, adding & removing outputs and moving a
window waiting on vblank events all seem solid & tear free on my 965 (though
on 915 we may still have some tearing due to the way interrupts work on that
chip, still have to test & fix if necessary).
What do you think?
Thanks,
Jesse
diff --git a/src/i830_display.c b/src/i830_display.c
index 56a718d..67c9cce 100644
--- a/src/i830_display.c
+++ b/src/i830_display.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include "xf86.h"
#include "i830.h"
@@ -730,6 +731,39 @@ i830_use_fb_compression(xf86CrtcPtr crtc)
return TRUE;
}
+#if defined(DRM_IOCTL_MODESET_CTL) && defined(XF86DRI)
+static void i830_modeset_ctl(xf86CrtcPtr crtc, int pre)
+{
+ScrnInfoPtr pScrn = crtc->scrn;
+I830Ptr pI830 = I830PTR(pScrn);
+I830CrtcPrivatePtr intel_crtc = crtc->driver_private;
+struct drm_modeset_ctl modeset;
+
+modeset.crtc = intel_crtc->plane;
+
+/*
+ * DPMS will be called many times (especially off), but we only
+ * want to catch the transition from on->off and off->on.
+ */
+if (pre && intel_crtc->dpms_mode != DPMSModeOff) {
+ /* On -> off is a pre modeset */
+ modeset.cmd = _DRM_PRE_MODESET;
+ ioctl(pI830->drmSubFD, DRM_IOCTL_MODESET_CTL, &modeset);
+ ErrorF("modeset: on -> off on plane %d\n", modeset.crtc);
+} else if (!pre && intel_crtc->dpms_mode == DPMSModeOff) {
+ /* Off -> on means post modeset */
+ modeset.cmd = _DRM_POST_MODESET;
+ ioctl(pI830->drmSubFD, DRM_IOCTL_MODESET_CTL, &modeset);
+ ErrorF("modeset: off -> on on plane %d\n", modeset.crtc);
+}
+}
+#else
+static void i830_modeset_ctl(xf86CrtcPtr crtc, int dpms_state)
+{
+return;
+}
+#endif /* DRM_IOCTL_MODESET_CTL && XF86DRI */
+
/**
* Sets the power management mode of the pipe and plane.
*
@@ -797,8 +831,10 @@ i830_crtc_dpms(xf86CrtcPtr crtc, int mode)
/* Reenable compression if needed */
if (i830_use_fb_compression(crtc))
i830_enable_fb_compression(crtc);
+ i830_modeset_ctl(crtc, 0);
break;
case DPMSModeOff:
+ i830_modeset_ctl(crtc, 1);
/* Shut off compression if in use */
if (i830_use_fb_compression(crtc))
i830_disable_fb_compression(crtc);
diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c
index 80e2111..58391b2 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -960,7 +960,7 @@ void LOCK_HARDWARE( struct intel_context *intel )
intel_fb->Base._ColorDrawBufferIndexes[0]);
}
-if (intel_rb && dPriv->vblFlags &&
+if (intel_rb && intel_fb->pf_num_pages && dPriv->vblFlags &&
!(dPriv->vblFlags & VBLANK_FLAG_NO_IRQ) &&
(intel_fb->vbl_waited - intel_rb->vbl_pending) > (1<<23)) {
drmVBlank vbl;
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14289] Request for pciid add
http://bugs.freedesktop.org/show_bug.cgi?id=14289 Alex Deucher <[EMAIL PROTECTED]> changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #3 from Alex Deucher <[EMAIL PROTECTED]> 2008-06-21 07:58:47 PST --- fixed. thanks! drm: 207f701e1affa18b0d54e09f7bf8b6447cb16258 mesa: dc25661099bcc4b107a30ca504fcc2e76db3492e ddx: aea9bf75cf0774afd3e65fcf3fd3851f5fb21ca3 Although from the perspective of the driver, there's not much difference. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16452] Mipmap texture filtering broken on RS690
http://bugs.freedesktop.org/show_bug.cgi?id=16452 --- Comment #4 from Alex Deucher <[EMAIL PROTECTED]> 2008-06-21 08:07:25 PST --- IIRC, RS4xx/RS6xx IGP chips require tiling for small textures. The patch in bug 8056 fixes the issue I think. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16452] Mipmap texture filtering broken on RS690
http://bugs.freedesktop.org/show_bug.cgi?id=16452 --- Comment #5 from Maciej Cencora <[EMAIL PROTECTED]> 2008-06-21 09:55:28 PST --- (In reply to comment #4) > IIRC, RS4xx/RS6xx IGP chips require tiling for small textures. The patch in > bug 8056 fixes the issue I think. > Probably, but it doesn't apply anymore. I checked before only square textures. If it's any help here are results for all POT textures from 1x1 up to 64x64 (all RGBA) Textures that are broken: 1x2, 1x4, 1x8, 1x16, 1x32, 1x64 2x2, 2x4, 2x8, 2x16, 2x32, 2x64 4x2, 4x4, 4x8, 4x16, 4x32, 4x64 8x8, 8x16, 8x32, 8x64 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16452] Mipmap texture filtering broken on RS690
http://bugs.freedesktop.org/show_bug.cgi?id=16452 --- Comment #2 from Nicolai Hähnle <[EMAIL PROTECTED]> 2008-06-21 06:17:02 PST --- The screenshot is from anisotropictest, http://steinsoft.net/index.php?site=Programming/Projects/OpenGL/anisotropictest I cannot reproduce this with current Git and my R420 (X800 Pro), but obviously there's a problem here. Uploading small textures seems like a good initial guess. Does anybody know of differences in the texture filtering on that hardware? Also, could you test programs that use small textures to begin with, without mipmapping? For example, start with Mesa's crossbar test and change the texture sizes by editing the code starting at line 246. There are four calls glTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, 8, 8, 0, GL_RGBA, GL_UNSIGNED_BYTE, temp ); The first 8 is the texture width, the second 8 is the texture height. Try with the original size first, and if this works, try with successively smaller sizes and see if it fails. This would point towards small texture memory layout as the culprit. I'd be kind of surprised by that, but then we all know the RS690 is a bit weird ;) If this does not fail, then who knows... I can't think of anything right now. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16452] Mipmap texture filtering broken on RS690
http://bugs.freedesktop.org/show_bug.cgi?id=16452 --- Comment #1 from Maciej Cencora <[EMAIL PROTECTED]> 2008-06-21 02:41:56 PST --- Created an attachment (id=17280) --> (http://bugs.freedesktop.org/attachment.cgi?id=17280) screenshot2 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Running 32 bit dri on 64bit kernel
Hello, I'm trying to get nouveau 3d acceleration to work for 32 bit apps on a 64 bit kernel, since it works ok for 64 bit apps. I've setup a 32 bit mesa and dri environment, and tested for direct rendering with 32 bit apps. The logs got filled with these entries, several of them per second: Jun 16 16:53:41 pinguinus [drm:drm_unlocked_ioctl] *ERROR* ret = 48 -12 The machine eventually hangs, which is not that unexpected. So an error occurred in drm_unlocked_ioctl with the command DRM_IOCTL_AGP_ACQUIRE, and the error was ENOMEM. I'm not sure how to debug this further, so any help would be appreciated! Thanks, Cheers, Renato Caldas - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
