From: Mattias N. <mat...@gm...> - 2005-10-27 22:44:27
|
Hi again, just wanted to let you know that I pulled the latest CVS tree this evening and all rendering problems are gone! Many, many, many thanks! I have given the r300 driver some workout with quake3 and there were no rendering problems at all. The missing trails in gltron are also there, transparent as they should be. Really great work! Mattias |
From: Jerome G. <j.g...@gm...> - 2005-10-28 09:39:59
|
On 10/28/05, Mattias Nissler <mat...@gm...> wrote: > Hi again, > > just wanted to let you know that I pulled the latest CVS tree this > evening and all rendering problems are gone! Many, many, many thanks! > I have given the r300 driver some workout with quake3 and there were > no rendering problems at all. The missing trails in gltron are also > there, transparent as they should be. Really great work! > > Mattias Aapo you commit anything about the endian swapping for fixing what Mattias was experiencing in his last report ? best, Jerome Glisse |
From: Aapo T. <ae...@ra...> - 2005-10-28 09:49:34
|
On Fri, 28 Oct 2005 11:39:57 +0200 Jerome Glisse <j.g...@gm...> wrote: > On 10/28/05, Mattias Nissler <mat...@gm...> wrote: > > Hi again, > > > > just wanted to let you know that I pulled the latest CVS tree this > > evening and all rendering problems are gone! Many, many, many thanks! > > I have given the r300 driver some workout with quake3 and there were > > no rendering problems at all. The missing trails in gltron are also > > there, transparent as they should be. Really great work! > > > > Mattias > > Aapo you commit anything about the endian swapping for fixing > what Mattias was experiencing in his last report ? No. Sounds like 32-bit elts work for ppc. 16-bit elts are used in vtxfmt_a path so thats still broken. -- Aapo Tahkola |
From: Benjamin H. <be...@ke...> - 2005-10-29 23:18:47
|
> > Aapo you commit anything about the endian swapping for fixing > > what Mattias was experiencing in his last report ? > > No. Sounds like 32-bit elts work for ppc. > 16-bit elts are used in vtxfmt_a path so thats still broken. They probably need HDW swapping... AFAIK, the CCE is doing 32 bits bytewap all the time. Thus, 16 bits data need to have top and bottom 16 bits swapped (HDW swap) to "correct" the result. Ben. |
From: Michel <mi...@da...> - 2005-10-31 14:00:11
|
On Sun, 2005-10-30 at 10:17 +1100, Benjamin Herrenschmidt wrote: > >=20 > > Sounds like 32-bit elts work for ppc. > > 16-bit elts are used in vtxfmt_a path so thats still broken. >=20 > They probably need HDW swapping... AFAIK, the CCE is doing 32 bits > bytewap all the time.=20 Yes, we set it up that way so that we don't have to take care of byte order for every CP command. > Thus, 16 bits data need to have top and bottom 16 bits swapped (HDW swap)= =20 > to "correct" the result. In the radeon and r200 drivers, it's even hairier than that because the elts aren't always aligned to 4 bytes. See EMIT_ELT in r{adeon,200}_tcl.c. --=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: Aapo T. <ae...@ra...> - 2005-10-31 15:25:15
|
On Mon, 31 Oct 2005 14:59:59 +0100 Michel D=E4nzer <mi...@da...> wrote: > On Sun, 2005-10-30 at 10:17 +1100, Benjamin Herrenschmidt wrote: > > >=20 > > > Sounds like 32-bit elts work for ppc. > > > 16-bit elts are used in vtxfmt_a path so thats still broken. > >=20 > > They probably need HDW swapping... AFAIK, the CCE is doing 32 bits > > bytewap all the time.=20 >=20 > Yes, we set it up that way so that we don't have to take care of byte > order for every CP command. >=20 > > Thus, 16 bits data need to have top and bottom 16 bits swapped (HDW swa= p)=20 > > to "correct" the result. >=20 > In the radeon and r200 drivers, it's even hairier than that because the > elts aren't always aligned to 4 bytes. See EMIT_ELT in > r{adeon,200}_tcl.c. I think its more hilarious than anything else. --=20 Aapo Tahkola |