Re: [Mesa3d-dev] radeon-rewrite branch merging.
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 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] radeon-rewrite branch merging.
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 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] radeon-rewrite branch merging.
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 -- 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
Re: [Mesa3d-dev] radeon-rewrite branch merging.
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
Re: [Mesa3d-dev] radeon-rewrite branch merging.
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
Re: [Mesa3d-dev] radeon-rewrite branch merging.
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 -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] radeon-rewrite branch merging.
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. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] radeon-rewrite branch merging.
On Thu, 2009-02-12 at 05: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. 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 e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- 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
