| Age | Commit message (Collapse) | Author |
|---|
|
|
|
They seem to be used for something else and using them for shader temps
seems to lead to GPU lock-ups.
Call _mesa_warning() when we run out of temps.
Also, clean up some debug code.
|
|
|
|
Thanks to branching, the state of c->current_const[i].index at the point
of emitting constant loads for this instruction may not match the actual
constant currently loaded in the reg at runtime. Fixes a regression in my
GLSL program for idr's class since b58b3a786aa38dcc9d72144c2cc691151e46e3d5.
|
|
This snuck in with the multi-draw-buffers commit, and is a major penalty
to performance. It doesn't appear to be required, as the only dependency
the surface BO has is on the state key (and if there's some other dependency,
it should just be in the key).
This brings openarena performance up to almost 2% faster than Mesa 7.4.
|
|
This was a leftover from the brw_wm_constant_buffer change.
|
|
This can avoid re-uploading constant data when it isn't necessary, and is
a step towards not updating other surfaces just because constants change.
It also brings the upload of the constant buffer next to the creation.
This brings openarena performance up another 4%, to 91% of the Mesa 7.4 branch.
|
|
Also, only create VS surface state if there's a VS constant buffer to be
uploaded, and set the contents of the buffer at the same time as creation.
|
|
Really, the creation and upload of constants should be in the same place,
since they should only happen together, and a state flag should be
triggered by them so that we don't thrash state around so much for just
updating constants. But this still recovers openarena performance by
another 19%, leaving us 16% behind Mesa 7.4 branch.
|
|
Conflicts:
src/mesa/drivers/dri/i965/brw_curbe.c
src/mesa/drivers/dri/i965/brw_vs_emit.c
src/mesa/drivers/dri/i965/brw_wm_glsl.c
|
|
|
|
Make the use_const_buffer field per-program and only call the code which
updates the constant buffer's data if the flag is set.
This should undo the perf regression from 20f3497e4b6756e330f7b3f54e8acaa1d6c92052
(cherry picked from master, commit dc9705d12d162ba6d087eb762e315de9f97bc456)
|
|
Make the use_const_buffer field per-program and only call the code which
updates the constant buffer's data if the flag is set.
This should undo the perf regression from 20f3497e4b6756e330f7b3f54e8acaa1d6c92052
|
|
Use a bitvector of used/free flags.
If we run out of temps, examine the live intervals of the temp regs in
the program and free those which are no longer alive.
Also, enable the new WM const buffer code.
|
|
dri_bo_subdata()
This wraps up the unfinished business from commit a9a363f8298e9d534e60e3d2869f8677138a1e7e
|
|
need to clamp point size to user set min/max values, even for constant
point size. Fixes glean pointAtten test.
|
|
The drm_intel_gem_bo_map_gtt() call that replaced dri_bo_map() is
producing errors like:
intel_bufmgr_gem.c:689: Error preparing buffer map 39 (vp_const_buffer): Invalid argument .
and returning NULL, causing a segfault in the memcpy().
Just reverting until we can get to the root issue...
|
|
Also fixes drawing to 3D texture depth levels.
|
|
This is a CPU win in general, but in particular reduces the pain of
Mesa's calculation of min/max indices in DrawElements (wtf?).
|
|
|
|
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.
|
|
|
|
i915 actually supports up to 4 (according to header file - not tested),
i965 up to 16 (code already handled this but slightly broken), so don't use 2
for all chips, even though angular dependency is very high.
|
|
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.
|
|
|
|
|
|
|
|
Fixes a regression from commit 2c30fd84dfa052949a117c78d932b58c1f88b446
seen with DRI1.
|
|
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.
|
|
|
|
Also enable them all regardless of screen bpp, as 32 bpp what I've been
testing against, and haven't been able to detect any screen bpp-specific
troubles with them.
|
|
For some reason, MOV instructions using immediate src values don't seem
to work reliably on the GLSL path. Disable them for now (falling back to
const buffer reads). This fixes a bunch of glean glsl1 failures.
|
|
|
|
|
|
A scatter-read should be possible, but we're just using two READs for
the time being.
|
|
|
|
Calls to release_tmps() were causing the temps holding constants to get
recycled.
|
|
|
|
There's really no need for two negation fields. This came from the
GL_NV_fragment_program extension. The new, unified Negate bitfield applies
after the absolute value step.
|
|
This mostly came down to finding the right MRF incantation in the
brw_dp_READ_4_vs() function.
Note: this feature is still disabled (but getting close to done).
|
|
Hook up a constant buffer, binding table, etc for the VS unit.
This will allow using large constant buffers with vertex shaders.
The new code is disabled at this time (use_const_buffer=FALSE).
|
|
|
