Re: [r300] texturing mode issue with r420 (X800 XT)
On Sun, 28 Aug 2005 22:18:20 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Hi, I've found some texturing modes course corruption and lockups on my hardware. With quake3 I get corruption, and often lockup when starting a match/map. Q3DM0 locks up 9 out of 10 times. Q3DM17 works 10 out of 10 times. This is most likely r420 specific. Q3DM0 would seem to use multi texturing more often than Q3DM17, so you might want to try progs/demos/multiarb . With bzflag I get corruption the instent I select the affected modes. The affected texture modes are: NEAREST_MIPMAP_LINEAR LINEAR_MIPMAP_LINEAR LINEAR_MIPMAP_NEAREST I imagine mipmaps would work a lot better if the gpu would know what levels are actually available... r300 tex reg layout is different from r200s so R200_MAX_MIP_LEVEL_SHIFT shouldnt work. -- Aapo Tahkola --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4277] via_dri.h out of sync with DDX driver.
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=4277 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2005-08-31 07:46 --- Fallout from previous commits: grep -n viaScreen-reg via_context.c:564:vmesa-regMMIOBase = (GLuint *)((GLuint)viaScreen-reg); via_context.c:565:vmesa-pnGEMode = (GLuint *)((GLuint)viaScreen-reg + 0x4); via_context.c:566:vmesa-regEngineStatus = (GLuint *)((GLuint)viaScreen-reg + 0x400); via_context.c:567:vmesa-regTranSet = (GLuint *)((GLuint)viaScreen-reg + 0x43C); via_context.c:568:vmesa-regTranSpace = (GLuint *)((GLuint)viaScreen-reg + 0x440); via_screen.c:166: drmUnmap(viaScreen-reg, gDRIPriv-regs.size); via_screen.c:197:drmUnmap(viaScreen-reg, gDRIPriv-regs.size); viaScreen-reg is never assigned anymore. I'm not certain why the drmAddress map change was necessary, but it will have broken something, even though i'm seeing no adverse effects in running glxgears. But then, i didn't see anything with Bool as char either, amazingly. -- 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. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4277] via_dri.h out of sync with DDX driver.
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=4277 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-31 08:20 --- Sorry, that was an change in my local tree that made it into the Mesa 6.4 branch, but it never got to the Mesa trunk code. I've backed that out. -- 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. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4327] New: texture mapping bug on unichrome
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=4327
Summary: texture mapping bug on unichrome
Product: DRI
Version: XOrg CVS
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: libdri
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]
I'm seeing a really weird texture mapping bug on unichrome. My app displays
really large images by specifying a reasonable sized texture (a tile, size
256x256 or 512x512) and calling glTexSubImage2D() to update that texture with a
portion of the larger image. The app then draws a textured quad for that
portion of the screen. This is repeated for all the tiles that make up the
image.
What I'm seeing appears to be a couple scanlines from one tiles swapped with a
couple scanlines from another tile. In addition, there seems to be a small
triangle of the swapped image in the lower left of each tile.
I last updated my cvs trees for X, drm, and Mesa August 30th, 2005.
I'm building for linux-dri-x86.
I don't see this issue with swrast, nvidia, or ati drivers.
The following is a small sample that reproduces the error:
#include GL/gl.h
#include GL/glx.h
#include X11/Xlib.h
#include X11/keysym.h
#include X11/Xatom.h
Display *dpy;
Window win;
GLboolean doubleBuffer = GL_TRUE;
static int snglBuf[] = {GLX_RGBA, GLX_DEPTH_SIZE, 16, None};
static int dblBuf[] = {GLX_RGBA, GLX_DEPTH_SIZE, 16, GLX_DOUBLEBUFFER, None};
int tiledim = 0;
int tilesize = 0;
unsigned char *image = NULL;
int numtiles = 3;
GLint texid = 0;
static GLfloat verts[4][2] = {
{ 0.0f, 0.0f },
{ 1.0f, 0.0f },
{ 1.0f, 1.0f },
{ 0.0f, 1.0f },
};
static GLfloat texcoords[4][2] = {
{ 0.0f, 0.0f },
{ 1.0f, 0.0f },
{ 1.0f, 1.0f },
{ 0.0f, 1.0f },
};
void init(void)
{
unsigned char *dst = NULL;
int i = 0;
// get tile size
glGetIntegerv(GL_MAX_TEXTURE_SIZE, tiledim);
tilesize = tiledim * tiledim * 4;
// create image buffer
image = (unsigned char *) malloc(numtiles * tilesize);
dst = image;
memset(image, 0, numtiles * tilesize);
// fill in red tile
for(i = 0; i tiledim * tiledim; i++)
{
*dst++ = 255; // r
*dst++ = 0; // g
*dst++ = 0; // b
*dst++ = 255; // a
}
// fill in green tile
for(i = 0; i tiledim * tiledim; i++)
{
*dst++ = 0; // r
*dst++ = 255; // g
*dst++ = 0; // b
*dst++ = 255; // a
}
// fill in blue tile
for(i = 0; i tiledim * tiledim; i++)
{
*dst++ = 0; // r
*dst++ = 0; // g
*dst++ = 255; // b
*dst++ = 255; // a
}
// create gl texture
glEnable(GL_TEXTURE_2D);
glGenTextures(1, texid);
glBindTexture(GL_TEXTURE_2D, texid);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, tiledim, tiledim, 0, GL_RGBA,
GL_UNSIGNED_BYTE, NULL);
// setup verts
glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glVertexPointer(2, GL_FLOAT, 0, verts);
glTexCoordPointer(2, GL_FLOAT, 0, texcoords);
// setup frustum
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glFrustum(-1.5, 1.5, -1.5, 1.5, 1, 1);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
}
void draw(void)
{
unsigned char *subimage = NULL;
int i = 0;
glLoadIdentity();
glTranslatef(-2.5, 0.0, -1.0);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
for(i = 0; i numtiles; i++)
{
subimage = image + (i * tilesize);
glTranslatef(1.0, 0.0, 0.0);
glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, tiledim, tiledim, GL_RGBA,
GL_UNSIGNED_BYTE, subimage);
glDrawArrays(GL_TRIANGLE_FAN, 0, 4);
}
glXSwapBuffers(dpy, win);
}
int main(int argc, char *argv[])
{
XVisualInfo*vi;
Colormapcmap;
XSetWindowAttributes swa;
GLXContext cx;
int dummy;
int asdf = 1;
XEvent event;
KeySym keysym;
XComposeStatus compose;
/*** (1) open a connection to the X server ***/
dpy = XOpenDisplay(NULL);
if (dpy == NULL)
{
printf(could not open display\n);
return 1;
}
/*** (2) make sure OpenGL's GLX extension supported ***/
if(!glXQueryExtension(dpy, dummy, dummy))
{
printf(X
[Bug 4327] texture mapping bug on unichrome
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=4327 --- Additional Comments From [EMAIL PROTECTED] 2005-08-31 17:50 --- I've been playing with this a bit more and have some more notes... - if in the sample, if you take out the glGetIntegerv and just set texdim to 64, the artifact will be a bit larger and more obvious. - if i use a separate texture id for each quad, everything looks fine. - if i do a glFinish after each glDrawArrays() everything looks fine. - it looks as if there's some sort of synchronization problem with glTexSubImage2D. as if one can change the texture with glTexSubImage2D() while a triangle is still being rasterized with that texture and it affects the rasterization of that triangle. it seems one would want to wait until the last glTexSubImage2D() was finished before allowing another one on the same texture object rather than allowing them to clobber all over each other. not sure if that's what's happening here, but it looks like it might be. -- 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. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Finishing up renderbuffer changes in DRI drivers
I'm trying to tie up some loose ends from the GL_EXT_framebuffer_object work I did a while back. I previously updated the span functions so they'd take a gl_renderbuffer pointer and now I'm making the code actually use that parameter. The idea is to use the fields of the gl_renderbuffer parameter to determine where to read/write the pixels, instead of using per-context state which is set in the SetBuffer routine. I'm checking in the updated radeon and r200 drivers and I'll do the mach64 and r128 drivers next. I've tested the radeon changes, but not the r200. If someone could run the reflect demo on r200 and use the a/s/d/f/c keys to exercise the span routines, that would be good. The readpix and singlebuffer demos are good tests too. In the r200 code, I've left in the old code surrounded by #ifdef 000 / #endif to make it obvious what I changed. I'll remove the #ifdef 000 code later. It would be nice if other driver maintainers could take a look and carry over the changes. The basic idea is to: 1. Remove the SetBuffer() routine. 2. In the span routines, cast the gl_renderbuffer pointer into a driRenderbuffer pointer and use its offset/pitch/cpp fields instead of the per-context offset/pitch/cpp fields. 3. Clean-up other code related to offset/pitch/cpp elsewhere as needed. After this is done, I can remove a bunch of unneeded code from the swrast module. -Brian --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
