[Bug 8645] Issue when rendering with 2 contexts to one window
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=8645 --- Additional Comments From [EMAIL PROTECTED] 2006-10-15 02:53 --- Good point, yes pageflip is enabled. It seems using different contexts to render to the same window is a bit jerky in general. The nvidia driver seems to share the color attribute between both contexts, and fglrx just crashes :-/ . Is that supposed to work? The glXSwapBuffers manpage suggests that, but I haven't found anything else. Maybe I can persuade our dict^H^H^H^H project maintainer to accept a SetThreadContext hack to take the rendering context away from the thread owning it... -- 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. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 7697] r300_check_offset fails on PCI-E R420 (5D4F)
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=7697 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2006-10-15 06:52 --- Now Ubuntu dev branch has mesa 6.5.1~20060817 and xserver-xorg-video-ati 6.6.2. Additionally, I've installed libdrm and linux-core/drm.ko + linux-core/radeon.ko from mesa-drm git HEAD. I'm still getting the same error messages when trying eg. glxgears. If I apply the following: diff --git a/shared-core/r300_cmdbuf.c b/shared-core/r300_cmdbuf.c index c65ffd5..561f614 100644 --- a/shared-core/r300_cmdbuf.c +++ b/shared-core/r300_cmdbuf.c @@ -259,7 +259,7 @@ static __inline__ int r300_check_offset( if (offset = dev_priv-gart_vm_start offset (dev_priv-gart_vm_start + dev_priv-gart_size)) return 0; - return 1; + return 0; } static __inline__ int r300_emit_carefully_checked_packet0(drm_radeon_private_t * and install the new radeon.ko generated, the error message disappears (offset check always returns 0) and 3D starts to work. Glxgears runs, GL* Gnome screensavers run etc. The problem is also happening when running x86 version of Linux instead of AMD64. Please tell me if I can gather relevant information for you or something. -- 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. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture function opengl specification
Jerome Glisse wrote: According to fragment program extension, TEX, TXP, ... should give you the right A value (Ap depending on which texture unit you are using). That's not how I read that. TEX,TXP,... refer to texture sampling only, there is no thing as previous unit there. Thus, for an RGB texture, A should be always 1. What induced me to this , is that in fragment program extension description they say to look at table 3.21 and in this one there is reference to Ap for A in RGB. Anyway i think you are right here. What version of the spec are you using? Table 3.21 only lists the component mapping here. Well, if my theory is sound, then the glean pixelFormats test is wrong. I've tried to trivially fix it up and also made it possible to use tex env combine mode. I think this might break the glDrawPixels tests but oddly enough that didn't happen. I did get a lots of failures though with an old radeon (and I'm sure r200 will fail too), turns out it uncovers some driver bugs... radeon and r200 only have an i8 single-component format, and you can't use that for a8 or l8 as the alpha (or rgb respectively) values will be wrong - guess there was a reason those formats weren't used initially... (not sure exactly why it doesn't work for L8, as I'd think if the ALPHA_IN_MAP isn't set this should work). I'm not quite sure how to fix that, the by far easiest method is to just use al88, but it would be possible to hack up tex env instead (and for the r200, fragment shader progs too - ugh). Anyway, r300 shouldn't have that problem with its native texture sampling swizzling/component replace. Roland Index: tpixelformats.cpp === RCS file: /cvsroot/glean/glean/src/glean/tpixelformats.cpp,v retrieving revision 1.8 diff -u -r1.8 tpixelformats.cpp --- tpixelformats.cpp 2 Oct 2006 19:50:53 - 1.8 +++ tpixelformats.cpp 15 Oct 2006 13:58:59 - @@ -39,6 +39,7 @@ #define USE_FRAG_PROG 0 +#define USE_TEXENV_COMBINE 1 namespace GLEAN { @@ -840,7 +841,11 @@ exp[1] = 0; exp[2] = 0; exp[testChan] = 255; +#if USE_FRAG_PROG || USE_TEXENV_COMBINE + exp[3] = 255; +#else exp[3] = 0; // fragment's alpha +#endif break; case GL_ALPHA: exp[0] = 0; @@ -852,7 +857,11 @@ exp[0] = exp[1] = exp[2] = testChan == 0 ? 255 : 0; - exp[3] = 0; // fragment's alpha +#if USE_FRAG_PROG || USE_TEXENV_COMBINE + exp[3] = 255; +#else + exp[3] = 0; // fragment's alpha +#endif break; case GL_LUMINANCE_ALPHA: exp[0] = @@ -888,7 +897,11 @@ exp[1] = 0; exp[2] = 0; exp[testChan] = 255; +#if USE_FRAG_PROG || USE_TEXENV_COMBINE + exp[3] = 255; +#else exp[3] = 0; // fragment's alpha +#endif break; case GL_ALPHA: exp[0] = 0; @@ -900,7 +913,11 @@ exp[0] = exp[1] = exp[2] = testChan == 0 ? 255 : 0; - exp[3] = 0; // fragment's alpha +#if USE_FRAG_PROG || USE_TEXENV_COMBINE + exp[3] = 255; +#else + exp[3] = 0; // fragment's alpha +#endif break; case GL_LUMINANCE_ALPHA: exp[0] = @@ -933,7 +950,11 @@ exp[0] = 255; exp[1] = 0; exp[2] = 0; +#if USE_FRAG_PROG || USE_TEXENV_COMBINE + exp[3] = 255; +#else exp[3] = 0; // fragment's alpha +#endif break; case GL_ALPHA: exp[0] = 0; @@ -945,7 +966,11 @@ exp[0] = exp[1] = exp[2] = 255; - exp[3] = 0; // fragment's alpha +#if USE_FRAG_PROG || USE_TEXENV_COMBINE + exp[3] = 255; +#else + exp[3] = 0; // fragment's alpha +#endif break; case GL_LUMINANCE_ALPHA: exp[0] = @@ -979,7 +1004,11 @@ exp[0] = 0; exp[1] = 255; exp[2] = 0; +#if USE_FRAG_PROG || USE_TEXENV_COMBINE + exp[3] = 255; +#else exp[3] = 0; // fragment's alpha +#endif break; case GL_ALPHA: exp[0] = 0; @@ -991,7 +1020,11 @@ exp[0] =
[Bug 8645] Issue when rendering with 2 contexts to one window
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=8645 --- Additional Comments From [EMAIL PROTECTED] 2006-10-15 13:42 --- (In reply to comment #4) Good point, yes pageflip is enabled. It seems using different contexts to render to the same window is a bit jerky in general. The nvidia driver seems to share the color attribute between both contexts, and fglrx just crashes :-/ . Is that supposed to work? The glXSwapBuffers manpage suggests that, but I haven't found anything else. From quickly glancing at it, I would just say the same, but I'm no expert in that area. Nevertheless, this looks like genuine driver bugs to me. Maybe I can persuade our dict^H^H^H^H project maintainer to accept a SetThreadContext hack to take the rendering context away from the thread owning it... Well, I guess if it really doesn't work with pretty much any driver, you might need to do that even if what you do is fully legal. I'd fix it for the radeon drivers but I currently can't quite see how you'd notice the other contexts upon a drawable change, as the __DRIdrawablePrivate struct only has a pointer to a single context. Calling glXMakeCurrent in the drawing loops should work around that problem (as that should make sure the hw buffer offsets get updated, just as putting glDrawBuffers(GL_BACK) in there does), though again I don't think this is needed by the spec. -- 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. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel