[Mesa3d-dev] [Bug 11956] New: drawing a line 2.0px in width has incorrect offset
http://bugs.freedesktop.org/show_bug.cgi?id=11956
Summary: drawing a line 2.0px in width has incorrect offset
Product: Mesa
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Mesa core
AssignedTo: mesa3d-dev@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]
Hi, when using blender3d with Mesa's libGL.so I notice a display problem that
isnt present with NVidia's or ATI's drivers.
http://members.optusnet.com.au/cjbarton/mesabug.png
This looks to be a bug in Mesa's line drawing function since blender uses it to
draw the outline.
Note that mesa has done this for a long time, and older versions had this
problem also.
The example below uses glLineWidth(2.0) and glDepthMask(0) and I assume line
drawing with glLineWidth(2.0) to be the problem.
is the function in blender that draws the outline around the mesh -
drawobject.c:1938
/* Mesh drawing routines */
static void draw_mesh_object_outline(Object *ob, DerivedMesh *dm)
{
if(G.vd-transp==0) { // not when we draw the transparent pass
glLineWidth(2.0);
glDepthMask(0);
/* if transparent, we cannot draw the edges for solid select...
edges have no material info.
drawFacesSolid() doesn't draw the transparent faces */
if(ob-dtx OB_DRAWTRANSP) {
glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
dm-drawFacesSolid(dm, set_gl_material);
glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
}
else {
dm-drawEdges(dm, 0);
}
glLineWidth(1.0);
glDepthMask(1);
}
}
--
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: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] Potential patch for R200 accelerated TFP
OK, here it is - the final version. Now given that I am running Fedora 7 at the
moment, exactly
what will I need to update in order to test it?
Are there any official Xorg packages that I will need to grab and compile, or
is everything
still unreleased from git repositories?
Cheers,
Chris
___
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/ diff --git a/src/mesa/drivers/dri/r200/r200_context.h b/src/mesa/drivers/dri/r200/r200_context.h
index bec09e8..c80180b 100644
--- a/src/mesa/drivers/dri/r200/r200_context.h
+++ b/src/mesa/drivers/dri/r200/r200_context.h
@@ -179,6 +179,7 @@ struct r200_tex_obj {
drm_radeon_tex_image_t image[6][RADEON_MAX_TEXTURE_LEVELS];
/* Six, for the cube faces */
+ GLboolean image_override; /* Image overridden by GLX_EXT_tfp */
GLuint pp_txfilter; /* hardware register values */
GLuint pp_txformat;
diff --git a/src/mesa/drivers/dri/r200/r200_tex.h b/src/mesa/drivers/dri/r200/r200_tex.h
index e6c0e00..10ff8e8 100644
--- a/src/mesa/drivers/dri/r200/r200_tex.h
+++ b/src/mesa/drivers/dri/r200/r200_tex.h
@@ -35,6 +35,10 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#ifndef __R200_TEX_H__
#define __R200_TEX_H__
+extern void r200SetTexOffset(__DRIcontext *pDRICtx, GLint texname,
+ unsigned long long offset, GLint depth,
+ GLuint pitch);
+
extern void r200UpdateTextureState( GLcontext *ctx );
extern int r200UploadTexImages( r200ContextPtr rmesa, r200TexObjPtr t, GLuint face );
diff --git a/src/mesa/drivers/dri/r200/r200_texmem.c b/src/mesa/drivers/dri/r200/r200_texmem.c
index d926313..772714b 100644
--- a/src/mesa/drivers/dri/r200/r200_texmem.c
+++ b/src/mesa/drivers/dri/r200/r200_texmem.c
@@ -181,7 +181,8 @@ static void r200UploadRectSubImage( r200ContextPtr rmesa,
/* In this case, could also use GART texturing. This is
* currently disabled, but has been tested works.
*/
- t-pp_txoffset = r200GartOffsetFromVirtual( rmesa, texImage-Data );
+ if ( !t-image_override )
+ t-pp_txoffset = r200GartOffsetFromVirtual( rmesa, texImage-Data );
t-pp_txpitch = texImage-RowStride * texFormat-TexelBytes - 32;
if (R200_DEBUG DEBUG_TEXTURE)
@@ -467,7 +468,7 @@ int r200UploadTexImages( r200ContextPtr rmesa, r200TexObjPtr t, GLuint face )
t-base.firstLevel, t-base.lastLevel );
}
- if ( !t || t-base.totalSize == 0 )
+ if ( !t || t-base.totalSize == 0 | t-image_override )
return 0;
if (R200_DEBUG DEBUG_SYNC) {
diff --git a/src/mesa/drivers/dri/r200/r200_texstate.c b/src/mesa/drivers/dri/r200/r200_texstate.c
index ae02ec4..c2f03dc 100644
--- a/src/mesa/drivers/dri/r200/r200_texstate.c
+++ b/src/mesa/drivers/dri/r200/r200_texstate.c
@@ -37,6 +37,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#include context.h
#include macros.h
#include texformat.h
+#include texobj.h
#include enums.h
#include r200_context.h
@@ -72,10 +73,11 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#define VALID_FORMAT(f) ( ((f) = MESA_FORMAT_RGBA_DXT5) \
(tx_table_le[f].format != 0x) )
-static const struct {
+struct tx_table {
GLuint format, filter;
-}
-tx_table_be[] =
+};
+
+static const struct tx_table tx_table_be[] =
{
[ MESA_FORMAT_RGBA ] = { R200_TXFORMAT_ABGR | R200_TXFORMAT_ALPHA_IN_MAP, 0 },
_ALPHA_REV(RGBA),
@@ -104,16 +106,13 @@ tx_table_be[] =
_ALPHA(RGBA_DXT5),
};
-static const struct {
- GLuint format, filter;
-}
-tx_table_le[] =
+static const struct tx_table tx_table_le[] =
{
_ALPHA(RGBA),
[ MESA_FORMAT_RGBA_REV ] = { R200_TXFORMAT_ABGR | R200_TXFORMAT_ALPHA_IN_MAP, 0 },
_ALPHA(ARGB),
_ALPHA_REV(ARGB),
- _INVALID(RGB888),
+ _COLOR(RGBA),
_COLOR(RGB565),
_COLOR_REV(RGB565),
_ALPHA(ARGB),
@@ -160,30 +159,23 @@ static void r200SetTexImages( r200ContextPtr rmesa,
GLint i, texelBytes;
GLint numLevels;
GLint log2Width, log2Height, log2Depth;
- const GLuint ui = 1;
- const GLubyte littleEndian = *((const GLubyte *) ui);
/* Set the hardware texture format
*/
+ if ( !t-image_override ) {
+ if ( VALID_FORMAT( baseImage-TexFormat-MesaFormat ) ) {
+ t-pp_txformat = ~(R200_TXFORMAT_FORMAT_MASK |
+ R200_TXFORMAT_ALPHA_IN_MAP);
+ t-pp_txfilter = ~R200_YUV_TO_RGB;
- t-pp_txformat = ~(R200_TXFORMAT_FORMAT_MASK |
- R200_TXFORMAT_ALPHA_IN_MAP);
- t-pp_txfilter = ~R200_YUV_TO_RGB;
-
- if ( VALID_FORMAT( baseImage-TexFormat-MesaFormat ) ) {
- if (littleEndian) {
t-pp_txformat |= tx_table_le[ baseImage-TexFormat-MesaFormat ].format;
t-pp_txfilter |= tx_table_le[ baseImage-TexFormat-MesaFormat ].filter;
}
else {
- t-pp_txformat |= tx_table_be[ baseImage-TexFormat-MesaFormat
[Mesa3d-dev] [Bug 11931] Mesa: banding in rendering when using blending for transparency, asm statement issue?
http://bugs.freedesktop.org/show_bug.cgi?id=11931 --- Comment #1 from [EMAIL PROTECTED] 2007-08-12 04:30 PST --- (In reply to comment #0) In the end, there's a small patch against an asm statement in spantmp2.h which fixes the problem in Debian on r200 in mesa 6.5.2 and 6.5.3 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=read_rgba.patch;att=1;bug=423739 But: - Is the 0 usage in asm statements a gcc-specific extension? If so, would this break x86 r200 DRI on non-gcc compilers, if any such are used? Isn't the whole usage of inline asm gcc-specific anyway? - Lots of other DRI drivers use spantmp2.h, why wouldn't this have shown up broken in these by now, if this were really the problem? The problem would only show up if compiled with x86 optimizations, and only in swrast fallbacks, which are rare in normal apps. Here's the reasoning behind the patch, spelled out in case it is utterly wrong: The patch is to make the 32-bit color buffer READ_RGBA macro, in its x86-assembly variant, know that the input parameter of the bswap instruction resides in the same register as the output parameter (change the r to a 0 for the input). Looking at the assembly code of r200ReadRGBAPixels_ARGB (generated by dri/r200/r200_span.c via dri/common/spantmp2.h) the patched code generates something like: mov%eax,0xffd0(%ebp) bswap %eax ror$0x8,%eax while the unpatched code, when compiled -O2, loses the initial mov instruction and hence the %eax register is actually never even initialized... This would also explain why turning off register-move optimizations is another way to fix the problem. Which follows from the gcc docs: Only a number in the constraint can guarantee that one operand will be in the same place as another. The mere fact that `foo' is the value of both operands is not enough to guarantee that they will be in the same place in the generated assembler code. When I last looked at this, it seemed pretty reasonable, but I'm no expert at inline assembly. I'm going to commit it now. -- 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11931] Mesa: banding in rendering when using blending for transparency, asm statement issue?
http://bugs.freedesktop.org/show_bug.cgi?id=11931 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] Potential patch for R200 accelerated TFP
On 8/12/07, Chris Rankin [EMAIL PROTECTED] wrote: OK, here it is - the final version. Now given that I am running Fedora 7 at the moment, exactly what will I need to update in order to test it? Are there any official Xorg packages that I will need to grab and compile, or is everything still unreleased from git repositories? shouldn't: - if ( !t || t-base.totalSize == 0 ) + if ( !t || t-base.totalSize == 0 | t-image_override ) be + if ( !t || t-base.totalSize == 0 || t-image_override ) You'll need a fairly recent (post 1.3 xserver) and mesa. you can grab them from git. Redhat may also provide experimental packages. Alex - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] 3D support for 2048x2048 on intel drivers
I've got two framebuffers and batchbuffers set up, but I'm having problems trying to send two batchbuffers to DRM. If I try, using a second call to drmCommandWrite in intel_batch_ioctl, I get kernel drm errors such as: [drm:drm_fence_lazy_wait] *ERROR* Fence timeout. GPU lockup or fence driver was taken down. [drm:drm_bo_expire_fence] *ERROR* Detected GPU lockup or fence driver was taken down. Evicting buffer. And then the card is usually hosed enough I need to reboot. I don't really know anything about fences, and looking through the code hasn't helped too much. Can anyone explain what's going on? Thanks, Chase - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11940] Mesa 7.1 implementation error: In _mesa_DeleteHashTable, found non-freed data
http://bugs.freedesktop.org/show_bug.cgi?id=11940 --- Comment #3 from [EMAIL PROTECTED] 2007-08-12 13:31 PST --- (In reply to comment #2) I don't think I have time to download/install epsxe (and prerequisites, etc). Could you run with gdb, set a breakpoint in _mesa_problem() and get a stack trace? not sure if this is the same issue, but using fbos triggers this (for instance fbotest1). -- 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 9880] draw texturt assertion fail when internalformat is GL_COMPRESSED_RGB_FXT1_3DFX and size is 2x2
http://bugs.freedesktop.org/show_bug.cgi?id=9880 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED -- 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11956] drawing a line 2.0px in width has incorrect offset
http://bugs.freedesktop.org/show_bug.cgi?id=11956 --- Comment #2 from [EMAIL PROTECTED] 2007-08-12 19:49 PST --- The image shows a 1px line around a 3d object, but this only works because the line drawn is 2px wide, and half of it is masked out by the 3d cube. Also, this works for ATI cards as well, which makes me think its not an nvidia quirk. A default install of blenders will show this problem if you want to test. Is there any other way to validate the OpenGL drawing? Here are some screenshots of opengl outlines rendering correctly. http://www.zeronave.it/zn/wp-content/uploads/2007/04/blender1.png http://www.lordfreedom.com/Pagine/Grafica/Download/Immagini/Blender.jpg http://upload.wikimedia.org/wikibooks/en/0/03/Screenshot-5.png http://www.siteduzero.com/uploads/fr/files/8001_9000/8249.png - with mesa only the top and right lines show. http://www.webalice.it/fulvio.peruggi/public/PegasosMorphOS/Articles/06_MorphOS_TLOS/Blender.jpg -- 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
