From: Jacek R. <pa...@fa...> - 2005-01-28 08:51:30
|
Hi, I have some questions about r200 depth tiling. Generally I'm also interested in r100 tiling too, but currently i work on r200. First of all in functions r200_mba_z16|32 from r200_span.c frontPitch offset is used. Is it intentional or just because depthOffset is also the same? Maybe it should be depthOffset? Depth tiles on r200 are 32x16 or 64x16, depending on FB depth, right? I don't quite follow third line before last? Can someone enlighten me? TIA. Generally if one could explain tiling a bit for me I would be grateful. What I'm trying to do is to is to modify depthOffset to be as close to top-left corner of viewport as possible and modify. I this possible with shared depth buffer. This means that each 3D window would have different depthOffset but pointing to the same shared buffer. Best, -- Jacek Rosik <pa...@fa...> |
From: Roland S. <rsc...@hi...> - 2005-01-28 15:27:43
|
Jacek Rosik wrote: > Hi, > > I have some questions about r200 depth tiling. Generally I'm also > interested in r100 tiling too, but currently i work on r200. > > First of all in functions r200_mba_z16|32 from r200_span.c frontPitch > offset is used. Is it intentional or just because depthOffset is > also the same? Maybe it should be depthOffset? Yes, I think depthPitch (you surely meant that, yes?) instead of frontPitch might be a good idea. I don't think there's a good reason to use frontPitch there, even though currently they are always the same. > Depth tiles on r200 are 32x16 or 64x16, depending on FB depth, right? > > Well, the span functions would indicate that. It doesn't quite match the experiences made when implementing hyperz, however (where the same number of tiles needed to be cleared regardless of 16 or 32bit z depth, and tile size more seemed to correspond to 4x4 microtiles and 8x2 macrotiles, thus a tile size of 32x8). I never really fully understood that however, something just doesn't fit. See th drm clear code for details. > > I don't quite follow third line before last? Can someone enlighten > me? You mean the pitch & 0x20 stuff? Yeah, looks strange. Looking at it, it seems like it ensures that each "block line" starts with alternating 2KB addresses (i.e. that 11th-bit). So y 0-15 will have set that (for x 0-31) to 0, y 16-31 to 1 and so on. Seems to me like it might be related to how the ram is organized (e.g. something like ensuring it's on a different memory channel or different bank or whatnot). This is, btw, quite similarly strange to what Stephane needed on his rv100 to get the correct pixel address for color tiling, this one also tinkered with that 11th bit (see RadeonDoAdjustFrame). > Generally if one could explain tiling a bit for me I would be > grateful. What I'm trying to do is to is to modify depthOffset to be > as close to top-left corner of viewport as possible and modify. I > this possible with shared depth buffer. This means that each 3D > window would have different depthOffset but pointing to the same > shared buffer. I'm not sure if it's possible to do that with depthOffset (well maybe). There is however an interesting bit in RB3D_CNTL (R200_DEPTH_XZ_OFFEST_ENABLE, I guess "XZ" is a typo, just as is "OFFEST"?) and the corresponding (?) register (R200_RB3D_DEPTHXY_OFFSET), which sound to me like they are exactly invented for that... Roland |
From: Stephane M. <mar...@ic...> - 2005-01-29 01:27:47
|
Roland Scheidegger wrote: >> >> I don't quite follow third line before last? Can someone enlighten me? > > You mean the pitch & 0x20 stuff? Yeah, looks strange. > Looking at it, it seems like it ensures that each "block line" starts > with alternating 2KB addresses (i.e. that 11th-bit). So y 0-15 will > have set that (for x 0-31) to 0, y 16-31 to 1 and so on. > Seems to me like it might be related to how the ram is organized (e.g. > something like ensuring it's on a different memory channel or > different bank or whatnot). > This is, btw, quite similarly strange to what Stephane needed on his > rv100 to get the correct pixel address for color tiling, this one also > tinkered with that 11th bit (see RadeonDoAdjustFrame). Also, since Jacek is interested in depth tiling, I have to mention that on my rv100, the depth buffer is not tiled until you use hyperz. Then when hyperz is used, the depth buffer becomes tiled. The depth tiling function is currently unknown (I still have to RE it) but it doesn't seem to work if I use the r100 or r200 depth tiling functions as defined in {radeon,r200}_span.c. > >> Generally if one could explain tiling a bit for me I would be >> grateful. What I'm trying to do is to is to modify depthOffset to be >> as close to top-left corner of viewport as possible and modify. I >> this possible with shared depth buffer. This means that each 3D >> window would have different depthOffset but pointing to the same >> shared buffer. > > I'm not sure if it's possible to do that with depthOffset (well > maybe). There is however an interesting bit in RB3D_CNTL > (R200_DEPTH_XZ_OFFEST_ENABLE, I guess "XZ" is a typo, just as is > "OFFEST"?) and the corresponding (?) register > (R200_RB3D_DEPTHXY_OFFSET), which sound to me like they are exactly > invented for that... Yes, AFAICT the same thing (private z buffers) should work on r100. Now I think the real trouble with private z buffers is how these will interfere with hyperz... Stephane |
From: Jacek R. <pa...@fa...> - 2005-01-29 08:38:17
|
Hi Dnia 29-01-2005, sob o godzinie 02:29 +0100, Stephane Marchesin napisa=B3(a): > Roland Scheidegger wrote: >=20 > >> > >> I don't quite follow third line before last? Can someone enlighten m= e? > > > > You mean the pitch & 0x20 stuff? Yeah, looks strange. > > Looking at it, it seems like it ensures that each "block line" starts= =20 > > with alternating 2KB addresses (i.e. that 11th-bit). So y 0-15 will=20 > > have set that (for x 0-31) to 0, y 16-31 to 1 and so on. > > Seems to me like it might be related to how the ram is organized (e.g= .=20 > > something like ensuring it's on a different memory channel or=20 > > different bank or whatnot). > > This is, btw, quite similarly strange to what Stephane needed on his=20 > > rv100 to get the correct pixel address for color tiling, this one als= o=20 > > tinkered with that 11th bit (see RadeonDoAdjustFrame). >=20 > Also, since Jacek is interested in depth tiling, I have to mention that= =20 > on my rv100, the depth buffer is not tiled until you use hyperz. > Then when hyperz is used, the depth buffer becomes tiled. The depth=20 > tiling function is currently unknown (I still have to RE it) but it=20 > doesn't seem to work if I use the r100 or r200 depth tiling functions a= s=20 > defined in {radeon,r200}_span.c. Would 7000 PCI be a rv100? I think I have one somewhere. Without depth tiling my Idea should be simpler to implement. > >> Generally if one could explain tiling a bit for me I would be=20 > >> grateful. What I'm trying to do is to is to modify depthOffset to be > >> as close to top-left corner of viewport as possible and modify. I=20 > >> this possible with shared depth buffer. This means that each 3D=20 > >> window would have different depthOffset but pointing to the same=20 > >> shared buffer. > > > > I'm not sure if it's possible to do that with depthOffset (well=20 > > maybe). There is however an interesting bit in RB3D_CNTL=20 > > (R200_DEPTH_XZ_OFFEST_ENABLE, I guess "XZ" is a typo, just as is=20 > > "OFFEST"?) and the corresponding (?) register=20 > > (R200_RB3D_DEPTHXY_OFFSET), which sound to me like they are exactly=20 > > invented for that... >=20 > Yes, AFAICT the same thing (private z buffers) should work on r100. >=20 > Now I think the real trouble with private z buffers is how these will=20 > interfere with hyperz... Huh I thought that hyperz would be simpler with private z buffers. What about private z buffers and private back buffers. Since most applications render only to back that would make them as fullscreen applications. Wouldn't It be simpler to implement hyperz and color tiling then? Best, --=20 Jacek Rosik <pa...@fa...> |
From: Stephane M. <mar...@ic...> - 2005-01-29 20:35:50
|
Jacek Rosik wrote: >Hi > >Dnia 29-01-2005, sob o godzinie 02:29 +0100, Stephane Marchesin >napisa=B3(a): > >>Roland Scheidegger wrote: >> >>>>I don't quite follow third line before last? Can someone enlighten me= ? >>>> >>>You mean the pitch & 0x20 stuff? Yeah, looks strange. >>>Looking at it, it seems like it ensures that each "block line" starts=20 >>>with alternating 2KB addresses (i.e. that 11th-bit). So y 0-15 will=20 >>>have set that (for x 0-31) to 0, y 16-31 to 1 and so on. >>>Seems to me like it might be related to how the ram is organized (e.g.= =20 >>>something like ensuring it's on a different memory channel or=20 >>>different bank or whatnot). >>>This is, btw, quite similarly strange to what Stephane needed on his=20 >>>rv100 to get the correct pixel address for color tiling, this one also= =20 >>>tinkered with that 11th bit (see RadeonDoAdjustFrame). >>> >>Also, since Jacek is interested in depth tiling, I have to mention that= =20 >>on my rv100, the depth buffer is not tiled until you use hyperz. >>Then when hyperz is used, the depth buffer becomes tiled. The depth=20 >>tiling function is currently unknown (I still have to RE it) but it=20 >>doesn't seem to work if I use the r100 or r200 depth tiling functions a= s=20 >>defined in {radeon,r200}_span.c. >> > >Would 7000 PCI be a rv100? I think I have one somewhere. Without depth >tiling my Idea should be simpler to implement. > Yes. But, I'd like to have hyperz enabled by default soon, so you'll=20 probably have to deal with depth tiling on this card too. Anyway it might be useful for some testing. > >>>>Generally if one could explain tiling a bit for me I would be=20 >>>>grateful. What I'm trying to do is to is to modify depthOffset to be >>>> as close to top-left corner of viewport as possible and modify. I=20 >>>>this possible with shared depth buffer. This means that each 3D=20 >>>>window would have different depthOffset but pointing to the same=20 >>>>shared buffer. >>>> >>>I'm not sure if it's possible to do that with depthOffset (well=20 >>>maybe). There is however an interesting bit in RB3D_CNTL=20 >>>(R200_DEPTH_XZ_OFFEST_ENABLE, I guess "XZ" is a typo, just as is=20 >>>"OFFEST"?) and the corresponding (?) register=20 >>>(R200_RB3D_DEPTHXY_OFFSET), which sound to me like they are exactly=20 >>>invented for that... >>> >>Yes, AFAICT the same thing (private z buffers) should work on r100. >> >>Now I think the real trouble with private z buffers is how these will=20 >>interfere with hyperz... >> > >Huh I thought that hyperz would be simpler with private z buffers. What >about private z buffers and private back buffers. Since most >applications render only to back that would make them as fullscreen >applications. Wouldn't It be simpler to implement hyperz and color >tiling then? > The trouble with hyperz is we're not quite sure how it works for the=20 corner cases (for example I'm not sure if it's possible to have private=20 depth buffers + hyperz). Not to mention that private depth or back buffers are a real pain to add=20 since you'd need a fb memory allocator. Btw, you don't want a private back buffer because this would disable=20 pageflip (which is way faster than the copy). Stephane |
From: Jacek R. <pa...@fa...> - 2005-01-31 09:09:48
|
Dnia 29-01-2005, sob o godzinie 21:38 +0100, Stephane Marchesin napisa=B3(a): > Jacek Rosik wrote: >=20 > >Would 7000 PCI be a rv100? I think I have one somewhere. Without depth > >tiling my Idea should be simpler to implement. > > > Yes. But, I'd like to have hyperz enabled by default soon, so you'll=20 > probably have to deal with depth tiling on this card too. > Anyway it might be useful for some testing. I hope there will be an option to disable color tiling? > >>>I'm not sure if it's possible to do that with depthOffset (well=20 > >>>maybe). There is however an interesting bit in RB3D_CNTL=20 > >>>(R200_DEPTH_XZ_OFFEST_ENABLE, I guess "XZ" is a typo, just as is=20 > >>>"OFFEST"?) and the corresponding (?) register=20 > >>>(R200_RB3D_DEPTHXY_OFFSET), which sound to me like they are exactly=20 > >>>invented for that... > >>> > >>Yes, AFAICT the same thing (private z buffers) should work on r100. > >> > >>Now I think the real trouble with private z buffers is how these will= =20 > >>interfere with hyperz... > >> > > > >Huh I thought that hyperz would be simpler with private z buffers. Wha= t > >about private z buffers and private back buffers. Since most > >applications render only to back that would make them as fullscreen > >applications. Wouldn't It be simpler to implement hyperz and color > >tiling then? > > > The trouble with hyperz is we're not quite sure how it works for the=20 > corner cases (for example I'm not sure if it's possible to have private= =20 > depth buffers + hyperz). > Not to mention that private depth or back buffers are a real pain to ad= d=20 > since you'd need a fb memory allocator. >=20 > Btw, you don't want a private back buffer because this would disable=20 > pageflip (which is way faster than the copy). I don't think this is argument against private backbuffers. Pageflipping only works with single client. We can still do pageflipping with single client with shared depth buffer and switch to private with more applications. Moreover we can detect fullscreen situation and do pageflipping even with private buffers too.=20 Anyway private z buffers would be a first step towards privet buffers. Do You think It would be possible to allocate z buffers with current X memory manager as pixmaps of appropriate size? This would be a temporary, just to test such solution. Best, --=20 Jacek Rosik <pa...@fa...> |
From: Stephane M. <mar...@ic...> - 2005-01-31 15:34:23
|
Jacek Rosik wrote: > Dnia 29-01-2005, sob o godzinie 21:38 +0100, Stephane Marchesin > napisa=B3(a): >=20 >>Jacek Rosik wrote: >> >> >>>Would 7000 PCI be a rv100? I think I have one somewhere. Without depth >>>tiling my Idea should be simpler to implement. >>> >> >>Yes. But, I'd like to have hyperz enabled by default soon, so you'll=20 >>probably have to deal with depth tiling on this card too. >>Anyway it might be useful for some testing. >=20 >=20 > I hope there will be an option to disable color tiling? >=20 You mean depth tiling I think ? There is no way to disable depth tiling on radeon, these cards have it=20 all the time (except the rv100 which only has depth tiling when hyperz=20 is used). >=20 >=20 >>>>>I'm not sure if it's possible to do that with depthOffset (well=20 >>>>>maybe). There is however an interesting bit in RB3D_CNTL=20 >>>>>(R200_DEPTH_XZ_OFFEST_ENABLE, I guess "XZ" is a typo, just as is=20 >>>>>"OFFEST"?) and the corresponding (?) register=20 >>>>>(R200_RB3D_DEPTHXY_OFFSET), which sound to me like they are exactly=20 >>>>>invented for that... >>>>> >>>> >>>>Yes, AFAICT the same thing (private z buffers) should work on r100. >>>> >>>>Now I think the real trouble with private z buffers is how these will= =20 >>>>interfere with hyperz... >>>> >>> >>>Huh I thought that hyperz would be simpler with private z buffers. Wha= t >>>about private z buffers and private back buffers. Since most >>>applications render only to back that would make them as fullscreen >>>applications. Wouldn't It be simpler to implement hyperz and color >>>tiling then? >>> >> >>The trouble with hyperz is we're not quite sure how it works for the=20 >>corner cases (for example I'm not sure if it's possible to have private= =20 >>depth buffers + hyperz). >>Not to mention that private depth or back buffers are a real pain to ad= d=20 >>since you'd need a fb memory allocator. >> >>Btw, you don't want a private back buffer because this would disable=20 >>pageflip (which is way faster than the copy). >=20 >=20 > I don't think this is argument against private backbuffers. Pageflippin= g > only works with single client. We can still do pageflipping with single > client with shared depth buffer and switch to private with more > applications. Moreover we can detect fullscreen situation and do > pageflipping even with private buffers too.=20 Right, in any case there has to be a mechanism to enable/disable it.=20 However, the fullscreen hooks are long dead. >=20 > Anyway private z buffers would be a first step towards privet buffers. > Do You think It would be possible to allocate z buffers with current X > memory manager as pixmaps of appropriate size? This would be a > temporary, just to test such solution. I think X can kick pixmaps out of video memory as it likes, so that=20 might not be very reliable. Stephane |
From: Jacek R. <pa...@fa...> - 2005-01-29 09:00:07
Attachments:
mesa-radeon-viewport-1.0.0
|
Hi, Dnia 28-01-2005, pi=B1 o godzinie 16:27 +0100, Roland Scheidegger napisa=B3(a):=20 > Jacek Rosik wrote: > > Hi, > >=20 > > I have some questions about r200 depth tiling. Generally I'm also=20 > > interested in r100 tiling too, but currently i work on r200. > >=20 > > First of all in functions r200_mba_z16|32 from r200_span.c frontPitch > > offset is used. Is it intentional or just because depthOffset is=20 > > also the same? Maybe it should be depthOffset? > Yes, I think depthPitch (you surely meant that, yes?) instead of > frontPitch might be a good idea. I don't think there's a good reason to > use frontPitch there, even though currently they are always the same. Yes, I meant depthPitch. They are the same but only for resolutions where width is multiple of 32. Depth pitch is rounded to be multiple of 32. Hmm... I think that is wrong since tile size seems to depend on fb depth and probably tiles on r100 also have different sizes. So this is correct only for r200 with 32bpp fb depth. > > Depth tiles on r200 are 32x16 or 64x16, depending on FB depth, right? > >=20 > >=20 > Well, the span functions would indicate that. It doesn't quite match th= e > experiences made when implementing hyperz, however (where the same > number of tiles needed to be cleared regardless of 16 or 32bit z depth, > and tile size more seemed to correspond to 4x4 microtiles and 8x2 > macrotiles, thus a tile size of 32x8). I never really fully understood > that however, something just doesn't fit. See th drm clear code for det= ails. Thanks, I'll take a look at it. > > I don't quite follow third line before last? Can someone enlighten=20 > > me? > You mean the pitch & 0x20 stuff? Yeah, looks strange. > Looking at it, it seems like it ensures that each "block line" starts=20 > with alternating 2KB addresses (i.e. that 11th-bit). So y 0-15 will hav= e=20 > set that (for x 0-31) to 0, y 16-31 to 1 and so on. > Seems to me like it might be related to how the ram is organized (e.g.=20 > something like ensuring it's on a different memory channel or different= =20 > bank or whatnot). Yeah, I thought something similar. > This is, btw, quite similarly strange to what Stephane needed on his=20 > rv100 to get the correct pixel address for color tiling, this one also=20 > tinkered with that 11th bit (see RadeonDoAdjustFrame). >=20 > > Generally if one could explain tiling a bit for me I would be=20 > > grateful. What I'm trying to do is to is to modify depthOffset to be > > as close to top-left corner of viewport as possible and modify. I=20 > > this possible with shared depth buffer. This means that each 3D=20 > > window would have different depthOffset but pointing to the same=20 > > shared buffer. > I'm not sure if it's possible to do that with depthOffset (well maybe).= =20 > There is however an interesting bit in RB3D_CNTL=20 > (R200_DEPTH_XZ_OFFEST_ENABLE, I guess "XZ" is a typo, just as is=20 > "OFFEST"?) and the corresponding (?) register=20 > (R200_RB3D_DEPTHXY_OFFSET), which sound to me like they are exactly=20 > invented for that... So this would mean that depth buffer can start at different x,y than color buffer? Can someone with the docs confirm that. Anyway I think I will experiment with it a little more and see what I'll get. Unfortunately I'll be quite busy in next weeks, but I hope I'll get back to it soon. BTW: I have working solution for color but I wonder if this will work with color tiling. Of course offset Would have to be aligned to the closest tile. Can You take a look at it? (It's missing some bits but generaly apps which don't use depth should work Unfortunately I don't think there are many ;). Attached is a patch. Any comments are welcome. Best, --=20 Jacek Rosik <pa...@fa...> |
From: Alex D. <ale...@gm...> - 2005-01-28 14:34:54
|
On Fri, 28 Jan 2005 09:51:25 +0100, Jacek Rosik <pa...@fa...> wrote: > Hi, > > I have some questions about r200 depth tiling. Generally I'm also > interested in r100 tiling too, but currently i work on r200. > > First of all in functions r200_mba_z16|32 from r200_span.c frontPitch > offset is used. Is it intentional or just because depthOffset is also > the same? Maybe it should be depthOffset? > > Depth tiles on r200 are 32x16 or 64x16, depending on FB depth, right? > > I don't quite follow third line before last? Can someone enlighten me? > > TIA. > > Generally if one could explain tiling a bit for me I would be grateful. > What I'm trying to do is to is to modify depthOffset to be as close to > top-left corner of viewport as possible and modify. I this possible with > shared depth buffer. This means that each 3D window would have different > depthOffset but pointing to the same shared buffer. > There are several good descriptions in the dri-devel archives, but it basically works like this: the framebuffer is divided up into fixed size (1024 bytes for example, so 16 bpp tiles would be 16x32x2 bytes or 24 bpp would be 16x16x4 bytes) tiles. The tiles take better advantage of GPU caches and can speed up rendering as you only have to update effected tiles. However, when you are dealing with tiles, you usually have to deal with full tiles so you need to pad your buffers accordingly so that you don't have any partial tiles. Hope that helps, Alex > Best, > -- > Jacek Rosik <pa...@fa...> > |
From: Roland S. <rsc...@hi...> - 2005-01-29 10:20:00
|
Jacek Rosik wrote: > Yes, I meant depthPitch. They are the same but only for resolutions > where width is multiple of 32. That's always the case (mode validation pitchInc was 64*pScrn->bitsPerPixel without color tiling), so you don't really need to round up to 32 for depth pitch. > Depth pitch is rounded to be multiple of 32. Hmm... I think that is > wrong since tile size seems to depend on fb depth and probably tiles > on r100 also have different sizes. So this is correct only for r200 > with 32bpp fb depth. You could be correct. Well you can try that with a resolution of 800x600 (and without color tiling), that should then give you wrong depth results. It might be possible though the chip actually handles depth buffers with not completely aligned pitches? > So this would mean that depth buffer can start at different x,y than > color buffer? Can someone with the docs confirm that. That's what I thought, just judging by the register bit... > BTW: I have working solution for color but I wonder if this will work > with color tiling. Of course offset Would have to be aligned to the > closest tile. Can You take a look at it? (It's missing some bits but > generaly apps which don't use depth should work Unfortunately I don't > think there are many ;). Attached is a patch. Any comments are > welcome. Unfortunately I can't really try that with my single monitor ;-). Roland |
From: Jacek R. <pa...@fa...> - 2005-01-29 10:28:35
|
Hi, Dnia 29-01-2005, sob o godzinie 11:19 +0100, Roland Scheidegger napisa=B3(a): > Jacek Rosik wrote: > > > > BTW: I have working solution for color but I wonder if this will work > > with color tiling. Of course offset Would have to be aligned to the=20 > > closest tile. Can You take a look at it? (It's missing some bits but=20 > > generaly apps which don't use depth should work Unfortunately I don't > > think there are many ;). Attached is a patch. Any comments are > > welcome. > Unfortunately I can't really try that with my single monitor ;-). I also have single monitor at home. Just set virtual width to be greater than 2048 and move window far to the left. This is basically just like MergedFB works. I use 4000x2000 virtual resolution. Best, --=20 Jacek Rosik <pa...@fa...> |
From: Adam K K. <ad...@vo...> - 2005-02-06 19:53:36
|
Jacek Rosik wrote: >Hi, > >Dnia 28-01-2005, pi=B1 o godzinie 16:27 +0100, Roland Scheidegger >napisa=B3(a):=20 > =20 > >>Jacek Rosik wrote: >> =20 >> >>>Hi, >>> >>>I have some questions about r200 depth tiling. Generally I'm also=20 >>>interested in r100 tiling too, but currently i work on r200. >>> >>>First of all in functions r200_mba_z16|32 from r200_span.c frontPitch >>> offset is used. Is it intentional or just because depthOffset is=20 >>>also the same? Maybe it should be depthOffset? >>> =20 >>> >>Yes, I think depthPitch (you surely meant that, yes?) instead of >>frontPitch might be a good idea. I don't think there's a good reason to >>use frontPitch there, even though currently they are always the same. >> =20 >> > >Yes, I meant depthPitch. They are the same but only for resolutions >where width is multiple of 32. Depth pitch is rounded to be multiple of >32. Hmm... I think that is wrong since tile size seems to depend on fb >depth and probably tiles on r100 also have different sizes. So this is >correct only for r200 with 32bpp fb depth. > > =20 > >>>Depth tiles on r200 are 32x16 or 64x16, depending on FB depth, right? >>> >>> >>> =20 >>> >>Well, the span functions would indicate that. It doesn't quite match th= e >>experiences made when implementing hyperz, however (where the same >>number of tiles needed to be cleared regardless of 16 or 32bit z depth, >>and tile size more seemed to correspond to 4x4 microtiles and 8x2 >>macrotiles, thus a tile size of 32x8). I never really fully understood >>that however, something just doesn't fit. See th drm clear code for det= ails. >> =20 >> > >Thanks, I'll take a look at it. > > =20 > >>>I don't quite follow third line before last? Can someone enlighten=20 >>>me? >>> =20 >>> >>You mean the pitch & 0x20 stuff? Yeah, looks strange. >>Looking at it, it seems like it ensures that each "block line" starts=20 >>with alternating 2KB addresses (i.e. that 11th-bit). So y 0-15 will hav= e=20 >>set that (for x 0-31) to 0, y 16-31 to 1 and so on. >>Seems to me like it might be related to how the ram is organized (e.g.=20 >>something like ensuring it's on a different memory channel or different= =20 >>bank or whatnot). >> =20 >> >Yeah, I thought something similar. > > =20 > >>This is, btw, quite similarly strange to what Stephane needed on his=20 >>rv100 to get the correct pixel address for color tiling, this one also=20 >>tinkered with that 11th bit (see RadeonDoAdjustFrame). >> >> =20 >> >>>Generally if one could explain tiling a bit for me I would be=20 >>>grateful. What I'm trying to do is to is to modify depthOffset to be >>> as close to top-left corner of viewport as possible and modify. I=20 >>>this possible with shared depth buffer. This means that each 3D=20 >>>window would have different depthOffset but pointing to the same=20 >>>shared buffer. >>> =20 >>> >>I'm not sure if it's possible to do that with depthOffset (well maybe).= =20 >>There is however an interesting bit in RB3D_CNTL=20 >>(R200_DEPTH_XZ_OFFEST_ENABLE, I guess "XZ" is a typo, just as is=20 >>"OFFEST"?) and the corresponding (?) register=20 >>(R200_RB3D_DEPTHXY_OFFSET), which sound to me like they are exactly=20 >>invented for that... >> =20 >> > >So this would mean that depth buffer can start at different x,y than >color buffer? Can someone with the docs confirm that. > >Anyway I think I will experiment with it a little more and see what I'll >get. Unfortunately I'll be quite busy in next weeks, but I hope I'll get >back to it soon. > >BTW: I have working solution for color but I wonder if this will work >with color tiling. Of course offset Would have to be aligned to the >closest tile. Can You take a look at it? (It's missing some bits but >generaly apps which don't use depth should work Unfortunately I don't >think there are many ;). Attached is a patch. Any comments are welcome. > =20 > I somehow missed this discussion the first time, but thankfully Alex=20 pointed it out to me... Anyway... I've applied your patch, Jacek. It mostly works, but=20 definitely has some issues: http://68.44.156.246/glforestfire.png http://68.44.156.246/glplanet.png This is what happens when I move the window to the lower right hand=20 corner on a MergedFB setup running at 2560x1024. Adam |
From: Mike M. <che...@ya...> - 2005-02-06 21:15:19
|
--- Adam K Kirchhoff <ad...@vo...> wrote: > Jacek Rosik wrote: > > >Hi, > > > >Dnia 28-01-2005, pi± o godzinie 16:27 +0100, Roland Scheidegger > >napisa³(a): > > > > > >>Jacek Rosik wrote: > >> > >> > >>>Hi, > >>> > >>>I have some questions about r200 depth tiling. Generally I'm also > >>>interested in r100 tiling too, but currently i work on r200. > >>> > >>>First of all in functions r200_mba_z16|32 from r200_span.c frontPitch > >>> offset is used. Is it intentional or just because depthOffset is > >>>also the same? Maybe it should be depthOffset? > >>> > >>> > >>Yes, I think depthPitch (you surely meant that, yes?) instead of > >>frontPitch might be a good idea. I don't think there's a good reason > to > >>use frontPitch there, even though currently they are always the same. > >> > >> > > > >Yes, I meant depthPitch. They are the same but only for resolutions > >where width is multiple of 32. Depth pitch is rounded to be multiple of > >32. Hmm... I think that is wrong since tile size seems to depend on fb > >depth and probably tiles on r100 also have different sizes. So this is > >correct only for r200 with 32bpp fb depth. > > > > > > > >>>Depth tiles on r200 are 32x16 or 64x16, depending on FB depth, right? > >>> > >>> > >>> > >>> > >>Well, the span functions would indicate that. It doesn't quite match > the > >>experiences made when implementing hyperz, however (where the same > >>number of tiles needed to be cleared regardless of 16 or 32bit z > depth, > >>and tile size more seemed to correspond to 4x4 microtiles and 8x2 > >>macrotiles, thus a tile size of 32x8). I never really fully understood > >>that however, something just doesn't fit. See th drm clear code for > details. > >> > >> > > > >Thanks, I'll take a look at it. > > > > > > > >>>I don't quite follow third line before last? Can someone enlighten > >>>me? > >>> > >>> > >>You mean the pitch & 0x20 stuff? Yeah, looks strange. > >>Looking at it, it seems like it ensures that each "block line" starts > >>with alternating 2KB addresses (i.e. that 11th-bit). So y 0-15 will > have > >>set that (for x 0-31) to 0, y 16-31 to 1 and so on. > >>Seems to me like it might be related to how the ram is organized (e.g. > > >>something like ensuring it's on a different memory channel or > different > >>bank or whatnot). > >> > >> > >Yeah, I thought something similar. > > > > > > > >>This is, btw, quite similarly strange to what Stephane needed on his > >>rv100 to get the correct pixel address for color tiling, this one also > > >>tinkered with that 11th bit (see RadeonDoAdjustFrame). > >> > >> > >> > >>>Generally if one could explain tiling a bit for me I would be > >>>grateful. What I'm trying to do is to is to modify depthOffset to be > >>> as close to top-left corner of viewport as possible and modify. I > >>>this possible with shared depth buffer. This means that each 3D > >>>window would have different depthOffset but pointing to the same > >>>shared buffer. > >>> > >>> > >>I'm not sure if it's possible to do that with depthOffset (well > maybe). > >>There is however an interesting bit in RB3D_CNTL > >>(R200_DEPTH_XZ_OFFEST_ENABLE, I guess "XZ" is a typo, just as is > >>"OFFEST"?) and the corresponding (?) register > >>(R200_RB3D_DEPTHXY_OFFSET), which sound to me like they are exactly > >>invented for that... > >> > >> > > > >So this would mean that depth buffer can start at different x,y than > >color buffer? Can someone with the docs confirm that. > > > >Anyway I think I will experiment with it a little more and see what > I'll > >get. Unfortunately I'll be quite busy in next weeks, but I hope I'll > get > >back to it soon. > > > >BTW: I have working solution for color but I wonder if this will work > >with color tiling. Of course offset Would have to be aligned to the > >closest tile. Can You take a look at it? (It's missing some bits but > >generaly apps which don't use depth should work Unfortunately I don't > >think there are many ;). Attached is a patch. Any comments are welcome. > > > > > I somehow missed this discussion the first time, but thankfully Alex > pointed it out to me... > > Anyway... I've applied your patch, Jacek. It mostly works, but > definitely has some issues: > > http://68.44.156.246/glforestfire.png > http://68.44.156.246/glplanet.png > > This is what happens when I move the window to the lower right hand > corner on a MergedFB setup running at 2560x1024. > The OFFSETS get changed but then the output needs to be translated back into position. AMY ONE HAVE A FIX FOR THIS!!!! Also you seam tobe getting something I did not get. In my attempts the img moved to the boarder of the window, so that the cutoff was allways at a window boundry. This could mean there are some math problems in the patch your using. > Adam > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo |
From: Jacek R. <pa...@fa...> - 2005-02-07 09:10:21
|
Dnia 06-02-2005, nie o godzinie 14:53 -0500, Adam K Kirchhoff napisa=B3(a): > Jacek Rosik wrote: > > > >BTW: I have working solution for color but I wonder if this will work > >with color tiling. Of course offset Would have to be aligned to the > >closest tile. Can You take a look at it? (It's missing some bits but > >generaly apps which don't use depth should work Unfortunately I don't > >think there are many ;). Attached is a patch. Any comments are welcome= . > > =20 > > > I somehow missed this discussion the first time, but thankfully Alex=20 > pointed it out to me... >=20 > Anyway... I've applied your patch, Jacek. It mostly works, but=20 > definitely has some issues: I thought It doesn't work. :) It was only a partial fix for color buffer only. >=20 > http://68.44.156.246/glforestfire.png This looks like those transparent triangles are rendered without depth buffer, while the rest is. Depth is not working so that's why those triangles appear. > http://68.44.156.246/glplanet.png > > This is what happens when I move the window to the lower right hand=20 > corner on a MergedFB setup running at 2560x1024. Does it look different if you force redisplay after window move. Just after window move offset is not updated correctly, it will be corrected at next frame. I haven't figure out that bit yet. Best, --=20 Jacek Rosik <pa...@fa...> |