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_ARGB8888 | 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. > T&L 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
