mesa3d-dev

[Mesa3d-dev] radeon-rewrite branch merging.

[Dave A. <ai...@li...>]

Hi,

So I have a goal to get a radeon driver that works on a bufmgr and that 
then can be used on non-mm/mm, and also where I can make DRI2 and FBOs 
work.

So with that in mind and not wanting to write this 3 times, I've done a 
major refactoring of the radeon/r200/r300 drivers.

I've refactored all the:
buffer management,
buffer swap + copy,
texture and mipmap management,
command submission handling,
state + atom emission
dma buffers,
lock code,

into common files for all 3 drivers, and re-used the same code in nearly 
the same ways across all 3.

So far I've been working on getting the legacy buffer/command code into 
shape so I can merge this in place of the current drivers without 
suffering any major regressions. Then start adding the code necessary for 
DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to 
merge, I'd like people to bash on it, and report any major regressions 
above the current r100/r200/r300 codebases with these drivers.

In order to get the mm/dri2 stuff working, I mainly need to 
1. get libdrm_radeon into a happy place. You don't require libdrm_radeon
for this stuff at all I've made wrappers that I just need to use some 
magic to hook up.
2. add userspace clear paths for r100/r200.
3. fix lockups from DRI2 lockless :)
4. make it go fast.

Most of the code was written by Nicolai and Jerome, I've just spent 2-3 
weeks moving it around the place until it works!!

I've done a series of piglit regressions and I have one or two to fix, but 
it seems to be only a couple left.

Also any suggestions for things I should use to test this? I've mainly 
been doing piglit + gears + ipers + openarena when I can.

Dave. 

Re: [Mesa3d-dev] radeon-rewrite branch merging.

[Eric A. <er...@an...>]

On Thu, 2009-02-12 at 05:29 +0000, Dave Airlie wrote:
> Hi,
> 
> So I have a goal to get a radeon driver that works on a bufmgr and that 
> then can be used on non-mm/mm, and also where I can make DRI2 and FBOs 
> work.
> 
> So with that in mind and not wanting to write this 3 times, I've done a 
> major refactoring of the radeon/r200/r300 drivers.
> 
> I've refactored all the:
> buffer management,
> buffer swap + copy,
> texture and mipmap management,
> command submission handling,
> state + atom emission
> dma buffers,
> lock code,
> 
> into common files for all 3 drivers, and re-used the same code in nearly 
> the same ways across all 3.
> 
> So far I've been working on getting the legacy buffer/command code into 
> shape so I can merge this in place of the current drivers without 
> suffering any major regressions. Then start adding the code necessary for 
> DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to 
> merge, I'd like people to bash on it, and report any major regressions 
> above the current r100/r200/r300 codebases with these drivers.
> 
> In order to get the mm/dri2 stuff working, I mainly need to 
> 1. get libdrm_radeon into a happy place. You don't require libdrm_radeon
> for this stuff at all I've made wrappers that I just need to use some 
> magic to hook up.
> 2. add userspace clear paths for r100/r200.
> 3. fix lockups from DRI2 lockless :)
> 4. make it go fast.
> 
> Most of the code was written by Nicolai and Jerome, I've just spent 2-3 
> weeks moving it around the place until it works!!
> 
> I've done a series of piglit regressions and I have one or two to fix, but 
> it seems to be only a couple left.
> 
> Also any suggestions for things I should use to test this? I've mainly 
> been doing piglit + gears + ipers + openarena when I can.

You might want to just steal intel_clear.c for the userspace clear path.
Bonus points if you actually move it somewhere appropriate in Mesa.

sauerbraten's a nice open-source game that works the driver a lot harder
than openarena does.

When you get to fbos, the gl branch of my cairo tree plus the gl branch
of my cairogears tree is mostly memory management and fbo handling right
now (until I fix it, then we'll hopefully need a more complicated
testcase than gears to actually hit it hard).

-- 
Eric Anholt
er...@an...                         eri...@in...

Re: [Mesa3d-dev] radeon-rewrite branch merging.

[Dave A. <ai...@li...>]

> Hi,
> 
> So I have a goal to get a radeon driver that works on a bufmgr and that 
> then can be used on non-mm/mm, and also where I can make DRI2 and FBOs 
> work.

r200 appears busted, but its wierd busted I'll blame the master merge and 
fix it tomorrow.

Dave.

> 
> So with that in mind and not wanting to write this 3 times, I've done a 
> major refactoring of the radeon/r200/r300 drivers.
> 
> I've refactored all the:
> buffer management,
> buffer swap + copy,
> texture and mipmap management,
> command submission handling,
> state + atom emission
> dma buffers,
> lock code,
> 
> into common files for all 3 drivers, and re-used the same code in nearly 
> the same ways across all 3.
> 
> So far I've been working on getting the legacy buffer/command code into 
> shape so I can merge this in place of the current drivers without 
> suffering any major regressions. Then start adding the code necessary for 
> DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to 
> merge, I'd like people to bash on it, and report any major regressions 
> above the current r100/r200/r300 codebases with these drivers.
> 
> In order to get the mm/dri2 stuff working, I mainly need to 
> 1. get libdrm_radeon into a happy place. You don't require libdrm_radeon
> for this stuff at all I've made wrappers that I just need to use some 
> magic to hook up.
> 2. add userspace clear paths for r100/r200.
> 3. fix lockups from DRI2 lockless :)
> 4. make it go fast.
> 
> Most of the code was written by Nicolai and Jerome, I've just spent 2-3 
> weeks moving it around the place until it works!!
> 
> I've done a series of piglit regressions and I have one or two to fix, but 
> it seems to be only a couple left.
> 
> Also any suggestions for things I should use to test this? I've mainly 
> been doing piglit + gears + ipers + openarena when I can.
> 
> Dave. 
> 
> 
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> --
> _______________________________________________
> Dri-devel mailing list
> Dri...@li...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
> 
> 

Re: [Mesa3d-dev] radeon-rewrite branch merging.

[Dave A. <ai...@li...>]

> 
> r200 appears busted, but its wierd busted I'll blame the master merge and 
> fix it tomorrow.

Okay r200 gears is back, I think it was an artifact of not getting a clean 
build, along with fixing some warnings.

Dave.
> 
> Dave.
> 
> > 
> > So with that in mind and not wanting to write this 3 times, I've done a 
> > major refactoring of the radeon/r200/r300 drivers.
> > 
> > I've refactored all the:
> > buffer management,
> > buffer swap + copy,
> > texture and mipmap management,
> > command submission handling,
> > state + atom emission
> > dma buffers,
> > lock code,
> > 
> > into common files for all 3 drivers, and re-used the same code in nearly 
> > the same ways across all 3.
> > 
> > So far I've been working on getting the legacy buffer/command code into 
> > shape so I can merge this in place of the current drivers without 
> > suffering any major regressions. Then start adding the code necessary for 
> > DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to 
> > merge, I'd like people to bash on it, and report any major regressions 
> > above the current r100/r200/r300 codebases with these drivers.
> > 
> > In order to get the mm/dri2 stuff working, I mainly need to 
> > 1. get libdrm_radeon into a happy place. You don't require libdrm_radeon
> > for this stuff at all I've made wrappers that I just need to use some 
> > magic to hook up.
> > 2. add userspace clear paths for r100/r200.
> > 3. fix lockups from DRI2 lockless :)
> > 4. make it go fast.
> > 
> > Most of the code was written by Nicolai and Jerome, I've just spent 2-3 
> > weeks moving it around the place until it works!!
> > 
> > I've done a series of piglit regressions and I have one or two to fix, but 
> > it seems to be only a couple left.
> > 
> > Also any suggestions for things I should use to test this? I've mainly 
> > been doing piglit + gears + ipers + openarena when I can.
> > 
> > Dave. 
> > 
> > 
> > ------------------------------------------------------------------------------
> > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> > software. With Adobe AIR, Ajax developers can use existing skills and code to
> > build responsive, highly engaging applications that combine the power of local
> > resources and data with the reach of the web. Download the Adobe AIR SDK and
> > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> > --
> > _______________________________________________
> > Dri-devel mailing list
> > Dri...@li...
> > https://lists.sourceforge.net/lists/listinfo/dri-devel
> > 
> > 
> 
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> --
> _______________________________________________
> Dri-devel mailing list
> Dri...@li...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
> 
> 

Re: [Mesa3d-dev] radeon-rewrite branch merging.

[Michel D. <mi...@da...>]

On Thu, 2009-02-12 at 05:29 +0000, Dave Airlie wrote:
> 
> So I have a goal to get a radeon driver that works on a bufmgr and that 
> then can be used on non-mm/mm, and also where I can make DRI2 and FBOs 
> work.
> 
> So with that in mind and not wanting to write this 3 times, I've done a 
> major refactoring of the radeon/r200/r300 drivers.
> 
> I've refactored all the:
> buffer management,
> buffer swap + copy,
> texture and mipmap management,
> command submission handling,
> state + atom emission
> dma buffers,
> lock code,
> 
> into common files for all 3 drivers, and re-used the same code in nearly 
> the same ways across all 3.
> 
> So far I've been working on getting the legacy buffer/command code into 
> shape so I can merge this in place of the current drivers without 
> suffering any major regressions. Then start adding the code necessary for 
> DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to 
> merge, I'd like people to bash on it, and report any major regressions 
> above the current r100/r200/r300 codebases with these drivers.

With the endianness fix below, it basically works for me. However, page
flipping is broken, looks like it always renders to the same buffer
regardless of which one is being displayed.

With gliv, I got quite broken rendering (though that could just be due
to the page flipping issues), several different error messages from the
3D driver and eventually a lockup (so unfortunately I lost the error
messages).

So I'm not sure it's quite ready to merge yet, but I have to say it's
amazing what you guys have achieved. :)


>From c4014baa4c8593f98e176af25590c99898b235ca Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michel=20D=C3=A4nzer?= <da...@vm...>
Date: Thu, 12 Feb 2009 10:08:47 +0100
Subject: r300: Fix R300_CMD_SCRATCH on big endian.

---
 src/mesa/drivers/dri/radeon/radeon_cs_drm.h    |   10 ++++++++++
 src/mesa/drivers/dri/radeon/radeon_cs_legacy.c |    3 +--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/radeon/radeon_cs_drm.h b/src/mesa/drivers/dri/radeon/radeon_cs_drm.h
index 8f0b449..6cc9daa 100644
--- a/src/mesa/drivers/dri/radeon/radeon_cs_drm.h
+++ b/src/mesa/drivers/dri/radeon/radeon_cs_drm.h
@@ -33,6 +33,7 @@
 #define RADEON_CS_H
 
 #include <stdint.h>
+#include "main/imports.h"
 #include "drm.h"
 #include "radeon_drm.h"
 
@@ -194,4 +195,13 @@ static inline void radeon_cs_write_dword(struct radeon_cs *cs, uint32_t dword)
     }
 }
 
+static inline void radeon_cs_write_qword(struct radeon_cs *cs, uint64_t qword)
+{
+    _mesa_memcpy(cs->packets + cs->cdw, &qword, sizeof(qword));
+    cs->cdw += 2;
+    if (cs->section) {
+        cs->section_cdw += 2;
+    }
+}
+
 #endif
diff --git a/src/mesa/drivers/dri/radeon/radeon_cs_legacy.c b/src/mesa/drivers/dri/radeon/radeon_cs_legacy.c
index 0f73dec..aa95d86 100644
--- a/src/mesa/drivers/dri/radeon/radeon_cs_legacy.c
+++ b/src/mesa/drivers/dri/radeon/radeon_cs_legacy.c
@@ -288,8 +288,7 @@ static int cs_emit(struct radeon_cs *cs)
       age.scratch.n_bufs = 1;
       age.scratch.flags = 0;
       radeon_cs_write_dword(cs, age.u);
-      radeon_cs_write_dword(cs, ull & 0xffffffff);
-      radeon_cs_write_dword(cs, ull >> 32);
+      radeon_cs_write_qword(cs, ull);
       radeon_cs_write_dword(cs, 0);
     }
 
-- 
1.6.1.2



-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [Mesa3d-dev] radeon-rewrite branch merging.

[Roland S. <sr...@vm...>]

On 12.02.2009 06:29, Dave Airlie wrote:
> Hi,
> 
> So I have a goal to get a radeon driver that works on a bufmgr and that 
> then can be used on non-mm/mm, and also where I can make DRI2 and FBOs 
> work.
> 
> So with that in mind and not wanting to write this 3 times, I've done a 
> major refactoring of the radeon/r200/r300 drivers.
> 
> I've refactored all the:
> buffer management,
> buffer swap + copy,
> texture and mipmap management,
> command submission handling,
> state + atom emission
> dma buffers,
> lock code,
> 
> into common files for all 3 drivers, and re-used the same code in nearly 
> the same ways across all 3.
> 
> So far I've been working on getting the legacy buffer/command code into 
> shape so I can merge this in place of the current drivers without 
> suffering any major regressions. Then start adding the code necessary for 
> DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to 
> merge, I'd like people to bash on it, and report any major regressions 
> above the current r100/r200/r300 codebases with these drivers.
> 
> In order to get the mm/dri2 stuff working, I mainly need to 
> 1. get libdrm_radeon into a happy place. You don't require libdrm_radeon
> for this stuff at all I've made wrappers that I just need to use some 
> magic to hook up.
> 2. add userspace clear paths for r100/r200.
> 3. fix lockups from DRI2 lockless :)
> 4. make it go fast.
> 
> Most of the code was written by Nicolai and Jerome, I've just spent 2-3 
> weeks moving it around the place until it works!!
> 
> I've done a series of piglit regressions and I have one or two to fix, but 
> it seems to be only a couple left.
> 
> Also any suggestions for things I should use to test this? I've mainly 
> been doing piglit + gears + ipers + openarena when I can.
> 
> Dave. 

Quite impressive!
Not spent too much time on it, but a couple of comments:
Are you sure the tiling patterns for r100/r200/r300 are really the same
for depth buffers in the span code? I thought they were different,
though maybe just the code was different...
Also, texture tiling is gone for now? A pity as it really makes some
performance difference (for uncompressed textures at least). Well if it
can be added back easily later (though IIRC there were some gruesome
differences between r100/r200 there) I don't care too much.
I think that you should not allow passing texture formats to
radeonChooseTextureFormats the hardware can't handle (float formats on
r100/r200) and return an error instead.

Roland

Re: [Mesa3d-dev] radeon-rewrite branch merging.

[Dave A. <ai...@li...>]

> > Compressed textures also seem to be broken, since they'll raise a FPE:
> > Program received signal SIGFPE, Arithmetic exception.
> > [Switching to Thread -1480239424 (LWP 11180)]
> > 0x9c80da1d in radeon_miptree_create (rmesa=0x9499c48, t=0x9909e80,
> > target=3553, firstLevel=0,
> >     lastLevel=10, width0=1024, height0=1024, depth0=1, bpp=0,
> > tilebits=0, compressed=38)
> >     at radeon_mipmap_tree.c:79
> > 79                              align = 32 / mt->bpp;
> >
> > bpp is derived initially from TexelBytes, which is always 0 for
> > compressed textures.
> 
> I'm probably to blame for that.

I think I've fixed it now, but I'd really appreciate a review of the 
changes I made.

texcmp passes on r200 for me here now.

Dave.

Re: [Mesa3d-dev] radeon-rewrite branch merging.

[Roland S. <sr...@vm...>]

On 13.02.2009 05:49, Dave Airlie wrote:
>>> Compressed textures also seem to be broken, since they'll raise a FPE:
>>> Program received signal SIGFPE, Arithmetic exception.
>>> [Switching to Thread -1480239424 (LWP 11180)]
>>> 0x9c80da1d in radeon_miptree_create (rmesa=0x9499c48, t=0x9909e80,
>>> target=3553, firstLevel=0,
>>>     lastLevel=10, width0=1024, height0=1024, depth0=1, bpp=0,
>>> tilebits=0, compressed=38)
>>>     at radeon_mipmap_tree.c:79
>>> 79                              align = 32 / mt->bpp;
>>>
>>> bpp is derived initially from TexelBytes, which is always 0 for
>>> compressed textures.
>> I'm probably to blame for that.
> 
> I think I've fixed it now, but I'd really appreciate a review of the 
> changes I made.
> 
> texcmp passes on r200 for me here now.

Seems to work for quick quake3 timedemo run too.
btw I no longer get the busy loop in legacy_wait_pending. page flip
seems broken for glxgears, but working in quake3 (?). rtcw:et doesn't
work however, the intro and main menu work alright despite there are
lots of these messages:
CS section end at (r200_cmdbuf.c,r200FireEB,161)
CS section size missmatch start at (r200_cmdbuf.c,r200FireEB,138) 8 vs 10
But these continue ingame (radar timedemo) and the output is mostly
(well sometimes it's possible to see what it should look like) a mess of
random triangles - at least it didn't hang :-).

Roland

Re: [Mesa3d-dev] radeon-rewrite branch merging.

[Roland S. <sr...@vm...>]

On 12.02.2009 13:48, Roland Scheidegger wrote:
> On 12.02.2009 06:29, Dave Airlie wrote:
>> Hi,
>>
>> So I have a goal to get a radeon driver that works on a bufmgr and that 
>> then can be used on non-mm/mm, and also where I can make DRI2 and FBOs 
>> work.
>>
>> So with that in mind and not wanting to write this 3 times, I've done a 
>> major refactoring of the radeon/r200/r300 drivers.
>>
>> I've refactored all the:
>> buffer management,
>> buffer swap + copy,
>> texture and mipmap management,
>> command submission handling,
>> state + atom emission
>> dma buffers,
>> lock code,
>>
>> into common files for all 3 drivers, and re-used the same code in nearly 
>> the same ways across all 3.
>>
>> So far I've been working on getting the legacy buffer/command code into 
>> shape so I can merge this in place of the current drivers without 
>> suffering any major regressions. Then start adding the code necessary for 
>> DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to 
>> merge, I'd like people to bash on it, and report any major regressions 
>> above the current r100/r200/r300 codebases with these drivers.
>>
>> In order to get the mm/dri2 stuff working, I mainly need to 
>> 1. get libdrm_radeon into a happy place. You don't require libdrm_radeon
>> for this stuff at all I've made wrappers that I just need to use some 
>> magic to hook up.
>> 2. add userspace clear paths for r100/r200.
>> 3. fix lockups from DRI2 lockless :)
>> 4. make it go fast.
>>
>> Most of the code was written by Nicolai and Jerome, I've just spent 2-3 
>> weeks moving it around the place until it works!!
>>
>> I've done a series of piglit regressions and I have one or two to fix, but 
>> it seems to be only a couple left.
>>
>> Also any suggestions for things I should use to test this? I've mainly 
>> been doing piglit + gears + ipers + openarena when I can.
>>
>> Dave. 
> 
> Quite impressive!
> Not spent too much time on it, but a couple of comments:
> Are you sure the tiling patterns for r100/r200/r300 are really the same
> for depth buffers in the span code? I thought they were different,
> though maybe just the code was different...
> Also, texture tiling is gone for now? A pity as it really makes some
> performance difference (for uncompressed textures at least). Well if it
> can be added back easily later (though IIRC there were some gruesome
> differences between r100/r200 there) I don't care too much.
> I think that you should not allow passing texture formats to
> radeonChooseTextureFormats the hardware can't handle (float formats on
> r100/r200) and return an error instead.

Compressed textures also seem to be broken, since they'll raise a FPE:
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread -1480239424 (LWP 11180)]
0x9c80da1d in radeon_miptree_create (rmesa=0x9499c48, t=0x9909e80,
target=3553, firstLevel=0,
    lastLevel=10, width0=1024, height0=1024, depth0=1, bpp=0,
tilebits=0, compressed=38)
    at radeon_mipmap_tree.c:79
79                              align = 32 / mt->bpp;

bpp is derived initially from TexelBytes, which is always 0 for
compressed textures.

Roland

Re: [Mesa3d-dev] radeon-rewrite branch merging.

[Roland S. <sr...@tu...>]

On 12.02.2009 15:10, Roland Scheidegger wrote:
> On 12.02.2009 13:48, Roland Scheidegger wrote:
>> On 12.02.2009 06:29, Dave Airlie wrote:
>>> Hi,
>>>
>>> So I have a goal to get a radeon driver that works on a bufmgr and that 
>>> then can be used on non-mm/mm, and also where I can make DRI2 and FBOs 
>>> work.
>>>
>>> So with that in mind and not wanting to write this 3 times, I've done a 
>>> major refactoring of the radeon/r200/r300 drivers.
>>>
>>> I've refactored all the:
>>> buffer management,
>>> buffer swap + copy,
>>> texture and mipmap management,
>>> command submission handling,
>>> state + atom emission
>>> dma buffers,
>>> lock code,
>>>
>>> into common files for all 3 drivers, and re-used the same code in nearly 
>>> the same ways across all 3.
>>>
>>> So far I've been working on getting the legacy buffer/command code into 
>>> shape so I can merge this in place of the current drivers without 
>>> suffering any major regressions. Then start adding the code necessary for 
>>> DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to 
>>> merge, I'd like people to bash on it, and report any major regressions 
>>> above the current r100/r200/r300 codebases with these drivers.
>>>
>>> In order to get the mm/dri2 stuff working, I mainly need to 
>>> 1. get libdrm_radeon into a happy place. You don't require libdrm_radeon
>>> for this stuff at all I've made wrappers that I just need to use some 
>>> magic to hook up.
>>> 2. add userspace clear paths for r100/r200.
>>> 3. fix lockups from DRI2 lockless :)
>>> 4. make it go fast.
>>>
>>> Most of the code was written by Nicolai and Jerome, I've just spent 2-3 
>>> weeks moving it around the place until it works!!
>>>
>>> I've done a series of piglit regressions and I have one or two to fix, but 
>>> it seems to be only a couple left.
>>>
>>> Also any suggestions for things I should use to test this? I've mainly 
>>> been doing piglit + gears + ipers + openarena when I can.
>>>
>>> Dave. 
>> Quite impressive!
>> Not spent too much time on it, but a couple of comments:
>> Are you sure the tiling patterns for r100/r200/r300 are really the same
>> for depth buffers in the span code? I thought they were different,
>> though maybe just the code was different...
>> Also, texture tiling is gone for now? A pity as it really makes some
>> performance difference (for uncompressed textures at least). Well if it
>> can be added back easily later (though IIRC there were some gruesome
>> differences between r100/r200 there) I don't care too much.
>> I think that you should not allow passing texture formats to
>> radeonChooseTextureFormats the hardware can't handle (float formats on
>> r100/r200) and return an error instead.
> 
> Compressed textures also seem to be broken, since they'll raise a FPE:
> Program received signal SIGFPE, Arithmetic exception.
> [Switching to Thread -1480239424 (LWP 11180)]
> 0x9c80da1d in radeon_miptree_create (rmesa=0x9499c48, t=0x9909e80,
> target=3553, firstLevel=0,
>     lastLevel=10, width0=1024, height0=1024, depth0=1, bpp=0,
> tilebits=0, compressed=38)
>     at radeon_mipmap_tree.c:79
> 79                              align = 32 / mt->bpp;
> 
> bpp is derived initially from TexelBytes, which is always 0 for
> compressed textures.

Hmm more bugs, pretty much everything I try on r200 (that includes
glxgears) gets infinitely stuck in legacy_wait_pending after a frame or two.

Roland

Re: [Mesa3d-dev] radeon-rewrite branch merging.

[Nicolai H. <nha...@gm...>]

Am Donnerstag 12 Februar 2009 15:10:11 schrieb Roland Scheidegger:
> Compressed textures also seem to be broken, since they'll raise a FPE:
> Program received signal SIGFPE, Arithmetic exception.
> [Switching to Thread -1480239424 (LWP 11180)]
> 0x9c80da1d in radeon_miptree_create (rmesa=0x9499c48, t=0x9909e80,
> target=3553, firstLevel=0,
>     lastLevel=10, width0=1024, height0=1024, depth0=1, bpp=0,
> tilebits=0, compressed=38)
>     at radeon_mipmap_tree.c:79
> 79                              align = 32 / mt->bpp;
>
> bpp is derived initially from TexelBytes, which is always 0 for
> compressed textures.

I'm probably to blame for that.

I will take a look at it this weekend.

cu,
Nicolai

Re: [Mesa3d-dev] radeon-rewrite branch merging.

[Nicolai H. <nha...@gm...>]

Hi,

Am Donnerstag 12 Februar 2009 06:29:27 schrieb Dave Airlie:
> So I have a goal to get a radeon driver that works on a bufmgr and that
> then can be used on non-mm/mm, and also where I can make DRI2 and FBOs
> work.

Yay!

[snip]
> So far I've been working on getting the legacy buffer/command code into
> shape so I can merge this in place of the current drivers without
> suffering any major regressions. Then start adding the code necessary for
> DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to
> merge, I'd like people to bash on it, and report any major regressions
> above the current r100/r200/r300 codebases with these drivers.

Tested on an X800 and X1650 (both AGP, both TCL).

I'm running with
- kernel from your drm-rawhide branch on kernel.org, but modeset=0
- xf86-video-ati from your radeon-gem-cs2 branch
- completely bare X: only an xterm is running, no window manager
However, I have been testing with modeset disabled.

I've been testing with piglit, openarena, glest, sauerbraten (and fixing some 
bugs along the way), and I don't see any regressions any more. However, on the 
X1650, I get an error from the X server like this:

  (EE) RADEON(0): Unable to reserve offscreen area for back buffer, you might
  experience screen corruption

It occurs every time a GL context is created. It doesn't seem to cause any 
problems, however, and may be more related to the DDX changes than the Mesa 
changes.

So from an r300 perspective, this seems pretty merge-ready to me.

cu,
Nicolai

Re: [Mesa3d-dev] radeon-rewrite branch merging.

[Michel D. <mi...@da...>]

On Thu, 2009-02-12 at 11:00 +0100, Michel Dänzer wrote:
> On Thu, 2009-02-12 at 05:29 +0000, Dave Airlie wrote:
> > 
> > So far I've been working on getting the legacy buffer/command code into 
> > shape so I can merge this in place of the current drivers without 
> > suffering any major regressions. Then start adding the code necessary for 
> > DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to 
> > merge, I'd like people to bash on it, and report any major regressions 
> > above the current r100/r200/r300 codebases with these drivers.
> 
> With the endianness fix below, it basically works for me. However, page
> flipping is broken, looks like it always renders to the same buffer
> regardless of which one is being displayed.
> 
> With gliv, I got quite broken rendering (though that could just be due
> to the page flipping issues), several different error messages from the
> 3D driver and eventually a lockup (so unfortunately I lost the error
> messages).
> 
> So I'm not sure it's quite ready to merge yet, but I have to say it's
> amazing what you guys have achieved. :)

Things seem to have improved nicely over the last month. :)

With the fix below, the only issue I noticed in a quick test of compiz,
xmoto and gliv is that there's a lot of messages like

CS section size missmatch start at (r300_cmdbuf.c,emit_tex_offsets,186)
4 vs 2
CS section end at (r300_cmdbuf.c,emit_tex_offsets,206)

(with 4 vs 2 sometimes replaced by other pairs of x vs x/2)

I briefly looked into fixing this but couldn't figure it out.

Once this is fixed though, the branch looks good to merge from my POV.


>From 9b92c57c969fea3d32145a2b284d011735a0be20 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michel=20D=C3=A4nzer?= <da...@vm...>
Date: Thu, 5 Mar 2009 11:52:49 +0100
Subject: radeon: Take the hardware lock for swaps and flips.

Otherwise they fail with AIGLX at least.
---
 src/mesa/drivers/dri/radeon/radeon_common.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/radeon/radeon_common.c b/src/mesa/drivers/dri/radeon/radeon_common.c
index 99270c9..5ee8627 100644
--- a/src/mesa/drivers/dri/radeon/radeon_common.c
+++ b/src/mesa/drivers/dri/radeon/radeon_common.c
@@ -420,6 +420,7 @@ void radeonCopyBuffer( __DRIdrawablePrivate *dPriv,
 		fprintf( stderr, "\n%s( %p )\n\n", __FUNCTION__, (void *) rmesa->glCtx );
 	}
 
+	LOCK_HARDWARE( rmesa );
 	nbox = dPriv->numClipRects; /* must be in locked region */
 
 	for ( i = 0 ; i < nbox ; ) {
@@ -509,6 +510,8 @@ static GLboolean radeonPageFlip( __DRIdrawablePrivate *dPriv )
 
 	psp = dPriv->driScreenPriv;
 
+	LOCK_HARDWARE( radeon );
+
 	if ( RADEON_DEBUG & DEBUG_IOCTL ) {
 		fprintf(stderr, "%s: pfCurrentPage: %d %d\n", __FUNCTION__,
 			radeon->sarea->pfCurrentPage, radeon->sarea->pfState);
-- 
1.6.2



-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [Mesa3d-dev] radeon-rewrite branch merging.

[Michel D. <mi...@da...>]

Another issue starting qtdemo from Qt 4.5:

qtdemo: radeon_lock.c:66: radeonGetLock: Assertion `drawable != ((void *)0)' failed.

Program received signal SIGABRT, Aborted.
0x0ec9542c in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
	in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0x0ec9542c in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x0ec970c4 in *__GI_abort () at abort.c:88
#2  0x0ec8c328 in *__GI___assert_fail (assertion=0xde7f744 "drawable != ((void *)0)", file=0xde7f75c "radeon_lock.c", line=66, function=0xde7f734 "radeonGetLock") at assert.c:78
#3  0x0dcb42b4 in radeonGetLock (rmesa=0x100f0d20, flags=<value optimized out>) at radeon_lock.c:66
#4  0x0dcb4348 in radeon_lock_hardware (radeon=<value optimized out>) at radeon_lock.c:112
#5  0x0dcb113c in rcommonFlushCmdBuf (rmesa=0x100f0d20, caller=0xde79854 "r300DestroyContext") at radeon_common.c:997
#6  0x0dc8168c in r300DestroyContext (driContextPriv=<value optimized out>) at r300_context.c:496
#7  0x0dc80124 in radeonDestroyContext (driContextPriv=<value optimized out>) at radeon_screen.c:1393
#8  0x0dc78f8c in driDestroyContext (pcp=0x100ebcc8) at ../common/dri_util.c:531
#9  0x0e8e8804 in driDestroyContext (context=0x100b5d08, psc=<value optimized out>, dpy=<value optimized out>) at dri_glx.c:444
#10 0x0e8b7ac8 in DestroyContext (dpy=0x10078c50, gc=0x100a7e38) at glxcmds.c:528
#11 0x0fe7e8e4 in QGLContext::reset (this=0x100a85b8) at qgl_x11.cpp:640
#12 0x0fe47098 in ~QGLContext (this=0x100a85b8) at qgl.cpp:1532
#13 0x0fe40c3c in ~QGLWidget (this=0x6f8281b8) at qgl.cpp:2795
#14 0x1002f2d0 in ?? ()
#15 0x10030190 in ?? ()
#16 0x1000b344 in ?? ()
#17 0x0ec7cae4 in generic_start_main (main=0x1000b2f0 <_init+448>, argc=1, ubp_av=0x6f828644, auxvec=0x6f828758, init=0x10034160, fini=<value optimized out>, rtld_fini=<value optimized out>, 
    stack_end=<value optimized out>) at ../csu/libc-start.c:222
#18 0x0ec7cca0 in __libc_start_main (argc=<value optimized out>, ubp_av=<value optimized out>, ubp_ev=<value optimized out>, auxvec=<value optimized out>, rtld_fini=<value optimized out>, 
    stinfo=<value optimized out>, stack_on_entry=<value optimized out>) at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:92
#19 0x00000000 in ?? ()


Works with master.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer