Re: r300 on Thinkpad r50p (RV350)
On Wed, 29 Jun 2005 22:07:35 -0400
Alex Deucher [EMAIL PROTECTED] wrote:
On 6/29/05, Roland Scheidegger [EMAIL PROTECTED] wrote:
Hamish Marson wrote:
Fixed it.
Sorry. It isn't an r300 problem... Or at least doesn't LOOK like an
r300 problem. I changed the xorg.conf set
Option EnablePageFlip on # [bool]
to
Option EnablePageFlip off # [bool]
and the flickering went away...
PageFlip should work usually on radeons (there can be issues when you
use it together with tiling, see
https://bugs.freedesktop.org/show_bug.cgi?id=2604), but since the r300
driver doesn't support tiling yet...
Though I don't know if pageflip is actually supposed to work on r300
based cards currently, I don't think there should be differences to the
other radeons in that area.
I just added tiling support for r3/4xx cards to xorg cvs.
Nice!
Couple fixes to get depth reads/writes working with 16 and 32 bit depth buffers:
diff -uNr ati/radeon_driver.c ati..s/radeon_driver.c
--- ati/radeon_driver.c Thu Jun 30 05:51:54 2005
+++ ati..s/radeon_driver.c Thu Jun 30 06:06:49 2005
@@ -6110,8 +6110,13 @@
depth_pattern = RADEON_SURF_TILE_DEPTH_16BPP;
else
depth_pattern = RADEON_SURF_TILE_DEPTH_32BPP;
-}
-else {
+} else if (IS_R300_VARIANT){
+ color_pattern = R300_SURF_TILE_COLOR_MACRO;
+ if (cpp == 2)
+ depth_pattern = R300_SURF_TILE_COLOR_MACRO;
+ else
+ depth_pattern = R300_SURF_TILE_COLOR_MACRO |
R300_SURF_TILE_DEPTH_32BPP;
+} else {
/* no idea about R300, just set it up the same as r200
if someone is crazy enough to try... */
color_pattern = R200_SURF_TILE_COLOR_MACRO;
@@ -6175,7 +6180,12 @@
drmRadeonSurfaceAlloc drmsurfalloc;
drmsurfalloc.size = bufferSize;
drmsurfalloc.address = info-depthOffset;
- drmsurfalloc.flags = swap_pattern | (width_bytes / 16) |
depth_pattern;
+
+ if (IS_R300_VARIANT)
+ drmsurfalloc.flags = swap_pattern | (width_bytes / 8) |
depth_pattern;
+ else
+ drmsurfalloc.flags = swap_pattern | (width_bytes / 16) |
depth_pattern;
+
retvalue = drmCommandWrite(info-drmFD, DRM_RADEON_SURF_ALLOC,
drmsurfalloc, sizeof(drmsurfalloc));
if (retvalue 0)
diff -uNr ati/radeon_reg.h ati..s/radeon_reg.h
--- ati/radeon_reg.hThu Jun 30 05:51:53 2005
+++ ati..s/radeon_reg.h Thu Jun 30 06:06:53 2005
@@ -1314,6 +1314,9 @@
# define R200_SURF_TILE_COLOR_BOTH(3 16)
# define R200_SURF_TILE_DEPTH_32BPP (4 16)
# define R200_SURF_TILE_DEPTH_16BPP (5 16)
+# define R300_SURF_TILE_NONE (0 16)
+# define R300_SURF_TILE_COLOR_MACRO (1 16)
+# define R300_SURF_TILE_DEPTH_32BPP (2 16)
# define RADEON_SURF_AP0_SWP_16BPP(1 20)
# define RADEON_SURF_AP0_SWP_32BPP(1 21)
# define RADEON_SURF_AP1_SWP_16BPP(1 22)
Please note that I havent tested this with current xorg cvs because of various
inconveniences.
What about the 2560 limit?
I noticed that with the new RADEONDoAdjustFrame I can have 1280x1024-1280x1024
setup if I remove the limits.
Pageflipping won't work for r300 until the sarea and drm are updated
to handle the additional xytiling regs.
I fixed couple of things with it and it should now work.
Its not very stable at least with tiling enabled(havent tested without) though
im afraid.
--
Aapo Tahkola
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300-commit] r300_driver/r300 r300_reg.h,1.44,1.45 r300_state.c,1.112,1.113
On Thu, 16 Jun 2005 14:22:36 +0200
Nicolai Haehnle [EMAIL PROTECTED] wrote:
On Thursday 16 June 2005 13:41, Aapo Tahkola wrote:
Update of /cvsroot/r300/r300_driver/r300
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6333
Modified Files:
r300_reg.h r300_state.c
Log Message:
Use depth tiling.
Will this work with software fallbacks?
Im not quite sure but more recent r200_span.c has few words about it.
Attached patch enables color tiling in case someone wants to play with it.
--
Aapo Tahkola
--- radeon_driver.c.origFri Jun 10 05:24:35 2005
+++ radeon_driver.c Tue Jun 21 18:13:31 2005
@@ -4745,10 +4745,6 @@
xf86DrvMsg(pScrn-scrnIndex, X_INFO, Color tiling disabled for 2nd
head\n);
info-allowColorTiling = FALSE;
}
-else if ((info-allowColorTiling) (info-ChipFamily =
CHIP_FAMILY_R300)) {
- xf86DrvMsg(pScrn-scrnIndex, X_INFO, Color tiling disabled for r300
and newer chips\n);
- info-allowColorTiling = FALSE;
-}
else if ((info-allowColorTiling) (info-FBDev)) {
xf86DrvMsg(pScrn-scrnIndex, X_WARNING,
Color tiling not supported with UseFBDev option\n);
@@ -5631,6 +5627,11 @@
if (!info-IsSecondary)
RADEONChangeSurfaces(pScrn);
+if (info-ChipFamily = CHIP_FAMILY_R300) {
+ unsigned char *RADEONMMIO = info-MMIO;
+ OUTREG(0x180, INREG(0x180) | 0x1100);
+}
+
if(info-MergedFB) {
/* need this here to fix up sarea values */
RADEONAdjustFrameMerged(scrnIndex, pScrn-frameX0, pScrn-frameY0, 0);
@@ -6133,7 +6134,12 @@
drmRadeonSurfaceAlloc drmsurfalloc;
drmsurfalloc.size = bufferSize;
drmsurfalloc.address = info-frontOffset;
- drmsurfalloc.flags = swap_pattern | (width_bytes / 16) |
color_pattern;
+
+ if (IS_R300_VARIANT)
+ drmsurfalloc.flags = swap_pattern | (width_bytes / 8) |
color_pattern;
+ else
+ drmsurfalloc.flags = swap_pattern | (width_bytes / 16) |
color_pattern;
+
retvalue = drmCommandWrite(info-drmFD, DRM_RADEON_SURF_ALLOC,
drmsurfalloc, sizeof(drmsurfalloc));
if (retvalue 0)
@@ -6172,7 +6178,10 @@
/* we don't need anything like WaitForFifo, no? */
if (!info-IsSecondary) {
if (info-tilingEnabled) {
- surf_info = swap_pattern | (width_bytes / 16) | color_pattern;
+ if (IS_R300_VARIANT)
+ surf_info = swap_pattern | (width_bytes / 8) | color_pattern;
+ else
+ surf_info = swap_pattern | (width_bytes / 16) |
color_pattern;
}
OUTREG(RADEON_SURFACE0_INFO, surf_info);
OUTREG(RADEON_SURFACE0_LOWER_BOUND, 0);
@@ -7088,10 +7097,16 @@
save-crtc_offset = 0;
save-crtc_offset_cntl = INREG(RADEON_CRTC_OFFSET_CNTL);
if (info-tilingEnabled) {
- save-crtc_offset_cntl |= RADEON_CRTC_TILE_EN;
+ if (IS_R300_VARIANT)
+ save-crtc_offset_cntl |= 0x8e00;
+ else
+ save-crtc_offset_cntl |= RADEON_CRTC_TILE_EN;
}
else {
- save-crtc_offset_cntl = ~RADEON_CRTC_TILE_EN;
+ if (IS_R300_VARIANT)
+ save-crtc_offset_cntl = ~0x8e00;
+ else
+ save-crtc_offset_cntl = ~RADEON_CRTC_TILE_EN;
}
save-crtc_pitch = (((pScrn-displayWidth * pScrn-bitsPerPixel) +
@@ -7273,10 +7288,16 @@
save-crtc2_offset = 0;
save-crtc2_offset_cntl = INREG(RADEON_CRTC2_OFFSET_CNTL)
RADEON_CRTC_OFFSET_FLIP_CNTL;
if (info-tilingEnabled) {
- save-crtc2_offset_cntl |= RADEON_CRTC_TILE_EN;
+ if (IS_R300_VARIANT)
+ save-crtc2_offset_cntl |= 0x8e00;
+ else
+ save-crtc2_offset_cntl |= RADEON_CRTC_TILE_EN;
}
else {
- save-crtc2_offset_cntl = ~RADEON_CRTC_TILE_EN;
+ if (IS_R300_VARIANT)
+ save-crtc2_offset_cntl = ~0x8e00;
+ else
+ save-crtc2_offset_cntl = ~RADEON_CRTC_TILE_EN;
}
/* this should be right */
Re: radeon DST_LINE
On Sat, 18 Jun 2005 22:18:43 +0200 Jerome Glisse [EMAIL PROTECTED] wrote: On 6/18/05, Adam Jackson [EMAIL PROTECTED] wrote: On Saturday 18 June 2005 13:38, Jerome Glisse wrote: On 6/18/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: On Sat, 18 Jun 2005, Jerome Glisse wrote: DST_LINE_START 0x1600 DST_LINE_END 0x1604 (from radeon fb) From the name, I guess that they initiate line drawing in 2d engine. I think it's more than that...but i maybe wrong, depending on value i put in it the lockup on 9800 can take a bit much time to appear...i haven't done statistic on that an thus i could be a feel more than a true a reality... The DDX uses them for the start and end coordinates of Bresenham lines. I have trouble believing they could be anything else. Yes it's unrevelent reg for the lockup it was just changing value of a related reg 0x16a0, after hours of writting random things in random place my judgement on the importance of reg is severely impaired... Wonder if the difference we saw after fglrx run isn't due to a packet send to the engine and not to a memory mapped reg... Could very well be. I might be useful trying to save them to a file and restore after rebooting. Or then you can start restoring unknown regs to initial values until the problem arises. -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On Fri, 10 Jun 2005 14:31:48 +1000 Ben Skeggs [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: Someone, I believe it was Aapo, said that they see white lines across the screen when the framerate is fairly high. I didn't see this up until yesterday when I had to change from my 9600pro to a 9600XT (I killed the card moving it between machines somehow). Are you using SiS based motherboard by any chance? Nope, I'm using an nforce3 based board (Gigabyte GA-K8NS Ultra-939) Following patch should fix this at the cost of some speed... This does indeed seem to correct the problem, and I don't notice a loss of speed. glxgears rose by about 20fps, and quake3 by 5-10 fps.. I updated xorg in the process of applying the patch, so it could be something from there. What exactly does the patch do? Or is it some magic we don't about yet? Perhaps ATI guys could answer that. -- Aapo Tahkola --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On Fri, 10 Jun 2005 17:04:06 +0200 Nicolai Haehnle [EMAIL PROTECTED] wrote: On Friday 10 June 2005 16:52, Aapo Tahkola wrote: On Fri, 10 Jun 2005 14:31:48 +1000 Ben Skeggs [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: Someone, I believe it was Aapo, said that they see white lines across the screen when the framerate is fairly high. I didn't see this up until yesterday when I had to change from my 9600pro to a 9600XT (I killed the card moving it between machines somehow). Are you using SiS based motherboard by any chance? Nope, I'm using an nforce3 based board (Gigabyte GA-K8NS Ultra-939) Following patch should fix this at the cost of some speed... This does indeed seem to correct the problem, and I don't notice a loss of speed. glxgears rose by about 20fps, and quake3 by 5-10 fps.. I updated xorg in the process of applying the patch, so it could be something from there. What exactly does the patch do? Or is it some magic we don't about yet? Perhaps ATI guys could answer that. Umm... you *must* have that piece of code from *somewhere*, it can't just have fallen out of the sky. And that alone could provide at least some clue as to what this does... I traced this down by compairing MMIO regs: 1.r300 driver after reboot 2.fgl with option BufferTiling set to off 3.r300 driver after fgl has been used http://rasterburn.org/~aet/regdump.tar.bz2 See lspci -v or xorg logs for correct ADDR . -- Aapo Tahkola --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
Someone, I believe it was Aapo, said that they see white lines across the
screen when the framerate is fairly high. I didn't see this up until yesterday
when I had to change from my 9600pro to a 9600XT (I killed the card moving
it between machines somehow).
Are you using SiS based motherboard by any chance?
Following patch should fix this at the cost of some speed...
--- radeon_driver.c.origFri Jun 10 05:24:35 2005
+++ radeon_driver.c Fri Jun 10 05:46:14 2005
@@ -5631,6 +5631,11 @@
if (!info-IsSecondary)
RADEONChangeSurfaces(pScrn);
+if (info-ChipFamily = CHIP_FAMILY_R300) {
+ unsigned char *RADEONMMIO = info-MMIO;
+ OUTREG(0x180, INREG(0x180) | 0x1100);
+}
+
if(info-MergedFB) {
/* need this here to fix up sarea values */
RADEONAdjustFrameMerged(scrnIndex, pScrn-frameX0, pScrn-frameY0, 0);
--
Aapo Tahkola
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
On Thursday 02 June 2005 13:08, Boris Peterbarg wrote: Aapo Tahkola wrote: I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Perhaps. I don't think it's just the pacifier sequence, though. I've been running applications with RADEON_DEBUG=sync, which causes idle calls between cmdbuf calls, and I've been seeing lockups where the read pointer sits after the beginning of what cmdbuf emits and long before the first rendering commands. I dont know if packet3 was issued before since I tweaked isosurf to dump each frame portion of RADEON_DEBUG info into files using freopen. But DISCARD BUF was really the only key difference in these logs. This indicates that at least one lockup is cause by one of the following: - intial pacifier sequence in r300_cp_cmdbuf - emission of cliprects or Cliprects seem to be little off scale when compairing progs/samples/logo against software rendering. Perhaps near plane is negative ? - initial unchecked_state commands sent by the client This is bad as you can see from first frame drawn by texwrap... Sticking: r300_setup_textures(ctx); r300_setup_rs_unit(ctx); r300SetupVertexShader(rmesa); r300SetupPixelShader(rmesa); or resethwstate to r300_run_vb_render should fix it. -- Aapo Tahkola --- 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] [patches] debugging lockups
On Fri, 3 Jun 2005 14:57:37 +0200 Nicolai Haehnle [EMAIL PROTECTED] wrote: On Friday 03 June 2005 10:28, Aapo Tahkola wrote: On Thursday 02 June 2005 13:08, Boris Peterbarg wrote: Aapo Tahkola wrote: I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Perhaps. I don't think it's just the pacifier sequence, though. I've been running applications with RADEON_DEBUG=sync, which causes idle calls between cmdbuf calls, and I've been seeing lockups where the read pointer sits after the beginning of what cmdbuf emits and long before the first rendering commands. I dont know if packet3 was issued before since I tweaked isosurf to dump each frame portion of RADEON_DEBUG info into files using freopen. But DISCARD BUF was really the only key difference in these logs. This indicates that at least one lockup is cause by one of the following: - intial pacifier sequence in r300_cp_cmdbuf - emission of cliprects or Cliprects seem to be little off scale when compairing progs/samples/logo against software rendering. Perhaps near plane is negative ? - initial unchecked_state commands sent by the client This is bad as you can see from first frame drawn by texwrap... Sticking: r300_setup_textures(ctx); r300_setup_rs_unit(ctx); r300SetupVertexShader(rmesa); r300SetupPixelShader(rmesa); or resethwstate to r300_run_vb_render should fix it. I'm not sure we're talking about the same thing here. This happens when the client sends a command buffer where all the state blocks (from r300-hw) are sent to the hardware *anyway*. It's actually the *order* of emission (e.g. the order in which insert_at_tail is called for state bits) that can make a difference. The thing is, while the order definitely *does* affect the probability of lockups, lockups will not go away completely even if I use the exact same order that fglrx uses. So I'm beginning to believe that we can't trust radeon_do_cp_idle to completely idle the chip, or that whatever is wrong is pretty fundamentally wrong (some wrong bits in how the memory is configured?). Remember that because of reemiting, those states arent in perfect order. Fortunately taking out lines 206-212 of r300_context.c doesnt seem to have any side effects on rv350. -- Aapo Tahkola --- 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] [patches] debugging lockups
Jerome Glisse wrote: On 6/1/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. If you're feeling adventurous, I'd appreciate it if you could also try this patch in combination with the patch.remove-userspace-pacifiers patch I posted earlier, though this patch appears to be dangerous still (even though I do not understand why). Well, my last attempt with this patch resulted in immediate lockups. Think it's still worth me testing this path in conjunction with the above patch? You should test it as this patch makes our driver behave more like fglrx. I will test it too, latter this day... Jerome Glisse Well, I'm not getting the immediate lockups that I got before with just the patch.remove-userspace-pacifiers. But I'm still getting seemingly random lockups with patch.remove-userspace-pacifiers + patch.drm-cmdbuf-more-pacifiers. No noticable regressions, but no noticable improvements. I can still play UT and Q3A from anywhere between 2 to 20 minutes. I thought I'd try a little experiment. I compiled the driver on my FreeBSD installation thanks to all the great work that had been done on that in the past. I then created a chrooted development environment in /compat/linux and compiled the linux version of the driver. Installed it in the compatability environment. Both Q3A and UT started up and ran on FreeBSD. And both locked up within the same general time frame I'm seeing under Linux. Not sure if this helps diagnose the problems any further, but I thought some people might be interested in hearing that linux OpenGL apps work on r300 hardware on FreeBSD. I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Any brave souls left? (patch attached) -- Aapo Tahkola cb_pacify.patch Description: Binary data
Re: [patches] Re: r300 radeon 9800 lockup
On Mon, 30 May 2005 20:31:24 -0400 Jonathan Bastien-Filiatrault [EMAIL PROTECTED] wrote: Adam K Kirchhoff wrote: 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 A) The first patch may help a little, but definitely doesn't eliminate the lockups. B) Huge regression. With both patches I get an immediate lockup when launching glxgears (before the window is even drawn). Adam Funny enough, two days ago, I played vegastrike for litterally _hours_ with my Radeon 9800 Pro, both patches applied, I restarted the game a couple times and I could not get it to lockup. However, the day after, I could not even start the game without causing a lockup. Looks like you did something good, keep up the great work. This is probably my fault if you updated local copy meanwhile. You can enable the old behaviour by commenting line #define CB_DPATH of r300_ioctl.c if its there. -- Aapo Tahkola --- 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 mergedfb+mouse lockups back
On Mon, 16 May 2005 23:23:49 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: On Tue, 17 May 2005, Lorenzo Colitti wrote: Dave Airlie wrote: I reapplied Vladimir's fix and the machine doesn't lock up any more. Maybe the fix should be checked in to CVS again? http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_mergedfb.c?rev=1.9view=log v 1.7 backs it out because it is buggy... I know, I read the checkin comment. However, is buggy better than locked up hard? This buggy part was due to the fix breaking down completely when used on SMP machines. The correct fix is to turn off SilkenMouse. For this particular bug this seems to work. However the dinoshade bug seems to get fixed only by adding RADEONWaitForIdleMMIO to every function in radeon_cursor.c . -- Aapo Tahkola --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
On Mon, 09 May 2005 19:09:40 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
Aapo Tahkola wrote:
On Tue, 03 May 2005 14:59:53 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
Aapo Tahkola wrote:
On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
Vladimir Dergachev [EMAIL PROTECTED] wrote:
On Thu, 21 Apr 2005, Aapo Tahkola wrote:
On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
Vladimir Dergachev [EMAIL PROTECTED] wrote:
With regard to state switching, it might be worth it to simply hash
various configuration (fog on /fog off, etc) and just upload state
difference on such changes.
Could work reasonably well. Problem with hashing all programs is that we
would most likely have so many different programs that it would be
undesirable to keep them in memory. Take for example omiting tex coord
transforms, rescaling of normals, normalization of normals..
Sure we could just start dropping them but that might lead to instable
framerates if we constantly translate new programs.
I cant say I knew any really good way to handle this at the moment so
its probably best to try something and see what problems arise.
Well, we know that the register space we are interested in is less than
4K.
A megabyte would hold 256 such configurations - should be plenty, no ?
Maybe for average case but not for worst.
Heres a list of problems that prevent r300 driver from using Keith's ffp
program generator:
1. _TnlProgram is of fixed size type and smaller than r300_vertex_program
What's the actual issue here? In what circumstances does this cause a
problem?
Mesa is holding drivers private data bound to programs in containers just
like in i915NewProgram.
I suggest this to be sorted out by adding PrivatePrt to vertex and fragment
program structures in Mesa.
This way drivers can allocate their private structures at translation stage
and more better estimate needed memory.
Also this fits well into the hashing scheme when arb programs generated by
t_vp_build.c could be destroyed once no longer needed.
I think the issue is that I was creating the structures directly rather
than calling ctx-Driver.NewProgram() to do this, as is the case with
all other fragment vertex programs.
Or that.
Heres a better version of the mov changes.
Changes to build_texture_transform should still break software tnl though.
The issue of creating/destroying the programs should probably be done at
a higher level, ie in mesa/main/texenvprogram.c, so that drivers don't
all end up with similar different hashing schemes.
I agree.
--
Aapo Tahkola
Index: t_vp_build.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/tnl/t_vp_build.c,v
retrieving revision 1.10
diff -u -b -B -u -r1.10 t_vp_build.c
--- t_vp_build.c11 May 2005 15:18:59 - 1.10
+++ t_vp_build.c11 May 2005 16:12:55 -
@@ -103,6 +103,8 @@
#define YSWIZZLE_Y
#define ZSWIZZLE_Z
#define WSWIZZLE_W
+#define ONE SWIZZLE_ONE
+#define ZERO SWIZZLE_ZERO
/* Construct a ureg:
@@ -968,10 +970,11 @@
for (i = 0; i ctx-Const.MaxTextureCoordUnits; i++) {
struct gl_texture_unit *texUnit = ctx-Texture.Unit[i];
GLuint texmat_enabled = ctx-Texture._TexMatEnabled ENABLE_TEXMAT(i);
- struct ureg out = register_output(p, VERT_RESULT_TEX0 + i);
+ struct ureg out;
if (texUnit-TexGenEnabled || texmat_enabled) {
struct ureg out_texgen = undef;
+out = register_output(p, VERT_RESULT_TEX0 + i);
if (texUnit-TexGenEnabled) {
GLuint copy_mask = 0;
@@ -1095,6 +1098,35 @@
static void build_passthrough( struct tnl_program *p, GLuint inputs )
{
+ GLcontext *ctx = p-ctx;
+ GLuint i, nr_lights = 0;
+
+ if (ctx-Light.Enabled == GL_FALSE)
+ emit_op1(p, VP_OPCODE_MOV, register_output(p, VERT_RESULT_COL0), 0,
+ register_input(p, VERT_ATTRIB_COLOR0));
+ else {
+
+ for (i = 0; i MAX_LIGHTS; i++)
+ if (ctx-Light.Light[i].Enabled)
+ nr_lights++;
+
+ if(nr_lights == 0) { /* Darkness */
+ struct ureg dummy = register_input( p, VERT_ATTRIB_POS );
+
+ emit_op1(p, VP_OPCODE_MOV, register_output(p, VERT_RESULT_COL0), 0,
+ swizzle(dummy, ZERO, ZERO, ZERO, ZERO));
+ }
+ }
+
+ for (i = 0; i ctx-Const.MaxTextureCoordUnits; i++) {
+ struct gl_texture_unit *texUnit = ctx-Texture.Unit[i];
+ GLuint texmat_enabled = ctx-Texture._TexMatEnabled ENABLE_TEXMAT(i);
+
+ if ((! (texUnit-TexGenEnabled || texmat_enabled))
texUnit-_ReallyEnabled) {
+struct ureg out = register_output(p, VERT_RESULT_TEX0 + i);
+emit_op1(p, VP_OPCODE_MOV, out, 0, register_input(p,
VERT_ATTRIB_TEX0+i));
+ }
+ }
}
Re: r300 fixed pipeline design
On Tue, 03 May 2005 14:59:53 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Thu, 21 Apr 2005 09:57:48 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: On Thu, 21 Apr 2005, Aapo Tahkola wrote: On Wed, 23 Feb 2005 15:03:38 -0500 (EST) Vladimir Dergachev [EMAIL PROTECTED] wrote: With regard to state switching, it might be worth it to simply hash various configuration (fog on /fog off, etc) and just upload state difference on such changes. Could work reasonably well. Problem with hashing all programs is that we would most likely have so many different programs that it would be undesirable to keep them in memory. Take for example omiting tex coord transforms, rescaling of normals, normalization of normals.. Sure we could just start dropping them but that might lead to instable framerates if we constantly translate new programs. I cant say I knew any really good way to handle this at the moment so its probably best to try something and see what problems arise. Well, we know that the register space we are interested in is less than 4K. A megabyte would hold 256 such configurations - should be plenty, no ? Maybe for average case but not for worst. Heres a list of problems that prevent r300 driver from using Keith's ffp program generator: 1. _TnlProgram is of fixed size type and smaller than r300_vertex_program What's the actual issue here? In what circumstances does this cause a problem? Mesa is holding drivers private data bound to programs in containers just like in i915NewProgram. I suggest this to be sorted out by adding PrivatePrt to vertex and fragment program structures in Mesa. This way drivers can allocate their private structures at translation stage and more better estimate needed memory. Also this fits well into the hashing scheme when arb programs generated by t_vp_build.c could be destroyed once no longer needed. 2. Programs generated are incomplete in sense that they dont move input color to output(also applies to texture coords) The programs share the semantics of regular vertex programs - which don't do this copying either. So, if you need to add this sort of copying when you encode a regular vertex program for the r300, you'll need to do the same thing with the generated programs. If not, I don't understand what's going on. According to issue 16 of vertex_progra spec, initial values of temps and results are undefined unless written to. 3. Number of temps exceeds 32 in some cases. Can you give some details? I'm sure this can be pared down a little. Happened with ut2k4. Ill look into this at better time. -- Aapo Tahkola --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
On Sat, 30 Apr 2005 15:43:08 +0300 Aapo Tahkola [EMAIL PROTECTED] wrote: Ill add something that allows to switch between hw and sw tnl on the fly using magic keys later today. Attached offensive beast does this. When compiled r300_tnl_switch.so is loaded with LD_PRELOAD, applications that use events to read keyboard input respond to F11 and F12 keys. -- Aapo Tahkola r300_tnl_switch.tar.bz2 Description: Binary data
Re: licenses, R300 code, etc
On Wed, 27 Apr 2005 23:26:31 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: /* $XFree86: xc/lib/GL/mesa/src/drv/r200/r200_lock.c,v 1.1 2002/10/30 12:51:52 alanh Exp $ */ /* Copyright (C) The Weather Channel, Inc. 2002. All Rights Reserved. The Weather Channel (TM) funded Tungsten Graphics to develop the initial release of the Radeon 8500 driver under the XFree86 license. This notice must be preserved. Basically the standard license for the Mesa drivers is the part from here down, plus a copyright line as above, with whoever you want as the copyright holder. So is it XFree86 license ? Pre or post 4.4.0 ? Or something else ? I would recommend avoiding confusion, and not using the name XFree86 license unless refering specifically to the XFree86 project. When refering to the XFree86 project's license, it is also best to indicate what specific version of the license you're refering to, as the older license was more or less MIT style, while the newer one has additional restrictions. MIT/X11 License is the traditional X license which most of the xc/* codebase is licensed under, including most drivers, etc. If adding a new driver to the tree, please license it MIT/X11. Yes, but my understanding was that Mesa is a separate piece of software from Xorg or XFree86 trees. I thought initially that it was under LGPL, but looking at http://www.mesa3d.org it does not appear so. There are many different licenses and there does not appear to be a policy for individual drivers. Not that the choice isn't good - it is :) The reason I am asking this is that I was recently asked whether R300 driver is free software (from GNU point of view) and I realized that I don't know precise answer that is pedantic enough from lawyers point of view. So to sum up what I know so far: * original R200 driver is under MIT/X11 license * the R300 driver derived from it appears under the same license due to the notices left over from R200 files (as we originally thought to merge the code in R200). Well we still could merge them. Unplugging r200 side just seemed to be easier since nobody seems to know weither we actually should merge them. This needs approval from everyone who contributed to R300 - please let me know ! Fine by me. * The DRM driver is under dual GPL/BSD license except for select pieces of linux code. R300 patches to it need to be under the same dual license to be usable both with Linux and BSD. Corrections and clarifications are much appreciated. thank you Vladimir Dergachev --- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Aapo Tahkola --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
On Thu, 21 Apr 2005 09:57:48 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: On Thu, 21 Apr 2005, Aapo Tahkola wrote: On Wed, 23 Feb 2005 15:03:38 -0500 (EST) Vladimir Dergachev [EMAIL PROTECTED] wrote: With regard to state switching, it might be worth it to simply hash various configuration (fog on /fog off, etc) and just upload state difference on such changes. Could work reasonably well. Problem with hashing all programs is that we would most likely have so many different programs that it would be undesirable to keep them in memory. Take for example omiting tex coord transforms, rescaling of normals, normalization of normals.. Sure we could just start dropping them but that might lead to instable framerates if we constantly translate new programs. I cant say I knew any really good way to handle this at the moment so its probably best to try something and see what problems arise. Well, we know that the register space we are interested in is less than 4K. A megabyte would hold 256 such configurations - should be plenty, no ? Maybe for average case but not for worst. Heres a list of problems that prevent r300 driver from using Keith's ffp program generator: 1. _TnlProgram is of fixed size type and smaller than r300_vertex_program 2. Programs generated are incomplete in sense that they dont move input color to output(also applies to texture coords) 3. Number of temps exceeds 32 in some cases. Attached patch temporarily fixes first two issues. Problems on r300 side(that im aware of): 1. Multitexturing is broken on r300 side as texcoords regs arent properly asigned in r300_setup_rs_unit 2. Problems with colors applied to textures(see dinoshade). Ill add something that allows to switch between hw and sw tnl on the fly using magic keys later today. -- Aapo Tahkola r300-fpl-mesa.patch Description: Binary data
Re: r300 fixed pipeline design
On Wed, 23 Feb 2005 15:03:38 -0500 (EST) Vladimir Dergachev [EMAIL PROTECTED] wrote: With regard to state switching, it might be worth it to simply hash various configuration (fog on /fog off, etc) and just upload state difference on such changes. Could work reasonably well. Problem with hashing all programs is that we would most likely have so many different programs that it would be undesirable to keep them in memory. Take for example omiting tex coord transforms, rescaling of normals, normalization of normals.. Sure we could just start dropping them but that might lead to instable framerates if we constantly translate new programs. I cant say I knew any really good way to handle this at the moment so its probably best to try something and see what problems arise. Attached tarball contains test code I extracted from that paper and bunch of modifications. Jerome Glisse(if im not mistaken) rolled up a lot cleaner version of it (see vprogram.c). Spotlights should work as of todays Mesa cvs and software vertex shading as bug #3087 is resolved. Keys 1, 2 and 3 switch between them. This would not be too complicated to implement, whatever the mechanism of shader generation. Btw, another interesting link would be: http://ati.com/developer/samples/dx9/FixedFuncShader.html Branching could be interesting if older radeons would support such a thing. What worked for ATI will not necessarily work for us, as getting the last fps is not as important as having a stable and maintainable driver. Thus we can (and do need to) experiment. I dont think we need to sacrifice framerates here. There are some one instruction saves like writing directly into result instead of using MOV from temp but those can probably be worked out with small hacks. best Vladimir Dergachev -- Aapo Tahkola fpl2.tar.bz2 Description: Binary data
Re: [r300] what about *BSD?
On Tue, 19 Apr 2005 15:42:43 +0200
Jan Kreuzer [EMAIL PROTECTED] wrote:
$ make
=== drm
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/drm
=== i915
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/i915
=== mach64
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/mach64
=== mga
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/mga
=== r128
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/r128
=== radeon
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon
cc -O -pipe -I. -I.. -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I.. -I. -I@
-I@/contrib/altq -I@/../include -finline-limit=8000 \
-fno-common -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2
-mno-mmx -mno-3dnow -msoft-float \
-fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes \
-Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.c
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.c:131:
error: syntax error before r300_init_reg_flags
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.c:134:
error: syntax error before numeric constant
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.c:134:
warning: type defaults to `int' in declaration of `memset'
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.c:134:
warning: function declaration isn't a prototype
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.c:134:
error: conflicting types for 'memset'
@/sys/libkern.h:118: error: previous definition of 'memset' was here
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.c:134:
warning: data definition has no type or storage class
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.c:60:
warning: 'r300_emit_cliprects' defined but not used
*** Error code 1
Stop in /usr/home/jan/dri/r300_driver/drm/bsd-core/radeon.
*** Error code 1
So it seems that r300 would work (as good as in linux), if the drm-part of it
would be updated to compile
under freebsd. But this is beyond my skills.
Try this:
--- r300_cmdbuf.c.orig Tue Apr 19 17:14:33 2005
+++ r300_cmdbuf.c Tue Apr 19 17:14:49 2005
@@ -125,13 +125,12 @@
return 0;
}
-unsigned char r300_reg_flags[0x12];
+unsigned char r300_reg_flags[0x12]={ 0 };
-void __init r300_init_reg_flags(void)
+void r300_init_reg_flags(void)
{
int i;
-memset(r300_reg_flags, 0, 0x12);
#define ADD_RANGE(reg, count)
for(i=(reg2);i(reg2)+count;i++)r300_reg_flags[i]|=1;
/* these match cmducs() command in r300_driver/r300/r300_cmdbuf.c */
Greetings Jan
--
Aapo Tahkola
---
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
On Tue, 19 Apr 2005 12:26:36 -0400
Jung-uk Kim [EMAIL PROTECTED] wrote:
On Tuesday 19 April 2005 10:18 am, Aapo Tahkola wrote:
On Tue, 19 Apr 2005 15:42:43 +0200
Jan Kreuzer [EMAIL PROTECTED] wrote:
$ make
=== drm
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/drm === i915
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/i915 === mach64
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/mach64 === mga
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/mga === r128
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/r128 === radeon
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon cc -O -pipe
-I. -I.. -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I.. -I. -I@
-I@/contrib/altq -I@/../include -finline-limit=8000 \ -fno-common
-mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2
-mno-mmx -mno-3dnow -msoft-float \
-fno-asynchronous-unwind-tables -ffreestanding -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes \ -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -std=c99 -c
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c:131: error: syntax error before r300_init_reg_flags
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c:134: error: syntax error before numeric constant
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c:134: warning: type defaults to `int' in declaration of `memset'
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c:134: warning: function declaration isn't a prototype
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c:134: error: conflicting types for 'memset' @/sys/libkern.h:118:
error: previous definition of 'memset' was here
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c:134: warning: data definition has no type or storage class
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c:60: warning: 'r300_emit_cliprects' defined but not used ***
Error code 1
Stop in /usr/home/jan/dri/r300_driver/drm/bsd-core/radeon.
*** Error code 1
So it seems that r300 would work (as good as in linux), if the
drm-part of it would be updated to compile under freebsd. But
this is beyond my skills.
Try this:
--- r300_cmdbuf.c.orig Tue Apr 19 17:14:33 2005
+++ r300_cmdbuf.c Tue Apr 19 17:14:49 2005
@@ -125,13 +125,12 @@
return 0;
}
-unsigned char r300_reg_flags[0x12];
+unsigned char r300_reg_flags[0x12]={ 0 };
-void __init r300_init_reg_flags(void)
+void r300_init_reg_flags(void)
{
int i;
-memset(r300_reg_flags, 0, 0x12);
memset() is okay and it is better that way (at least for
FreeBSD/amd64):
http://lists.freebsd.org/pipermail/freebsd-amd64/2005-March/004058.html
My experiment shows GCC misoptimizes this type of initialization on
AMD64 where glibc is not used (i. e., *BSD).
Jans compiler doesnt seem to like memseting arrays:
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.c:134:
error: syntax error before numeric constant
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.c:134:
warning: type defaults to `int' in declaration of `memset'
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.c:134:
warning: function declaration isn't a prototype
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.c:134:
error: conflicting types for 'memset'
@/sys/libkern.h:118: error: previous definition of 'memset' was here
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.c:134:
warning: data definition has no type or storage class
Maybe just loop it to zero?
I would stick r300_init_reg_flags call to radeon_preinit() since it seems to be
called on bsds and x86s.
Removing __init is enough, I believe. Please see my previous posting.
Thanks,
Jung-uk Kim
#define ADD_RANGE(reg, count)
for(i=(reg2);i(reg2)+count;i++)r300_reg_flags[i]|=1;
/* these match cmducs() command in
r300_driver/r300/r300_cmdbuf.c */
Greetings Jan
--
Aapo Tahkola
---
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https
Re: [r300] what about *BSD?
On Tue, 19 Apr 2005 16:09:45 -0400
Jung-uk Kim [EMAIL PROTECTED] wrote:
On Tuesday 19 April 2005 02:14 pm, Jung-uk Kim wrote:
On Tuesday 19 April 2005 02:02 pm, Aapo Tahkola wrote:
On Tue, 19 Apr 2005 12:26:36 -0400
Jung-uk Kim [EMAIL PROTECTED] wrote:
On Tuesday 19 April 2005 10:18 am, Aapo Tahkola wrote:
On Tue, 19 Apr 2005 15:42:43 +0200
Jan Kreuzer [EMAIL PROTECTED] wrote:
$ make
=== drm
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/drm === i915
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/i915 === mach64
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/mach64 === mga
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/mga === r128
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/r128 === radeon
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon cc -O
-pipe -I. -I.. -D_KERNEL -DKLD_MODULE -nostdinc -I- -I.
-I.. -I. -I@ -I@/contrib/altq -I@/../include
-finline-limit=8000 \ -fno-common -mcmodel=kernel
-mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx
-mno-3dnow -msoft-float \ -fno-asynchronous-unwind-tables
-ffreestanding -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes \ -Wpointer-arith
-Winline -Wcast-qual -fformat-extensions -std=c99 -c
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c:131: error: syntax error before
r300_init_reg_flags
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c:134: error: syntax error before numeric constant
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c:134: warning: type defaults to `int' in
declaration of `memset'
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c:134: warning: function declaration isn't a
prototype
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c:134: error: conflicting types for 'memset'
@/sys/libkern.h:118: error: previous definition of 'memset'
was here
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c:134: warning: data definition has no type or
storage class
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c:60: warning: 'r300_emit_cliprects' defined but not
used *** Error code 1
Stop in /usr/home/jan/dri/r300_driver/drm/bsd-core/radeon.
*** Error code 1
So it seems that r300 would work (as good as in linux), if
the drm-part of it would be updated to compile under
freebsd. But this is beyond my skills.
Try this:
--- r300_cmdbuf.c.orig Tue Apr 19 17:14:33 2005
+++ r300_cmdbuf.c Tue Apr 19 17:14:49 2005
@@ -125,13 +125,12 @@
return 0;
}
-unsigned char r300_reg_flags[0x12];
+unsigned char r300_reg_flags[0x12]={ 0 };
-void __init r300_init_reg_flags(void)
+void r300_init_reg_flags(void)
{
int i;
-memset(r300_reg_flags, 0, 0x12);
memset() is okay and it is better that way (at least for
FreeBSD/amd64):
http://lists.freebsd.org/pipermail/freebsd-amd64/2005-March/004
05 8.html
My experiment shows GCC misoptimizes this type of
initialization on AMD64 where glibc is not used (i. e., *BSD).
Jans compiler doesnt seem to like memseting arrays:
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
bu f.c:134: error: syntax error before numeric constant
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
bu f.c:134: warning: type defaults to `int' in declaration of
`memset'
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
bu f.c:134: warning: function declaration isn't a prototype
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
bu f.c:134: error: conflicting types for 'memset'
@/sys/libkern.h:118: error: previous definition of 'memset'
was here
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
bu f.c:134: warning: data definition has no type or storage
class
Maybe just loop it to zero?
No, the previous syntax error (i. e., __init) was causing the
second syntax error. If you remove it, all the syntax errors
disappear. ;-)
I would stick r300_init_reg_flags call to radeon_preinit() since
it seems to be called on bsds and x86s.
I'll try that and let you know.
It doesn't seem to work. In fact, I tried it in many
Linux port of 3dprof
I rolled up a (very) quick Linux port of 3dprof's 3DProfSource/radeon_setclk/r6clock-dll/radcard.cpp . By default reference_divider is decreased always when this program is run. This will cause memory clocks to increase too much and memory corruption to occur. Modifying mem_feedback_divider and/or vpu_feedback_divider doesnt currently work or the values are incorrect. To get this program to run you need to change some constants at top of main.c and in init_bioshdr(). Needless to say that im not responsible for any damages caused by this program. If someone wants to turn this into a usable program, feel free to do so, just dont claim I wrote any portions of it :) -- Aapo Tahkola 3dprof-linux.tar.bz2 Description: Binary data
Re: [r300] what about *BSD?
After reading all the promising success stories about the r300 project, I am wondering whether anybody successfully tried it on a *BSD. Some time ago I tried on DragonFly BSD and in Xorg.0.log I found a message that DRI was enabled, but glxinfo said direct rendering: No. DRMs BSD support was added blindfold without any testing so it might not work as expected. You might want to check out steps after Xorg says DRI is enabled from http://dri.freedesktop.org/wiki/DriTroubleshooting . Thanks, Johannes -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Idx buffer? Was: [Bug 2702] r200 driver does not support brilineartexture filtering
[EMAIL PROTECTED] schrieb: the drm version of the patch. Straightforward, I did not apply it to cvs since it needs a version bump, and I don't think this feature alone is worth that. Idx buffer support could be one of such features. Unfortunately no one seems to be interested in writing drm support for it. What is an idx buffer? Google finds just pages of source code where a variable named buffer is assig ned to one named idx. Correct me if im wrong but doesnt the r200 driver currently write element indices into command buffer as there have been no way to use them from video memory. Im talking about the indices that are passed to glDrawElements. Support for R200_CP_CMD_INDX_BUFFER and R200_CP_CMD_3D_DRAW_INDX_2 in other words. Philipp -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] gliding_penguin snapshot
Vladimir Dergachev wrote: Hi Adam, Could you remind me what video card you have ? And also any other details that might be relevant (like resolution, refresh rate, motherboard chipset, AGP mode, etc). thank you ! Vladimir Dergachev I have a Radeon 9800 Pro (R350). I use a mergedfb desktop at 2560x1024... I don't know the refresh rate offhand. It's a dual xeon machine. I'm running AGP at 4x. Generally speaking, at that resolution, I'm able to play a couple holes of neverputt before my machine locks up. Tuxracer and PPracer, on the other hand, lockup immediately. Neverputt tends to lockup between holes, or sometimes when I'm aiming my shot... When I start X with the lower resolution, neverputt locks up almost immediately. Given this, I'm assuming the lockups happen when the framerate is at it's highest. We could check the states that are different between rv350 and r300 on fgl. Im on irc in case you are interested... -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 state save mechanism
As someone might of noticed, r300Clear calls r300ResetHwState as it tampers over states as there have been no good way to save the states that r300ClearBuffer needs to modify. I discussed about the possible aproaches of doing state saving with Vladimir. Implementing something like R200_DB_STATECHANGE doesnt look like a good alternative as cases where something like this would be needed seem rare. Hence functions that want to play with states should probably handle it by themselves if possible. Instead of saving the states we could write states that r300Clear needs to modify directly into command buffer and just dirty mark state atoms that have been altered. Any pros, cons, other ideas? -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] nasty bug found and fixed
Bad news: That extra instruction causes texobj=NULL and therefore texture corruption. Looks like it indeed. This is caused by incorrectly enabling texture units based on inputs. Something like if(ctx-Texture.Unit[i].Enabled == 0) continue; in r300_setup_textures fixes it but performance loss is pretty great. I think this is because maos code fills dma regions with bad data as it never actually checks that user passed texcoords. AFAIK cases where program didnt pass vertex elements but vertex programs input wants it should either be left uncofigured or filled with default vector with no walk. Anyhow this is still a bit open as mesa doesnt configure render inputs based on vertex programs(my opinion is that it shouldnt either) and that too many test programs arent available. Rune Petersen -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] nasty bug found and fixed
Ok. I said that this bug doesnt exist and it was just my problem ... I changed my mind as it appeared again after rebuilding just about everything and tracked it down after long battle. This was caused by missing curly braces around texcoord VAP input configuration and resulted in all 8 texture units to be configured whenever vertex programs were used. However there is one thing I dont understand about this: How did badly configuring VAP input caused vertex programs to get broken when dummy var was added into struct r300_dma or struct r300_state ? AFAIK, even if textures would be enabled for no reason there should be enough checks in r300_setup_textures and other places not to cause bad pointers to read from there. There was a bug that could of caused this: #define ALLOC_STATE( ATOM, CHK, SZ, NM, IDX ) \ ... r300-hw.ATOM.cmd = (uint32_t*)CALLOC(SZ * sizeof(uint32_t)); \ ... caller: ALLOC_STATE( tex.filter, variable, mtu+1, tex_filter, 0 ); result: r300-hw.ATOM.cmd = (uint32_t*)CALLOC(mtu+1 * sizeof(uint32_t)); \ This have been fixed some time ago though. Further more I modified verify_r300ResetHwState earlier to test that each state atom can actually hold all data its ment to hold, so these type of bugs should be gone. Could it be because R300_MAX_AOS_ARRAYS is only 8 whereas 9 would of needed ? Im not sure if trying to figure this out like this is worth the effort though as we can probably figure out any outstanding problems with textures by writing test programs. Some shots: http://nu.rasterburn.org/~aet/arbvptorus_1.png http://nu.rasterburn.org/~aet/arbvptorus_2.png -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] nasty bug found
On Thu, 24 Feb 2005, Aapo Tahkola wrote: Hi. I noticed that Vladimirs adition to struct r300_state caused arbvptorus to get broken pretty badly. This is pretty much similar to the bug where vb mode color buffer clears were broken. Iv been trying to figure out this for a while now with no success and I was thinking if anyone else would like to give it a shot. I traced its causer down the structures to struct r300_dma before struct r300_dma_region current;. This doesnt exactly mean that its in dma code but at least its a start. Unfortunately i havent found anything useful in compiler warnings and im currectly lacking ideas of how to find it... Does the bug still show up with immediate mode ? I had some success running 3d apps under valgrind before. This bug *completely* disappeared after I builded xorg 6.8.2 and fetched programs/Xserver/hw/xfree86/drivers/ati and programs/Xserver/hw/xfree86/drivers/i2c from cvs on top of it today. After doing that I had some oddish issues with glxgears giving only ~20fps (yes I know it was accelerated as I saw those little white lines and debug info). After rebuilding kernel with profiling support in attempts to find it, it was gone(frames boosted up too). I tried to make it appear again by reinstalling 6.8.1(with very old ddx patch) and by rebuilding without profiling with no success. I have six different compiler versions and I often swap between em to get program x to compile. So I suppose compiling kernel and drm with different gcc versions could of been the problem.. best Vladimir Dergachev -- Aapo Tahkola -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] nasty bug found
Hi. I noticed that Vladimirs adition to struct r300_state caused arbvptorus to get broken pretty badly. This is pretty much similar to the bug where vb mode color buffer clears were broken. Iv been trying to figure out this for a while now with no success and I was thinking if anyone else would like to give it a shot. I traced its causer down the structures to struct r300_dma before struct r300_dma_region current;. This doesnt exactly mean that its in dma code but at least its a start. Unfortunately i havent found anything useful in compiler warnings and im currectly lacking ideas of how to find it... -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] nasty bug found
Aapo Tahkola wrote: Hi. I noticed that Vladimirs adition to struct r300_state caused arbvptorus to get broken pretty badly. This is pretty much similar to the bug where vb mode color buffer clears were broken. Iv been trying to figure out this for a while now with no success and I was thinking if anyone else would like to give it a shot. I traced its causer down the structures to struct r300_dma before struct r300_dma_region current;. This doesnt exactly mean that its in dma code but at least its a start. Unfortunately i havent found anything useful in compiler warnings and im currectly lacking ideas of how to find it... I would like to give it a try, but I need a simple program that triggers it. Mesa/progs/tests/arbvptorus.c is pretty much as simple as it can get. You could comment instructions after the first four DP4s and calls to glProgramLocalParameter4fARB later. Its pretty strange that when removing usage of vertex program from the example these problems go away. I didnt test with per-vertex colors though. By replacing glutSolidTorus(0.75, 2.0, 10, 20) with a glutSolidTeapot(4); you should see some errors when resizing the window. I think this is a pretty good sign in sense that fixing this might actually affect general stability of vb mode. (i had similar issues and lockups when trying to make fire_EB work) You can temporarily fix this by moving int dummy; in struct r300_dma below current as said in comments. Rune Petersen -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 fixed pipeline design
Greetings all. I noticed that the code generation for r300 fixed pipeline has just started and decided to start this discussion before the actual implementation gets going at full speed. To cut to the chase, I would like to suggest alternative implementation using mesas struct vertex_program as a placeholder for fragments. As a fragment I mean smallest possible piece of code that can be combined into final program. Some examples could be: directional light, exponental fog, ... http://www.idi.ntnu.no/grupper/su/sif8094-reports/2002/p10.pdf should give you a some idea what I mean. IMO pretty much only benefit that could be achieved by implementing fixed pipeline by using mesas structures and functions is its generality. You could make it run on any chip that supports vertex programs. And I do not only mean full pipeline but just eg. fog. Im pretty founded of the possibility that mesa could implement parts that driver wants as vertex program fallbacks like this. Im not saying that by drivers supporting vertex programs would give it support for these fallbacks as I dont think translation from mesas representation to chip specific form just isnt fast enough for single state changes. Therefore fragments should be translated into form that chip wants only once(during first state change) or upon context creation. Completely different aproach would be to have only one fragment of each type and call them to get desired results. However I havent noticed anything in r300 that would even make this even close to possible. Though I think hardware vendors move into that direction sooner or later. -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 success stories
nwn probably uses something which requires elts to be supported (ie. glDrawElements). The latest cvs snapshot has made a start on this, but more information is needed. I've had some success with ut2004 by putting the indices into the command buffer, but ultimately this is not how we want to do it. As far as i could see from the cvs-logs the elts thing was added 17 hours ago, however i tested nwn earlier and the screenshots looked the same. So it seems that this change is not responsible for this weird looking. However i now can turn on reflection in neverball without an slowdown (before i had an slowdown). I disagree. I have done tests with glDrawElements and it gets horribly broken when more than one element buffer appears. Also in quake3(full version) menus, more random vertices appear when mouse isnt visible. Test found at: http://nu.rasterburn.org/~aet/idx_2.tar.bz2 clearly shows these problems. I dont get any lockups since about a week (which seems to be strange as many others get lockups), however i do not use xorg-cvs, but ubuntus xorg-package (seems to be the latest 6.8.2-beta) with the ati.patch from r300. Is this with vertex buffers turned on? If so, can you cause a lockup by moving a window over the top of the glxgears window? This is the only way I can cause a lockup with the vertex buffer code. I'm using xorg cvs from 1-2 days before the dlloader changes. This is the exact same bug i found before support for dma moves for vbs. I was able to reproduce one bug that might be related to this. I get lock up when starting glxgears in workspace 1 and switching to workspace 2. This also happens with DEBUG=1 unlike other bugs iv seen. Hmm i must test this with an earlier snapshot, then i will report back. Greetings Jan -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] More tests...
BTW, i have added some code to do idx buffers in r300_driver. Should i commit this code or do you want to figure out this first? Ill post in more details of my findings about idx buffers in case someone wants to take a look. Hi Aapo, I had take a look at the elt code - great ! One question: are you sure it works correctly with the r300EmitAOS being passed start as the 3rd argument ? I would expect that indices want this argument to be 0 (so they are always counted from the start of the array). You are right. Unfortunately changing it doesnt seem to fix anything visible :( Im about to commit some code that allows easily to test with magic_1. Unfortunately(again) my tests so far with magic_1 != 0 has resulted in a immediate lock up. Im hoping that Marcheu will be able to dig some info about magic_2 that i suspect isnt right all the time. Unless someone comes up with a solution to these problems soon im going to remove this code from r300_driver and move this to r300_demo (replacing it with code shown in test_idx_triangles). thank you Vladimir Dergachev -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
