[Bug 12570] New: glean case depthStencil causes Assertion failure in DRI driver
http://bugs.freedesktop.org/show_bug.cgi?id=12570 Summary: glean case depthStencil causes Assertion failure in DRI driver Product: Mesa Version: CVS Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] System Environment: -- latest Mesa, Drm, Xserver, Xf86_video_intel Bug detailed description: -- During running glean test case depthStencil, one assertion is failed: i915_vtbl.c:427: i915_emit_state: Assertion `(state->Program[0] & 0x1ff) + 2 == state->ProgramSize' failed. And the test case aborted. Reproduce steps: you can run it by: glean -r resultdir -t depthStencil Current result: -- Test the GL_EXT_packed_depth_stencil extension. depthStencil: PASS rgba8, db, win+pmap, id 35 glReadPixels GL_DEPTH_STENCIL rate: 0.00 MBytes per second. glReadPixels GL_DEPTH/GLuint rate: 0.00 MBytes per second. glReadPixels GL_DEPTH/GLushort rate: 0.00 MBytes per second. depthStencil: PASS rgba8, win+pmap, id 36 glReadPixels GL_DEPTH_STENCIL rate: 0.00 MBytes per second. glReadPixels GL_DEPTH/GLuint rate: 0.00 MBytes per second. glReadPixels GL_DEPTH/GLushort rate: 0.00 MBytes per second. glean: i915_vtbl.c:427: i915_emit_state: Assertion `(state->Program[0] & 0x1ff) + 2 == state->ProgramSize' failed. Aborted Expected result: this glean case should pass without any error -- Configure bugmail: http://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. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12132] occlusion query should return the number of samples passed depth test
http://bugs.freedesktop.org/show_bug.cgi?id=12132 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from [EMAIL PROTECTED] 2007-09-25 19:07 PST --- fixed in mesa commit 395b3bf6f95b35a84a74d4baf7e04bc67cf3771c -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Pre-superioctl,
> I'm about to merge the pre-superioctl branch but I've pushed it for a review > first. > There are a couple of fixes that shouldn't affect any ongoing super-ioctl > work, but then there also is some important changes. > > a) A fence error member. The idea is that when we detect a lockup, we signal > all fences with fence->error set to non-zero. Then the X server will exit > more cleanly if it's also using a superioctl, and we can remove the drm > module without too much trouble. > > b) An interface to map buffer objects from kernel space in whatever memory > region they currently reside. drm_bo_kmap / drm_bo_kunmap. Though the > ioremap_nocache call might need some tweaking to avoid the cache flushes. > > c) compat support for PAT write-combining. Buffer objects with the _TTM map > type will be mapped PAT write-combined if the processor supports it. > Otherwise uncached. We will need this for new hardware that doesn't allow > mapping through the aperture, but PAT initializing should be done properly at > goot time. > > Finally a new function to simplify superioctl error paths. The way we > currently do it is to validate buffers as usual, but the ioctl "handled" > argument is not updated. This means that if we hit an -EAGAIN, the whole > validation sequence need to be re-run, which is not a big problem because > -EAGAINs are not very common, (typically just mouse movement). Buffers will > be placed on the unfenced list, but if we hit an error we just call > drm_putback_buffer_objects() that put them back on the lru list, keeping the > old fences and without updating the bo->fence_type and bo->fence_class > members. > > If command submission succeeds, we just call drm_fence_buffer_buffer_objects > as usual. If this call fails for any reason, we idle the GPU and call > drm_putback_buffer_objects(), and return an error to user-space that may do > it's own pool fencing. This should be rock solid AFAICT. > > This makes it possible to use a local "unfenced" list if desired, and should > allow us to remove the global one if we feel there is a need. > > It also avoids creating a fence a validate-time, which is a bit awkward. It looks good to me, I'm just starting on making a 915 superioctl cleanly using BOs to store the relocations so I'll base it off this branch.. Dave. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Monday, September 24, 2007 1:25 am Michel Dänzer wrote: > On Fri, 2007-09-21 at 12:46 -0700, Jesse Barnes wrote: > > On Friday, September 21, 2007 2:51 am Michel Dänzer wrote: > > > > - add code to Mesa so GetMSC/WaitForMSC set > > > > DRM_VBLANK_SECONDARY correctly > > > > > > One idea (with some handwaving :) would be the common code > > > keeping around a pointer to the driver's vblank_flags variable or > > > keeping track of the flags per drawable in some other sensible > > > way. > > > > I like the idea, here's something concrete. I put the vblank stuff > > into the screen private, but I'm not sure if that's the best place > > (logically the vblank counters are screen specific), > > The drawable private would seem more appropriate, as these are > drawable attributes. Here's a new version that moves the new fields over to the drawable private. I added a new drawable hook to implement the callback, and in the process discovered that all the drivers I could find either set their MSC routines to NULL or used the generic calls. So I didn't bother creating a new driver API hook for the new call; I just set it directly to the version in vblank.c in driCreateNewDrawable(). Would it make sense to rip out all the wrappers in dri_util.c, set everything directly in driCreateNewDrawable() and driUtilCreateNewScreen()? It seems that drivers that set their MSC routines to NULL will return GL_BAD_CONTEXT from calls like glXWaitVideoSyncSGI(), and if e.g. drmWaitVBlank() failed clients would get the same result, so compatibility would be preserved... Or should I add a new driver hook for the new per-drawable getMSC function and update every driver? Thanks, Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12241] With the game trackballs large parts get rendered black
http://bugs.freedesktop.org/show_bug.cgi?id=12241 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #6 from [EMAIL PROTECTED] 2007-09-25 00:41 PST --- I can no longer reproduce the crash with the latest mesa version from Fedora, and I just found out I already filed the parts going black bug, closing this as a dup of that one. *** This bug has been marked as a duplicate of bug 11174 *** -- Configure bugmail: http://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. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12132] occlusion query should return the number of samples passed depth test
http://bugs.freedesktop.org/show_bug.cgi?id=12132 --- Comment #4 from [EMAIL PROTECTED] 2007-09-25 00:36 PST --- seems commit(be3099f26547f48066bbdd7a36578b54da9170b4) brings in this issue -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 9264] GLX_BIND_TO_MIPMAP_TEXTURE_EXT attribute should only be GL_FALSE or GL_TRUE
http://bugs.freedesktop.org/show_bug.cgi?id=9264 --- Comment #5 from [EMAIL PROTECTED] 2007-09-25 00:23 PST --- (In reply to comment #4) > This patch will return GL_FALSE for GLX_BIND_TO_MIPMAP_TEXTURE_EXT when > bindToMipmapTexture is still set to GLX_DONT_CARE. Correct? Right. > I guess I don't see how that's different from pre-initializing > bindToMipmapTexture to GL_FALSE. I'm afraid I can't explain why, but it definitely does make a difference. Apparently pre-initializing these fields causes the configs to be treated differently in places where they shouldn't be. -- Configure bugmail: http://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. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
