Re: rs480 + r300 driver fun..
On 4/9/07, Alex Jackson awj_in_japan-at-hotmail.com |rivatv-devel| ... wrote: What has to be done now? Where can look to start hacking Mesa to support it? (I've spent all of my time so far in DRM.. (radeon_cp.c) ) Does setting tcl_mode=0 in .drirc make it work? I tested this with my Xpress 200M (128M video RAM, no system RAM). glxgears runs, and even exits cleanly when I press Esc; however, it displays an utterly corrupted window instead of the lovely spinning gears we all want to see. The displacement of vertices is most likely caused by the fact that r300 drivers swtcl path cheats and does vertex transformation in hardware. That's also why arbvpwarpmesh fails to work when sw path is active. See: http://www.egore911.de/vype/dri-log/index.php?page=dri-devel-2007-04-09.log http://www.egore911.de/vype/dri-log/index.php?page=dri-devel-2007-04-10.log I haven't seen any dumps so I can't comment on whats wrong with other attribs. Of course, it would help if I'd have some hardware to work with. -- Aapo Tahkola - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] r300_scratch in r300_cmdbuf.c is broken
On Thu, 1 Mar 2007 17:46:12 +0200 Panagiotis Papadakos [EMAIL PROTECTED] wrote: Diving more into the code, I also found weird how the scratch cmd packet is build in radeon_mm_use, in radeon_mm.c. I think it should be like in the attached patch. This patch will break 64 bit systems. It only works on your system because drm cuts 32 bits off the pointer. This is what drm expects to see: 64_bit_pointer for every buffer 32_bit_index Thus, rmesa-rmm-u_list[id].age is at 64_bit_pointer[32_bit_index] . Since age and h_pending go in pairs, rmesa-rmm-u_list[id].h_pending is at 64_bit_pointer[32_bit_index + 1] . Hope this clears out things a bit. -- Aapo Tahkola - 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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] r300_scratch in r300_cmdbuf.c is broken
On Thu, 1 Mar 2007 21:33:16 +0200 Panagiotis Papadakos [EMAIL PROTECTED] wrote: On Thursday 01 March 2007 20:11, Aapo Tahkola wrote: On Thu, 1 Mar 2007 17:46:12 +0200 Panagiotis Papadakos [EMAIL PROTECTED] wrote: Diving more into the code, I also found weird how the scratch cmd packet is build in radeon_mm_use, in radeon_mm.c. I think it should be like in the attached patch. This patch will break 64 bit systems. It only works on your system because drm cuts 32 bits off the pointer. This is what drm expects to see: 64_bit_pointer for every buffer 32_bit_index Thus, rmesa-rmm-u_list[id].age is at 64_bit_pointer[32_bit_index] . Since age and h_pending go in pairs, rmesa-rmm-u_list[id].h_pending is at 64_bit_pointer[32_bit_index + 1] . Hope this clears out things a bit. Yep. I think you are right. Two questions though: 1) Should we increment h_pending, before memcpy to the buf? (Is there any way that the drm reads the old value?) Doesn't matter as long as it is done before pushing it in r300_cmdbuf.c. 2) Could you also see the attached patch, for the drm r300_scratch? I think that the logic is wrong. Before the loop, you increment the buf, 8 bytes, although you should already be reading age and h_pending, since the outer while loop removes the head. Somehow all the loop seems a bit weird to me. You are mixing up what comes from the command buffer and what kernel calculates itself. buf_idx *= 2; /* 8 bytes per buf */ converts index of age and h_pending pairs into index that points to a .age in 32 bit buffer. In reality, buf_idx is always 0. Remember that ref_age_base + 1 equals ref_age_base[1] . P.S. Before applying this patch I was getting many messages like this one: Feb 27 15:48:53 localhost kernel: [drm:drm_ioctl] pid=3538, cmd=0x40046457, nr=0x57, dev 0xe200, auth=1 Feb 27 15:48:53 localhost kernel: [drm:drm_ioctl] ret = fffc which I have not seen after applying this patch. Sure you didn't just turn off debug messages? See Method to limit rendering latency in driconf if you don't want to use irqs. Thanks for your time. !DSPAM:45e727c3100221632612511! -- Aapo Tahkola - 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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3 benchmarks.
On Wed, 30 Aug 2006 20:50:16 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sun, 13 Aug 2006 02:17:40 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Roland Scheidegger wrote: Rune Petersen wrote: Roland Scheidegger wrote: Adam K Kirchhoff wrote: Just thought I'd post some updated benchmarks of Doom3. These were all run with the first timedemo at 640x480, and (for the open source drivers) with ColorTiling turned on in the xorg.conf file. I'll list all tests with the open source drivers first: x700 + r300 (with arb renderer) - 5.5 FPS (There's not much point in testing it with the r200 or arb2 renderers at the moment.) What's the problem with arb2? fragment.position input is not implemented yet. fglrx driver parses it from VP to FP via a texcoord route. I've been hitting my head on this for some time. Only got as far as only getting a soft lockup which isn't very useful. That kinda makes sense. On r200 you could already pass vertex data to the fragment registers (but you couldn't use position as input), so the data was interpolated by the texcoord interpolator but texture lookup was disabled (see the ATI_fs spec / r200 dri implementation). At first sight looks like a similar mechanism might be used by r300 I guess, interpolating position or texcoords isn't too different is it? I've had been looking into this, and the vertex shader is supplying the position to the fragment shader as a texcoord, the only apparent difference in shader setup between a position and a real texcoord, is a real texcoord is supplied as input for the vertex shader. I would really like to capture the vertex program of program/fp/tri-depth and the fglrx driver. But I'm betting the vertex shader is capable of writing to a texcoord. All I need is a safe way for the vertex shader code to know if the fragment shader needs the position. Any help with this would be great. Bug #8056 patch can do this. Take a look at r300_select_vertex_shader(). Thank you. About your patch: Can't reproduce your result with gearbox [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4e28 sz=1) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed It should be same as t-offset when the cube is drawn. subtexrate: The result is not too reliable with this, but at least it doesn't crash =) There looks to be a mess up of src dest. sometimes the src is the teapot other times the root window. doSubRect cases will definitely fail. It would seem as if the clip rects would be relative to something else. Odd that it never crashes with default clip rects... -- Aapo Tahkola - 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: Doom3 benchmarks.
On Sun, 13 Aug 2006 02:17:40 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Roland Scheidegger wrote: Rune Petersen wrote: Roland Scheidegger wrote: Adam K Kirchhoff wrote: Just thought I'd post some updated benchmarks of Doom3. These were all run with the first timedemo at 640x480, and (for the open source drivers) with ColorTiling turned on in the xorg.conf file. I'll list all tests with the open source drivers first: x700 + r300 (with arb renderer) - 5.5 FPS (There's not much point in testing it with the r200 or arb2 renderers at the moment.) What's the problem with arb2? fragment.position input is not implemented yet. fglrx driver parses it from VP to FP via a texcoord route. I've been hitting my head on this for some time. Only got as far as only getting a soft lockup which isn't very useful. That kinda makes sense. On r200 you could already pass vertex data to the fragment registers (but you couldn't use position as input), so the data was interpolated by the texcoord interpolator but texture lookup was disabled (see the ATI_fs spec / r200 dri implementation). At first sight looks like a similar mechanism might be used by r300 I guess, interpolating position or texcoords isn't too different is it? I've had been looking into this, and the vertex shader is supplying the position to the fragment shader as a texcoord, the only apparent difference in shader setup between a position and a real texcoord, is a real texcoord is supplied as input for the vertex shader. I would really like to capture the vertex program of program/fp/tri-depth and the fglrx driver. But I'm betting the vertex shader is capable of writing to a texcoord. All I need is a safe way for the vertex shader code to know if the fragment shader needs the position. Any help with this would be great. Bug #8056 patch can do this. Take a look at r300_select_vertex_shader(). -- Aapo Tahkola - 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: results of Radeon 9800 Pro test
On Mon, 28 Aug 2006 21:21:59 +0200 Jacek Poplawski [EMAIL PROTECTED] wrote: On 8/28/06, Ian Romanick [EMAIL PROTECTED] wrote: glest - refuses to start (Exception: Your system supports OpenGL version 1.2 (1.3 Mesa 6.5.1) Glest needs at least version 1.3 to work) This implies that glest is getting an indirect rendering context. Yes, sorry, I tried to run it from root :-( It starts when I run it from user. Landscape renders correctly when I am in menu, but when I start game I see just gray screen and few white rectangles (missing textures again?). I think that this application is just not mature enough - there is an error about 3D textures even if I disable it in menu: [EMAIL PROTECTED] glest]$ ./glest Mesa: CPU vendor: AuthenticAMD Mesa: CPU name: AMD Athlon(tm) XP 1800+ Mesa: MMX cpu detected. Mesa: 3DNow! cpu detected. Mesa: SSE cpu detected. Mesa: Not testing OS support for SSE, leaving enabled. Try R300_SPAN_DISABLE_LOCKING env var if this hangs. *WARN_ONCE* File r300_vertexprog.c function t_dst_index line 184 Unknown output 3 *** Couldn't process event: Error creating texture 3D *WARN_ONCE* File r300_render.c function r300Fallback line 388 Software fallback:ctx-RenderMode != GL_RENDER *** This doesn't even work with full raster fallbacks in r300. With my Ati Radeon 7000 (Freedesktop-DRI-Drivers) I just saw a grey area ingame, until I deactivated shadows and 3D-textures in the options. -- http://www.glest.org/board2/viewtopic.php?t=1162sid=9d6b42d8f9429e5e6b259b63e13f9816 -- Aapo Tahkola - 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: [r300] sauerbraten and ut2k4 performance tips
On Wed, 23 Aug 2006 21:45:25 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Tue, 15 Aug 2006 22:16:48 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: Sauerbraten: a) open console and type /floatvtx 1 or b) use this patch or c) wait for this patch to get integrated What version did you use? the latest release hits a fallback: *WARN_ONCE* File r300_render.c function r300Fallback line 402 Software fallback:ctx-Polygon.OffsetLine *** So I lied. Maybe we should add dri-conf options for them? It's not like we could magically fix them all in any case. Something like this? (could be made nicer =) I couldn't really decide if it should be part of the driver or as a separate patch to apply. It does 2 things: 1) Allows you to disable S3TC, wine-games sometimes need S3TC enabled. 2) Disable fallbacks that usually have low impact. Fine by me. disable_lowimpact_fallback and hw_tcl_on should really be part of struct r300_context to avoid thread issues. -- Aapo Tahkola - 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: Xi Graphics marketing.
On Fri, 25 Aug 2006 07:07:44 -0400 Adam K Kirchhoff [EMAIL PROTECTED] wrote: FYI, Apparently Xi Graphics has kicked off a new marketing campaign again... This PDF is linked to from their homepage: ftp://ftp.xig.com/pub/docs/State_of_Accelerated-X.pdf Shame that they didn't go on claiming their drivers secure or even DoS-proof. -- Aapo Tahkola - 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: [R300] Error with rss screensaver
On Wed, 23 Aug 2006 18:36:44 +0200 Dario Laera [EMAIL PROTECTED] wrote: Hi, I've tried euphoria screensaver (http://rss-glx.sourceforge.net/) with latest r300 cvs and I get this error: DISPATCH ERROR! _glapi_add_dispatch failed to add glProgramLocalParameters4fvEXT! DISPATCH ERROR! _glapi_add_dispatch failed to add glProgramEnvParameters4fvEXT! DISPATCH ERROR! _glapi_add_dispatch failed to add glProgramLocalParameters4fvEXT! DISPATCH ERROR! _glapi_add_dispatch failed to add glProgramEnvParameters4fvEXT! *WARN_ONCE* File r300_maos.c function r300EmitArrays line 546 Cannot handle offset bc302000 with stride 3, comp 3 *** I do not see this with rss-glx_0.8.1 . Anyway, it's not fatal. -- Aapo Tahkola - 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: [r300] sauerbraten and ut2k4 performance tips
On Tue, 15 Aug 2006 22:16:48 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: Sauerbraten: a) open console and type /floatvtx 1 or b) use this patch or c) wait for this patch to get integrated What version did you use? the latest release hits a fallback: *WARN_ONCE* File r300_render.c function r300Fallback line 402 Software fallback:ctx-Polygon.OffsetLine *** So I lied. Maybe we should add dri-conf options for them? It's not like we could magically fix them all in any case. -- Aapo Tahkola - 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
[r300] sauerbraten and ut2k4 performance tips
Sauerbraten: a) open console and type /floatvtx 1 or b) use this patch or c) wait for this patch to get integrated Unreal Tournament 2004: Set UseVBO option to True in ~/.ut2004/System/UT2004.ini . Rune, could you add these to your status list? -- Aapo Tahkola - 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: [r300] sauerbraten and ut2k4 performance tips
*cough* patch. -- Aapo Tahkola diff -uNr src_orig/engine/rendergl.cpp src/engine/rendergl.cpp --- src_orig/engine/rendergl.cpp 2006-08-15 18:51:23.0 +0300 +++ src/engine/rendergl.cpp 2006-07-31 03:29:06.0 +0300 @@ -140,6 +140,7 @@ const char *vendor = (const char *)glGetString(GL_VENDOR); extern int floatvtx; if(strstr(vendor, ATI)) floatvtx = 1; +if(strstr(vendor, Tungsten Graphics, Inc.)) floatvtx = 1; if(floatvtx) conoutf(WARNING: Using floating point vertexes. (use \/floatvtx 0\ to disable)); if(forcenoshaders || !strstr(exts, GL_ARB_vertex_program) || !strstr(exts, GL_ARB_fragment_program)) - 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: Doom3 benchmarks.
On Sun, 06 Aug 2006 22:57:21 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Roland Scheidegger wrote: Adam K Kirchhoff wrote: Just thought I'd post some updated benchmarks of Doom3. These were all run with the first timedemo at 640x480, and (for the open source drivers) with ColorTiling turned on in the xorg.conf file. I'll list all tests with the open source drivers first: x700 + r300 (with arb renderer) - 5.5 FPS (There's not much point in testing it with the r200 or arb2 renderers at the moment.) What's the problem with arb2? fragment.position input is not implemented yet. fglrx driver parses it from VP to FP via a texcoord route. I've been hitting my head on this for some time. Only got as far as only getting a soft lockup which isn't very useful. The r300 driver does not currently support the r200 render path (and I doubt it will in the future - there's just not enough interest in supporting ATI_fs on r300 which is not widely used). 9000 (with arb renderer) - 15.9 9000 (with r200 renderer) - 15.4 The huge performance increase I get by using an r200 card is pretty consistent with what I see in other games. There seems to be some performance problems with the r300 driver. I don't think anyone knows what's going on but I could be wrong... I have seen some strange slowdowns not caused bu any apparent fallback (Nexiuz w/bloom) though I could have missed a fallback path. Light bloom usually need render to texture type of functionality which in turn needs accelerated CopyTexSubImage2D or ReadPixels. These are implemented using the span functions currently. CopyTexSubImage2D cannot be accelerated because we need to update copy of the texture kept in system memory(for raster fallbacks). Secondly, normal bitblt cannot be used to perform these operations since it doesn't support necessary pitches and offsets - x/y tricks used in r300_texmem.c will not work as r300 tends to think that micro tile starts at given offset. dxtn happens to be broken because we cant do micro tiling on normal textures. I tried implementing blits using 3d engine and textures but I ran into trouble with clip rects so I had to give up. Buffer swaps work fine with it though. -- Aapo Tahkola - 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.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][PATCH] fix vertex attribs - try 2 - Re: [r300] ARB vp attribs broken?
On Mon, 26 Jun 2006 21:22:12 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Brian Paul wrote: Rune Petersen wrote: Tilman Sauerbeck wrote: Rune Petersen [2006-06-25 16:31]: I've been looking at vertex shaders this weekend. It would appear that attribs are broken. The most straight forward way to test this it to compare progs/tests/arbvptest3 to progs/tests/vptest3 On my system I get different colors when I resize the window. Can someone confirm this? (it would explain why Doom 3 is broken) Yes, I have reported this some weeks ago: http://marc.theaimsgroup.com/?l=dri-develm=114855685402158w=2 Don't know how I fixed that... It would appear to be caused bu the reshuffling of the attribs. Any idea where the attribs are passed to the driver? and how to read the data in the attribs... I can't comment on the r300 driver, but the change in vertex aliasing in core Mesa is pretty simple. It's really just a change of which index into the VB-Attribs[] array corresponds to glVertexAttribARB(index, ...). This is getting embarrassing... try 3 attached. Checked in. Thanks. -- Aapo Tahkola 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: 9800 lockups, why fixing them seems to be that hard ?
On Sun, 18 Jun 2006 11:58:31 +0200 Jerome Glisse [EMAIL PROTECTED] wrote: On 6/18/06, Elie Morisse [EMAIL PROTECTED] wrote: Hi, I'm keeping an eye on DRM and Mesa CVS commits since 9 months now, test regularly the whole thing to watch out the fix which will make my 9800 Pro usable, but nothing at all yet. Are there particular reasons to that ? What are you missing to make progress ? This is far from being easy (at least i find it difficult). We know that we are missing initialization things that fglrx does. I am still testing different part of fglrx initialization but there is about 3Mo of this. More over, some of this lockup the chip as soon as you fire them... So basicly what we are missing is people and time to do this. I have very little time (i am phd student and this already eat up almost all my time). Have you tried aborting initialization while fglrx is at it? That would allow divide and conquer type of approach. I integrated iba into libsegfault and its working brilliantly. I think it should be possible to even put all ring buffer traffic and indirect buffers on ignore. -- Aapo Tahkola -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
On Sun, 18 Jun 2006 12:53:40 +0200 Tilman Sauerbeck [EMAIL PROTECTED] wrote: Rune Petersen [2006-06-18 02:27]: Tilman Sauerbeck wrote: Rune Petersen [2006-06-17 23:38]: I'm having problems with the ARL instruction. It appears to mostly return 0. Yes. It would probably help if you could document in which cases it works reliably and in which cases it doesn't :) Something very strange is going on with ARL: I have an array with all non-zero values. I do an ARL on any given value within the array. I read the array myArray[addr.x] and I allways get the value at index 0. if I add an offset myArray[addr.x + offset] where addr.x + offset array size provided addr.x is the correct value, I get 0. Looks to me like there is a bounds check on arrays that work correctly, but the actual array lookup is broken. Is this at all possible? Interesting, I can also reproduce this behaviour. So it seems like ARL is working correctly, but reading from ADDRESSes is broken. It should work now. Thanks. -- Aapo Tahkola -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 9800 lockups, why fixing them seems to be that hard ?
On Sun, 18 Jun 2006 14:13:10 +0200 Jerome Glisse [EMAIL PROTECTED] wrote: On 6/18/06, Aapo Tahkola [EMAIL PROTECTED] wrote: On Sun, 18 Jun 2006 11:58:31 +0200 Jerome Glisse [EMAIL PROTECTED] wrote: On 6/18/06, Elie Morisse [EMAIL PROTECTED] wrote: Hi, I'm keeping an eye on DRM and Mesa CVS commits since 9 months now, test regularly the whole thing to watch out the fix which will make my 9800 Pro usable, but nothing at all yet. Are there particular reasons to that ? What are you missing to make progress ? This is far from being easy (at least i find it difficult). We know that we are missing initialization things that fglrx does. I am still testing different part of fglrx initialization but there is about 3Mo of this. More over, some of this lockup the chip as soon as you fire them... So basicly what we are missing is people and time to do this. I have very little time (i am phd student and this already eat up almost all my time). Have you tried aborting initialization while fglrx is at it? That would allow divide and conquer type of approach. I integrated iba into libsegfault and its working brilliantly. I think it should be possible to even put all ring buffer traffic and indirect buffers on ignore. fglrx initialization is prety fast i would have to put the break facility in libsegfault. Before trying such things i would like to test some ram latency things that fglrx does but which lockup the chip when i mimick fglrx... I never used IDA, it's your tools for spying indirect buffer right ? I should have a look at it :) Is it somewhere ? http://www.rasterburn.org/~aet/libsegfault-iba.tar.bz2 -- Aapo Tahkola -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
On Sun, 11 Jun 2006 15:01:15 +0200
Rune Petersen [EMAIL PROTECTED] wrote:
Aapo Tahkola wrote:
On Wed, 07 Jun 2006 17:49:00 +0200
Rune Petersen [EMAIL PROTECTED] wrote:
Aapo Tahkola wrote:
On Wed, 07 Jun 2006 10:51:08 +0200
Rune Petersen [EMAIL PROTECTED] wrote:
Aapo Tahkola wrote:
On Sat, 3 Jun 2006 05:04:04 +0200
Jacek Poplawski [EMAIL PROTECTED] wrote:
I am trying to run http://maniadrive.raydium.org/ on Radeon
9800 with Mesa CVS.
3D view in the menu background works, but when I want to play I
see:
*WARN_ONCE*
File r300_vertexprog.c function r300_translate_vertex_shader
line 564 Ran out of temps, num temps 13, us 12
***
Can the driver only use 13 temps natively?
I was under the impression that there was 32 or 64 vertex temps.
r300 - r480 only have 14. A good optimizer can make sure that the
limits are never really hit.
Ok, but How do you find there numbers?
I can only find reports like this (X850: 32 vp temps):
http://www.delphi3d.net/hardware/viewreport.php?report=1412
Remove fallback, craft test app that uses 15 temps and see if it
works. Be aware though that you need to beat it hard to get
reliable results. I guess there's some capacitance in the
circuits...
I found the 3dsmax viewset in SPECViewperf 8.1 which uses 15 temps.
increasing the temps count to 15 I can run the viewset multiple times
without lockup or visible errors.
I think the safest safest way is to set it to 15 and if an app hits
the fallback do a test to see if the app can run without fallback.
Try this.
It should start working again when you move MOV R14, R0; more
closer to the instruction that reads R14.
--
Aapo Tahkola
/*
* A lit, rotating torus via vertex program
*/
#include assert.h
#include string.h
#include stdio.h
#include stdlib.h
#include math.h
#define GL_GLEXT_PROTOTYPES
#include GL/glut.h
static float Xrot = 0.0, Yrot = 0.0, Zrot = 0.0;
static GLboolean Anim = GL_TRUE;
static void Idle( void )
{
Xrot += .3;
Yrot += .4;
Zrot += .2;
glutPostRedisplay();
}
static void Display( void )
{
glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
glPushMatrix();
glRotatef(Xrot, 1, 0, 0);
glRotatef(Yrot, 0, 1, 0);
glRotatef(Zrot, 0, 0, 1);
glutSolidTorus(0.75, 2.0, 10, 20);
glPopMatrix();
glutSwapBuffers();
}
static void Reshape( int width, int height )
{
glViewport( 0, 0, width, height );
glMatrixMode( GL_PROJECTION );
glLoadIdentity();
glFrustum( -2.0, 2.0, -2.0, 2.0, 5.0, 25.0 );
glMatrixMode( GL_MODELVIEW );
glLoadIdentity();
glTranslatef( 0.0, 0.0, -12.0 );
}
static void Key( unsigned char key, int x, int y )
{
(void) x;
(void) y;
switch (key) {
case ' ':
Xrot = Yrot = Zrot = 0;
break;
case 'a':
Anim = !Anim;
if (Anim)
glutIdleFunc(Idle);
else
glutIdleFunc(NULL);
break;
case 'z':
Zrot -= 5.0;
break;
case 'Z':
Zrot += 5.0;
break;
case 27:
exit(0);
break;
}
glutPostRedisplay();
}
static void SpecialKey( int key, int x, int y )
{
const GLfloat step = 3.0;
(void) x;
(void) y;
switch (key) {
case GLUT_KEY_UP:
Xrot -= step;
break;
case GLUT_KEY_DOWN:
Xrot += step;
break;
case GLUT_KEY_LEFT:
Yrot -= step;
break;
case GLUT_KEY_RIGHT:
Yrot += step;
break;
}
glutPostRedisplay();
}
static void Init( void )
{
GLint errno;
GLuint prognum;
/* borrowed from an nvidia demo:
* c[0..3] = modelview matrix
* c[4..7] = invtrans modelview matrix
* c[32] = light pos
* c[35] = diffuse color
*/
static const char prog[] =
!!ARBvp1.0\n
TEMP R0, R1; \n
TEMP R2, R3, R4, R5, R6, R7, R8, R9, R10, R11, R12, R13, R14, R15; \n
#Simple transform and diffuse lighting\n
# object x MVP - clip\n
DP4 result.position.x, state.matrix.mvp.row[0], vertex.position ;\n
DP4 result.position.y, state.matrix.mvp.row[1], vertex.position ;\n
DP4 result.position.z, state.matrix.mvp.row[2], vertex.position ;\n
DP4 result.position.w, state.matrix.mvp.row[3], vertex.position ;\n
# normal x MV-1T - lighting normal\n
DP3 R1.x, state.matrix.modelview.invtrans.row[0], vertex.normal ;\n
DP3 R1.y, state.matrix.modelview.invtrans.row[1], vertex.normal;\n
DP3 R1.z, state.matrix.modelview.invtrans.row[2], vertex.normal;\n
DP3 R0, program.local[32], R1; # L.N\n
#if 0
MUL result.color.xyz, R0, program.local[35] ; # col = L.N * diffuse\n
#else
MOV R14, R0;\n
MOV R2, vertex.position;\n
MOV R3, vertex.position;\n
Re: DRI + Radeon_Driver = Black screen (when startx)
On Fri, 9 Jun 2006 22:49:53 +0200 [EMAIL PROTECTED] wrote: Hi I have a probleme with the DRI : Ok, I have followed step to step the tutorial for build DRI and mesa?. So If I load in my xorg.conf ?the DRI and the radeon driver?, when I type startx there are a Black screen? and I can?t make a CTRL + ATL + DEL for shut down the X ? I must restart the PC?. But if I load in my xorg.conf ONLY driver radeon (without DRI) the startx work Ok there my xorg.conf: http://rapidshare.de/files/22461482/xorg.conf.txt.html According to your xorg.conf you are using vesa driver not ati. I think your xf86-video-ati and drm might be lacking benh's memory mapping fixes which could cause it to hang the card. Can you update xorg to 7.1? Setting GARTSize to some value might also prevent immediate lock, though it will not fix the problem entirely. -- Aapo Tahkola -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
On Mon, 12 Jun 2006 00:56:36 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sun, 11 Jun 2006 15:01:15 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Wed, 07 Jun 2006 17:49:00 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Wed, 07 Jun 2006 10:51:08 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sat, 3 Jun 2006 05:04:04 +0200 Jacek Poplawski [EMAIL PROTECTED] wrote: I am trying to run http://maniadrive.raydium.org/ on Radeon 9800 with Mesa CVS. 3D view in the menu background works, but when I want to play I see: *WARN_ONCE* File r300_vertexprog.c function r300_translate_vertex_shader line 564 Ran out of temps, num temps 13, us 12 *** Can the driver only use 13 temps natively? I was under the impression that there was 32 or 64 vertex temps. r300 - r480 only have 14. A good optimizer can make sure that the limits are never really hit. Ok, but How do you find there numbers? I can only find reports like this (X850: 32 vp temps): http://www.delphi3d.net/hardware/viewreport.php?report=1412 Remove fallback, craft test app that uses 15 temps and see if it works. Be aware though that you need to beat it hard to get reliable results. I guess there's some capacitance in the circuits... I found the 3dsmax viewset in SPECViewperf 8.1 which uses 15 temps. increasing the temps count to 15 I can run the viewset multiple times without lockup or visible errors. I think the safest safest way is to set it to 15 and if an app hits the fallback do a test to see if the app can run without fallback. Try this. It should start working again when you move MOV R14, R0; more closer to the instruction that reads R14. Gave it a try: 23 or less instructions between the two MOV instructions and it works. Translates into VSF_MAX_FRAGMENT_TEMPS being 17. The card is an X800 XT. You cannot count it based on how many instructions are between them, those are there just to increase the time that temp needs to hold its value before its read. You need to add and initialize new temps if you want to test higher temps. _mesa_print_program is probably useful. -- Aapo Tahkola -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
On Wed, 07 Jun 2006 17:49:00 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Wed, 07 Jun 2006 10:51:08 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sat, 3 Jun 2006 05:04:04 +0200 Jacek Poplawski [EMAIL PROTECTED] wrote: I am trying to run http://maniadrive.raydium.org/ on Radeon 9800 with Mesa CVS. 3D view in the menu background works, but when I want to play I see: *WARN_ONCE* File r300_vertexprog.c function r300_translate_vertex_shader line 564 Ran out of temps, num temps 13, us 12 *** Can the driver only use 13 temps natively? I was under the impression that there was 32 or 64 vertex temps. r300 - r480 only have 14. A good optimizer can make sure that the limits are never really hit. Ok, but How do you find there numbers? I can only find reports like this (X850: 32 vp temps): http://www.delphi3d.net/hardware/viewreport.php?report=1412 Remove fallback, craft test app that uses 15 temps and see if it works. Be aware though that you need to beat it hard to get reliable results. I guess there's some capacitance in the circuits... -- Aapo Tahkola -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: mesa-6.5: assertion failed on resolution change
On Mon, 22 May 2006 00:02:11 -0400 Alex Deucher [EMAIL PROTECTED] wrote: On 5/21/06, Roland Scheidegger [EMAIL PROTECTED] wrote: Pawel Salek wrote: ColorTiling works like a charm: it gives factor two speedup in glxgears, one can play RTCW at 1280x1024 *and* the random lines are gone! Is there any reason this option is not the default? I am not sure, maybe it could be made the default by now? Historically, it is off by default because it didn't work on r3xx/r4xx cards (it was always on by default on older chips since it exists), because it wasn't fully implemented. I think it works without problems nowadays on all chips (dunno about the rs400 igps, though). I believe though it caused to lock up the r300/r350 chips even faster (with opengl apps) but that is probably more of a side effect. Someone more familiar with the r300 cards needs to answer that if it should be the default but it sure would be nice - the radeon chips are increasingly relying on this to get good performance (first generation (r1xx) radeon chips roughly gain 20% or so, 2nd generation (r2xx) more like 50%, and 3rd (r3xx/r4xx) 100%). r3/4xx needs a drm update to make colortiling work with pageflipping for non-zero offsets sice they use a slightly different register setup. That's why it's been disabled. It's trivial, but no one has gotten around to doing it. That doesn't prevent you from enabling tiling and forcing pageflipping disabled. If someone really cares for pageflipping he/she can fix it. Beyond that its currently broken and it doesn't really improve performance noticeably. Oh and it doesn't really play well with fbos if we ever happen to add support for em. -- Aapo Tahkola -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
On Wed, 07 Jun 2006 10:51:08 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sat, 3 Jun 2006 05:04:04 +0200 Jacek Poplawski [EMAIL PROTECTED] wrote: I am trying to run http://maniadrive.raydium.org/ on Radeon 9800 with Mesa CVS. 3D view in the menu background works, but when I want to play I see: *WARN_ONCE* File r300_vertexprog.c function r300_translate_vertex_shader line 564 Ran out of temps, num temps 13, us 12 *** Can the driver only use 13 temps natively? I was under the impression that there was 32 or 64 vertex temps. r300 - r480 only have 14. A good optimizer can make sure that the limits are never really hit. -- Aapo Tahkola -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
On Sat, 3 Jun 2006 05:04:04 +0200 Jacek Poplawski [EMAIL PROTECTED] wrote: I am trying to run http://maniadrive.raydium.org/ on Radeon 9800 with Mesa CVS. 3D view in the menu background works, but when I want to play I see: *WARN_ONCE* File r300_vertexprog.c function r300_translate_vertex_shader line 564 Ran out of temps, num temps 13, us 12 *** Software tcl will be used in this case. *WARN_ONCE* File r300_vertexprog.c function t_dst_index line 178 Unknown output 13 *** mania_drive.static: tnl/t_vb_arbprogram.c:1249: run_arb_vertex_program: Assertion `p' failed. Is there a way to disable vertex programs? r300_run_tcl_render has line saying: vp-native = GL_FALSE; You shouldn't need to disable them though as iv already fixed this bug in cvs. You probably want to disable stencil shadows to get reasonable performance. -- Aapo Tahkola -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][patch] retry when busy
On Sun, 28 May 2006 19:57:40 +0200 Roland Scheidegger [EMAIL PROTECTED] wrote: Rune Petersen wrote: Hmm, interesting. This problem does not appear to be r300 specific, radeon/r200 use the same code (haven't seen problems with it, though). That said, it looks to me like that ioctl will actually never return EAGAIN, maybe the original intention was to just wait indefinitely on EBUSY instead of EAGAIN? I would agree, but mu knowledge is limited. So is mine... (e.g. while (ret (errno == EINTR || errno == EBUSY));) And by looking at it, does it make sense that the timeout value in the kernel depends on the kernel-of-the-day HZ value, rather than some hardware-dependant (probably fixed) value? Isn't the timeout value dependent on HZ? 3*HZ is always 3 seconds no matter what HZ is (provided its the same value used to compile the kernel). Ah right. I think I misinterpreted something. That said, 3 seconds sounds like a rather long time, why would there still be timeouts? Its not that long time for a benchmark. It should probably be infinite if no hw lock is being held. Lock should be dropped in case of longer waits so that user is given a chance to stop the process. -- Aapo Tahkola --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Quake4 benchmarks
On Tue, 23 May 2006 19:18:56 -0400 Adam K Kirchhoff [EMAIL PROTECTED] wrote: FYI, I downloaded the hwspirit timedemo for quake4 yesterday and decided to compare the framerate between the fglrx, r200, and xig drivers with my Radeon 9000: 9000 - xig - 14.7 9000 - fgl - 11.3 9000 - xorg - 16.2 Today I decided to give it a shot with my 9600. The fglrx drivers gave me 16.8 FPS, and the r300 drivers gave me this: http://68.44.156.246/quake4-screenshot.png As you can see, everything is quite shiny (but not quite as washed out as the screenshot shows... I had to brighten it a little to make it visible). This is with both page flipping and color tiling enabled (though I tried without page flipping and got the same results). And I have the libtxc_dxtn library compiled and installed. If I remove that library, quake4 completely refuses to start: ..using GL_ARB_multitexture ...using GL_ARB_texture_env_combine ...using GL_ARB_texture_cube_map ...using GL_ARB_texture_env_dot3 ...using GL_ARB_texture_env_add X..GL_ARB_texture_non_power_of_two not found ...using GL_NV_blend_square ...using GL_ARB_texture_compression X..GL_EXT_texture_compression_s3tc not found signal caught: Segmentation fault si_code 1 Trying to exit gracefully.. Any ideas? AFAIK, dxt3/5 textures need to be tiled in order to work with multitexturing. fglrx does texture uploads differently so I dont know how to tile them on upload. Textures looking washed out might be another bug as ut2k4 doesnt show similar artifacts(only squares). -- Aapo Tahkola --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: mesa-6.5: assertion failed on resolution change
On Sun, 21 May 2006 00:55:23 +0200 Pawel Salek [EMAIL PROTECTED] wrote: Hi all, I use mesa-6.5-6 - as currently in Fedora Development - to drive RV350 (1002:4150) glxgears performance is not particularly impressive (920fps; my former gfx r200-based card used to give 1700-2200 depending on the driver revision) and there are random lines flashing on the screen, which may be just some memory bandwith problems (resolution 1280x1280, 24bpp) since the lines go away at lower resolutions. Anyway, a more serious problem is a failed assertion in radeon driver when one tries to eg. change the resolution in Return to Castle Wolfenstein. The message is: wolfsp.x86: radeon_mm.c:464: radeon_mm_free: Assertion `id = rmesa- rmm-u_last' failed. This has been fixed in CVS. You can set ColorTiling option to true in xorg.conf to get a speed boost. -- Aapo Tahkola --- 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: r300 freezes the X server after resume from suspend2 (suspend to disk)
On Mon, 3 Apr 2006 16:54:05 +0200 Tino Keitel [EMAIL PROTECTED] wrote: Hi folks, I wonder if suspend to disk can be used at all with the r300 driver in XOrg 6.9 oder 7.0, since I doesn't work for me. Are there any success stories? If yes, what version of XOrg, DRM and Mesa should I try? Works fine here as I said already. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: no GL painter on Radeon 9600
On Wed, 12 Apr 2006 14:01:15 +0200 Tino Keitel [EMAIL PROTECTED] wrote: Hi folks, I use a TV software called MythTV with XOrg 7 and the r300 driver to get DRI support for my Radeon 9600. The GUI uses OpenGL, but it fails to start with this message: 2006-04-12 11:14:21.778 Using NV NPOT texture extension drmRadeonCmdBuffer: -22 (exiting) What does dmesg say about it? What drm and mesa versions are you using? -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: no GL painter on Radeon 9600
On Wed, 12 Apr 2006 16:39:28 +0200 Tino Keitel [EMAIL PROTECTED] wrote: On Wed, Apr 12, 2006 at 16:30:44 +, Aapo Tahkola wrote: On Wed, 12 Apr 2006 14:01:15 +0200 Tino Keitel [EMAIL PROTECTED] wrote: Hi folks, I use a TV software called MythTV with XOrg 7 and the r300 driver to get DRI support for my Radeon 9600. The GUI uses OpenGL, but it fails to start with this message: 2006-04-12 11:14:21.778 Using NV NPOT texture extension drmRadeonCmdBuffer: -22 (exiting) What does dmesg say about it? What drm and mesa versions are you using? dmesg: [drm:r300_emit_packet3] *ERROR* bad packet3 type 64 at e57668b8 [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet3 failed $ dpkg -l libgl1-mesa-dri | tail -1 ii libgl1-mesa-dri 6.4.1-0.4 A free implementation of the OpenGL API -- DRI modules $ dpkg -l libdrm2 | tail -1 ii libdrm22.0.1-1Userspace interface to kernel DRM services -- runtime The radeon.ko modules says: [drm] Initialized radeon 1.22.0 20051229 on minor 0 It is the radeon module from the 2.6.16 kernel. You'll need newer drm. You might also get it going by applying http://webcvs.freedesktop.org/dri/drm/shared-core/r300_cmdbuf.c?r1=1.7r2=1.8 . r300 driver shipped with mesa 6.5 fixes many problems but has PCIE support and q3 video mode switches broken. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: no GL painter on Radeon 9600
On Wed, 12 Apr 2006 17:40:41 +0200 Tino Keitel [EMAIL PROTECTED] wrote: On Wed, Apr 12, 2006 at 17:29:26 +, Aapo Tahkola wrote: [...] You'll need newer drm. Do you mean radeon.ko, libdrm and r300_dri.so? radeon.ko, drm.ko and libdrm come in same package(CVS http://webcvs.freedesktop.org/dri/drm/). In general, newer radeon.ko should always work with older r300_dri.so. Since r300 driver is still more or less in development still, we have chosen to do quite many bumps between radeon.ko and core r300 driver(r300_dri.so), thus making it in general refuse to work with older DRMs. (cleaner code/less bugs/less effort this way) You might also get it going by applying http://webcvs.freedesktop.org/dri/drm/shared-core/r300_cmdbuf.c?r1=1.7r2=1.8 . My 2.6.16 source fails to compile after patching, maybe I can fix it. or then you can just stick case RADEON_CNTL_BITBLT_MULTI: right after RADEON_CP_NOP: case. It will make your system in-theory-compromisable though. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] changing video settings in Q3 based games causes assertion in radeon_mm_free
On Sat, 08 Apr 2006 20:25:37 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Hi, When pressing apply in nexuiz i get this assertion: radeon_mm.c:464: radeon_mm_free: Assertion `id = rmesa-rmm-u_last' failed. Should work now. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Xorg-HEAD with XGL branch with Mesa 6.5 issues
On Tue, 21 Mar 2006 22:51:23 -0500 Shawn Starr [EMAIL PROTECTED] wrote: Xgl: tnl/t_vb_arbprogram.c:1279: run_arb_vertex_program: Assertion `p' failed. If I build the Xgl branch install it _then_ install Xorg-HEAD. Xgl works rather well, except if I start certain applications: firefox or konsole it crashes out and dumps this to log. I believe this is my fault. r300 driver currently messes around with _MaintainTnlProgram in attempts to disabled software tnl programs. Leaving it enabled after entering software tnl makes both software tnl programs _and_ traditional tnl stages to be applied on verts. I think blocking out _tnl_arb_vertex_program_stage when tnl program is given to it would be a good way to fix this. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 freezes the X server after resume from suspend2 (suspend to disk)
On Thu, 23 Mar 2006 12:07:05 +0100 Tino Keitel [EMAIL PROTECTED] wrote: Hi folks, when I use suspend2 the X server freezes any shows a somewhat garbled display after resume. I have to reboot after this. I use the r300 driver from Xorg 6.9 and kernel 2.6.15 on a Radeon 9600. I read somewhere that r300 should work with suspend to disk a while ago. When I switch to the text console before suspend, the resume succeeds, but I have the problem from above as soon as I switch back to the X screen. Without radeon.ko loaded, resume works fine. Is this a known problem? Should I try the recent snapshots? Works just fine here with Xorg 7.0.0, and cvs versions of cvs xf86-video-ati + drm. Kernel I have is 2.6.14.2 and everything except drm is built-in. I have tested both rv350 and r480 on sis and via based mobos. After resuming from suspend(with 3D applications running) I can see lots of corruption(random coloured pixels) taking place on textures. This is very slight on my r480 but on rv350 this is way more severe. I dont think theres any critical data being kept on video memory so this shouldnt really cause any locks. I could imagine PCIE cards might not work because of this if the GART-tables arent reset on resume. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: enable hw vertex programs by default causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Mon, 13 Mar 2006 20:23:29 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sun, 12 Mar 2006 17:51:16 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sat, 11 Mar 2006 22:48:49 +0100 Rune Petersen [EMAIL PROTECTED] wrote: All this is just a symptom of dri tex heap manager. nwn will reload textures but they will be given different locations on vram. You can print out t-offset at around line 506 of r300_texmem.c if you are interested in seeing how it behaves. But if you do keep in mind that you need to do it after UNLOCK_HARDWARE or else bad things will happen. You should check that Ben's fix is kicking in by looking for message saying: Setting GART location based on new memory map in dmesg. If you still see problems with it enabled you can confirm GART overlapping by loading drm.ko with DEBUG=1 (AFAIK) and compairing dev_priv-gart_vm_start against dev_priv-fb_location and dev_priv-fb_size . DRM doesnt print these values but you can calculated it based on Xorg log. Find line that says: (II) RADEON(0): Will use x kb for textures at offset x and compaire upper bound of that against dev_priv-gart_vm_start. Me stupid, there is a module-path in xorg.conf and I forgot to change i to the new path. Now nwn looks nice, and all games works (ut2k? still have corruption(?) on some textures). Nice to hear it works now :) I'v checked in a fix that should make nearly all ut2k4 texturing problems disappear. s3tc multitexturing and 8x8 cubic maps are still broken so try to avoid them. Does nwn still lock? No, not with limited amount I've been playing, but it usually crashed on the first or second map. I've something else that locks up :) progs/demos/clearspd it lockups after a few seconds. You can try commenting r300_context.h:#define CB_DPATH . If that doesnt help, one could write a simple app that does same as clearspd but renders quads instead. Based on that, we could then put the blame on buffer clear code or high fillrate. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: enable hw vertex programs by default causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Sun, 12 Mar 2006 17:51:16 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sat, 11 Mar 2006 22:48:49 +0100 Rune Petersen [EMAIL PROTECTED] wrote: All this is just a symptom of dri tex heap manager. nwn will reload textures but they will be given different locations on vram. You can print out t-offset at around line 506 of r300_texmem.c if you are interested in seeing how it behaves. But if you do keep in mind that you need to do it after UNLOCK_HARDWARE or else bad things will happen. You should check that Ben's fix is kicking in by looking for message saying: Setting GART location based on new memory map in dmesg. If you still see problems with it enabled you can confirm GART overlapping by loading drm.ko with DEBUG=1 (AFAIK) and compairing dev_priv-gart_vm_start against dev_priv-fb_location and dev_priv-fb_size . DRM doesnt print these values but you can calculated it based on Xorg log. Find line that says: (II) RADEON(0): Will use x kb for textures at offset x and compaire upper bound of that against dev_priv-gart_vm_start. Me stupid, there is a module-path in xorg.conf and I forgot to change i to the new path. Now nwn looks nice, and all games works (ut2k? still have corruption(?) on some textures). Nice to hear it works now :) I'v checked in a fix that should make nearly all ut2k4 texturing problems disappear. s3tc multitexturing and 8x8 cubic maps are still broken so try to avoid them. Does nwn still lock? -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: enable hw vertex programs by default causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Sat, 11 Mar 2006 22:48:49 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Fri, 10 Mar 2006 21:58:50 +0100 Rune Petersen [EMAIL PROTECTED] wrote: The best images this time were in the menu (grows upwards this time): http://megahurts.dk/rune/stuff/nwn_menu_1.png http://megahurts.dk/rune/stuff/nwn_menu_2.png http://megahurts.dk/rune/stuff/nwn_menu_3.png Get xf86-video-ati and drm with Ben's fixes and try again. You might see it go upwards or downwards depending on how they are rending. nwn background image is made up of four textures sized 512x512, 512x88, 288x512, 288x88. I assumed I had a snapshot with all Ben's changes, I was wrong. updating xf86-video-ati cured the corruption then starting nwn the second time. As for the in-game corruption its a little different now. the second map loaded still have corrupted textures (slightly more then before). if I return to the first map and enter the second map again there is no corruption apart for some green on the weapons. all subsequent maps load with no trouble. there might still be trouble with maps that needs textures not already loaded. All this is just a symptom of dri tex heap manager. nwn will reload textures but they will be given different locations on vram. You can print out t-offset at around line 506 of r300_texmem.c if you are interested in seeing how it behaves. But if you do keep in mind that you need to do it after UNLOCK_HARDWARE or else bad things will happen. You should check that Ben's fix is kicking in by looking for message saying: Setting GART location based on new memory map in dmesg. If you still see problems with it enabled you can confirm GART overlapping by loading drm.ko with DEBUG=1 (AFAIK) and compairing dev_priv-gart_vm_start against dev_priv-fb_location and dev_priv-fb_size . DRM doesnt print these values but you can calculated it based on Xorg log. Find line that says: (II) RADEON(0): Will use x kb for textures at offset x and compaire upper bound of that against dev_priv-gart_vm_start. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 - GL_POLYGON_OFFSET_FILL FallBack!
On Sun, 5 Mar 2006 22:00:39 + Pedro Maia [EMAIL PROTECTED] wrote: Hello, i'm trying to play the game Cube (http://wouter.fov120.com/cube/) but i can't because the renderization is beign done in software mode. Is Polygon.OffsetLine not yet supported in r300, or do i need to activate any special thing. Not supported currently. Smooth lines, line stipples, line offsets, points and point sprites are done via special voodoo tricks on r300. Some of the bits to do them are around raster setup and some of those regs are pretty touchy to make everything lock. Improving span functions might do the trick also but im not too sure thats fast enough if vector graphics programs start using 3d. I guess they will be supported when pressure gets high enough... -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: enable hw vertex programs by default causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Fri, 10 Mar 2006 18:27:51 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sat, 04 Mar 2006 20:55:50 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Update: The Free temps when possible patch makes NWN lockup again. It would appear that hw tcl is very fragile on some cards. Sorry, I missed your mail. I just added option that will initialize all temps in vertex programs when enabled. This does not cover initializing outputs so it is still possible that something goes wrong there. You can use it by exporting R300_VP_SAFETY in your env. You should see WARN_ONCE when its enabled but keep in mind that nwn repipes stderr to /dev/null so you wont see it. I tried it, it had no effect, I don't think its the temp registers. I suspect there is something broken with the vp code or it triggers a bug somewhere else. Do I recall correctly that you have had this problem with textures before hw vps were enabled too? Also I'm am able to see corruption in the nwn loading/splash screen. The corruption seams structured, and it gradually changes from left to right, top to bottom. Is there any way to capture this? (without using a camera) I dont think iv seen anything like that but seeing it on a flat surface might set off some ideas. You can enter console and write: sleep 10 DISPLAY=:0 xwd -root | xwdtopnm | pnmtopng foo.png or: DISPLAY=:0 scrot -d 10 foo.png and switch back to X. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: enable hw vertex programs by default causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Sat, 04 Mar 2006 20:55:50 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Update: The Free temps when possible patch makes NWN lockup again. It would appear that hw tcl is very fragile on some cards. Sorry, I missed your mail. I just added option that will initialize all temps in vertex programs when enabled. This does not cover initializing outputs so it is still possible that something goes wrong there. You can use it by exporting R300_VP_SAFETY in your env. You should see WARN_ONCE when its enabled but keep in mind that nwn repipes stderr to /dev/null so you wont see it. I'm hoping to fix this after GLSL support has been added so I don't have to rewrite it twice. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] CVS HEAD segfaults on r420
On Wed, 08 Mar 2006 20:30:14 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Tue, 07 Mar 2006 21:43:22 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Hi, Me again. Quite a few games segfault with the CVS HEAD, I tried disabling vbo (//define HW_VBOS ) but didn't change anything. nwn: Quake3: ut2003(demo): ut2004(demo): segfaults. Should work now. It is better, but still problems. nwn: Works without hw tcl, but texture corruption of curtain objects (nothing new..). Quake3: Working ut2003(demo): Menu works, game segfaults. Missed these: *WARN_ONCE* File radeon_mm.c function radeon_mm_alloc line 182 Ran out of GART memory! Please consider adjusting GARTSize option. *** *WARN_ONCE* File r300_ioctl.c function r300RefillCurrentDmaRegion line 629 Whops! Dont know how to evict VBOs yet. *** Put: Option GARTSize 64 into Device section of xorg.conf and it should run just fine. I admit that r300 driver shouldnt quit like that and I'm working on it. That doesn't change the fact that not adjusting GARTSize will make r300 driver run at lowered performance. ut2004(demo): Texture corruption and eventual lockup. The only hope on tracking down problem with your card is to be able to isolate it somehow. Apps like ut2k4 q3 are pretty complicated beasts to debug... Good start would be to determine if the textures really get corrupted or if its a symptom of something else. Mesa demos/tests would be good for this sort of thing but anything with less than 1k of code should do. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Benchmarks.
On Mon, 06 Mar 2006 04:11:58 +0100 Roland Scheidegger [EMAIL PROTECTED] wrote: Adam K Kirchhoff wrote: Using umark for benchmarking UT2004 (1024x768 with all low or very low display settings)... First DM-1on1-Albatross: 9600 - fgl - 11.378239 / 35.393394 / 82.763985 fps - Score = 35.407494 9600 - dri - 5.033368 / 8.846323 / 17.930601 fps - Score = 8.850811 Nothing new here, dri performance is still limited by the lack of ARB_vbo or at least decent drawArrays performance avoiding fallbacks. r300 driver now supports this in HW. It should work pretty well as long as GART is big enough and application doesn't request to draw with more than 65535 verts. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: enable hw vertex programs by default causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Tue, 28 Feb 2006 22:04:49 +0100 Rune Petersen [EMAIL PROTECTED] wrote: This also fixes the lockup I've been having in Quake3 map0. There is still corruption which spreads to include the menu, and is persistent even when restarting the game. But hay it's an improvement. Can you get a screenshot of it? -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: enable hw vertex programs by default causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
On Mon, 27 Feb 2006 19:47:35 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Hi, Found the cause the patch: enable hw vertex programs by default. The only fix I've found is to disable it (attached patch). I am willing to test better solutions, but until then can it be disabled by default? Try with these two patches applied: http://rasterburn.org/~aet/r300_lit.diff http://rasterburn.org/~aet/r300_no_fog.diff I was able to get a trace on the vertex program behind one nwn lock but I cannot make it lock my box any more. -- Aapo Tahkola --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri on r300
On Sat, 18 Feb 2006 21:45:54 -0500 Patrick McFarland [EMAIL PROTECTED] wrote: Well, I finally upgraded my Radeon 8500 to a Radeon 9600, however trying to use Xorg's DRI drivers with it causes X to completely lock up on startup. ATI's binary drivers work fine, however. Also, starting Xorg without Load dri works fine Xorg's radeon driver. So, whats wrong? https://bugs.freedesktop.org/show_bug.cgi?id=5912 might have some useful options to try. Also make sure fast writes arent enabled. Lastly, radeon memory map issues come to mind. -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri on r300
On Mon, 20 Feb 2006 16:48:24 -0500 Patrick McFarland [EMAIL PROTECTED] wrote: On Monday 20 February 2006 16:36, Alex Deucher wrote: On 2/20/06, Patrick McFarland [EMAIL PROTECTED] wrote: On Monday 20 February 2006 17:09, Aapo Tahkola wrote: On Sat, 18 Feb 2006 21:45:54 -0500 Patrick McFarland [EMAIL PROTECTED] wrote: Well, I finally upgraded my Radeon 8500 to a Radeon 9600, however trying to use Xorg's DRI drivers with it causes X to completely lock up on startup. ATI's binary drivers work fine, however. Also, starting Xorg without Load dri works fine Xorg's radeon driver. So, whats wrong? https://bugs.freedesktop.org/show_bug.cgi?id=5912 might have some useful options to try. Also make sure fast writes arent enabled. Lastly, radeon memory map issues come to mind. I already did all the usual turn off fast writes and 8x in bios thing. What I don't get is that the binary drivers work fine, and Windows works fine. I'm wondering if its an incompatibility with the hardware. Its a RV350 AP plugged into a K8 running in 32 bit mode. why would be it incompatible if it works with fglrx and windows? I meant with DRI. r300 driver doesnt kick in until you start some 3d app. Given that, the fault is either in ddx or drm. What model brand is this card? How much memory? -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: front/back buffer offsets in DRM
On Mon, 28 Nov 2005 02:59:05 +0100 Roland Scheidegger [EMAIL PROTECTED] wrote: Felix Kühling wrote: Whats the point of doing these operations in DRM anyway? Personally I would just pull out as much code from there as possible. I was wondering about that too. There may be some reason for doing those things in the kernel, but I don't know of any. At least on some hardware buffer clearing and swapping is done by the 2D engine. Instead of exposing the necessary functionality through some generic blit or fill ioctls, specific clear and swap operations were implemented. The fact that the Xserver provides the offsets and pitches adds some sense of security by preventing untrusted clients from overwriting random memory. I believe it should be possible to replace clear and swap ioctls with generic blit and fill ioctls that do some range checking on their arguments. You can't do that for special clears like the hyperz fast z clear on radeons. It could probably still be moved to userspace though, but I'm not too sure it makes a lot of sense. I think better long term plan would be to simulate 2d operations via standard opengl operations. That way we would get CopyTexSubImage* and similar operations accelerated with far less effort than by writing driver specific routines to do it. I agree on keeping the 2d routines around but you have to see that they are very limited in sense of what you can do with them. Another thing that bothers me is the amount of duplicate code around. radeon_cp_texture(), texrects uploads, and buffer swaps are just same operations done differently. -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Marbleblast + r300
On Thu, 26 Jan 2006 14:41:45 +0100 Jerome Glisse [EMAIL PROTECTED] wrote: On 1/26/06, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Marbleblast, a game from GarageGames, seems to have an issue with the r300 driver... The game crashes when it goes to start a new level. It crashes with: drmRadeonCmdBuffer: -22 (exiting) drmRadeonCmdBuffer: -22 (exiting) dmesg shows: [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4540 sz=3) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed This likely due to an old drm, Aapo added a new reg lately to fix texture upload issue. Thus you need a new drm which accept to program this reg. Problem here was that offset(=0x0) from a disabled tmu were sent to drm. multiarb with unit 0 disabled and unit 1 enabled triggered this same problem. This should be fixed in cvs now. -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Marbleblast + r300
On Thu, 26 Jan 2006 18:06:25 + Aapo Tahkola [EMAIL PROTECTED] wrote: On Thu, 26 Jan 2006 14:41:45 +0100 Jerome Glisse [EMAIL PROTECTED] wrote: On 1/26/06, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Marbleblast, a game from GarageGames, seems to have an issue with the r300 driver... The game crashes when it goes to start a new level. It crashes with: drmRadeonCmdBuffer: -22 (exiting) drmRadeonCmdBuffer: -22 (exiting) dmesg shows: [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4540 sz=3) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed This likely due to an old drm, Aapo added a new reg lately to fix texture upload issue. Thus you need a new drm which accept to program this reg. Problem here was that offset(=0x0) from a disabled tmu were sent to drm. multiarb with unit 0 disabled and unit 1 enabled triggered this same problem. This should be fixed in cvs now. Forgot to mention that I had to disable GL_TEXTURE_LOD_BIAS_EXT because it directly touches state atoms. Does anyone have any ideas on how to make that appear in struct r300_tex_obj ? Secondly, some Marbleblast levels seem to trigger assertion in texenvprogram.c:619 . -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: status
On Wed, 25 Jan 2006 20:29:05 +0100 khaqq [EMAIL PROTECTED] wrote: On Wed, 25 Jan 2006 11:51:17 +0100 Kristoffer [EMAIL PROTECTED] wrote: I'm thinking of trying the radeon driver again, but i'm wondering wether or not it will ever catch up with the fglrx driver on speed? what's the status of this, or goal? and what's the status on 9800 pro dual monitor support with 3d? thanks for all your hard work anyway. my guess is that you're going to get either silence from the list, or a answer to your own question by doing benchmarks-type response. the only thing I can say is that fglrx is better than dri on some aspects of GL, unfortunatly this is what is used in UT2K3 / UT2K4 for example. there are plans to fix this, as time allows. The ut2k4 problem(s) have been in a semi-fixed state for a while now. Bits and bolts dealing with it arent just enabled by default because quite a few changes are needed to get it fully transparent. Couple shots: http://www.rasterburn.org/~aet/ut2k4_tweaked.png http://www.rasterburn.org/~aet/ut2k4_vanilla.png -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: status
On Wed, 25 Jan 2006 17:28:17 -0500 Adam K Kirchhoff [EMAIL PROTECTED] wrote: On Wednesday 25 January 2006 19:01, Aapo Tahkola wrote: On Wed, 25 Jan 2006 20:29:05 +0100 khaqq [EMAIL PROTECTED] wrote: On Wed, 25 Jan 2006 11:51:17 +0100 Kristoffer [EMAIL PROTECTED] wrote: I'm thinking of trying the radeon driver again, but i'm wondering wether or not it will ever catch up with the fglrx driver on speed? what's the status of this, or goal? and what's the status on 9800 pro dual monitor support with 3d? thanks for all your hard work anyway. my guess is that you're going to get either silence from the list, or a answer to your own question by doing benchmarks-type response. the only thing I can say is that fglrx is better than dri on some aspects of GL, unfortunatly this is what is used in UT2K3 / UT2K4 for example. there are plans to fix this, as time allows. The ut2k4 problem(s) have been in a semi-fixed state for a while now. Bits and bolts dealing with it arent just enabled by default because quite a few changes are needed to get it fully transparent. Couple shots: http://www.rasterburn.org/~aet/ut2k4_tweaked.png http://www.rasterburn.org/~aet/ut2k4_vanilla.png Do these fixes remove the need to disable s3tc to avoid the flickering tiling problem? These changes are already in cvs with exception of fb vbos(pretty useless anyways) and the drm scratch patch. s3tc problem is still there im afraid. Im using patches off #5353 to get around the texture swapping problem... -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 fragment program write to depth
On Sat, 21 Jan 2006 19:14:02 +0100 Jerome Glisse [EMAIL PROTECTED] wrote: Hi, Write to depth in fragment program doesn't work. Looking at fglrx dump, shows that sometimes fglrx doesn't even set the R300_PFS_NODE_OUTPUT_DEPTH. Also using a fragment program very similar to one produced by fglrx doesn't work. I (Ben too) suspect that we miss somethings elsewhere. Did anyone already looked at that ? Have you checked regs around 0x4F00 - 0x4Fxx ? I imagine early z test should be off at least. -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI AIW Radeon 9800 Pro - LockUp
On Sun, 08 Jan 2006 14:31:02 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: Alright. Have you been able to reproduce this with any other app? Perhaps if it hits in menus it might be able to track it down but I wouldnt try it otherwise. Also, does it lock always at the same time or is it random? No only Quake 3. in-game lockups are rare, most happens when loading maps (might be locking up on the first frame) the worst map is Q3DM0, which might help track it down. Also r_texturebits 32 vs. r_texturebits 16 increases the chance of a lockup. Could you try Q3DM0 with this patch applied to r300_render.c ? It should ignore all rendering commands at around time leaving menu. Let me know if you cant reproduce the lock with it. BTW, killall -15 quake3.x86; xrandr -s 0 might be handy if it doesnt lock... it does still lockup, I can kill quake3, but am unable to recover the screen. the last screen is loading SOUNDS... So it doesnt hard lock system as it used to? If thats the case, then Im afraid states have something to do with the lock. From r300 drivers point of view, texture depth doesnt really make much difference. -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI AIW Radeon 9800 Pro - LockUp
On Fri, 06 Jan 2006 23:07:30 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Adam K Kirchhoff wrote: Then with the X300 - X850, I think it's only the X800 and X850 cards have 256-bit interfaces, correct? Do X800 cards experience the same lockups? Yes, my x850 pro had the same problem although the symptoms were very different from what others have reported. See bug #5294. My X800 XT is working fine, the only real problem I have with lockups are with Quake 3 and is unrelated. Im a bit dubious your problem not being related as I had some similar problems with q3. Could you test if manytex -size 512 512 -n 100 works? It should lock immediately if theres some problem as indirect buffers kept in gart get tampered over by texture uploads. -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI AIW Radeon 9800 Pro - LockUp
On Sat, 07 Jan 2006 23:58:44 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: My X800 XT is working fine, the only real problem I have with lockups are with Quake 3 and is unrelated. Im a bit dubious your problem not being related as I had some similar problems with q3. Could you test if manytex -size 512 512 -n 100 works? It should lock immediately if theres some problem as indirect buffers kept in gart get tampered over by texture uploads. Looks fine, and no lockup. Alright. Have you been able to reproduce this with any other app? Perhaps if it hits in menus it might be able to track it down but I wouldnt try it otherwise. Also, does it lock always at the same time or is it random? -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI AIW Radeon 9800 Pro - LockUp
On Sun, 08 Jan 2006 01:33:56 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sat, 07 Jan 2006 23:58:44 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: My X800 XT is working fine, the only real problem I have with lockups are with Quake 3 and is unrelated. Im a bit dubious your problem not being related as I had some similar problems with q3. Could you test if manytex -size 512 512 -n 100 works? It should lock immediately if theres some problem as indirect buffers kept in gart get tampered over by texture uploads. Looks fine, and no lockup. Alright. Have you been able to reproduce this with any other app? Perhaps if it hits in menus it might be able to track it down but I wouldnt try it otherwise. Also, does it lock always at the same time or is it random? No only Quake 3. in-game lockups are rare, most happens when loading maps (might be locking up on the first frame) the worst map is Q3DM0, which might help track it down. Also r_texturebits 32 vs. r_texturebits 16 increases the chance of a lockup. Could you try Q3DM0 with this patch applied to r300_render.c ? It should ignore all rendering commands at around time leaving menu. Let me know if you cant reproduce the lock with it. BTW, killall -15 quake3.x86; xrandr -s 0 might be handy if it doesnt lock... -- Aapo Tahkola q3_render_ign.patch Description: Binary data
Re: ATI AIW Radeon 9800 Pro - LockUp
On Wed, 04 Jan 2006 21:07:41 -0400 Jon [EMAIL PROTECTED] wrote: I have a ATI AIW Radeon 9800 Pro (r350), I'm getting plenty of freezing with r300 DRI module. I tried Quake3 (wont get past beginning of opening game video, locks computer solid) and Xmoto (lasts for a few seconds than computer locks) GLXGears runs fine and for a long time, no freezing. (10755 frames in 5.0 sec = 2151 FPS etc) I'm using FreeBSD 6.0 Stable, I just built from cvs at freedesktop.org Mesa3D ,DRM kernel module and the r300 DRI module. Is their anything I can test or do? This is a known problem with r9500, r9700 and r9800 cards. You can initialize the card with official drivers. No other fix beyond that exist nor is being planned on. -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: I want to help with ATI Mobility Radeon 9600
On Sat, 10 Dec 2005 15:17:31 +0100 Erik [EMAIL PROTECTED] wrote: Philipp Klaus Krause wrote: Erik schrieb: # emerge -pv xorg-x11|grep xorg [ebuild R ] x11-base/xorg-x11-6.8.2-r6 -3dfx -3dnow +bitmap-fonts -cjk -debug -dlloader -dmx -doc -font-server -insecure-drivers +ipv6 -minimal +mmx +nls -nocxx +opengl +pam -sdk +sse -static +truetype-fonts +type1-fonts (-uclibc) -xprint +xv 0 kB This comes from /var/log/Xorg.0.log: (WW) RADEON(0): Direct rendering not yet supported on Radeon 9500 and newer cards (II) RADEON(0): Memory manager initialized to (0,0) (1920,8191) (II) RADEON(0): Reserved area from (0,1200) to (1920,1202) (II) RADEON(0): Largest offscreen area available: 1920 x 6989 (II) RADEON(0): Render acceleration unsupported on Radeon 9500/9700 and newer. (II) RADEON(0): Render acceleration disabled What should I do to help? You need a new driver, consisting of a newer xorg, DRM and Mesa. Install a current driver, which supports your card first: See http://dri.freedesktop.org/wiki/Building for building drivers from current CVS. OK, I followed the steps. When building Mesa, I had to change the instruction make linux-dri-x86 to make PKG_CONFIG_PATH=/lib/pkgconfig linux-dri-x86 to make it work. When following the advice Make sure you have run at least make dep on your kernel tree or the build will fail. i got *** Warning: make dep is unnecessary now. Then I tried with glxgears: libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering What does that mean and what went wrong? I attach some files for reference. [drm] Initialized radeon 1.17.0 20050311 on minor 0: Youll need 1.20 radeon drm. -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: I want to help with ATI Mobility Radeon 9600
On Sat, 10 Dec 2005 17:04:51 +0100 Philipp Klaus Krause [EMAIL PROTECTED] wrote: And 3D-acceleration seems to work! But I get some warnings: *WARN_ONCE* File r300_state.c function r300Enable line 457 TODO - double side stencil ! *** No ctx-FragmentProgram._Current!! That's normal for an experimental unfinished driver like the r300 one. It's slower than it will be after further optimization. PÜrobably the warning above means that hardware can do double sided stencil, but it's not implemented yet in the driver and thus won't work or causes a software fallback. Most software fallbacks have been disabled because they are simply too slow. See r300_render.c: r300Fallback for a list. You can get some extra boost by sticking: Option ColorTiling true into xorg.conf ut2k4 can further be boosted with vbos but this isnt very useful because the amount of mem left for textures is too low. (cards with 256 of vram get clipped to 128 mb) s3tc doesnt currently work well enough with ut2k4... On top of that, some applications like nexuiz and nwn get killed by the amount of vertex data passing through the driver. Both of these implement locked arrays but I havent been able to figure if they implement presistent vertex buffers with it somehow. -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: I want to help with ATI Mobility Radeon 9600
On Sat, 10 Dec 2005 18:38:50 +0100 Erik [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sat, 10 Dec 2005 17:04:51 +0100 Philipp Klaus Krause [EMAIL PROTECTED] wrote: And 3D-acceleration seems to work! But I get some warnings: *WARN_ONCE* File r300_state.c function r300Enable line 457 TODO - double side stencil ! *** No ctx-FragmentProgram._Current!! That's normal for an experimental unfinished driver like the r300 one. It's slower than it will be after further optimization. PÜrobably the warning above means that hardware can do double sided stencil, but it's not implemented yet in the driver and thus won't work or causes a software fallback. Most software fallbacks have been disabled because they are simply too slow. See r300_render.c: r300Fallback for a list. I have 2 versions of that file: 25565 Dec 4 01:37 ./Mesa/src/mesa/drivers/dri/r300/r300_render.c 19306 Jul 31 18:47 ./xc/extras/Mesa/src/mesa/drivers/dri/r300/r300_render.c I assume you mean the newest file. If a software fallback for a hardware operation is disabled, does that mean that the operation can not be done at all? (I have no clue what a double side stencil is.) You can get some extra boost by sticking: Option ColorTiling true into xorg.conf Sounds good that the driver can be made faster, but why would I have to turn it on in a configuration file? Because it doesnt work in conjunction with page flipping. Or actually it does but officially it doesnt. :) I tried tuxracer and it seemd to work. (I wanted to try boson, but the package for a dependency was broken, so I wait until it is fixed.) Is there anything else I should test and report about? Not really, we already know pretty much every issue you can have with the driver... It would be nice to get some numbers for comparison with prop drivers. Unfortunately doing so means using vbos since other paths get shadowed by slower/incorrect vertex data upload routines. -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: BUG: System lockup with kpovmodeler
On Sat, 10 Dec 2005 19:37:18 +0100 Erik [EMAIL PROTECTED] wrote: I tested kpovmodeler and it locked up the system so I had to turn it off by holding down the power button 4 seconds. This is reproductible, but only if kpovmodeler is able to open DRM. This is the output that kpovmodeler shows before locking the system: kpovmodeler: WARNING: Serialization method for Light shadows old implementation kpovmodeler: WARNING: Serialization method for GlobalSettings shadows old implementation kpovmodeler: WARNING: Serialization method for Interior shadows old implementation kpovmodeler: WARNING: Serialization method for Pattern shadows old implementation kpovmodeler: WARNING: Serialization method for Normal shadows old implementation kpovmodeler: WARNING: Serialization method for Warp shadows old implementation kpovmodeler: WARNING: Serialization method for Finish shadows old implementation kpovmodeler: WARNING: Serialization method for Media shadows old implementation kpovmodeler: WARNING: Serialization method for GraphicalObject shadows old implementation kpovmodeler: WARNING: Serialization method for Pigment shadows old implementation kpovmodeler: WARNING: Serialization method for Texture shadows old implementation kpovmodeler: WARNING: Serialization method for BicubicPatch shadows old implementation kpovmodeler: WARNING: Serialization method for Triangle shadows old implementation *WARN_ONCE* File r300_state.c function r300Enable line 457 TODO - double side stencil ! *** No ctx-FragmentProgram._Current!! *WARN_ONCE* File r300_render.c function r300_render_vb_primitive line 514 Rendering with elt buffers *** The output probably has nothing to do with the lockup, because it is written before (at application startup). It locks the system when I click on the Cone icon and select insert as first subobject. The keyboard no longer works, so no switching to virtual terminals or killing X-server is possible. The mouse cursor moves, but the GUI does not respond to clicks. What version is this? 1.1.2 seems to work fine here. Too bad I dont have my rv350 hooked. -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: front/back buffer offsets in DRM
On Fri, 25 Nov 2005 16:16:48 -0700 Brian Paul [EMAIL PROTECTED] wrote: I've been playing around with the EGL r200 driver. Digging through the framebuffer allocation code I've found a few problems. In order to support pbuffers and framebuffer objects we need to be able to work with color/depth/stencil buffers are various locations in video memory. The current code sets the front/back/depth buffer offsets and pitches once in the radeon_do_init_cp() function and there's no way to change them thereafter. It looks like the only code that uses this information is the glClear and SwapBuffers-related code in radeon_cp_dispatch_clear(), radeon_cp_dispatch_swap() and radeon_cp_dispatch_flip(). And the code that enables/disables color tiling. Could someone more familiar with the code comment on what it would take to fix the code so that color/depth buffers at arbitrary locations can be used? I'd probably do away with the front/back_offset/pitch fields entirely and pass the offset/pitch values as parameters to the ioctls. I'd also write the code so there's no distinction between front/back color buffers. Whats the point of doing these operations in DRM anyway? Personally I would just pull out as much code from there as possible. -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Activating Fast Write mode kills the machine
On Mon, 14 Nov 2005 08:10:30 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Is it a hardware bug or lack of docs on how it's implemented? One could argue that AGP itself is a HW bug in the firstplace and works due to mere luck. Enabling fast write is pushing that luck too far. Just to add that omega drivers actually recommend to use fast writes on r9600. Could it just be that the chip behaves little differently when fast writes are enabled? There was a funky number in PPL parameters at #4847 logs. -- Aapo Tahkola --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Snapshot build failed
On Fri, 04 Nov 2005 23:53:56 -0500 Felix Kuehling [EMAIL PROTECTED] wrote: A snapshot build failed at Fr Nov 4 23:53:56 EST 2005. Should build now. -- Aapo Tahkola --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300]Mesa Tests
On Thu, 27 Oct 2005 19:59:29 +0100 pedro.lixo [EMAIL PROTECTED] wrote: Mesa Tests R300 driver latest cvs! Remove the Warn_once from results Xorg Options #Option GARTSise 32 #Option RenderAccel true #Tiling disable SUCESS ./arbvptest1 ./arbvptest3 ./arbvptorus ./arbvpwarpmesh ./arbfptest1 ./arbfpspec ./arbfptexture ./blendminmax ./blendsquare ./bufferobj ./bug_3101 ./bug_3195 ./cva ./dinoshade ./invert ./manytex (although it passes i see some particles, i don't know if it's only visual fail, or driver) ./no_s3tc (although it has the problem with small textures, already know bug) ./packedpixels (although when we first see the window, the last square are not correct GL_unsigned_int 8_8_8_8 (normal, it's all green), but if i try take a snapshot or if i minize it the window comes normal again green with red stripe ) ./seccolor (same problem as above, first color in red is not correct and we can see garbage in 1st cube, but if program lose context, and then have it again the render is then ok, if i press 'space', the cubes appear correctly) Black texel shouldnt interpolate. ./yuvsquare (same problem as above if i move pad keys render works well again) Should be fixed now. ./projtex (it worked well, although textures were too dark, almost can't see girl texture) ./sharedtex ./stencil_wrap ./tex1d ./texline ./texobjshare ./texwrap ./vparray ./vptest3 ./vptorus ./vpwarpmesh ./zreaddraw Depth value range: [0.001511, 1.00] FAILS ./arbfptrig GL_RENDERER = Mesa DRI R300 20040924 AGP 4x TCL glGetError = 0x0 glError(GL_PROGRAM_ERROR_STRING_ARB) = r300_fragprog.c::parse_program(): unknown fpi-Opcode 33 pc=0* Mesa program: - MOV TEMP[0] STATE[0] SCS TEMP[0] INPUT[4]. ADD TEMP[0] TEMP[0] STATE[1]. MUL TEMP[0] TEMP[0] STATE[2]. MOV OUTPUT[0] TEMP[0] Hardware program NODE 0: alu_offset: 0, tex_offset: 0, alu_end: -1, tex_end: -1 1230 00050a80 11b0 03860820 1270 00040889 11f0 00860820 r300SetupPixelShader: No valid fragment shader, exiting ./crossbar Diferent colors, http://pwp.netcabo.pt/0448311801/xorg/crossbar.png ./fbotest1 (No FBO support no framebuffer extension, expected i think!) GL_EXT_framebuffer_object not found! GL_RENDERER = Mesa DRI R300 20040924 AGP 4x TCL Mesa 6.4 implementation error: User called no-op dispatch function (an unsupported extension function?) Please report at bugzilla.freedesktop.org fbotest1: fbotest1.c:121: Init: Assertion `MyFB' failed. Aborted ./fbotexture GL_EXT_framebuffer_object not found! I suppose a little limited FBO's could be done with some effort. I dont think I have time for that though. ./floattex Sorry, this test requires GL_MESAX_texture_float ./fog (althought it starts, it misses extension) GL_RENDERER = Mesa DRI R300 20040924 AGP 4x TCL GL_VERSION = 1.3 Mesa 6.4 Some output of this program requires GL_EXT_fog_coord ./fogcoord GL_RENDERER = Mesa DRI R300 20040924 AGP 4x TCL GL_VERSION = 1.3 Mesa 6.4 Sorry, this program requires GL_EXT_fog_coord /fptest1 (Meaning ?!) Mesa 6.4 implementation error: User called no-op dispatch function (an unsupported extension function?) Please report at bugzilla.freedesktop.org glGetError = 1280 ./fptexture Error: GL_NV_fragment_program not supported! I suppose we could enable this one. ./multipal Sorry, GL_EXT_paletted_texture not supported by this renderer. ./pbo GL_VERSION = 1.3 Mesa 6.4 GL_RENDERER = Mesa DRI R300 20040924 AGP 4x TCL Sorry, this demo requires GL_EXT_pixel_buffer_object Maybe... ./stencilwrap - Fails complete log attach ./texrect (complete log in attach) 8 texture units supported, using 2. 2048 x 2048 max texture rectangle size Texture 0: ../images/girl.rgb (194 x 188) Texture 1: ../images/reflect.rgb (128 x 128) drmRadeonCmdBuffer: -22 (exiting) See bug #4150 . /vptest1 vptest1: vptest1.c:131: Init: Assertion `!glIsProgramNV(1)' failed. Aborted How do we detect when parsing has failed? ./vptest2 Mesa 6.4 implementation error: Bad target in r300NewProgram Please report at bugzilla.freedesktop.org vptest2: vptest2.c:63: Test1: Assertion `glIsProgramNV(1)' failed. Aborted Little better now. ./yuvrect (complete log in attach) Image: 194x188 drmRadeonCmdBuffer: -22 (exiting) See bug #4150 . -- Aapo Tahkola --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 powerpc: success (absolutely!)
On Mon, 31 Oct 2005 14:59:59 +0100
Michel Dänzer [EMAIL PROTECTED] wrote:
On Sun, 2005-10-30 at 10:17 +1100, Benjamin Herrenschmidt wrote:
Sounds like 32-bit elts work for ppc.
16-bit elts are used in vtxfmt_a path so thats still broken.
They probably need HDW swapping... AFAIK, the CCE is doing 32 bits
bytewap all the time.
Yes, we set it up that way so that we don't have to take care of byte
order for every CP command.
Thus, 16 bits data need to have top and bottom 16 bits swapped (HDW swap)
to correct the result.
In the radeon and r200 drivers, it's even hairier than that because the
elts aren't always aligned to 4 bytes. See EMIT_ELT in
r{adeon,200}_tcl.c.
I think its more hilarious than anything else.
--
Aapo Tahkola
---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 powerpc: success (wokds now...)
On Fri, 28 Oct 2005 15:08:52 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Fri, 2005-10-28 at 14:13 +1000, Benjamin Herrenschmidt wrote: This is exactly the kind of crap I see here too on the G5, so that irons out a 32 vs 64 bits issue. The strangest thing is that paulus is currently running a version of the driver on his G5 that does not have this issue. It's fairly old, it seems to be a checkout of the old r300 branch from April 13 or 14 this year (yah, I told you old :) That one uses 32-bit immediate elts(start_index32_packet). I don't have time to investigate this for now though. Paul might have hacked something in there too though but I have his source tree so I can run diffs Ok, I just rebuild from Mesa CVS with current kernel git DRM and ... it works. I haven't checked if a fix went into CVS, but it works nicely :) I tossed out conversion to 16-bit elts on Wednesday. -- Aapo Tahkola --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 powerpc: success (absolutely!)
On Fri, 28 Oct 2005 11:39:57 +0200 Jerome Glisse [EMAIL PROTECTED] wrote: On 10/28/05, Mattias Nissler [EMAIL PROTECTED] wrote: Hi again, just wanted to let you know that I pulled the latest CVS tree this evening and all rendering problems are gone! Many, many, many thanks! I have given the r300 driver some workout with quake3 and there were no rendering problems at all. The missing trails in gltron are also there, transparent as they should be. Really great work! Mattias Aapo you commit anything about the endian swapping for fixing what Mattias was experiencing in his last report ? No. Sounds like 32-bit elts work for ppc. 16-bit elts are used in vtxfmt_a path so thats still broken. -- Aapo Tahkola --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Last Commit break things!
On Thu, 27 Oct 2005 00:23:54 +0100 pedro.lixo [EMAIL PROTECTED] wrote: Just to warn that in last commit to r300, aapot has forgeted to del the 2 headers that have been deleted from the project both #include r200_tcl.h, #include r200_sanity.h, are not needed anymore, so please update radeon_ioctl.c It should work fine as R200_MERGED is 0. Did you make clean/remove depend before building? -- Aapo Tahkola --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 powerpc: success (quite some...)
On Thu, 27 Oct 2005 14:00:18 +0200 Mattias Nissler [EMAIL PROTECTED] wrote: 3. quake3: I did some heavy struggling with the quake3 source tree, but now I could get it running. It renders correctly when I use the Mesa software renderer (but unplayable then, of course). With r300 I made the same experience reported by BenH earlier this month: intro works, main menu somewhat broken, submenus work, the game itself is completely messed up :-( If you are curious here are some shots: http://www-user.rhrk.uni-kl.de/~nissler/q3shots/shot10.jpeg http://www-user.rhrk.uni-kl.de/~nissler/q3shots/shot11.jpeg http://www-user.rhrk.uni-kl.de/~nissler/q3shots/shot12.jpeg http://www-user.rhrk.uni-kl.de/~nissler/q3shots/shot13.jpeg http://www-user.rhrk.uni-kl.de/~nissler/q3shots/shot14.jpeg Any ideas what could be causing those problems? Is quake3 rendering correctly on x86 at the moment? I am willing to look into the source if someone could give me a few hints what to look for. I can also do some further testing if that helps... Im not ppc expert but you could try this. -- Aapo Tahkola r300_ppc_elt.patch Description: Binary data
Re: r300 powerpc: success (quite some...)
On Thu, 27 Oct 2005 15:03:26 +0200 Jerome Glisse [EMAIL PROTECTED] wrote: On 10/27/05, Aapo Tahkola [EMAIL PROTECTED] wrote: On Thu, 27 Oct 2005 14:00:18 +0200 Mattias Nissler [EMAIL PROTECTED] wrote: 3. quake3: I did some heavy struggling with the quake3 source tree, but now I could get it running. It renders correctly when I use the Mesa software renderer (but unplayable then, of course). With r300 I made the same experience reported by BenH earlier this month: intro works, main menu somewhat broken, submenus work, the game itself is completely messed up :-( If you are curious here are some shots: http://www-user.rhrk.uni-kl.de/~nissler/q3shots/shot10.jpeg http://www-user.rhrk.uni-kl.de/~nissler/q3shots/shot11.jpeg http://www-user.rhrk.uni-kl.de/~nissler/q3shots/shot12.jpeg http://www-user.rhrk.uni-kl.de/~nissler/q3shots/shot13.jpeg http://www-user.rhrk.uni-kl.de/~nissler/q3shots/shot14.jpeg Any ideas what could be causing those problems? Is quake3 rendering correctly on x86 at the moment? I am willing to look into the source if someone could give me a few hints what to look for. I can also do some further testing if that helps... Im not ppc expert but you could try this. The hardware could do the swapping for us no ? If i remember correctly i have put a couple of ifdef about big endian in setup code to do some swapping... reg 2140 was for that (see r300_state and look for big endian). Thats probably only for vertex data. INDX_BUFFER is basicly just a gpu memory fetcher that can be used with just about any packet if you know the address. Given that I suspect R300_EB_UNK1 or R300_EB_UNK2 is different on ppc. Anyway long time i didn't get access to my ppc config, i will try to take a look at what i have got on that. Has anyone tested color tiling on ppc yet? It would be nice to get it enabled by default... -- Aapo Tahkola --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] Prototype for implementing vertex buffer allocations in user space
These patches implement simple vertex buffer allocations in user space. Relying on radeon_alloc means that reclaiming buffers allocated by other processes isnt possible. -- Aapo Tahkola r300_user_buffers.patch Description: Binary data r300_drm_scratch.patch Description: Binary data
Re: r300 + agpfastwrite
On Mon, 19 Sep 2005 01:18:48 +0200 john [EMAIL PROTECTED] wrote: hello! I'm using the r300 driver from mesa+drm cvs and would like to know if there is any way of using agpfastwrite? Such option exist but I dont think anyone has seen it work. -- Aapo Tahkola --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: offtopic: quake3 source
On Sat, 17 Sep 2005 14:05:11 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Bernardo Innocenti wrote: Roland Scheidegger wrote: I've just noticed I have page-flipping enabled in my xorg.conf. I can't afford to crash my X session at this time, but I'll try disabling it later. Works just fine for me (x86, latest drm, latest Mesa, rv250, pageflipping, color tiling, hyperz). My xorg is a bit outdated though (one week old). Hmmm... I'm on x86_64. Perhaps it's a bug in the DRM ioctl32 code? Neverball for x86_64 works fine btw... I shall try with a 32bit version too. You may also want to try this patch, which makes quake3 more stable on my R420 card. Really? Could you try if demos/lodbias works for you? or you can try setting r_textureMode to GL_NEAREST_MIPMAP_NEAREST and try using 16 bit textures (r_texturebits). Fixes in this patch: -Invalid mipmap filters chosen -Fix and enable cube maps -Fix command buffer corruption caused by r300EmitBlit -Fix bad temp count for vsf(fixes lots of little problems with it) -- Aapo Tahkola r300-mipmap.patch Description: Binary data
Re: dual-TMU support
On Sat, 17 Sep 2005 09:48:37 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: On Thu, 15 Sep 2005, Chris Chiappa wrote: Wasn't sure whether to send this to dri-users or dri-devel but it's sort of a bug report so I figured I'd send it here. Following the Building instructions on the DRI Wiki I believe I have DRI working on my Thinkpad T42 (Radeon Mobility M10). glxinfo tells me: direct rendering: Yes and I seem to get about 1340 fps in glxgears. Not great, but certainly better than software. Quake 2 seems to run fine with glx support. (Both glxgears and Q2 print various messages like TODO - double side stencil ! and user error: Need more than 2 vertices to draw primitive QS ! but I assume those are mostly debugging-related). My (perhaps overly ambitious) TODO messages mark code that needs work. For example, double side stencil does not work, so if you want to play with it all you have to do is grep for the text of message in the source code. The user error messages is due to the fact that glxgears sometimes outputs insufficient number of vertices to draw a primitive - for example only 2 vertices for a quad. This is normal AFAIK, and since mesa doesnt do it, we need to. For all I care this message should be removed. goal, however, would be to be able to run World of Warcraft. It runs under Wine with fglrx, but I experience frequent crashes and of course in any case would prefer to use free drivers. :) Running WoW with the r300 driver yields this complaint: Your 3D accelerator card is not supported by World of Warcraft. Please install a 3D accelerator card with dual-TMU support. You could try r300-mipmap.patch I posted to the other thread. Silly question - what is TMU ? From what I googled at bit, this message just means that your card is too old to run wow. As to what makes wow think so, who knows. Perhaps it works if you manipulate OpenGL extensions lists to support everything. Also make sure that you arent using indirect mesa for any reason. -- Aapo Tahkola --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] patches wanted !
On Fri, 19 Aug 2005 14:22:43 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: Hi all, As you probably know the code from r300.sf.net got merged into main Mesa and DRM trees. This is great, but it looks like everyone thinks they should check in only the perfect patches. This won't work as few people (if any) can spend days focused on the same issue. Perhaps we should just finish the driver for now. I should have some time next month. Well, you get the idea - there is still much fun to be had with this driver :) Sure, much fun would come from a proper memory manager *if* it never gets done. -- Aapo Tahkola --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dual-TMU support
On Sat, 17 Sep 2005 22:48:43 +0200 Nicolai Haehnle [EMAIL PROTECTED] wrote: On Saturday 17 September 2005 16:04, Aapo Tahkola wrote: On Sat, 17 Sep 2005 09:48:37 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: The user error messages is due to the fact that glxgears sometimes outputs insufficient number of vertices to draw a primitive - for example only 2 vertices for a quad. This is normal AFAIK, and since mesa doesnt do it, we need to. For all I care this message should be removed. This is by no means normal, and is the symptom of a bug in Mesa's recording of vertex arrays in display lists. At least the last time I looked at it it was. Yes but invalid vertex count also reaches r300 side when not using display lists. From the blue book: Incomplete specification results when either too few vertices are provided to specify even a single primitive or when an incorrect multiple of vertices is specified. The incomplete primitive is ignored; the rest are drawn. -- Aapo Tahkola --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
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
Re: ColorTiling issue on r420
On Wed, 24 Aug 2005 16:26:58 -0400 Alex Deucher [EMAIL PROTECTED] wrote: On 8/24/05, Aapo Tahkola [EMAIL PROTECTED] wrote: On Fri, 15 Jul 2005 12:04:43 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Just to add that login (KDM) is more or less fine (cursor is corrupted untill its moved). Attached diff should fix this temporarily. Im still unsure why MaxSurfaceWidth ends up affecting piches and stuff... Odd... I never saw any problems like that. However, if you set your virtual desktop greater than 3968, the desktop gets VERY corrupt. I don't see why that would affect pitches either. That check doesnt currently seem to work because some setup(at preinit) with color tiling enabled will get done earlier. Does this version break r200s or radeons? -- Aapo Tahkola Index: radeon_driver.c === RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v retrieving revision 1.69 diff -u -b -B -u -r1.69 radeon_driver.c --- radeon_driver.c 8 Aug 2005 23:42:36 - 1.69 +++ radeon_driver.c 25 Aug 2005 12:53:31 - @@ -3684,7 +3684,6 @@ NULL, /* linePitches */ 8 * 64,/* minPitch */ 8 * 1024, /* maxPitch */ - info-allowColorTiling ? info-MaxSurfaceWidth : 64 * pScrn1-bitsPerPixel, /* pitchInc */ 128, /* minHeight */ 8 * 1024, /*2048,*//* maxHeight */ @@ -3747,7 +3746,6 @@ NULL, /* linePitches */ 8 * 64,/* minPitch */ 8 * 1024, /* maxPitch */ - info-allowColorTiling ? info-MaxSurfaceWidth : 64 * pScrn1-bitsPerPixel, /* pitchInc */ 128, /* minHeight */ 8 * 1024, /*2048,*//* maxHeight */ @@ -3949,7 +3947,6 @@ NULL, /* linePitches */ 8 * 64,/* minPitch */ 8 * 1024, /* maxPitch */ - info-allowColorTiling ? info-MaxSurfaceWidth : 64 * pScrn-bitsPerPixel, /* pitchInc */ 128, /* minHeight */ info-MaxLines, /* maxHeight */ @@ -4018,7 +4015,6 @@ NULL, /* linePitches */ 8 * 64,/* minPitch */ 8 * 1024, /* maxPitch */ - info-allowColorTiling ? info-MaxSurfaceWidth : 64 * pScrn-bitsPerPixel, /* pitchInc */ 128, /* minHeight */ info-MaxLines, /* maxHeight */
Re: ColorTiling issue on r420
On Thu, 25 Aug 2005 16:19:19 +0200 Roland Scheidegger [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: That check doesnt currently seem to work because some setup(at preinit) with color tiling enabled will get done earlier. Does this version break r200s or radeons? From the top of my head, I think it does. For certain 16bit resolutions, that is (as the resolution won't be a multiple of 2048 bits wide, which is the block width of those chips for color tiling - i.e. 64 pixels for 32bit, 128 pixels for 16bit). That said, I think the use of info-MaxSurfaceWidth doesn't make any sense there, it is pure coincidence that 2048 is the same (in pixels) for the max width as it is (in bits) for the pitch increment. Isn't the block width of the r300 based chips 2048 bits too? It seems to be. -- 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
Re: ColorTiling issue on r420
On Fri, 15 Jul 2005 12:04:43 +0200
Rune Petersen [EMAIL PROTECTED] wrote:
Just to add that login (KDM) is more or less fine (cursor is corrupted
untill its moved).
Attached diff should fix this temporarily.
Im still unsure why MaxSurfaceWidth ends up affecting piches and stuff...
--
Aapo Tahkola
Index: radeon_driver.c
===
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.69
diff -u -b -B -u -r1.69 radeon_driver.c
--- radeon_driver.c 8 Aug 2005 23:42:36 - 1.69
+++ radeon_driver.c 24 Aug 2005 19:24:02 -
@@ -4746,7 +4746,7 @@
/* false by default on R3/4xx */
info-allowColorTiling = xf86ReturnOptValBool(info-Options,
OPTION_COLOR_TILING, FALSE);
- info-MaxSurfaceWidth = 3968; /* one would have thought 4096...*/
+ info-MaxSurfaceWidth = 4096/*3968*/; /* one would have thought
4096...*/
info-MaxLines = 4096;
} else {
info-allowColorTiling = xf86ReturnOptValBool(info-Options,
Re: Kernel / user interface for new memory manager
On Thu, 18 Aug 2005 16:53:37 -0700 Ian Romanick [EMAIL PROTECTED] wrote: [1] http://marc.theaimsgroup.com/?l=mesa3d-devm=01398019810w=2 Couple links on the subject: http://doom-ed.com/john-carmack/virtualized-video-card-local-memory-is-the-right-thing.html http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PG01p=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmlr=1f=Gl=50s1=%2220050168472%22.PGNR.OS=DN/20050168472RS=DN/20050168472 -- 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
Re: Fwd: radeon YCbCr output
On Sun, 7 Aug 2005 19:30:48 +0100 (BST) Steven Newbury [EMAIL PROTECTED] wrote: I've managed to get my Radeon 8500 to work with YPbPr output under Windows. I did have a bit of trouble finding how to do it again, eventually found this thread on avsforum: http://www.avsforum.com/avs-vb/showthread.php?t=212199page=1pp=20 The picture quality is incomparable to s-video and the Windows driver only supports US HDTV standard output modes, while my TV also supports PAL type HDTV modes ie. 576p; hopefully this limitation will be gone if I can get this working with Xorg. It's worth noting that it does NOT work on all Radeon cards, specifically my 9200SE will not work in YPbPr mode. --- Alex Deucher [EMAIL PROTECTED] wrote: On 8/6/05, Steven Newbury [EMAIL PROTECTED] wrote: --- Alex Deucher [EMAIL PROTECTED] wrote: Not really. Ati hasn't released any information about setting up the chip for component output. Perhaps you can dump the radeon registers in windows and compare how that driver sets things up, or perhaps the fglrx driver supports component out too and you could use the register dump tools from the r300 project. Hi again! I'm going to have a go at getting Windows working with component out and get a register dump from it. Do you know where I could find a register dumper for Windows? I don't know off hand. Or should I try compiling http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/hy0/radeon_dump.tgz under Cygwin? Would that work? I've never tried. You can give it a shot and see what happens. I've got it to compile, however to to open /dev/mem I had to change it to open it RDONLY, I don't why that would be, this is a default install of WinXP so my user account is running as Administrator. I've now come to another problem, cygwin/nt5.1 doesn't have a /proc/bus/pci so radeon_dump is segfaulting: $ ./radeon_dump Unknown card radeon_dump: ATI (null) BIOS Image start: --- Segmentation fault (core dumped) I'm still looking for a native Win32 Radeon register dumper though I've not yet had any luck in that regard. Only device drivers can access hardware under windows. Fortunately at least one _working_ HW-library still exists - http://zealsoftstudio.com/memaccess/ . -- Aapo Tahkola regdump.tar.bz2 Description: Binary data
Re: R300 memory leak
On Sat, 30 Jul 2005 18:57:30 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: On Sat, 30 Jul 2005, Vladimir Dergachev wrote: Hi all, I've been running with code checked in Mesa tree and there appears to be rather large memory leak which can be plainly seen by running glxgears and watching top. One more piece of information - the memory leak increases with the size of the window. This is very surprising as I did not think window size should matter. Also, the code path pointed by Valgrind does not appear to cause this, at least not in the obvious way - putting printf(Hello\n) in r300NewProgram does not print many Hello's so this is not the actual culprit.. Does anyone have suggestions ? 'key' is never freed when existing key is found at _mesa_UpdateTexEnvProgram / _tnl_UpdateFixedFunctionProgram. Sorry, forgot to report this one... -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Tue, 26 Jul 2005 14:18:10 +0200
Bellido Nicolas [EMAIL PROTECTED] wrote:
On Monday 25 July 2005 16:22, Aapo Tahkola wrote:
On Mon, 25 Jul 2005 08:59:53 +0200
[drm:drm_ioctl] pid=9733, cmd=0x40106450, nr=0x50, dev 0xe200, auth=1
[drm:radeon_cp_cmdbuf] RADEON_CMD_SCALARS2
[drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type 0 at e08fa024
r300_do_cp_cmdbuf doesnt get called...
That's indeed strange. From radeon_cp_cmdbuf in shared-core/radeon_state.c:
if(dev_priv-microcode_version == UCODE_R300) {
int temp;
temp=r300_do_cp_cmdbuf(dev, filp, filp_priv, cmdbuf);
if (orig_bufsz != 0)
drm_free(kbuf, orig_bufsz, DRM_MEM_DRIVER);
return temp;
}
Although dmesg says:
[drm] Loading R300 Microcode
So in the function radeon_cp_load_microcode in shared-core/radon_cp.c:
if (dev_priv-microcode_version==UCODE_R200) {
[snip]
} else if (dev_priv-microcode_version==UCODE_R300) {
DRM_INFO(Loading R300 Microcode\n);
for ( i = 0 ; i 256 ; i++ ) {
RADEON_WRITE( RADEON_CP_ME_RAM_DATAH,
R300_cp_microcode[i][1] );
RADEON_WRITE( RADEON_CP_ME_RAM_DATAL,
R300_cp_microcode[i][0] );
}
} else {
[snip]
The test against the microcode_version succeeds...
And, from the logs, I don't see the DRM_IOCTL_RADEON_CP_INIT ioctl called
twice...
Ideas ?
You dont have two cards hooked up by any chance? :)
Does Xorg.0.log get the card right?
You probably want to check if microcode_version actually has any sane value at
radeon_cp_cmdbuf.
Try something like:
printk(microcode_version %d\n, dev_priv-microcode_version);
return DRM_ERR(EINVAL);
--
Aapo Tahkola
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Wed, 27 Jul 2005 12:25:27 +0200 Bellido Nicolas [EMAIL PROTECTED] wrote: On Wednesday 27 July 2005 08:44, Aapo Tahkola wrote: On Tue, 26 Jul 2005 14:18:10 +0200 You dont have two cards hooked up by any chance? :) No, no handmade mobo with 2 agp slots :) Does Xorg.0.log get the card right? Apparently yes, it does. You probably want to check if microcode_version actually has any sane value at radeon_cp_cmdbuf. Try something like: printk(microcode_version %d\n, dev_priv-microcode_version); return DRM_ERR(EINVAL); Yeah, I was planning to do smthg like that. But, how do you explain: [drm:drm_ioctl] pid=9733, cmd=0x40106450, nr=0x50, dev 0xe200, auth=1 DRM_COMMAND_BASE + DRM_RADEON_CMDBUF == 0x50 [drm:radeon_cp_cmdbuf] RADEON_CMD_SCALARS2 cmd type 7 equals to R300_CMD_WAIT(from r300DoEmitState) [drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type 0 at e08fa024 This is random bits of memory already as cmd length of previous wasnt right. -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Wed, 27 Jul 2005 21:53:14 +0200
Bellido Nicolas [EMAIL PROTECTED] wrote:
On Wednesday 27 July 2005 19:04, Aapo Tahkola wrote:
On Wed, 27 Jul 2005 12:25:27 +0200
Bellido Nicolas [EMAIL PROTECTED] wrote:
On Wednesday 27 July 2005 08:44, Aapo Tahkola wrote:
On Tue, 26 Jul 2005 14:18:10 +0200
You dont have two cards hooked up by any chance? :)
No, no handmade mobo with 2 agp slots :)
Does Xorg.0.log get the card right?
RADEON_PARAM_GART_BUFFER_OFFSET
Apparently yes, it does.
You probably want to check if microcode_version actually has any sane
value at radeon_cp_cmdbuf. Try something like:
printk(microcode_version %d\n, dev_priv-microcode_version);
return DRM_ERR(EINVAL);
Yeah, I was planning to do smthg like that.
But, how do you explain:
[drm:drm_ioctl] pid=9733, cmd=0x40106450, nr=0x50, dev 0xe200, auth=1
DRM_COMMAND_BASE + DRM_RADEON_CMDBUF == 0x50
[drm:radeon_cp_cmdbuf] RADEON_CMD_SCALARS2
cmd type 7 equals to R300_CMD_WAIT(from r300DoEmitState)
[drm:rRADEON_PARAM_GART_BUFFER_OFFSETadeon_cp_cmdbuf] *ERROR* bad
cmd_type 0 at e08fa024
This is random bits of memory already as cmd length of previous wasnt
right.
I meant I don't understand why there is a RADEON_CMD_SCALAR2 followed by the
*ERROR* message, without a drm_ioctl notice in between...
Possibly because the PID is different than for the other calls ?
Because it processes multiple packets:
while (cmdbuf.bufsz = sizeof(header)) {
header.i = *(int *)cmdbuf.buf;
cmdbuf.buf += sizeof(header);
cmdbuf.bufsz -= sizeof(header);
switch (header.header.cmd_type) {
--
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
Re: [Dri-users] X hangs when starting glxgears on r350
On Wed, 27 Jul 2005 23:38:57 +0200
Bellido Nicolas [EMAIL PROTECTED] wrote:
On Wednesday 27 July 2005 10:13, Jerome Glisse wrote:
On 7/27/05, Bellido Nicolas [EMAIL PROTECTED] wrote:
BTW, do you have any scenario where you are sure X will hang ??
Launch ut2003 or 2004 (don't remember which one) demos then start a game
(quick launch) and it will lockup during level loading or few second after
the intro begin...Other opengl apps do the same a flight simulator which
i didn't remember the name will lockup in the menu after few secs..
Btw if i try to resize or move glxgears i have a lockup, less often but
some times...
ut2k4 did the trick...
I get lockups during the mission breafing or shortly after beginning of intro.
Modprobing drm with debug=1, shows two cases:
. ut2004-bin does an DRM_IOCTL_DMA ioctl, but radeon_freelist_get, called by
radeon_cp_buffers returns NULL;
last_dispatch gets wrong value if buffer has more than one dma discard: (could
someone check this change in?)
Index: r300_cmdbuf.c
===
RCS file: /cvs/dri/drm/shared-core/r300_cmdbuf.c,v
retrieving revision 1.1
diff -u -b -B -u -r1.1 r300_cmdbuf.c
--- r300_cmdbuf.c 20 Jul 2005 21:17:47 - 1.1
+++ r300_cmdbuf.c 27 Jul 2005 20:43:50 -
@@ -623,7 +623,7 @@
drm_radeon_private_t *dev_priv = dev-dev_private;
drm_radeon_buf_priv_t *buf_priv = buf-dev_private;
- buf_priv-age = dev_priv-sarea_priv-last_dispatch+1;
+ buf_priv-age = ++dev_priv-sarea_priv-last_dispatch;
buf-pending = 1;
buf-used = 0;
}
@@ -788,8 +788,6 @@
if (emit_dispatch_age) {
RING_LOCALS;
- dev_priv-sarea_priv-last_dispatch++;
-
/* Emit the vertex buffer age */
BEGIN_RING(2);
RADEON_DISPATCH_AGE(dev_priv-sarea_priv-last_dispatch);
--
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
Re: r300 testing..
On Mon, 27 Jun 2005 01:57:56 +0200
Roland Scheidegger [EMAIL PROTECTED] wrote:
Ben Skeggs wrote:
S3TC does seem to be the killer for UT2004. I started porting over the
S3TC stuff from the r200 driver a while
back, but haven't had a lot of time recently to fix a couple of issues
with it. Overall fps doesn't seem to take a
huge gain, but the sudden drops to 1-2fps in certain levels
(CTF-Faceclassic) disappear when S3TC's enabled.
That's true, but to avoid the huge drops you could also just decrease
texture detail. Or implement the second texture heap in main memory and
use gart texturing (though you'd also need to manually increase the gart
size). There are some problems with that for r200, and the strategy for
what textures to put where may not be optimal currently, but the drops
should be gone.
That said, the performance in ut2k4 is probably really slow (apart from
that problem) due to deficiencies in drawArrays handling, at least that
was the case for r200 last time I checked...
First hack attempts to improve it.
Later two patches workaround RADEON_BUFFER_SIZE limit.
While this actually appears to work theres no speed boost in general.
--
Aapo Tahkola
Index: t_array_api.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/tnl/t_array_api.c,v
retrieving revision 1.52
diff -u -b -B -u -r1.52 t_array_api.c
--- t_array_api.c 18 Jul 2005 12:31:30 - 1.52
+++ t_array_api.c 27 Jul 2005 20:28:16 -
@@ -78,21 +78,20 @@
}
-/* Note this function no longer takes a 'start' value, the range is
- * assumed to start at zero. The old trick of subtracting 'start'
- * from each index won't work if the indices are not in writeable
- * memory.
- */
static void _tnl_draw_range_elements( GLcontext *ctx, GLenum mode,
+ GLuint min_index,
GLuint max_index,
GLsizei index_count, GLuint *indices )
{
TNLcontext *tnl = TNL_CONTEXT(ctx);
struct tnl_prim prim;
+ int i;
+ static int size=0;
+ static GLuint *ind=NULL;
FLUSH_CURRENT( ctx, 0 );
- _tnl_vb_bind_arrays( ctx, 0, max_index );
+ _tnl_vb_bind_arrays( ctx, min_index, max_index );
tnl-vb.Primitive = prim;
tnl-vb.Primitive[0].mode = mode | PRIM_BEGIN | PRIM_END;
@@ -100,8 +99,15 @@
tnl-vb.Primitive[0].count = index_count;
tnl-vb.PrimitiveCount = 1;
- tnl-vb.Elts = (GLuint *)indices;
+ if(index_count size){
+ size = index_count;
+ free(ind);
+ ind = malloc(index_count * sizeof(GLuint));
+ }
+ for(i=0; i index_count; i++)
+ ind[i] = indices[i] - min_index;
+ tnl-vb.Elts = ind;
tnl-Driver.RunPipeline( ctx );
}
@@ -297,20 +301,19 @@
* at the whole locked range.
*/
- if (start == 0 ctx-Array.LockFirst == 0
- end (ctx-Array.LockFirst + ctx-Array.LockCount))
-_tnl_draw_range_elements( ctx, mode,
+ if (end-start+1 (ctx-Array.LockFirst + ctx-Array.LockCount)){
+_tnl_draw_range_elements( ctx, mode, start,
ctx-Array.LockCount,
count, ui_indices );
- else {
+} else {
fallback_drawelements( ctx, mode, count, ui_indices );
}
}
- else if (start == 0 end ctx-Const.MaxArrayLockSize) {
+ else if (end-start+1 ctx-Const.MaxArrayLockSize) {
/* The arrays aren't locked but we can still fit them inside a
* single vertexbuffer.
*/
- _tnl_draw_range_elements( ctx, mode, end + 1, count, ui_indices );
+ _tnl_draw_range_elements( ctx, mode, start, end + 1, count, ui_indices );
}
else {
/* Range is too big to optimize:
@@ -352,7 +355,7 @@
if (ctx-Array.LockCount) {
if (ctx-Array.LockFirst == 0)
-_tnl_draw_range_elements( ctx, mode,
+_tnl_draw_range_elements( ctx, mode, 0,
ctx-Array.LockCount,
count, ui_indices );
else
@@ -361,16 +364,18 @@
else {
/* Scan the index list and see if we can use the locked path anyway.
*/
- GLuint max_elt = 0;
+ GLuint max_elt = 0, min_elt = ~0;
GLint i;
- for (i = 0 ; i count ; i++)
+ for (i = 0 ; i count ; i++){
if (ui_indices[i] max_elt)
max_elt = ui_indices[i];
-
- if (max_elt ctx-Const.MaxArrayLockSize /* can we use it? */
- max_elt (GLuint) count)/* do we want to use it? */
-_tnl_draw_range_elements( ctx, mode, max_elt+1, count, ui_indices );
+if (ui_indices[i] min_elt)
+min_elt = ui_indices[i];
+ }
+ if (max_elt-min_elt+1 ctx-Const.MaxArrayLockSize /* can we use it?
*/
+ max_elt-min_elt+1 (GLuint) count) /* do we want to use
it? */
+_tnl_draw_range_elements
Re: ATI commercial driver and software suspend
On Tue, 26 Jul 2005 13:37:02 -0700 Nguyen The Toan [EMAIL PROTECTED] wrote: You need a program called vbetool. This allows one to save and restore the graphic card state before suspending and after resuming. I wonder if this could be used to hunt down the r300 problem. -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Mon, 25 Jul 2005 08:59:53 +0200 Bellido Nicolas [EMAIL PROTECTED] wrote: On Monday 25 July 2005 00:47, Roland Scheidegger wrote: Bellido Nicolas wrote: When the radeon module is loaded, i get in the kernel logs: Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA KT880 chipset agpgart: AGP aperture is 128M @ 0xe000 [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt :01:00.0[A] - GSI 16 (level, low) - IRQ 16 [drm] Initialized radeon 1.16.0 20050311 on minor 0: ATI Technologies Inc Radeon R350 [Radeon 9800 Pro] This is just a shot in the dark, have you built the drm module too? The r300 driver needs a new version too. I don't know what would happen if you don't build it however, but it certainly wouldn't work. That's the version string I have in radeon_drv.c: $ grep 20050311 linux-core/radeon_drv.h #define DRIVER_DATE 20050311 Checked out yesterday from drm cvs on freedesktop.org. In case it helps, i just insmoded the drm module with debug=1. Here are the last lines ok kmsg. [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] pid=9684, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 [drm:radeon_freelist_get] done_age = 236 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=13 s=0 e=88 d=0 [drm:radeon_cp_dispatch_indirect] indirect: buf=13 s=0x0 e=0x58 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=13 s=88 e=104 d=1 [drm:radeon_cp_dispatch_indirect] indirect: buf=13 s=0x58 e=0x68 [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] pid=9684, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 [drm:radeon_freelist_get] done_age = 237 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=14 s=0 e=176 d=0 [drm:radeon_cp_dispatch_indirect] indirect: buf=14 s=0x0 e=0xb0 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=14 s=176 e=192 d=1 [drm:radeon_cp_dispatch_indirect] indirect: buf=14 s=0xb0 e=0xc0 [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] pid=9684, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 [drm:radeon_freelist_get] done_age = 238 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=15 s=0 e=124 d=0 [drm:radeon_cp_dispatch_indirect] indirect: buf=15 s=0x0 e=0x7c [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=15 s=128 e=144 d=1 [drm:radeon_cp_dispatch_indirect] indirect: buf=15 s=0x80 e=0x90 [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] pid=9684, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 [drm:radeon_freelist_get] done_age = 239 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=16 s=0 e=108 d=0 [drm:radeon_cp_dispatch_indirect] indirect: buf=16 s=0x0 e=0x6c [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=16 s=112 e=128 d=1 [drm:radeon_cp_dispatch_indirect] indirect: buf=16 s=0x70 e=0x80 [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] pid=9733, cmd=0x4008642a, nr=0x2a, dev 0xe200, auth=1 [drm:drm_lock] 3 (pid 9733) requests lock (0x0001), flags = 0x [drm:drm_lock] 3 has lock [drm:drm_ioctl] pid=9733, cmd=0x40106450, nr=0x50, dev 0xe200, auth=1 [drm:radeon_cp_cmdbuf] RADEON_CMD_SCALARS2 [drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type 0 at e08fa024 r300_do_cp_cmdbuf doesnt get called... -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 DRI report
On Wed, 13 Jul 2005 17:22:36 +0300
Aapo Tahkola [EMAIL PROTECTED] wrote:
Also, r300s state management is not currently very efficient as can be seen
from oprofiled reports... :)
Measured this and state traffic seems to go from 10 to 60 MB per second
depending on application.
Tnl programs give even higher rates in some cases.
Index: r300_cmdbuf.c
===
RCS file: /cvsroot/r300/r300_driver/r300/r300_cmdbuf.c,v
retrieving revision 1.44
diff -u -b -B -u -r1.44 r300_cmdbuf.c
--- r300_cmdbuf.c 27 Jun 2005 15:56:14 - 1.44
+++ r300_cmdbuf.c 14 Jul 2005 05:58:40 -
@@ -54,6 +54,7 @@
// Set this to 1 for extremely verbose debugging of command buffers
#define DEBUG_CMDBUF 0
+#include sys/time.h
/**
@@ -100,6 +101,28 @@
fprintf(stderr, Syncing in %s (from %s)\n\n, __FUNCTION__,
caller);
radeonWaitForIdleLocked(r300-radeon);
}
+ {
+ static struct timeval t;
+ struct timeval temp;
+ unsigned long msec;
+ static unsigned long bytes = 0;
+
+ bytes += cmd.bufsz;
+
+ gettimeofday(temp, NULL);
+ msec = (temp.tv_sec - t.tv_sec) * 100 + temp.tv_usec -
t.tv_usec;
+ if(msec 100){
+ float f = msec/100.0;
+ f = bytes / f;
+
+ fprintf(stderr, %.02f\n, f/1024.0/1024.0);
+ t = temp;
+ bytes = 0;
+ }
+
+ }
--
Aapo Tahkola
---
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ColorTiling issue on r420
On Thu, 14 Jul 2005 23:07:28 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Hi, With ColorTiling enabled I get gradual corruption og the desktop/screen on my X800 XT (AGP). 3D applications games are fine. the corruption happends during popups (menus etc.). I'm using the late CVS og r300_driver and Xorg. Any idea where to start debugging this? Does changing resolution fix it? Any differences in RADEON_CRTC_OFFSET_CNTL or RADEON_SURFACEx_INFO regs? It might be that there are some new bits for compressed fb. Also, some of the aligns are probably not right for r300 and up, though so far I havent seen nothing worse than slight texture corruption when moving 3d apps out of visible screen area. -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 DRI report
On Tue, 12 Jul 2005 21:33:16 +0200 Sander Sweers [EMAIL PROTECTED] wrote: On 12/07/05, Michel Dänzer [EMAIL PROTECTED] wrote: On Tue, 2005-07-12 at 13:06 +0200, Sander Sweers wrote: Well xscreensaver is horrible to do any tests with, I never get above the 25 fps :( Which hack(s) are you trying, and are you passing -delay 0? atlantis -root -whalespeed 458 -delay 0 -size 8350 -count 3 -gradient -fps Changed this for atlantis and it gave me 23fps instead of 3, thanks. I get 120 fps with color tiling on pretty much same hw as you and 1280x1024 resolution. Youll need to use xorg cvs and ColorTiling option to enable it. Blocktube will not go above 25fps, even with delay is 0. Only with -wireframe it will go to 32fps. It seems that something is wrong here as increasing/decreasing window size doesnt affect framerates at all. My guess so far would be that the command buffer gets too fed up and causes this bottleneck. Are there other hacks I can use? (-no-fog usually does not give more than 1 extra fps). Fog is not yet supported. -- Aapo Tahkola --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 DRI report
On Wed, 13 Jul 2005 13:27:31 +0200 Lorenzo Colitti [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: atlantis -root -whalespeed 458 -delay 0 -size 8350 -count 3 -gradient -fps Changed this for atlantis and it gave me 23fps instead of 3, thanks. I get 120 fps with color tiling on pretty much same hw as you and 1280x1024 resolution. Youll need to use xorg cvs and ColorTiling option to enable it. Yep, color tiling is a big win here. When I turned it on, ./atlantis -whalespeed 458 -delay 0 -size 8350 -count 3 -gradient -fps (not fulscreen) went from 10 FPS to ~200 FPS. I also get 1000 FPS in glxgears while before I used to get ~500. This is on a rage mobility 9600 M10 (RV350) on a Pentium M 1.4 GHz. Blocktube will not go above 25fps, even with delay is 0. Only with -wireframe it will go to 32fps. For reference, I get ~26 FPS with wireframe and ~19 without (not full screen). With no HW acceleration I get 7 FPS. It seems that something is wrong here as increasing/decreasing window size doesnt affect framerates at all. My guess so far would be that the command buffer gets too fed up and causes this bottleneck. Why should increasing window size affect framerates? I thought that as far as the graphics chip was concerned, a triangle was just a triangle irrespective of size, and we're not hitting fill rate limits here... or is there something I'm missing? AFAIK, hardware is usually done in a such way that pretty much everything is proportional to the master frequency. That said, less pixels should mean that it takes less clocks to get the job done. Also, r300s state management is not currently very efficient as can be seen from oprofiled reports... :) -- Aapo Tahkola --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
On Sat, 2 Jul 2005 08:57:17 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: we may not be able to prevent all such cases doesn't mean we shouldn't prevent the ones we can. Without VPU recovery, it is very likely that the prices would be too high to stand. I really mean 'the ones we can'. All I'm saying is that we should try to prevent it whenever reasonably possible and that the fact that it may not always be is IMHO a bad excuse for never trying. Im looking at the whole picture here. I dont really think we have enough manpower and interest of finishing this kind of boring task using the most difficult approach available. I would like to disagree with you both (Aapo and Michel) :) 1. In order to systematically prevent lockups we need to know what lockups the card is susceptible to. Right now we cannot even find a cause of particular lockup with Radeon 9800 cards, let alone be certain that any usage of particular registers is valid. We do know which registers control access to system memory and this we control tightly. 2. The issue of making sure no lockups exists will appear a lot less boring if put in a different context: Can we measure how long it takes the card to perform certain elementary operation and construct a model that would describe performance ? This is not a trivial task as we access the card through, essentially, a batch interface which would make it hard to time elementary operations by themselves with good precision (say 5% ?). Need to get past Mesas array caches and other funnies. To get to that we need true hw VBO's and we cannot even dream of them until Mesa allows us to support native unsigned char colors. Why bother with such project ? 1. Characterizing such a complex black-box device is not trivial and whatever automation techniques will be invented should prove useful for other things 2. Right now we ignore issues like sharing of memory bandwidth with CRTC or overlay. Knowing timing will allow to fine-tune the raw performance of the driver. 3. It would be interesting to see whether one can do real-time rendering - not in the sense of playing real-time game, but in the sense of issuing a drawing operation and knowing exactly when it completes. In advance? If not, scratch regs should take care of this pretty easily. -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
On Mon, 04 Jul 2005 17:12:17 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Sat, 2 Jul 2005 08:57:17 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: we may not be able to prevent all such cases doesn't mean we shouldn't prevent the ones we can. Without VPU recovery, it is very likely that the prices would be too high to stand. I really mean 'the ones we can'. All I'm saying is that we should try to prevent it whenever reasonably possible and that the fact that it may not always be is IMHO a bad excuse for never trying. Im looking at the whole picture here. I dont really think we have enough manpower and interest of finishing this kind of boring task using the most difficult approach available. I would like to disagree with you both (Aapo and Michel) :) 1. In order to systematically prevent lockups we need to know what lockups the card is susceptible to. Right now we cannot even find a cause of particular lockup with Radeon 9800 cards, let alone be certain that any usage of particular registers is valid. We do know which registers control access to system memory and this we control tightly. 2. The issue of making sure no lockups exists will appear a lot less boring if put in a different context: Can we measure how long it takes the card to perform certain elementary operation and construct a model that would describe performance ? This is not a trivial task as we access the card through, essentially, a batch interface which would make it hard to time elementary operations by themselves with good precision (say 5% ?). Need to get past Mesas array caches and other funnies. To get to that we need true hw VBO's and we cannot even dream of them until Mesa allows us to support native unsigned char colors. Mesa certainly doesn't stop you doing this - you just have to hook it out at the right level. Well I figured it might actually be good thing since ObjPtr and others point into right place for mapped objects and array cache would provide way to convert this data and pull it to system memory if driver wouldnt support ub colors. Things like the array cache are entirely optional - you don't have to use them in your driver, or not all the time. I havent really crawled myself trought the sources so I dont really know what would be the best way to actually go around this. Not to even mention that I dont really want to read 5 lines of code to get one feature supported. -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
On Mon, 4 Jul 2005 12:12:05 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: elementary operation and construct a model that would describe performance ? This is not a trivial task as we access the card through, essentially, a batch interface which would make it hard to time elementary operations by themselves with good precision (say 5% ?). Need to get past Mesas array caches and other funnies. To get to that we need true hw VBO's and we cannot even dream of them until Mesa allows us to support native unsigned char colors. One could just access the hardware directly for purposes of such measurement. Maybe but you might end up in writing code that isnt generally useful as I did. Attached patch is what I did and its really vapour ware if you ask me. -- Aapo Tahkola bench_hack.patch Description: Binary data
Re: [R300] drm driver: merge upstream, security, etc
On Fri, 01 Jul 2005 10:51:23 -0400 Michel Dänzer [EMAIL PROTECTED] wrote: On Fri, 2005-07-01 at 03:24 +0300, Aapo Tahkola wrote: On Sun, 26 Jun 2005 23:48:11 -0400 Michel Dänzer [EMAIL PROTECTED] wrote: On Sun, 2005-06-26 at 18:05 -0700, Eric Anholt wrote: On Mon, 2005-06-27 at 01:19 +0100, Alan Cox wrote: Disagree also about axing the comment - its useful to know why something is being done. Wait, the comment says TODO: Remove this; we can't afford to let userspace control something that locks up the graphics card so easily. We're not removing the code being referred to, as far as I've heard, and we can't afford is contradictory to what we have agreed on for DRI policy (drivers can't escalate privelege, but can hang the machine). When did this 'agreement' occur? I can't remember agreeing to that. That we may not be able to prevent all such cases doesn't mean we shouldn't prevent the ones we can. Without VPU recovery, it is very likely that the prices would be too high to stand. I really mean 'the ones we can'. All I'm saying is that we should try to prevent it whenever reasonably possible and that the fact that it may not always be is IMHO a bad excuse for never trying. Im looking at the whole picture here. I dont really think we have enough manpower and interest of finishing this kind of boring task using the most difficult approach available. -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
On Sun, 26 Jun 2005 23:48:11 -0400 Michel Dänzer [EMAIL PROTECTED] wrote: On Sun, 2005-06-26 at 18:05 -0700, Eric Anholt wrote: On Mon, 2005-06-27 at 01:19 +0100, Alan Cox wrote: Disagree also about axing the comment - its useful to know why something is being done. Wait, the comment says TODO: Remove this; we can't afford to let userspace control something that locks up the graphics card so easily. We're not removing the code being referred to, as far as I've heard, and we can't afford is contradictory to what we have agreed on for DRI policy (drivers can't escalate privelege, but can hang the machine). When did this 'agreement' occur? I can't remember agreeing to that. That we may not be able to prevent all such cases doesn't mean we shouldn't prevent the ones we can. Without VPU recovery, it is very likely that the prices would be too high to stand. And as long as we dont have that, we dont know how well it works and there is very little point in blocking anything. -4f18 is basicly needed whenever touching Z related registers -4e4c is needed when touching color buffer related registers -2284 is needed before programming vertex programs _and_ maybe before touching VAP registers -different types of 1720's are needed when touching some other regs R300_WAIT_3D | R300_WAIT_3D_CLEAN in r300DoEmitState takes care of mergedfb problems in case someone missed that. As far as iv understood these are needed only if you modify stated after packet3. -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
