| Age | Commit message (Collapse) | Author |
|---|
|
Passes piglit glsl-vs-loop testcase.
Bug #20171
|
|
This should help with things like lightsmark, but I don't have a testcase
for this commit.
|
|
|
|
This showed a 1.9% (+/-.3%, n=3) improvement in OA performance with high
geometry settings.
|
|
|
|
Fixes piglit glsl-vs-if-bool and progs/glsl/twoside, and will likely be
useful for the looping code.
Bug #18992
|
|
Previously, we'd be branching based on whatever condition code happened to be
laying around.
|
|
I was getting tired of doing the dance of INTEL_DEBUG=batch, copying it out,
and running intel-gen4disasm on it.
|
|
See comment on Vertex URB Entry Read Length for VS_STATE.
This, combined with the previous three commits, fixes #22945.
|
|
This fix is just from code and docs inspection, but it may fix hangs on
some applications.
|
|
1. new PCI ids
2. fix some 3D commands on new chipset
3. fix send instruction on new chipset
4. new VUE vertex header
5. ff_sync message (added by Zou Nan Hai <nanhai.zou@intel.com>)
6. the offset in JMPI is in unit of 64bits on new chipset
7. new cube map layout
|
|
If we can't fit all the VS outputs into the MRF, we need to overflow into
temporary GRF registers, then use some MOVs and a second brw_urb_WRITE()
instruction to place the overflow vertex results into the URB.
This is hit when a vertex/fragment shader pair has a large number of varying
variables (12 or more).
There's still something broken here, but it seems close...
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
