Age | Commit message (Collapse) | Author |
|
Use _NEW_PROGRAM_CONSTANTS when changing constant/uniform buffer values.
Binding a new program/shader sets both _NEW_PROGRAM and _NEW_PROGRAM_CONSTANTS.
|
|
|
|
In the VS constants can now be handled in two different ways:
1. If there's room in the GRF, put constants there. They're preloaded from
the CURBE prior to VS execution. This is the historical approach. The
problem is the GRF may not have room for all the shader's constants and
temps and misc registers. Hence...
2. Use a separate constant buffer which is read from using a READ message.
This allows a very large number of constants and frees up GRF regs for
shader temporaries. This is the new approach. May be a little slower
than 1.
1 vs. 2 is chosen according to how many constants and temps the shader needs.
|
|
|
|
These types are only found in the new surface state cache now.
|
|
|
|
|
|
The new, second cache will only be used for surface-related items.
Since we can create many surfaces the original, single cache could get
filled quickly. When we cleared it, we had to regenerate shaders, etc.
With two caches, we can avoid doing that.
|
|
|
|
No more dynamic atoms so we can simplify the state validation code a little.
|
|
|
|
|
|
When program constants change we create a new VS constant buffer
instead of re-using the old one. This allows us to have several
const buffers in flight with vertex rendering.
|
|
|
|
|
|
Make sure we detect constant buffer changes indicated by the new flag.
Should be able to remove _NEW_PROGRAM (and _NEW_MODELVIEW, _NEW_LIGHT, etc)
from several places (someday.
|
|
This is a follow-on to commit c1a3b852807fb160f0cd246c1364b7336b4b947e.
Note that (at this time) wherever _NEW_PROGRAM_CONSTANTS is set we're still
setting _NEW_PROGRAM so this won't really make any difference (for now).
|
|
Lost in commit e50dd26ca6d0eb0d0f97c2780020ea16e3d4a687.
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
Need to do this to ensure vbo code unmaps its buffers before calling
the driver, which may be sitting on top of a memory manager which
objects to firing commands from a mapped buffer.
|
|
When a new program is bound but no constants are updated we still need
to update the Gallium const buffer.
|
|
|
|
We can simplify this now that we no longer have any dynamic atoms.
|
|
Just use the new _NEW_PROGRAM_CONSTANTS flag instead.
|
|
This state flag will be used to indicate that vertex/fragment program
constants have changed. _NEW_PROGRAM will be used to indicate changes
to the vertex/fragment shader itself, or misc related state.
_NEW_PROGRAM_CONSTANTS is also set whenever a program parameter that's
tracking GL state has changed. For example, if the projection matrix is
in the parameter list, calling glFrustum() will cause _NEW_PROGRAM_CONSTANTS
to be set. This will let to remove the need for dynamic state atoms in
some drivers.
For now, we still set _NEW_PROGRAM in all the places we used to. We'll no
longer set _NEW_PROGRAM in glUniform() after drivers/etc have been updated.
|
|
|
|
|
|
|
|
|
|
|
|
This came from commit 1b2ab023673261b4b942e1126c0b599d02fbd4a0
|
|
|
|
|
|
|
|
This needs a proper fix to propogate the out-of-memory condition back
up to Mesa and the app as a GL error. Until then, at least catch the
problem at its source.
|
|
|
|
|
|
|
|
Fixes a regression from commit 2c30fd84dfa052949a117c78d932b58c1f88b446
seen with DRI1.
|
|
|
|
Fixes bug seen in progs/tests/vptest1.c
|
|
Fixes gearsvbo app by Michael Clark.
|
|
Fixes progs/glsl/skinning.c demo.
|
|
|
|
The READ message's msg_control value can be 0 or 1 to indicate that the
Oword should be read into the lower or upper half of the target register.
It seems that the other half of the register gets clobbered though. So
we read into two dest registers then use a MOV to combine the upper/lower
halves.
|
|
|
|
|
|
|
|
Now that we have real constant buffers, the demands on the CURBE are lessened.
When we use real VS/WM constant buffers we only use the CURBE for clip planes.
|
|
There are two usage types of buffer CPU accesses:
One where we try to use the buffer contents for multiple draw commands in
a batch. (batch := sequence of commands that are flushed together),
like incrementally adding bitmaps to a bitmap texture that is reallocated
on flush.
And one where we assume we can safely overwrite the old buffer contexts, like
glTexSubImage. In this case we need to make sure all old drawing commands
referencing the buffer are flushed before we map the buffer.
This is easily forgotten.
Add wrappers for the most common of these operations. The first type is
prefixed with "st_no_flush" and the second type is prefixed with
"st_cond_flush", where "cond" indicates that we attmpt to only flush
if there is indeed unflushed draw commands referencing the buffer.
Prefixed functions are
screen::get_tex_transfer
pipe_buffer_write
pipe_buffer_read
pipe_buffer_map
Please use the wrappers whenever possible.
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
|