On Wed, 2009-08-12 at 15:27 +0100, Keith Whitwell wrote:
Dave,
The big problem with the (second) radeon approach of state objects was
that we defined those objects statically encoded them into the kernel
interface. That meant that when new hardware functionality was needed
(or discovered)
Dave,
The big problem with the (second) radeon approach of state objects was
that we defined those objects statically encoded them into the kernel
interface. That meant that when new hardware functionality was needed
(or discovered) we had to rev the kernel interface, usually in a fairly
ugly
On Sat, Aug 8, 2009 at 7:51 AM, Jerome Glissegli...@freedesktop.org wrote:
Investigating where time is spent in radeon/kms world when doing
rendering leaded me to question the design of CS ioctl. As i am among
the people behind it, i think i should give some historical background
on the choice
Investigating where time is spent in radeon/kms world when doing
rendering leaded me to question the design of CS ioctl. As i am among
the people behind it, i think i should give some historical background
on the choice that were made.
The first motivation behind cs ioctl was to take common
