Age | Commit message (Collapse) | Author |
|
|
|
|
|
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
|
|
|
|
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.
|
|
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.
|
|
|
|
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).
|
|
|
|
|
|
|
|
Previously, the prog_instruction::Data field was used to map original Mesa
instructions to brw instructions in order to resolve subroutine calls. This
was a rather tangled mess. Plus it's an obstacle to implementing dynamic
allocation/growing of the instruction buffer (it's still a fixed size).
Mesa's GLSL compiler emits a label for each subroutine and CAL instruction.
Now we use those labels to patch the subroutine calls after code generation
has been done. We just keep a list of all CAL instructions that needs patching
and a list of all subroutine labels. It's a simple matter to resolve them.
This also consolidates some redundant post-emit code between brw_vs_emit.c and
brw_wm_glsl.c and removes some loops that cleared the prog_instruction::Data
fields at the end.
Plus, a bunch of new comments.
|
|
This doesn't effect correctness, but we were emitting an extraneous ADD.
|
|
|
|
|
|
|
|
Bug #19226.
|
|
Also, fix some RNDD vs. RNDZ confusion elsewhere.
|
|
|
|
|
|
|
|
The partial precision mode doesn't have quite enough bits of precision
to pass conformance tests.
|
|
|
|
This cuts one MOV out when setting a zero header.
|
|
The mobile and desktop chipsets are the same, and having them separate is
more typing and more chances to screw up.
|
|
|
|
|
|
Patch is correctly applied this time.
|
|
|
|
This reverts commit b993d539a76e7f1446890a85e4b61deec4d4162d. The
patch was applied incorrectly. Actual fix coming soon. Sorry for the
noise.
|
|
|
|
|
|
This reverts commit 3158e981f5f37768e9b04765704b9eaece8b899b.
rhw issue has gone away on IGD.
|
|
|
|
|
|
The WM code had this right, so copy its behavior. This reverts a flipping
of the arguments to SLT in brw_vs_tnl which came in with the GLSL code that
probably occurred to work around the flipped results, and brings the code back
in line with t_vp_build.c.
|
|
|
|
Conflicts:
src/mesa/drivers/dri/i965/brw_sf.h
src/mesa/drivers/dri/i965/intel_context.c
|
|
|
|
eg: #include "shader/program.h" and remove -I$(TOP)/src/mesa/program
|
|
|
|
|