[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
