represents realworld usage. In particular, avoid situations where
the client texture image and the mesa copy (if there is one) are both
resident in L2 cache.
relies over-heavily on the DRI lock to protect offsets in the
command stream from changing before being queued on the ring,
and should be viewed as being a pretty temporary mechanism
before a more robust alternative is implemented, most likely
based on a batchbuffer relocation list that will be used
to patch prebuilt batchbuffers after validation takes place.
software rasterizer fallbacks. This has two functions, firstly to
ensure that the Data pointers point to something and secondly to
ensure than any pending fences on those buffers are discharged before
allowing the software rasterizer to read/write the data.
This needs to be integrated with Brian's validate code.
got it by other methods. Typically this is buffers being written to by
hardware excluding the fixed front/back/depth buffers which are have
pre-allocated memory.
At some point will want to pass BM_READ/BM_WRITE flags to catch the
couple of cases where buffers are treated differently in each case.
a memory space. Allow some pools to be excluded from the upload/evict
processing, meaning that any buffers within those pools are effectively
fixed. Add a mechanism to create buffers in those pools.
This allows the legacy fixed front/depth/back buffers to be represented
in this scheme and will allow other future pinned buffers to be allocated
from fixed pools in such a way that they cannot fragment the rest of
the texture memory.
- Add code to validate textures before use.
- Simplify vertex paths for now.
- Make vertex paths validate textures. This is done pretty
with some pretty heavy-handed use of the dri lock - fixing this is
a priority.
- Add lots of debug statements
demos/texobj renders, but textures are incorrect.
which keeps track of a whole, well-defined mipmap tree. These are a
fixed layout on intel hardware and managing them is complicated in the
face of GL's TexImage function calls where data can arrive in any order,
making it difficult to guess a layout ahead of time.
Wrapping mipmap trees up in a struct and programming interface like this
reduces the burden elsewhere.
techniques as the old dri memory manager behind the new interface. Will
use this to port the i915 driver to this interface to hopefully get
some easy insights from using the interface.
Lots of changes, and fixes for some badness on my behalf.
1. Disposable data used during fp compile is now per-context,
rather than per-program to save memory.
2. Track usage of INPUT/TEMP registers from Mesa program, free
them when no longer required so the hw temps can be re-used.
3. Changed LAST_NODE to OUTPUT_COLOR (see r300_reg.h)
4. Implemented remaining ARB_f_p instructions, with the exception
of the trig/LIT opcodes.
5. Treat ZERO/ONE swizzles the same way as other native swizzles.
6. emit_arith changes, basically a complete re-write. Should
produce cleaner instructions, but no real functional changes.
internal reg -> hw reg routines shared with emit_tex. A bit
messy still.
