Re: sunffb

Hello,

> > We finally got the sunffb driver to work on NetBSD/sparc64,
> > including acceleration. Turns out there was a problem in the VIS
> > assembler code:
> > 	 wr			%g0, 0, %fprs
> > this will turn off the FPU so any subsequent FPU instruction will
> > cause a trap. On NetBSD this led to huge numbers of traps which
> > rendered the Xserver unusable when acceleration was enabled.
> > So for NetBSD I changed this to
> > 	 wr			%g0, 4, %fprs
> > to leave the FPU active and clean only the dirty bits. No more
> > excessive traps and things work.
> 
> I'm inclined to simply change both occurrences.

At least for NetBSD we'll definitely do so in our repository.
 
> > Since I highly doubt this is an oversight - what's the purpose of
> > turning off the FPU after using VIS? Apparently the author expected
> > the OS to do something which NetBSD doesn't do, but what? And why?
> > Provoking a trap seems a rather expensive way to reset the FPU ( if
> > that's the purpose... )
> 
> > PS: yes, I mailed the author too
> 
> Let us know if you get a response.

He said it's supposed to keep the scheduler from storing/saving FPU
context until someone really uses it again ( which causes a trap ), at
least on Linux. I'm not sure this helps much in this code - the ffb/afb
doesn't have block transfer hardware ( they dropped it because VIS is
faster ) so the VIS code will run a lot.
Maybe writing 0 into %fprs should be Linux-specific.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)

iQEVAwUBQpxtPspnzkX8Yg2nAQJQZwgApOOmPz1jg2d8Ekmzs58OZPU53kWo3uU/
/mItcqXp/dogiqvdnfofmWZEN7+W8kooB4UmQ7bav59hdQsTjBOqG2dkS3455YqK
hxNxBYg7HH6PtwSP9F3k0N6khWMa6Dj1R618qsTQVtlKSQMSPZBKz/dCxaYLYR0D
1dDpIKvp3vM+rK5m2Z8zjR6YMmqDNkhFQAUScStZN91+uOiVdFYPa5MgWdUs8IdF
PUZPK1h2TnL6t013U91VRhs0i1vhCXPQ8Iyf2bdMYc1pWYatFAyIGawNTPK6zxYO
xhidfr5WCRUa01ULsbzSksdWgC7hjbWhwQytDKTlzZVkUkuwe2jnvg==
=mAxW
-----END PGP SIGNATURE-----