| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
to do it
|
|
May not always happen due to passthrough modes, etc.
|
|
The two functions were mostly the same. We can look at the shader header
info to determine if it's a vertex or fragment shader.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Precompute tiles_per_row. Use ushort multiplies in a few places. New comments.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remote display to my usual terminal shows the right colors again.
Not 100% sure about the shuffle control words, but they seem to work.
|
|
Not convenient and almost not used at all. Better replacements in p_debug.h
|
|
|
|
This fixes the missing bitmaps in the engine and fogcoord demos.
|
|
|
|
The later follows the naming scheme of other limits.
Keep the old definition until all possible usage is updated.
|
|
|
|
|
|
|
|
This also implements code-gen for the float-to-packed color
conversion. It's currently hardcoded for A8R8G8B8, but that can
easily be fixed as soon as other color depths are supported by the
Cell driver.
|
|
The cell driver still uses an internal CELL_FLUSH_WAIT flag, in the long run
proper fencing should be implemented for it.
|
|
|
|
|
|
|
|
Code generation should be performed when the device-specific state
atom is created, not when it is bound.
|
|
Previously the constant color blend factor was compiled into the
generated code. This meant that the code had to be regenerated each
time the constant color was changed. This doesn't fit with the model
used in Gallium.
As-is, the code could be better. The constant color is loaded for
every quad processed, even if it is not used. Also, if a lot of (1-x)
blend factors are used, 1.0 will be loaded and reloaded into registers
many times.
|
