[Bug 8218] Errors during World of Warcraft "stress test"
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=8218 --- Additional Comments From [EMAIL PROTECTED] 2006-09-19 18:16 --- (In reply to comment #13) > (In reply to comment #11) > > Lots of those: > > ==17068== Invalid write of size 4 > > ==17068==at 0x4167F6C: emit_vector (r200_maos_arrays.c:287) > > Not sure. I guess it's the float/int casts causing trouble here? > What float/int casts? out is an int* and data is a char*, so where's the > float? Yeah, no float there. As I already mentioned, the problem (which actually is only a problem with valgrind) seems to be entirely different anyway. > This also looked interesting: > ==17123== Invalid write of size 1 > ==17123==at 0x40069A6: memcpy (mac_replace_strmem.c:394) > ==17123==by 0x4156245: r200UploadTexImages (string3.h:51) > ==17123==by 0x41580E9: r200UpdateTextureUnit (r200_texstate.c:1546) Yes, somewhat interesting. Unfortunately the output is a bit useless, what's up with that string3.h file? No idea on which line in r200UploadTexImages function this happens. > And with regards to the vbo code: > ... > > Last possibility would be the r200 vtxfmt code, if it's > > no longer buggy if you use tcl_mode=1 then that's the case. > > I switched to tcl_mode=1 by default a while ago because I thought it might be > faster (hardware vs software), and the feature is still buggy when ARB_vbo is > enabled. This is basically why I tried using valgrind - to see if anything > showed up in the software vbo code. Yes, with modern games, tcl_mode=1 should never be slower, as all modern apps use vertex arrays, which cause a straight fallback out of vtxfmt code all the time (and it might thus save some cpu time for not doing some additional work - it's highly unlikely to make really a measurable difference though). > Incidentally, I saw that the r300 implements vbos in hardware. Is this an > extra > feature of the R300 hardware, or could the R200 hardware do this too? No, r200 (and r100 too) can easily do that, with basically the same code as r300 uses for that. It's on my TODO list... -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8218] Errors during World of Warcraft "stress test"
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=8218 --- Additional Comments From [EMAIL PROTECTED] 2006-09-19 17:58 --- (In reply to comment #11) > Lots of those: > ==17068== Invalid write of size 4 > ==17068==at 0x4167F6C: emit_vector (r200_maos_arrays.c:287) > Not sure. I guess it's the float/int casts causing trouble here? What float/int casts? out is an int* and data is a char*, so where's the float? This also looked interesting: ==17123== Invalid write of size 1 ==17123==at 0x40069A6: memcpy (mac_replace_strmem.c:394) ==17123==by 0x4156245: r200UploadTexImages (string3.h:51) ==17123==by 0x41580E9: r200UpdateTextureUnit (r200_texstate.c:1546) ==17123==by 0x41585FF: r200UpdateTextureState (r200_texstate.c:1668) ==17123==by 0x414C5E3: r200ValidateState (r200_state.c:2372) ==17123==by 0x4145560: r200MakeCurrent (r200_context.c:718) ==17123==by 0x414225F: driBindContext (dri_util.c:343) ==17123==by 0x4277CABB: (within /usr/lib/libGL.so.1.2) ==17123==by 0x4277ECAE: glXMakeContextCurrent (in /usr/lib/libGL.so.1.2) ==17123==by 0x4277EF42: glXMakeCurrent (in /usr/lib/libGL.so.1.2) ==17123==by 0x41101B5B: fgSetWindow (in /usr/lib/libglut.so.3.8.0) ==17123==by 0x410FD2E6: glutMainLoopEvent (in /usr/lib/libglut.so.3.8.0) ==17123== Address 0xB7D16183 is not stack'd, malloc'd or (recently) free'd And with regards to the vbo code: ... > Last possibility would be the r200 vtxfmt code, if it's > no longer buggy if you use tcl_mode=1 then that's the case. I switched to tcl_mode=1 by default a while ago because I thought it might be faster (hardware vs software), and the feature is still buggy when ARB_vbo is enabled. This is basically why I tried using valgrind - to see if anything showed up in the software vbo code. Incidentally, I saw that the r300 implements vbos in hardware. Is this an extra feature of the R300 hardware, or could the R200 hardware do this 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8218] Errors during World of Warcraft "stress test"
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=8218 --- Additional Comments From [EMAIL PROTECTED] 2006-09-19 17:51 --- (In reply to comment #11) > Lots of those: > ==17068== Invalid write of size 4 > ==17068==at 0x4167F6C: emit_vector (r200_maos_arrays.c:287) > Not sure. I guess it's the float/int casts causing trouble here? > > Those in the swtcl path look fairly similar. > ==17068== Invalid write of size 4 > ==17068==at 0x415F72A: r200_render_quad_strip_verts (t_dd_triemit.h:80) > IIRC gcc will actually report warnings when compiled with strict aliasing at > around these places. That's probably not a related problem, however, I was wrong. Those writes are invalid because valgrind thinks we're writing past allocated memory. This is however not the case, again valgrind doesn't know that this memory (those are writes to the indirect buffers) is allocated elsewhere. Well, that's what I think happens, at least. -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8218] Errors during World of Warcraft "stress test"
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=8218 --- Additional Comments From [EMAIL PROTECTED] 2006-09-19 17:21 --- Sorry for the unreadable copy & paste mess caused by the stupid small comment box (and it's not possible to edit afterwards). Corrected version follows. (In reply to comment #5) > Created an attachment (id=7086) --> (https://bugs.freedesktop.org/attachment.cgi?id=7086&action=view) [edit] > valgrind 3.1.0 output from arbvpwarpmesh > > Uninitialised values and invalid writes(?). I'm not an expert for valgrind. Just some quick thoughts: ==17068== Conditional jump or move depends on uninitialised value(s) ==17068==at 0x4147992: r200Clear (r200_ioctl.c:698) ==17068== Conditional jump or move depends on uninitialised value(s) ==17068==at 0x4146ECA: r200WaitForFrameCompletion (r200_ioctl.c:391) These two don't look unitialized to me - I think valgrind can't know that these values (in the sarea) are indeed written by drm, and thus assumes they aren't initialized. Lots of those: ==17068== Invalid write of size 4 ==17068==at 0x4167F6C: emit_vector (r200_maos_arrays.c:287) Not sure. I guess it's the float/int casts causing trouble here? Those in the swtcl path look fairly similar. ==17068== Invalid write of size 4 ==17068==at 0x415F72A: r200_render_quad_strip_verts (t_dd_triemit.h:80) IIRC gcc will actually report warnings when compiled with strict aliasing at around these places. These two are somewhat interesting: ==17068== Syscall param write(buf) points to uninitialised byte(s) ==17068==at 0x41485F13: __write_nocancel (in /lib/libc-2.4.so) ==17068==by 0x4157567E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0) ==17068== Syscall param ioctl(generic) points to uninitialised byte(s) ==17068==at 0x4148D3B9: ioctl (in /lib/libc-2.4.so) ==17068==by 0x4141279: do_wait (vblank.c:243) ==17068==by 0x4141350: driWaitForVBlank (vblank.c:311) ==17068==by 0x4148618: r200CopyBuffer (r200_ioctl.c:453) ==17068==by 0x4145775: r200SwapBuffers (r200_context.c:653) ==17068==by 0x414148E: driSwapBuffers (dri_util.c:472) ==17068==by 0x4277AEDD: glXSwapBuffers (in /usr/lib/libGL.so.1.2) ==17068==by 0x410F453D: glutSwapBuffers (in /usr/lib/libglut.so.3.8.0) ==17068==by 0x80494F4: Display (arbvpwarpmesh.c:88) ==17068==by 0x410FCB85: (within /usr/lib/libglut.so.3.8.0) ==17068==by 0x41100161: fgEnumWindows (in /usr/lib/libglut.so.3.8.0) ==17068==by 0x410FD43A: glutMainLoopEvent (in /usr/lib/libglut.so.3.8.0) ==17068== Address 0xBEB412E4 is on thread 1's stack ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068==This could cause spurious value errors to appear. ==17068==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068==This could cause spurious value errors to appear. ==17068==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068==This could cause spurious value errors to appear. ==17068==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. I've no idea what the problem here really is (yeah yeah I know I should read README_MISSING_SYSCALL_OR_IOCTL), the first one of these is somewhere buried in libX11, maybe that's part of Xorg's ioctl-wrapper-for-everything design. As for ARB_vbo, you're right they are not implemented in the driver. Any bugs you see when using them are likely either a bug in mesa core, an application bug, or exhibiting a problem which does not exist without them because the app would do something different when not using it (i.e. instead of just doing basically the same but with standard vertex arrays, it might do something completely different). Last possibility would be the r200 vtxfmt code, if it's no longer buggy if you use tcl_mode=1 then that's the case. -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8218] Errors during World of Warcraft "stress test"
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=8218 --- Additional Comments From [EMAIL PROTECTED] 2006-09-19 17:15 --- (In reply to comment #5) > Created an attachment (id=7086) --> (https://bugs.freedesktop.org/attachment.cgi?id=7086&action=view) [edit] > valgrind 3.1.0 output from arbvpwarpmesh > > Uninitialised values and invalid writes(?). I'm not an expert for valgrind. Just some quick thoughts: ==17068== Conditional jump or move depends on uninitialised value(s) ==17068==at 0x4147992: r200Clear (r200_ioctl.c:698) ==17068== Conditional jump or move depends on uninitialised value(s) ==17068==at 0x4146ECA: r200WaitForFrameCompletion (r200_ioctl.c:391) These two don't look unitialized to me - I think valgrind can't know that these values (in the sarea) are indeed written by drm, and thus assumes they aren't initialized. Lots of those: ==17068== Invalid write of size 4 ==17068==at 0x4167F6C: emit_vector (r200_maos_arrays.c:287) Not sure. I guess it's the float/int casts causing trouble here? Those in the swtcl path look fairly similar. ==17068== Invalid write of size 4 ==17068==at 0x415F72A: r200_render_quad_strip_verts (t_dd_triemit.h:80) IIRC gcc will actually report warnings when compiled with strict aliasing at around these places. These two are intersting: ==17068== Syscall param write(buf) points to uninitialised byte(s) ==17068==at 0x41485F13: __write_nocancel (in /lib/libc-2.4.so) ==17068==by 0x4157567E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0) ==17068== Syscall param ioctl(generic) points to uninitialised byte(s) ==17068==at 0x4148D3B9: ioctl (in /lib/libc-2.4.so) ==17068==by 0x4141279: do_wait (vblank.c:243) ==17068==by 0x4141350: driWaitForVBlank (vblank.c:311) ==17068==by 0x4148618: r200CopyBuffer (r200_ioctl.c:453) ==17068==by 0x4145775: r200SwapBuffers (r200_context.c:653) ==17068==by 0x414148E: driSwapBuffers (dri_util.c:472) ==17068==by 0x4277AEDD: glXSwapBuffers (in /usr/lib/libGL.so.1.2) ==17068==by 0x410F453D: glutSwapBuffers (in /usr/lib/libglut.so.3.8.0) ==17068==by 0x80494F4: Display (arbvpwarpmesh.c:88) ==17068==by 0x410FCB85: (within /usr/lib/libglut.so.3.8.0) ==17068==by 0x41100161: fgEnumWindows (in /usr/lib/libglut.so.3.8.0) ==17068==by 0x410FD43A: glutMainLoopEvent (in /usr/lib/libglut.so.3.8.0) ==17068== Address 0xBEB412E4 is on thread 1's stack ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068==This could cause spurious value errors to appear. ==17068==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068==This could cause spurious value errors to appear. ==17068==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints ==17068==This could cause spurious value errors to appear. ==17068==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. I've no idea what the problem here really is (yeah yeah I know I should read se values (in the sarea) are indeed written by drm, and thus assumes they aren't initialized. Lots of those: ==17068== Invalid write of size 4 ==17068==at 0x4167F6C: emit_vector (r200_maos_arrays.c:287) Not sure. I guess it's the float/int casts causing trouble here? Those in the swtcl path look fairly similar. ==17068== Invalid write of size 4 ==17068==at 0x415F72A: r200_render_quad_strip_verts (t_dd_triemit.h:80) IIRC gcc will actually report warnings when compiled with strict aliasing at around these places. These two are intersting: ==17068== Syscall param write(buf) points to uninitialised byte(s) ==17068==at 0x41485F13: __write_nocancel (in /lib/libc-2.4.so) ==17068==by 0x4157567E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0) ==17068== Syscall param ioctl(generic) points to uninitialised byte(s) ==17068==at 0x4148D3B9: ioctl (in /lib/libc-2.4.so) ==17068==by 0x4141279: do_wait (vblank.c:243) ==17068==by 0x4141350: driWaitForVBlank (vblank.c:311) ==17068==by 0x4148618: r200CopyBuffer (r200_ioctl.c:453) ==17068==by 0x4145775: r200SwapBuffers (r200_context.c:653) ==17068==by 0x414148E: driSwapBuffers (dri_util.c:472) ==17068==by 0x4277AEDD: glXSwapBuffers (in /usr/lib/libGL.so.1.2) ==17068==by 0x410F453D: glutSwapBuffers (in /usr/lib/libglut.so.3.8.0) ==17068==by 0x80494F4: Display (arbvpwarpmesh.c:88) ==17068==by 0x410FCB85: (within /usr/lib/libglut.so.3.8.0) ==17068==by 0x41100161: fgEnumWindows (in /usr/lib/libglut.so.3.8.0) ==17068==by 0x410FD43A: glutMainLoopEvent (in /usr/lib/libglut.so.3.8.0) ==17068== Address 0xBEB412E4 is on thread 1's
[Bug 8218] Errors during World of Warcraft "stress test"
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=8218 --- Additional Comments From [EMAIL PROTECTED] 2006-09-19 16:42 --- Created an attachment (id=7090) --> (https://bugs.freedesktop.org/attachment.cgi?id=7090&action=view) valgrind 3.1.0 output from yuvrect Uninitialised values and invalid(?) memcpy() and writes. -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8218] Errors during World of Warcraft "stress test"
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=8218 --- Additional Comments From [EMAIL PROTECTED] 2006-09-19 16:41 --- Created an attachment (id=7089) --> (https://bugs.freedesktop.org/attachment.cgi?id=7089&action=view) valgrind 3.1.0 output from manytex Uninitialised values and invalid(?) writes. -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8218] Errors during World of Warcraft "stress test"
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=8218 --- Additional Comments From [EMAIL PROTECTED] 2006-09-19 16:38 --- Created an attachment (id=7088) --> (https://bugs.freedesktop.org/attachment.cgi?id=7088&action=view) valgrind 3.1.0 output from fogcoord Uninitialised values and different invalid(?) writes. -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8218] Errors during World of Warcraft "stress test"
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=8218 --- Additional Comments From [EMAIL PROTECTED] 2006-09-19 16:36 --- Created an attachment (id=7087) --> (https://bugs.freedesktop.org/attachment.cgi?id=7087&action=view) valgrind 3.1.0 output from arbvptest3 Uninitialised values and invalid writes(?). -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8218] Errors during World of Warcraft "stress test"
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=8218 --- Additional Comments From [EMAIL PROTECTED] 2006-09-19 16:34 --- Created an attachment (id=7086) --> (https://bugs.freedesktop.org/attachment.cgi?id=7086&action=view) valgrind 3.1.0 output from arbvpwarpmesh Uninitialised values and invalid writes(?). -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8218] Errors during World of Warcraft "stress test"
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=8218 --- Additional Comments From [EMAIL PROTECTED] 2006-09-19 15:42 --- Created an attachment (id=7085) --> (https://bugs.freedesktop.org/attachment.cgi?id=7085&action=view) valgrind 3.1.0 output from bufferobj program I'm not sure how capable valgrind 3.1.0 is of finding errors in Mesa memory, but the r200 DRI seems to implement vertex buffer objects in software and so I thought it worth a look. -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
On Tue, 2006-09-19 at 12:49 +0200, Thomas Hellström wrote: > Benjamin Herrenschmidt wrote: > > On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote: > > > > > > > But this should be the same problem encountered by the agpgart driver? > > > x86 and x86-64 calls change_page_attr() to take care of this. > > > On powerpc it is simply a noop. () > > > > > > > Possibly. We sort-of ignore the issue for now on PowerPC and happen to > > be lucky most of the time because 32 bits PowerPC aren't that agressive > > at prefetching... > > > > I haven't looked at change_page_attr() implementation on x86 but I know > > they also map the linear mapping with large pages. I don't know what > > happens if you start trying to change a single page attribute. x86 can > > breakup that large page into 4k pages, so maybe that's what happens. > > > > > Yes, I think that's what happens. I know some Athlon chips had a big > issue with this some time ago. > > I notice there are special functions in to alloc / free GATT > pages, so the general idea might be to have a pool of uncached pages > in the future for powerpc? Even better would perhaps be to have pages > that aren't mapped for the kernel. (like highmem pages on x86). Yes, that's exactly what I'm thinking about doing. However, this is only a problem for AGP. For objects that are in video memory but can also be moved back to main memory (what I call "evicted") under pressure by the memory manager, one thing I was wondering is, do we have to bother about cache settings at all ? That is, have them mapped non-cacheable when in vram and cacheable when in main memory. Is there any reason why there would be a problem with userland having the same buffer being sometimes cacheable and non-cacheable ? I don't think so as long as userland isn't using cache tricks and whatever primitive is used to do the copy to/from vram properly accounts for it. Ben. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8357] Rendering with r300 right of 2650px width is disstorted
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=8357 --- Additional Comments From [EMAIL PROTECTED] 2006-09-19 11:59 --- Created an attachment (id=7079) --> (https://bugs.freedesktop.org/attachment.cgi?id=7079&action=view) glxgears rendering on border -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8357] Rendering with r300 right of 2650px width is disstorted
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=8357 --- Additional Comments From [EMAIL PROTECTED] 2006-09-19 11:58 --- Created an attachment (id=7078) --> (https://bugs.freedesktop.org/attachment.cgi?id=7078&action=view) blender_rendering -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8357] New: Rendering with r300 right of 2650px width is disstorted
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=8357 Summary: Rendering with r300 right of 2650px width is disstorted Product: DRI Version: XOrg CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: General AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] I run a dualhead setup with a desktop of 3080x1050 (thats the biggest setup, I run also smaller setups). This is the card in the notebook: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] In Bug 8299 i mentioned, that the rendering of blender is disstored (see first attachment). It can easily be reproduced when runnig glxgears - just move it over or onto the invisible border (see second attachment). Aapo Tahkola gives in comment #10 of Bug 8299 some hints which might be good starting points. -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5376] xmoto help menu causes mouse cursor related locks to appear
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=5376 --- Additional Comments From [EMAIL PROTECTED] 2006-09-19 08:25 --- My guess would be the card doesn't like getting hammered on RADEON_CRTC2_GEN_CNTL. Maybe you guys can play with making RADEONChooseCursorCRTC() a little cleverer wrt that. -- 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
Thomas Hellström wrote: > Benjamin Herrenschmidt wrote: >> On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote: >> >> >>> But this should be the same problem encountered by the agpgart driver? >>> x86 and x86-64 calls change_page_attr() to take care of this. >>> On powerpc it is simply a noop. () >>> >> >> Possibly. We sort-of ignore the issue for now on PowerPC and happen to >> be lucky most of the time because 32 bits PowerPC aren't that agressive >> at prefetching... >> >> I haven't looked at change_page_attr() implementation on x86 but I know >> they also map the linear mapping with large pages. I don't know what >> happens if you start trying to change a single page attribute. x86 can >> breakup that large page into 4k pages, so maybe that's what happens. >> >> > Yes, I think that's what happens. I know some Athlon chips had a big > issue with this some time ago. > > I notice there are special functions in to alloc / free GATT > pages, so the general idea might be to have a pool of uncached pages > in the future for powerpc? Even better would perhaps be to have pages > that aren't mapped for the kernel. (like highmem pages on x86). > As a side note, it's not always possible to map the whole video memory. For example on ATI chips you can't map VRAM above 128MB, on Nvidia you can't above 256MB. Still, that memory has to be managed somehow. In that case, such memory areas will be hidden from the application anyway. Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
Benjamin Herrenschmidt wrote: On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote: But this should be the same problem encountered by the agpgart driver? x86 and x86-64 calls change_page_attr() to take care of this. On powerpc it is simply a noop. () Possibly. We sort-of ignore the issue for now on PowerPC and happen to be lucky most of the time because 32 bits PowerPC aren't that agressive at prefetching... I haven't looked at change_page_attr() implementation on x86 but I know they also map the linear mapping with large pages. I don't know what happens if you start trying to change a single page attribute. x86 can breakup that large page into 4k pages, so maybe that's what happens. Yes, I think that's what happens. I know some Athlon chips had a big issue with this some time ago. I notice there are special functions in to alloc / free GATT pages, so the general idea might be to have a pool of uncached pages in the future for powerpc? Even better would perhaps be to have pages that aren't mapped for the kernel. (like highmem pages on x86). /Thomas - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote: > But this should be the same problem encountered by the agpgart driver? > x86 and x86-64 calls change_page_attr() to take care of this. > On powerpc it is simply a noop. () Possibly. We sort-of ignore the issue for now on PowerPC and happen to be lucky most of the time because 32 bits PowerPC aren't that agressive at prefetching... I haven't looked at change_page_attr() implementation on x86 but I know they also map the linear mapping with large pages. I don't know what happens if you start trying to change a single page attribute. x86 can breakup that large page into 4k pages, so maybe that's what happens. > Currently we take the following approach when the GPU needs access to > a buffer: > > 0) Take the hardware lock. > 1) The buffer is validated, and if not present in the GATT, it's > flipped in. At this point, idle buffers may be flipped out. > 2) The app submits a batch buffer (or in the general case a command > sequence). All buffers that are referenced by this command sequence > needs to have been validated, and the command sequence should be > updated with their new GATT offset. > 3) A "fence" is emitted, and associated with all unfenced buffers. > 4) The hardware lock is released. > 5) When the fence has expired (The GPU is finished with the command > sequence), the buffers associated with it may optionally be thrown > out. > > One problem is that buffers that need to be pinned (_always_ available > to the GPU) cannot be thrown out and will thus fragment the aperture- > or VRAM space. > > Buffers also carry usage- and mapping refcounts. They are not allowed > to be validated when mapped, and (except under some circumstances) are > not allowed to be mapped while validated. Buffer destruction occurs > when the refcount goes to zero. Yup. My idea was to allow the locking from userspace to allow for chips that can allow userspace direct command submission. Basically, lock/pin the buffer if it's still in the card, and if that fails (because it's been evicted already), then fallback to a kernel call. Ben. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
Benjamin Herrenschmidt wrote: Actually, the TTM memory manager already does this, but also changes the caching policy of the linear kernel map. The later is not portable unfortunately, and can have other serious performance impacts. Typically, the kernel linear map is mapped using larger page sizes, or in some cases, even large TLB entries, or separate translation registers (like BATs). Thus you cannot affect the caching policy of a single 4k page. Also, on some processors, you can't just break down a single large page into small pages neither. For example, on desktop PowerPC, entire segments of 256M can have only one page size. Even x86 might have some interesting issues here... But this should be the same problem encountered by the agpgart driver? x86 and x86-64 calls change_page_attr() to take care of this. On powerpc it is simply a noop. () Unfortunately this leads to rather costly cache and TLB flushes. Particularly on SMP. Yup. What about a futex-like approach: A shared are mapped by both kernel and user has locks for the buffers. When submitting a command involving a buffer, userland tries to lock it. This is a simple atomic operation in user space. If that fails (the lock for that buffer is held, possibly by the kernel, or the buffer is swapped out), them it does an ioctl to the DRM to get access (which involves sleeping until the buffer can be retreived). One the operation is complete, the apps can release the locks to buffers it holds. In fact, if there is a mapping to buffers <-> objects for cards like nVidia with objects and notifiers, the kernel could auto-unlock objects when the completion interrupt for them occurs. Ben. Currently we take the following approach when the GPU needs access to a buffer: 0) Take the hardware lock. 1) The buffer is validated, and if not present in the GATT, it's flipped in. At this point, idle buffers may be flipped out. 2) The app submits a batch buffer (or in the general case a command sequence). All buffers that are referenced by this command sequence needs to have been validated, and the command sequence should be updated with their new GATT offset. 3) A "fence" is emitted, and associated with all unfenced buffers. 4) The hardware lock is released. 5) When the fence has expired (The GPU is finished with the command sequence), the buffers associated with it may optionally be thrown out. One problem is that buffers that need to be pinned (_always_ available to the GPU) cannot be thrown out and will thus fragment the aperture- or VRAM space. Buffers also carry usage- and mapping refcounts. They are not allowed to be validated when mapped, and (except under some circumstances) are not allowed to be mapped while validated. Buffer destruction occurs when the refcount goes to zero. /Thomas - 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=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
