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