| Age | Commit message (Collapse) | Author |
|---|
|
This code existed to dump logs of hardware access to be replayed in simulation.
Since we have real hardware now, it's not really needed.
|
|
some 3D programs such as pymol work well.
|
|
|
|
|
|
call swsetup_Wakeup before falling back to software rendering
|
|
|
|
|
|
|
|
|
|
passing them to the kernel. This works because all drawing commands
in the 965 driver are emitted with the lock held and the batchbuffer
is always flushed prior to releasing the lock. This allows multiple
cliprects to be dealt with, without replaying entire batchbuffers and
redundantly re-emitting state.
|
|
identify context switches between members of a share group -
ie. multiple contexts in a single application, possibly on different
threads. In this case the contexts share a bufmgr instance and there
is no need to evict textures - so don't.
2) Use a new flag 'need_flush' to ensure hardware rendering is flushed
prior to starting a software fallback.
|
|
|
|
|
|
hack to the drm to disable command verification on the cmd_buffer
ioctl. Doesn't exactly replay as commands are normally delivered as
batchbuffers but are captured and replayed as commands on the ring.
|
|
rendering operations to take place after evicting all resident
buffers.
Cope better with memory allocation failures throughout the driver and
improve tracking of failures.
|
|
as non-aliasing and cope with the >32 attributes that result, taking
materials into account.
|
|
This driver comes from Tungsten Graphics, with a few further modifications by
Intel.
|
