From: <bug...@fr...> - 2005-08-31 23:45:36
|
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...@li... ReportedBy: fl...@ac... 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, 10000); 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; Colormap cmap; 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 server has no OpenGL GLX extension\n"); return 1; } /*** (3) find an appropriate visual ***/ /* find an OpenGL-capable RGB visual with depth buffer */ vi = glXChooseVisual(dpy, DefaultScreen(dpy), dblBuf); if (vi == NULL) { printf("couldn't get dblBuf\n"); vi = glXChooseVisual(dpy, DefaultScreen(dpy), snglBuf); if (vi == NULL) { printf("no RGB visual with depth buffer\n"); return 1; } doubleBuffer = GL_FALSE; } //printf("got visual id 0x%x\n", vi->visualid); if(vi->class != TrueColor) { printf("TrueColor visual required for this program\n"); } /*** (4) create an OpenGL rendering context ***/ /* create an OpenGL rendering context */ cx = glXCreateContext(dpy, vi, None, GL_TRUE); if (cx == NULL) { printf("could not create rendering context\n"); return 1; } /*** (5) create an X window with the selected visual ***/ /* create an X colormap since probably not using default visual */ cmap = XCreateColormap(dpy, RootWindow(dpy, vi->screen), vi->visual, AllocNone); swa.colormap = cmap; swa.border_pixel = 0; swa.override_redirect = False; swa.event_mask = ExposureMask | ButtonPressMask | StructureNotifyMask; win = XCreateWindow(dpy, RootWindow(dpy, vi->screen), 0, 0, 640, 480, 0, vi->depth, InputOutput, vi->visual, CWOverrideRedirect | CWBorderPixel | CWColormap | CWEventMask, &swa); /*** (6) bind the rendering context to the window ***/ glXMakeCurrent(dpy, win, cx); /*** (7) request the X window to be displayed on the screen ***/ XSelectInput(dpy, win, ExposureMask | KeyPressMask | KeyReleaseMask | ButtonPressMask | StructureNotifyMask); Cursor no_ptr; Pixmap bm_no; XColor black, xdummy; Colormap colormap; static char no_data[] = { 0,0,0,0,0,0,0,0 }; /* make sure the window is in the upper-left */ XMoveWindow(dpy, win, 0, 0); /* * Some code to hide the cursor. This just creates an empty 8x8 pixmap * and defines the cursor to be that pixmap. */ colormap = DefaultColormap(dpy, DefaultScreen(dpy)); XAllocNamedColor(dpy, colormap, "black", &black, &xdummy); bm_no = XCreateBitmapFromData(dpy, win, no_data, 8, 8); no_ptr = XCreatePixmapCursor(dpy, bm_no, bm_no, &black, &black, 0, 0); XDefineCursor(dpy, win, no_ptr); XFreeCursor(dpy, no_ptr); XMapWindow(dpy, win); XFlush(dpy); init(); asdf = 1; while(asdf) { if(XPending(dpy)) { if(XCheckWindowEvent(dpy, win, KeyPressMask | KeyReleaseMask | ExposureMask | ButtonPressMask | StructureNotifyMask, &event)) /* loop to compress events */ { switch (event.type) { case KeyPress: XLookupString((XKeyEvent *)&event, NULL, 0x00, &keysym, &compose); if(keysym == XK_Escape) { asdf = 0; } break; } } } draw(); } return 0; } -- 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. |
From: <bug...@fr...> - 2005-09-01 00:50:20
|
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 fl...@ac... 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. |
From: <bug...@fr...> - 2005-10-12 15:28:21
|
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 id...@us... changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO ------- Additional Comments From id...@us... 2005-10-12 08:28 ------- Is this bug still reproducable? I seem to recall keithw making some changes related to this since August. -- 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. |
From: <bug...@fr...> - 2005-10-12 23:59:35
|
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 fl...@ac... 2005-10-12 16:59 ------- I just did a cvs update to my xorg, drm, and mesa trees and rebuilt everything. The problem still occurs. Is there anything else I should've updated? You can still test it the program I pasted into the bug report. As I mentioned earlier, you can change tiledim to 256 or 64 to see the problem a little more clearly. hope that helps. -- 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. |
From: <bug...@fr...> - 2005-10-14 08:05:49
|
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 uni...@sh... 2005-10-14 01:05 ------- Hmm. IIRC, the Unichrome driver does not explicitly wait for 3D engine idle before doing a back-to-front buffer blit, since this would probably involve making DMA quiescent and doing a busy-wait on the 3D engine. Rather, it assumes the command regulator waits for 3D engine idle before issuing a 2D blit. This might well be the cause, but then this would have severe performance implications in very important applications such as glxgears ;) We should really figure out wether this is the case. /Thomas -- 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. |
From: <bug...@fr...> - 2005-10-14 09:20:44
|
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 ke...@tu... 2005-10-14 02:20 ------- Texture upload (viaTexSubImage2D) is just done with a memcpy, not via a 2d blit. A quick look at the code shows that dma is flushed to the hardware prior to the memcpy, but not that the hardware is idled. Via teximages are already tagged with a breadcrumb indicating when they were last used. Breadcrumb is a per-frame counter, so you'd want to do something like: if (tex->breadcrumb <= highest_retired_breadcrumb) { /* image hasn't been used recently - just go ahead and update */ } else if (tex->breadcrumb <= highest_submitted_breadcrumb) { /* image was used in a previous frame, but still pending on hardware */ wait-for-breadcrumb } else { /* image has been used this frame */ wait-for-dma-idle } I don't think this has any bearing on SwapBuffers? -- 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. |
From: <bug...@fr...> - 2005-10-14 09:25:10
|
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 ke...@tu... 2005-10-14 02:25 ------- Couple more comments. I think the current implementation of viaTexImage2D is correct - any texture memory which might still be acccessed by hardware is not updated - a new memory block is allocated instead (see via_release_pending_textures). An optimization for viaTexSubImage2D() would be to check if the whole texture image is being updated and if so, use the viaTexImage path instead of waiting. -- 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. |
From: <bug...@fr...> - 2005-10-14 22:25:29
|
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 uni...@sh... 2005-10-14 15:25 ------- OK, Hmm, I wasn't reading too carefully. I thought the problem might be caused by a back-to front blit occuring before the 3D engine had completed it's rendering to the back buffer. Anyway, I compiled the submitted code and the problem is reproduced, and I did some sync testing in viaTexSubImage2D: If VIA_FLUSH_DMA(vmesa) is replaced by viaWaitIdle(vmesa), the problem goes away, so it seems clear that the texture memory is written to while the 3D engine uses it. The problem seems to be how to sync without having to lock and wait for engine idle. If the command regulator really waits for 3D engine idle before issuing a pending 2D blit, then the problem is easily solved by emitting a breadcrumb after the DMA flush and wait for it to be read. However, if the breadcrumb is blitted at the end of the command stream while the 3D engine still renders, there is a problem and we'll have to lock and wait for 3D engine idle. If this is really the case, then this must be done also before back-to-front buffer blits otherwise parts of the image may not be completely rendered before the blit occurs. Luckily, I don't think this is the case, and really, commenting out while(!viaCheckIdle(vmesa)) ; from viaWaitIdle still makes the sample case render correctly. Also, while looking at this, some things strike me: 1) Breadcrumb 32-bit wraparounds don't seem to be correctly handled? 2) Shouldn't viaCheckIdle be called locked from within viaWaitIdle? /Thomas -- 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. |
From: <bug...@fr...> - 2005-10-15 16:27:14
|
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 ke...@tu... 2005-10-15 09:27 ------- Using the 2d engine for breadcrumbs seems to work fine, so it seems the operation of 2d and 3d engines is somewhat coordinated. It would be good to make a stress-test for this. Wraparounds aren't handled correctly (or at all, I think). I don't think there's a need to lock before calling CheckIdle(), it's not changing the hardware state, I think it's ok to read an mmio reg without holding the lock. -- 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. |
From: <bug...@fr...> - 2005-10-17 07:28:07
|
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 mi...@da... 2005-10-17 00:28 ------- (In reply to comment #8) > > I don't think there's a need to lock before calling CheckIdle(), it's not > changing the hardware state, I think it's ok to read an mmio reg without holding > the lock. True, but the problem is that if you don't take the lock, another process could theoretically keep the engine busy indefinitely. -- 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. |
From: <bug...@fr...> - 2005-10-19 22:10:32
|
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 aj...@nw... changed: What |Removed |Added ---------------------------------------------------------------------------- Component|libdri |Drivers/DRI/Unichrome Product|DRI |Mesa Version|XOrg CVS |unspecified -- 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. |
From: <bug...@fr...> - 2005-10-20 07:47:34
|
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 uni...@sh... 2005-10-20 00:47 ------- Created an attachment (id=3590) --> (https://bugs.freedesktop.org/attachment.cgi?id=3590&action=view) Patch that seems to fix the problem I've attached a patch that seems to fix the problem, by making a light version of viaWaitIdle, and calling it before texture image uploads. In addition it addresses the breadcrumb 32 bit wraparound issue and the possible CPU-time starvation issue in viaWaitIdle. -- 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. |
From: <bug...@fr...> - 2005-10-20 13:38:33
|
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 bri...@tu... 2005-10-20 06:38 ------- If you decide to go with this patch, please apply it to the 6.4 branch too. -- 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. |
From: <bug...@fr...> - 2005-10-22 16:23:26
|
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 uni...@sh... changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Resolution| |FIXED ------- Additional Comments From uni...@sh... 2005-10-22 09:23 ------- Fixed in Mesa 6.4 branch CVS. -- 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. |