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
------------------------------------------------------------------------------
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-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
