Commit Graph

5 Commits

Author SHA1 Message Date
Ben Skeggs
d58086deaa drm/nv40-50/gr: restructure grctx/prog generation
The conditional definition of the generation helper functions apparently
confuses some IDEs....

Reported-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-05-24 16:31:58 +10:00
Ben Skeggs
c693931d93 drm/nv40: make detection of 0x4097-ful chipsets available everywhere
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-01-17 11:28:31 +10:00
Ben Skeggs
b3beb167af drm/nouveau: modify object accessors, offset in bytes rather than dwords
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-09-24 16:20:00 +10:00
Ben Skeggs
de1f46a4b9 drm/nv40: remove some completed ctxprog TODOs
I actually thought these were gone already when the initial commit was
done.. I guess not!

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-05-19 13:15:14 +10:00
Ben Skeggs
054b93e444 drm/nv40: implement ctxprog/state generation
The context programs are *very* simple compared to the ones used by
the binary driver.  There's notes in nv40_grctx.c explaining most of
the things we don't implement.  If we discover if/why any of it is
required further down the track, we'll handle it then.

The PGRAPH state generated for each chipset should match what NVIDIA
do almost exactly (there's a couple of exceptions).  If someone has
a lot of time on their hands, they could figure out the mapping of
object/method to PGRAPH register and demagic the initial state a little,
it's not terribly important however.

At time of commit, confirmed to be working at least well enough for
accelerated X (and where tested, for 3D apps) on NV40, NV43, NV44, NV46,
NV49, NV4A, NV4B and NV4E.

A module option has been added to force the use of external firmware
blobs if it becomes required.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2009-12-16 17:05:39 +10:00