From: Rune P. <ru...@me...> - 2005-05-27 18:41:20
|
Hi, One more for good messure. 2048x2048 texturer are corrupted. half (1024x2048) is correct, the rest is random data from memory. An easy way to reproduce this is using NeHe Lesson 06 and change the bitmap to a 2048x2048 bitmap. Rune Petersen |
From: Michel <mi...@da...> - 2005-05-27 20:27:50
|
On Fri, 2005-05-27 at 20:48 +0200, Rune Petersen wrote: > Hi, > One more for good messure. > 2048x2048 texturer are corrupted. half (1024x2048) is correct, the rest=20 > is random data from memory. Not being familiar with the r300 code, I can only guess, but it sounds like the r300 driver still always uses a 1-byte format for texture uploads and hits the size limit of the 2D engine. This was changed for the other Radeon drivers when support for texture tiling was added. --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: Rune P. <ru...@me...> - 2005-05-27 21:14:19
|
Michel D=C3=A4nzer wrote: > On Fri, 2005-05-27 at 20:48 +0200, Rune Petersen wrote: >=20 >>Hi, >>One more for good messure. >>2048x2048 texturer are corrupted. half (1024x2048) is correct, the rest= =20 >>is random data from memory. >=20 >=20 > Not being familiar with the r300 code, I can only guess, but it sounds > like the r300 driver still always uses a 1-byte format for texture > uploads and hits the size limit of the 2D engine. This was changed for > the other Radeon drivers when support for texture tiling was added. >=20 Can you tell me when this was added? (might give me some ideas) Rune Petersen |
From: Roland S. <rsc...@hi...> - 2005-05-28 02:55:30
|
Rune Petersen wrote: > Michel D=C3=A4nzer wrote: >=20 >> On Fri, 2005-05-27 at 20:48 +0200, Rune Petersen wrote: >> >>> Hi, >>> One more for good messure. >>> 2048x2048 texturer are corrupted. half (1024x2048) is correct, the=20 >>> rest is random data from memory. >> >> >> >> Not being familiar with the r300 code, I can only guess, but it sounds >> like the r300 driver still always uses a 1-byte format for texture >> uploads and hits the size limit of the 2D engine. This was changed for >> the other Radeon drivers when support for texture tiling was added. >> > Can you tell me when this was added? (might give me some ideas) Before the texture tiling stuff (2005-02-10) when this code was changed=20 to no longer use always a 1-byte format there already was an easier fix=20 for exactly that problem, which still used 1-byte formats but=20 incremented the offset (2004-10-07). Roland |
From: Rune P. <ru...@me...> - 2005-05-28 15:45:52
|
Roland Scheidegger wrote: > Rune Petersen wrote: >=20 >> Michel D=C3=A4nzer wrote: >> >>> On Fri, 2005-05-27 at 20:48 +0200, Rune Petersen wrote: >>> >>>> Hi, >>>> One more for good messure. >>>> 2048x2048 texturer are corrupted. half (1024x2048) is correct, the=20 >>>> rest is random data from memory. >>> >>> >>> >>> >>> Not being familiar with the r300 code, I can only guess, but it sound= s >>> like the r300 driver still always uses a 1-byte format for texture >>> uploads and hits the size limit of the 2D engine. This was changed fo= r >>> the other Radeon drivers when support for texture tiling was added. >>> >> Can you tell me when this was added? (might give me some ideas) >=20 > Before the texture tiling stuff (2005-02-10) when this code was changed= =20 > to no longer use always a 1-byte format there already was an easier fix= =20 > for exactly that problem, which still used 1-byte formats but=20 > incremented the offset (2004-10-07). That hack doesn't work, x (and y) for the image is 0, whick makes no=20 impact on the offset. It's bug #960. Rune Petersen |
From: Roland S. <rsc...@hi...> - 2005-05-29 00:54:33
|
Rune Petersen wrote: > Roland Scheidegger wrote: >=20 >> Rune Petersen wrote: >> >>> Michel D=C3=A4nzer wrote: >>> >>>> On Fri, 2005-05-27 at 20:48 +0200, Rune Petersen wrote: >>>> >>>>> Hi, >>>>> One more for good messure. >>>>> 2048x2048 texturer are corrupted. half (1024x2048) is correct, the=20 >>>>> rest is random data from memory. >>>> >>>> >>>> >>>> >>>> >>>> Not being familiar with the r300 code, I can only guess, but it soun= ds >>>> like the r300 driver still always uses a 1-byte format for texture >>>> uploads and hits the size limit of the 2D engine. This was changed f= or >>>> the other Radeon drivers when support for texture tiling was added. >>>> >>> Can you tell me when this was added? (might give me some ideas) >> >> >> Before the texture tiling stuff (2005-02-10) when this code was=20 >> changed to no longer use always a 1-byte format there already was an=20 >> easier fix for exactly that problem, which still used 1-byte formats=20 >> but incremented the offset (2004-10-07). >=20 > That hack doesn't work, x (and y) for the image is 0, whick makes no=20 > impact on the offset. It's bug #960. Ah yes, I remember now, it only affected mip-maps. I think though the=20 maximum size anyone tested there was only 2048x1024, not 2048x2048, so=20 in fact the fix maybe wouldn't have worked on such 2048x2048x4 textures=20 without mipmpas neither. I don't think that size actually gets ever=20 announced on any radeon (r100/r200) card as the driver can only handle=20 128MB, with the crappy memory management only 70MB or so will be=20 available for textures which isn't enough to fit 4 (the default amount=20 of texture units announced) such textures with mipmaps, though you may=20 get that size announced with configuration. The new code should work=20 however in any case. Roland |