Re: [R300] the_perfect_frag snapshot
On Mon, May 23, 2005 at 01:37:10PM +0200, Dario Laera wrote: I'm doing some test with this driver, and I read on the website that Radeon 9600 (including Radeon Mobility M10) - works well, no lockups... well, not for me :P Exactly, I can play almost every 3d game avaible for linux/PPC, but I get lockups when not in full screen mode. In window mode moving the mouse is a risk, from glxgears to neverball. I remember this problem was discussed some time ago on this list, but don't seems fixed for me. Thought I'd give this code a whirl on the Albook. (Radeon Mobility M10) After the initial install, I saw exactly the above -- immediate lockup a second or so after starting glxgears. However, after a reboot, it's been perfectly stable ever since, both in windowed and full screen mode, with every 3D app I've been able to try. Which isn't many unfortunately, since the unstable Ubuntu release I've got on there is in the middle of a C++ ABI transition none of the packages that depend on libglu1 will install at the moment. So far I've only managed to try glxgears, the rss-glx screensavers and neverball, but all seem to be entirely stable. Only slight problem is that the current Xorg CVS seems prone to crashing via double frees on VT switch, but that's unlikely not the dri code's fault I guess. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] the_perfect_frag snapshot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vladimir Dergachev wrote: I tagged yesterday the_perfect_frag snapshot of R300 driver. The code is in CVS at http://r300.sf.net As the name suggests I cannot find visible faults with rendering Quake3 levels. Also, PPRacer shows no artifacts either, at least in the first few levels.. Today's CVS worked quite well on my 9600 Pro playing Legends [1], although the ground was blue when it should've been brown. Also the main menu has a ton of blue stripes across the bottom. The UT2003 demo crashed when I tried to load the DM-Asbestos level, but everything else looked good. The UT2004 demo crashed when trying to start either the AS-Convoy or BR-Colossus levels. The others were pretty much unplayably slow but looked great. The Doom 3 demo wouldn't even start. On America's Army, the text was almost unreadable (but I see this on the TODO). Also, the clouds overhead and straight ahead on the first training mission looked like square boxes. Thanks, Donnie 1. http://www.legendsthegame.net/ but it's down atm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCmCOKXVaO67S1rtsRAi3AAKDC/XvUBcre0F5U14gncC9SdjiwQwCfYQnT VCRC3vojRTSZ8eC7zhQSJQQ= =Rv0Z -END PGP SIGNATURE- --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] the_perfect_frag snapshot
oops.. cc-ing dri-devel this time. Donnie Berkholz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vladimir Dergachev wrote: I tagged yesterday the_perfect_frag snapshot of R300 driver. The code is in CVS at http://r300.sf.net As the name suggests I cannot find visible faults with rendering Quake3 levels. Also, PPRacer shows no artifacts either, at least in the first few levels.. Today's CVS worked quite well on my 9600 Pro playing Legends [1], although the ground was blue when it should've been brown. Also the main menu has a ton of blue stripes across the bottom. Are you using the latest Mesa CVS aswell? UT2004 had similar issues before support for ATI_texture_env_combine3 was added to the texenv generation stuff. The UT2003 demo crashed when I tried to load the DM-Asbestos level, but everything else looked good. The UT2004 demo crashed when trying to start either the AS-Convoy or BR-Colossus levels. The others were pretty much unplayably slow but looked great. After the crash, on the console did you see a message to the effect of Aiii AOS Array count exceeded? I saw this in a number of UT2004 levels. I bumped the maximum from 8 to 16, and AS-Convoy/BR-Colossus seem to start okay. I don't have ut2003 handy to test with, I'll see if ut2003-demo is in portage later on. The Doom 3 demo wouldn't even start. Doom3 retail requires ARB_texture_cube_map, which I've disabled as I don't think we support it properly yet, and it causes some problems with ut2k4. You can re-enable it by uncommenting the line at the top of r300_context.c. Doom3 seems to run okay with the ARB rendering path. Starts okay with R200 and ARB2 paths, but in-game crashes with an unknown fragment program opcode.. According to the output it's an NV_fragment_program opcode, and we're not advertising that extension.. Ben Skeggs. On America's Army, the text was almost unreadable (but I see this on the TODO). Also, the clouds overhead and straight ahead on the first training mission looked like square boxes. Thanks, Donnie 1. http://www.legendsthegame.net/ but it's down atm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCmCOKXVaO67S1rtsRAi3AAKDC/XvUBcre0F5U14gncC9SdjiwQwCfYQnT VCRC3vojRTSZ8eC7zhQSJQQ= =Rv0Z -END PGP SIGNATURE- --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: SIGSEGV in r200 when called by JOGL (Java for OpenGL)
Philipp! Vielen Dank. Philipp Klaus Krause wrote: Nik schrieb: It's unlikely that you'll have to debug the kernel module. The bug probably is is the DRI. Ok, thanks. Any tips on what I should be looking for in the DRI? If the problem is in the DRI, then does that it mean it should affect cards/drivers other than r200? I don't remember any r200 version which worked with jogl. The version that came with the 2.4.29 worked for me (at least more than it is now). (I downloaded the 2.4.29 kernel source and build it myself). Cheers! Nik --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: SIGSEGV in r200 when called by JOGL (Java for OpenGL)
Nik schrieb: Philipp! Vielen Dank. Philipp Klaus Krause wrote: Nik schrieb: It's unlikely that you'll have to debug the kernel module. The bug probably is is the DRI. Ok, thanks. Any tips on what I should be looking for in the DRI? If the problem is in the DRI, then does that it mean it should affect cards/drivers other than r200? No. The structure of the drivers is about this: The card-speciifc module in the kernel, which is used by the card specific driver part in the DRI. DRI is in the Mesa tree, which also contains the non card-specific stuff: Basically there is the Mesa software implementation and the DRI drivers replace some parts of that with hardware-specific functionality. If I remeber correctly, the problem does not affect Mesa software rendering. Thus it should be in the r200 specififc part. That lives in Mesa/src/mesa/drivers/dri/r200. Philipp --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: SIGSEGV in r200 when called by JOGL (Java for OpenGL)
Phillip! Nochmal vielen Dank. Entschuldigen sie mir auch bitte dass ich so wenig weiss dass ich immer noch neue Fragen stellen muessen. Philipp Klaus Krause wrote: Nik schrieb: If I remeber correctly, the problem does not affect Mesa software rendering. Thus it should be in the r200 specififc part. That lives in Mesa/src/mesa/drivers/dri/r200. ...which brings me to the next point: Presumably, I should be testing/debugging this in a recent version of the DRI source? But which one? Should I be checking out from CVS? Or is it acceptable for me to work with the source of my distro (2.6.11-1.14_FC3)? And could someone please point me to a document that explains how I should proceed to update my machine to the correct DRI version? I tried to update to a number of newer versions of DRI, but I always get symbol missing and/or symbol mismatch errors. Tscheurr! Nik --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: SIGSEGV in r200 when called by JOGL (Java for OpenGL)
Philipp Klaus Krause wrote: Nik schrieb: Oh ok. So in terms of names, the structure is: The card-speciifc module in the kernel == radeon the card specific driver part in the DRI. == r200 correct? Ok, so the r200 driver is actually not a kernel module, but is a driver used by the DRI library? Well, that sounds like it should make things easier - hopefully that is the case. The folks at JOGL indicated the problem could be due to JOGL making extensive of threads. Does that sound like a good plasce to start the investigation, or would you suggest I just start tracing back from the exception? Thank you again for all your help :o) Cheers! Nik --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: SIGSEGV in r200 when called by JOGL (Java for OpenGL)
Nik schrieb: Philipp Klaus Krause wrote: Nik schrieb: Oh ok. So in terms of names, the structure is: The card-speciifc module in the kernel == radeon the card specific driver part in the DRI. == r200 correct? Yes. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: SIGSEGV in r200 when called by JOGL (Java for OpenGL)
Nik schrieb: ...which brings me to the next point: Presumably, I should be testing/debugging this in a recent version of the DRI source? But which one? Should I be checking out from CVS? Or is it acceptable for me to work with the source of my distro (2.6.11-1.14_FC3)? And could someone please point me to a document that explains how I should proceed to update my machine to the correct DRI version? I tried to update to a number of newer versions of DRI, but I always get symbol missing and/or symbol mismatch errors. For the DRI you should use the latest CVS version. For the Xorg or XFree you can keep your distributions version. For the DRM use the one from CVS or from a recent kernel. You 2.6.11 should be fine. Build instructions are at http://dri.freedesktop.org/wiki/Building It should be enough to install the 3D drivers as described in that document in section 1.8. Philipp --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: SIGSEGV in r200 when called by JOGL (Java for OpenGL)
On Sat, 2005-05-28 at 20:07 +1000, Nik wrote: The folks at JOGL indicated the problem could be due to JOGL making extensive of threads. Does that sound like a good plasce to start the investigation, or would you suggest I just start tracing back from the exception? That's usually a good idea indeed. Beware that you should run gdb via ssh from a different machine as otherwise you'll lose control if execution stops while the hardware lock is held. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 2048x2048 texture corruption
Roland Scheidegger wrote: Rune Petersen wrote: Michel Dnzer wrote: On Fri, 2005-05-27 at 20:48 +0200, Rune Petersen wrote: Hi, One more for good messure. 2048x2048 texturer are corrupted. half (1024x2048) is correct, the rest is random data from memory. Not being familiar with the r300 code, I can only guess, but it sounds like the r300 driver still always uses a 1-byte format for texture uploads and hits the size limit of the 2D engine. This was changed for the other Radeon drivers when support for texture tiling was added. Can you tell me when this was added? (might give me some ideas) Before the texture tiling stuff (2005-02-10) when this code was changed to no longer use always a 1-byte format there already was an easier fix for exactly that problem, which still used 1-byte formats but incremented the offset (2004-10-07). That hack doesn't work, x (and y) for the image is 0, whick makes no impact on the offset. It's bug #960. Rune Petersen --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3217] Computer hangs during X.org shutdown. I get bad page state at __free_pages_ok if I /etc/init.d/xdm stop. i915 glx xorg 6.8.99.3
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3217 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3217] Computer hangs during X.org shutdown. I get bad page state at __free_pages_ok if I /etc/init.d/xdm stop. i915 glx xorg 6.8.99.3
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3217 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-05-28 13:38 --- Committed. Thanks for cleaning up after my mess :/ -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2673] Missing memset lets setversion ioctl corrupt memory.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2673 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-05-28 13:41 --- Committed on 2005/03/08 by airlied. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM depends on ???
On Sat, May 28, 2005 at 11:39:00PM +0200, Geert Uytterhoeven wrote: DRM depending on `AGP=n' is driving me crazy! How to make CONFIG_DRM not eligible for selection on platforms that do not have AGP? Since many of the core DRM files depend on PCI, add a dependency on PCI, to minimize the damage. Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED] --- linux-2.6.12-rc5/drivers/char/drm/Kconfig2005-05-25 19:37:53.0 +0200 +++ linux-m68k-2.6.12-rc5/drivers/char/drm/Kconfig 2005-04-05 10:12:41.0 +0200 @@ -6,7 +6,7 @@ # config DRM tristate Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) -depends on AGP || AGP=n +depends on (AGP || AGP=n) PCI The whole dependancy seems like nonsense to me. I think depends on PCI is a lot more sensible. Dave --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patches] Re: r300 radeon 9800 lockup
On 5/28/05, Nicolai Haehnle [EMAIL PROTECTED] wrote: Hi everybody, I once again tripped upon an R300 lockup (possibly the same one that everybody's been talking about) and spent the last one and half days chasing it down. It turns out that writing the vertex buffer age to scratch registers (the ones that are written back to main memory) during a 3D sequence is a bad idea. Apparently, this confuses the memory controller so much that some part of the engine locks up hard. The attached patch.out-of-loop-dispatch-age fixes this, at least for me. The attached patch.remove-userspace-pacifiers removes additional unnecessary emission of the pacifier sequence from the userspace driver. Userspace isn't supposed to emit this sequence anyway. Could everybody please test whether a) the first patch really does fix the lockups people are seeing and b) whether combining both the first and the second patch causes any regressions. If everything's fine with these patches, I'm going to commit them in a few days or so. Seems you are on the good path :) with the first patch i can play quake3 a little bit more (without it i get a lock within a minute or so). Ut2004 lockup too but at least now i can see the menu... If i apply the second patch it leads me to the past situation, a quick lockup... Jerome Glisse --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patches] Re: r300 radeon 9800 lockup
Morning,
After playing UT2004 for 10 or so minutes, and then quickly checking
some other
apps known to worn, I see no regressions with either patch.
I'll be putting it through some more rigorous testing as the day
progresses, will
report back if I find anything.
Also, out of interest, what triggered the lockup you saw?
-Ben.
Nicolai Haehnle wrote:
Hi everybody,
I once again tripped upon an R300 lockup (possibly the same one that
everybody's been talking about) and spent the last one and half days
chasing it down.
It turns out that writing the vertex buffer age to scratch registers (the
ones that are written back to main memory) during a 3D sequence is a bad
idea. Apparently, this confuses the memory controller so much that some
part of the engine locks up hard.
The attached patch.out-of-loop-dispatch-age fixes this, at least for me.
The attached patch.remove-userspace-pacifiers removes additional unnecessary
emission of the pacifier sequence from the userspace driver. Userspace
isn't supposed to emit this sequence anyway.
Could everybody please test whether
a) the first patch really does fix the lockups people are seeing and
b) whether combining both the first and the second patch causes any
regressions.
If everything's fine with these patches, I'm going to commit them in a few
days or so.
cu,
Nicolai
Index: drm/shared-core/r300_cmdbuf.c
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/r300_cmdbuf.c,v
retrieving revision 1.22
diff -u -3 -p -r1.22 r300_cmdbuf.c
--- drm/shared-core/r300_cmdbuf.c 28 May 2005 05:18:42 - 1.22
+++ drm/shared-core/r300_cmdbuf.c 28 May 2005 20:56:59 -
@@ -487,21 +487,19 @@ static __inline__ void r300_pacify(drm_r
}
+/**
+ * Called by r300_do_cp_cmdbuf to update the internal buffer age and state.
+ * The actual age emit is done by r300_do_cp_cmdbuf, which is why you must
+ * be careful about how this function is called.
+ */
static void r300_discard_buffer(drm_device_t * dev, drm_buf_t * buf)
{
-drm_radeon_private_t *dev_priv = dev-dev_private;
-drm_radeon_buf_priv_t *buf_priv = buf-dev_private;
-RING_LOCALS;
-
-buf_priv-age = ++dev_priv-sarea_priv-last_dispatch;
-
-/* Emit the vertex buffer age */
-BEGIN_RING(2);
-RADEON_DISPATCH_AGE(buf_priv-age);
-ADVANCE_RING();
+ drm_radeon_private_t *dev_priv = dev-dev_private;
+ drm_radeon_buf_priv_t *buf_priv = buf-dev_private;
-buf-pending = 1;
-buf-used = 0;
+ buf_priv-age = dev_priv-sarea_priv-last_dispatch+1;
+ buf-pending = 1;
+ buf-used = 0;
}
@@ -518,6 +516,7 @@ int r300_do_cp_cmdbuf(drm_device_t* dev,
drm_radeon_private_t *dev_priv = dev-dev_private;
drm_device_dma_t *dma = dev-dma;
drm_buf_t *buf = NULL;
+ int emit_dispatch_age = 0;
int ret = 0;
DRM_DEBUG(\n);
@@ -608,14 +607,15 @@ int r300_do_cp_cmdbuf(drm_device_t* dev,
goto cleanup;
}
- r300_discard_buffer(dev, buf);
+ emit_dispatch_age = 1;
+ r300_discard_buffer(dev, buf);
break;
case R300_CMD_WAIT:
/* simple enough, we can do it here */
DRM_DEBUG(R300_CMD_WAIT\n);
if(header.wait.flags==0)break; /* nothing to do */
-
+
{
RING_LOCALS;
@@ -639,6 +639,24 @@ int r300_do_cp_cmdbuf(drm_device_t* dev,
cleanup:
r300_pacify(dev_priv);
+
+ /* We emit the vertex buffer age here, outside the pacifier brackets
+* for two reasons:
+* (1) This may coalesce multiple age emissions into a single one and
+* (2) more importantly, some chips lock up hard when scratch registers
+* are written inside the pacifier bracket.
+*/
+ 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);
+ ADVANCE_RING();
+ }
+
COMMIT_RING();
return ret;
Index: r300/r300_render.c
===
RCS file: /cvsroot/r300/r300_driver/r300/r300_render.c,v
retrieving revision 1.87
diff -u -3 -p -r1.87 r300_render.c
--- r300/r300_render.c 19 May 2005 00:03:52 - 1.87
+++ r300/r300_render.c 28 May 2005 20:49:43 -
@@ -489,23 +489,18 @@ static GLboolean r300_run_vb_render(GLco
struct vertex_buffer *VB = tnl-vb;
int i, j;
LOCAL_VARS
Re: [r300] 2048x2048 texture corruption
Rune Petersen wrote: Roland Scheidegger wrote: Rune Petersen wrote: Michel Dnzer wrote: On Fri, 2005-05-27 at 20:48 +0200, Rune Petersen wrote: Hi, One more for good messure. 2048x2048 texturer are corrupted. half (1024x2048) is correct, the rest is random data from memory. Not being familiar with the r300 code, I can only guess, but it sounds like the r300 driver still always uses a 1-byte format for texture uploads and hits the size limit of the 2D engine. This was changed for the other Radeon drivers when support for texture tiling was added. Can you tell me when this was added? (might give me some ideas) Before the texture tiling stuff (2005-02-10) when this code was changed to no longer use always a 1-byte format there already was an easier fix for exactly that problem, which still used 1-byte formats but incremented the offset (2004-10-07). That hack doesn't work, x (and y) for the image is 0, whick makes no impact on the offset. It's bug #960. Ah yes, I remember now, it only affected mip-maps. I think though the maximum size anyone tested there was only 2048x1024, not 2048x2048, so in fact the fix maybe wouldn't have worked on such 2048x2048x4 textures without mipmpas neither. I don't think that size actually gets ever announced on any radeon (r100/r200) card as the driver can only handle 128MB, with the crappy memory management only 70MB or so will be available for textures which isn't enough to fit 4 (the default amount of texture units announced) such textures with mipmaps, though you may get that size announced with configuration. The new code should work however in any case. Roland --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] DRM depends on ???
DRM depending on `AGP=n' is driving me crazy! How to make CONFIG_DRM not
eligible for selection on platforms that do not have AGP?
Since many of the core DRM files depend on PCI, add a dependency on PCI,
to minimize the damage.
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
--- linux-2.6.12-rc5/drivers/char/drm/Kconfig 2005-05-25 19:37:53.0
+0200
+++ linux-m68k-2.6.12-rc5/drivers/char/drm/Kconfig 2005-04-05
10:12:41.0 +0200
@@ -6,7 +6,7 @@
#
config DRM
tristate Direct Rendering Manager (XFree86 4.1.0 and higher DRI
support)
- depends on AGP || AGP=n
+ depends on (AGP || AGP=n) PCI
help
Kernel-level support for the Direct Rendering Infrastructure (DRI)
introduced in XFree86 4.0. If you say Y here, you need to select
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM depends on ???
On May 28, 2005, at 17:50:05, Dave Jones wrote: On Sat, May 28, 2005 at 11:39:00PM +0200, Geert Uytterhoeven wrote: config DRM tristate Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) -depends on AGP || AGP=n +depends on (AGP || AGP=n) PCI The whole dependancy seems like nonsense to me. I think depends on PCI is a lot more sensible. I think the original reasoning was something like this: If DRM is built-in, then AGP _must_ be built-in or not included at all, modular won't work. If DRM is modular or not built, then AGP may be built- in, modular, or not built at all. The depends on AGP || AGP=n means that if DRM=y, then AGP=y or AGP=n, and if DRM=m or DRM=n, then AGP=y or AGP=m or AGP=n. Yes it's unclear and yes it should probably be documented in a comment somewhere. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C$ UB/L/X/*(+)$ P+++()$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e-$ h!*()++$ r !y?(-) --END GEEK CODE BLOCK-- --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
