Re: R300 depth buffer
Hi, First of all, you should really check out the r300_driver module from CVS of the r300 project on SourceForge, and especially have a look at docs/r300_reg.h, which is where I put all register information that I and others have found so far. On Tuesday 26 October 2004 14:18, Jerome Glisse wrote: Hi, I was playing a little around with r300 mainly looking at depth buffer. I'm still unable to make it work properly. Thus i have few questions. In radeon driver it seems that default value for z_scale z_offset are 0 (radeon/radeon_state_init.c) Why are they set like that ? I changed the depth in order to have something more conveniant on screen : adaptor.depth_pitch=display_width | (0x8 16); maybe better to write it as : adaptor.depth_pitch=display_width | (0x4 17); As long as we don't know what these constants mean, is there really a difference? in void Emit3dRegs(void) i used informations from radeon register. /* do not enable either of stencil, Z or anything else */ e32(CP_PACKET0(RADEON_RB3D_CNTL,0)); e32(RADEON_COLOR_FORMAT_ARGB | RADEON_Z_ENABLE); e32(CP_PACKET0(RADEON_RB3D_ZSTENCILCNTL,0)); e32(RADEON_Z_WRITE_ENABLE | RADEON_DEPTH_FORMAT_32BIT_FLOAT_Z | RADEON_Z_TEST_LESS); Basically everything in the 3D hardware interface has changed from R200 to R300, so the above almost certainly doesn't do what you want. Again, have a look at r300_reg.h Also, my work-in-progress driver can already clear the depth buffer in hardware in a way that is consistent with the software fallback, so you can have a look at how the registers are set up there, in r300_ioctl.c and r300_state.c. Maybe we should put somewhere a list of things to find and who is working on it, thus people won't work on the same things in the mean time or they could work together more eviciently. Also maybe it could be usefull to make a plan of things we want to discover. z buffer stencil buffer That would be very helpful. I haven't looked at stencil settings at all, and I'm kind of confused about the Z-buffer format. The R300 seems to use ZZZS format for 24bit depth/8bit stencil where the R300 used SZZZ. matrix stack for modelview, projection texture (is the information of radeon enought ?) I think I've pretty much got that down. The R300 has a very flexible programmable vertex processor, and the driver is responsible for setting up the correct matrices. TL route Again, I think I've got most of that down. If you could help with texture specification/formats, I'd be very thankful. The register addresses are already in r300_reg.h, but the texture format itself, how mipmaps work etc. is still a mystery. I think with this feature we could make a quite good first hardware accelerated driver. By the way i find that clear_depth_buffer clear_color_buffer are quite complex. Is all the stuff they have in really necessary ? (i will try to look at that latter but if someone already done it). No, most of those are redundant state updates produced by ATI's proprietary driver. Again, look at how the work-in-progress DRI driver does it. Oh yes i almost forgot :) my device id is 0x4e4a (it is a radeon 9800) I've added this and other IDs from pciids.sf.net to the experimental driver in r300_driver/drm cu, Nicolai Jerome Glisse pgpvsr9MCtyY6.pgp Description: PGP signature
Re: R300 depth buffer
Vladimir Dergachev wrote: Hi Jerome, I just have a moment, so I likely missed some of the questions in the e-mail. I just want to point out that the example in r300_demo that paints triangles is likely wrong. You see it uses parameters to upload vertex coordinates. I would have expected that those are actually uploaded using corresponding CP_PACKET3 call (it is inside the setup function). This would certainly be needed for indices and such. So this function is best refactored.. best Vladimir Dergachev Thus i will try to check if i can find the correct way to send vertex coordinates. I was confident that was the correct way :). For the adaptator pitch i think the good way to setup it is : adaptor.depth_pitch=(display_widthRADEON_DEPTHPITCH_MASK) | RADEON_DEPTH_ENDIAN_NO_SWAP; This came from r200 driver. Jerome Glisse --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 depth buffer
Hi Jerome, I just have a moment, so I likely missed some of the questions in the e-mail. I just want to point out that the example in r300_demo that paints triangles is likely wrong. You see it uses parameters to upload vertex coordinates. I would have expected that those are actually uploaded using corresponding CP_PACKET3 call (it is inside the setup function). This would certainly be needed for indices and such. So this function is best refactored.. best Vladimir Dergachev On Tue, 26 Oct 2004, Jerome Glisse wrote: Hi, I was playing a little around with r300 mainly looking at depth buffer. I'm still unable to make it work properly. Thus i have few questions. In radeon driver it seems that default value for z_scale z_offset are 0 (radeon/radeon_state_init.c) Why are they set like that ? I changed the depth in order to have something more conveniant on screen : adaptor.depth_pitch=display_width | (0x8 16); maybe better to write it as : adaptor.depth_pitch=display_width | (0x4 17); in void Emit3dRegs(void) i used informations from radeon register. /* do not enable either of stencil, Z or anything else */ e32(CP_PACKET0(RADEON_RB3D_CNTL,0)); e32(RADEON_COLOR_FORMAT_ARGB | RADEON_Z_ENABLE); e32(CP_PACKET0(RADEON_RB3D_ZSTENCILCNTL,0)); e32(RADEON_Z_WRITE_ENABLE | RADEON_DEPTH_FORMAT_32BIT_FLOAT_Z | RADEON_Z_TEST_LESS); You can find a screenshot here where we see the depth buffer triangle drawn in depth buffer : http://www.iteam.org/~lebowski/r300_depth.png The triangle are drawn in the order they are send. The white blue triangle should be cover by the colored triangle. Did i miss something somewhere in order to activate the depth buffer or to make it works properly. If anyone has a clue. Maybe we should put somewhere a list of things to find and who is working on it, thus people won't work on the same things in the mean time or they could work together more eviciently. Also maybe it could be usefull to make a plan of things we want to discover. z buffer stencil buffer matrix stack for modelview, projection texture (is the information of radeon enought ?) TL route I think with this feature we could make a quite good first hardware accelerated driver. By the way i find that clear_depth_buffer clear_color_buffer are quite complex. Is all the stuff they have in really necessary ? (i will try to look at that latter but if someone already done it). Oh yes i almost forgot :) my device id is 0x4e4a (it is a radeon 9800) Jerome Glisse --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
