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 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.php&p=sourceforge&CID=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 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.php&p=sourceforge&CID=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=lnk&kid=120709&bid=263057&dat=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=lnk&kid=120709&bid=263057&dat=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=1162&sid=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=lnk&kid=120709&bid=263057&dat=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=lnk&kid=120709&bid=263057&dat=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=lnk&kid=120709&bid=263057&dat=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=lnk&kid=120709&bid=263057&dat=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=lnk&kid=120709&bid=263057&dat=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=lnk&kid=120709&bid=263057&dat=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=lnk&kid=120709&bid=263057&dat=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.php&p=sourceforge&CID=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-devel&m=114855685402158&w=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=lnk&kid=120709&bid=263057&dat=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 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, 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 + ] where addr.x + > > > "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 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 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: 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 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
#include
#include
#include
#include
#define GL_GLEXT_PROTOTYPES
#include
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.m
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: 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: 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 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=lnk&kid=107521&bid=248729&dat=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=lnk&kid=107521&bid=248729&dat=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=lnk&kid=120709&bid=263057&dat=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=lnk&kid=110944&bid=241720&dat=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 +0000, 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.7&r2=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=lnk&kid=110944&bid=241720&dat=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 +0000, 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.7&r2=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=lnk&kid=110944&bid=241720&dat=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=lnk&kid=110944&bid=241720&dat=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=lnk&kid=110944&bid=241720&dat=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=lnk&kid=110944&bid=241720&dat=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=lnk&kid=110944&bid=241720&dat=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=lnk&kid=110944&bid=241720&dat=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=lnk&kid=110944&bid=241720&dat=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=lnk&kid=110944&bid=241720&dat=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 21:58:50 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: > Aapo Tahkola wrote: > > On Fri, 10 Mar 2006 18:27:51 +0100 > > Rune Petersen <[EMAIL PROTECTED]> wrote: > > > >>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? > Yes I did but a different kind, flashing "tiles" of colors on the > texture. was fix with clear cache patch ( this was also reported by others). > > > > > >>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. > > > 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. -- 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=lnk&kid=110944&bid=241720&dat=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=lnk&kid=110944&bid=241720&dat=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=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Lockups
On Thu, 02 Mar 2006 09:27:37 +0100 Christoph Brill <[EMAIL PROTECTED]> wrote: > Hi list, > > I'm still seeing lots of lockups with my r300 (Radeon 9700Pro) with > current drm/mesa/xf86-video-ati cvs. I think I found a reproducable > lockup. It happens when I use Wings3d[1] (a free modeller). Wings has a > grid for orientation when I move around the camera it works fine. But as > soon as the grid hits the borders of the window, my system locks up. I'm > not 100% sure so if anyone else can reproduce this it would be great. As long as it gets solved by initializing the card with fglrx, I don't see any point in investigating. Does it lock only if you hit upper or lower bound of screen? -- 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=lnk&kid=110944&bid=241720&dat=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=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Benchmarks.
On Thu, 9 Mar 2006 16:44:07 + (UTC) Jeff Muizelaar <[EMAIL PROTECTED]> wrote: > Aapo Tahkola rasterburn.org> writes: > > > > > 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. > > > > What needs to be done to add support for this on r200? r200 doesnt have any free scratch regs so that needs to be fixed first. I haven't looked at this but I can see that fourth reg doesn't work on r300 out of the box. After that you can get USER_BUFFERS working and tested. Rest is just porting r200 to use radeon_vertex_buffer(ill write routines to do vertex_buffer->radeon_vertex_buffer) and making sure idx bufs work. -- 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=lnk&kid=110944&bid=241720&dat=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=lnk&kid=110944&bid=241720&dat=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 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. -- 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=lnk&kid=110944&bid=241720&dat=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=lnk&kid=110944&bid=241720&dat=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 Wed, 01 Mar 2006 20:58:49 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: > I made a mistake, and did not use clean Mesa source. > > sorry about the noise. > > with: > int future_hw_tcl_on=1; > int hw_tcl_on=1; > > nwn: > Texture corruption (random changing garbage) on some > items/doors. this > corruption will bleed into other games started after nwn is closed (like > Quake3). > This is an improvement over the lockup I get without the > patch.( it > did lockup once) > > Quake3: > No corruption. the mirror and teleport is still partly broken, > but no > corruption. > > with: > int future_hw_tcl_on=0; > int hw_tcl_on=0; > > nwn: > No corruption. > > Quake3: > map0: Texture corruption (random changing garbage). this > corruption > will bleed into other games started after Quake3 is closed. > http://megahurts.dk/rune/stuff/shot0003.jpg I dont see anything wrong with that shot. Does it change if you look from different angle? If it changes all the time, id say you have gart overlapping with fb. -- 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=lnk&kid=110944&bid=241720&dat=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=lnk&kid=110944&bid=241720&dat=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=lnk&kid=110944&bid=241720&dat=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=lnk&kid=103432&bid=230486&dat=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=lnk&kid=103432&bid=230486&dat=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=lnk&kid3432&bid#0486&dat1642 -- ___ 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=lnk&kid=103432&bid=230486&dat=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 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=lnk&kid=103432&bid=230486&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 - problem with fragment program
On Thu, 26 Jan 2006 16:58:49 +0200 Boris Peterbarg <[EMAIL PROTECTED]> wrote: > Hi, > I've been trying to run project xenocide(projectxenocide.com), but at > the start of it there's a ps20 shader which always causes a crash. > Setting "USE_ARB_F_P == 0" in r300_context.c makes the program run. > I'm using current mesa and drm(1.2) > The error I get is: > drmRadeonCmdBuffer: -22 (exiting) > > And in dmesg: > [drm:r300_emit_carefully_checked_packet0] *ERROR* Cannot emit more than > 64 values at a time (reg=4c00 sz=68) > [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed USE_ARB_F_P == 0 path has not been updated in a while and in prior to fixing Marbleblast, its going to disappear completely. Even if it would work you would have more problems than with texenvprogram.c path. What do we need to support ps20 ? -- 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=lnk&kid=103432&bid=230486&dat=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=lnk&kid=103432&bid=230486&dat=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=lnk&kid=103432&bid=230486&dat=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=lnk&kid=103432&bid=230486&dat=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=7637&alloc_id=16865&op=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 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=7637&alloc_id=16865&op=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=7637&alloc_id=16865&op=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 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=7637&alloc_id=16865&op=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=7637&alloc_id=16865&op=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_idv37&alloc_id865&op=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_idv37&alloc_id865&op=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=7637&alloc_id=16865&op=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=7637&alloc_id=16865&op=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. >
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 (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 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 (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
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] 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
[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: "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] 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 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: 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: [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 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 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 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-dev&m=01398019810&w=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=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220050168472%22.PGNR.&OS=DN/20050168472&RS=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=212199&page=1&pp=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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 testing..
On Thu, 28 Jul 2005 00:38:38 +0200 Roland Scheidegger <[EMAIL PROTECTED]> wrote: > Aapo Tahkola wrote: > >>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. > > That's what I found out some time ago as well, I did pretty similar > changes (basically bring back that start value). Once upon a time I also > had a hack so mesa could handle GL_UNSIGNED_SHORT elements lists > natively (no more converting them with _ac_import_elements to > UNSIGNED_INT and later back to shorts again in the driver) without any > success neither. > I never really found out why the old mesa code was 2 times faster :-(. First patch is working alright. without(ut2k3, citadel): 7.339034 / 20.030720 / 164.477829 fps -- Score = 19.973906 rand[1492594185] and with: 11.727319 / 31.931662 / 223.457932 fps -- Score = 31.496284 rand[31108770] What I dont know is why dma_ext doesnt speed up things where fallback_drawarrays would clearly get lots of hits. -- 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_elem
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: [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 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=7477&alloc_id=16492&op=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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
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=7477&alloc_id=16492&op=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=7477&alloc_id=16492&op=click -- ___ 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=7477&alloc_id=16492&op=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
/**
@@ -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
