| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The tmp_row storage allocation took into account the format's y block
size by allocating y_step rows of data. However, the x block size was
not being taken into account when deciding how wide those rows need to
be.
Now make sure that tmp_row is at least x_step by y_step in size.
|
|
|
|
Depth-stencil manually written given that each one is very close to
be a special case.
u_format_zs.c's still untested.
|
|
Untested.
|
|
support.
Not all is bad, but I'm afraid I'll have to throw the baby with the water
given they are all tied to together.
|
|
Putting calls to util_format_init all over the codebase is infeasible.
Instead, half float tables are pregenerated, and the s3tc library is
loaded on demand.
I believe this is a solution that combines performance, cleanliness,
flexibility and portability.
|
|
This solution avoids the issue of how to run the initializers and
also allows those pages (and the parts of them in processor caches)
to be shared between multiple processes.
The drawback is slightly higher library size.
|
|
Switch from auto-init to explicit init for util_half per Brian Paul's
indication.
NOTE: this is probably broken because not enough things call util_format_init.
Will be fixed shortly
|
|
Otherwise there's no way to unpack blocks with height >1
|
|
|
|
|
|
Make sure the format descriptor table can be indexed directly.
|
|
There are some inconsistencies in pipe_format, but above all, there
simply aren't enough bits in an enum to conveniently store all
information about a pixel format we need to be able to dynamically
generate pixel packing/unpacking code.
|
