| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Rename old IGDNG to Ironlake, and set 'gen' number for
Ironlake as 5, so tracking the features with generation num
instead of special is_ironlake flag.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
Fixes piglit glsl-orangebook-ch06-bump, regressed with
4fc57322258a750c0a9cabc77372b5ccde1fa877
|
|
The hope is to later take advantage of the reduced constant usage to
free up regs. This only covers the GLSL path at the moment, because
the brw_wm_emit path doesn't get the information as to whether a float
value is a constant or a uniform.
|
|
I keep finding the desire to force this path to debug it instead of
cooking up goofy-looking testcases to do so.
|
|
Saves an instruction in PINTERP, LINTERP, and PIXEL_W from
brw_wm_glsl.c For non-GLSL it isn't used yet because the deltas have
to be laid out differently.
|
|
This would be triggered by use of sqrt() along with control flow.
Fixes piglit-fs-sqrt-branch and a bug in Yo Frankie!.
|
|
|
|
Corresponds to d225a25e21a24508aea3b877c78beb35502e942d and fixes
piglit glsl-fs-loop-nested. Bug #25173.
|
|
We were doing it ad-hoc before, as instructions with potential
aliasing problems were identified. But thanks to swizzling basically
anything can have aliasing, so just do it generally at source reg
setup time. This is somewhat inefficient, because sometimes an
operation doesn't need unaliasing protection if the swizzling is safe,
but the unaliasing before didn't cover those cases either.
Fixes piglit glsl-fs-loop.
|
|
|
|
Conflicts:
configs/darwin
src/gallium/auxiliary/util/u_clear.h
src/gallium/state_trackers/xorg/xorg_exa_tgsi.c
src/mesa/drivers/dri/i965/brw_draw_upload.c
|
|
|
|
|
|
Caught by clang.
|
|
Saves ~480 bytes of code.
|
|
Add a GLbitfield64 type and several macros to operate on 64-bit
fields. The OutputsWritten field of gl_program is changed to use that
type. This results in a fair amount of fallout in drivers that use
programs.
No changes are strictly necessary at this point as all bits used are
below the 32-bit boundary. Fairly soon several bits will be added for
clip distances written by a vertex shader. This will cause several
bits used for varyings to be pushed above the 32-bit boundary. This
will affect any drivers that support GLSL.
At this point, only the i965 driver has been modified to support this
eventuality.
I did this as a "squash" merge. There were several places through the
outputswritten64 branch where things were broken. I foresee this
causing difficulties later for bisecting. The history is still
available in the branch.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm.h
|
|
This should fix TXB on G45 and older in the GLSL case.
|
|
New comments should explain some of the confusion about how this message
works.
|
|
They're the same regardless of execution width for 8, 4x2, and 16.
|
|
|
|
This should fix issues with antialiased lines in GLSL.
|
|
The PINTERP code should be faster for brw_wm_glsl.c now since brw_wm_emit.c's
had been improved, and pixel_w should no longer stomp on a neighbor to dst.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This drops support for get_src_reg_imm in these, but the prospect of getting
brw_wm_pass*.c onto our GLSL path is well worth some temporary pain.
|
|
This matches brw_wm_emit.c, which we'll be using shortly. There's a
possible penalty here in that we'll allocate registers for unused channels,
since we aren't doing ref tracking like brw_wm_pass*.c does. However, my
measurements on GM965 don't show any for either OA or UT2004 with the GLSL
path forced.
|
|
This makes things a bit easier to remember/understand.
|
|
Previously, it was trying to mess around with the varying's
WM setup data to produce a result. Along with not actually working when
passed a varying, this wouldn't work if you did dFd[xy]() on a temporary.
Instead, just calculate the derivative using the neighbors in the subspan.
|
|
The instructions we're translating already went through the brw_wm_pass_fp()
function which does the sampler->texture unit mapping. We were applying
the sample->unit mapping a second time in the GLSL texture emitters.
Often, this made no difference but other times it could lead to accessing
an invalid texture and could cause a GPU lockup.
|
|
|
|
|
|
This matches brw_wm_pass*.c behavior, and fixes the norsetto shadow demo.
Bug #19489
|
|
|
|
|
|
|
|
This is preparation for merging of brw_wm_glsl.c and
brw_wm_emit.c, and glsl.c doesn't swizzle channel results around.
|
|
This doesn't fix the glean testcase, but I guess it provides hope.
|
|
I was getting tired of doing the dance of INTEL_DEBUG=batch, copying it out,
and running intel-gen4disasm on it.
|
|
The LOOP/ENDLOOP pair is renamed to BGNFOR/ENDFOR as its behaviour
is similar to a C language for-loop.
The BGNLOOP2/ENDLOOP2 pair is renamed to BGNLOOP/ENDLOOP as now
there is no name collision.
|
|
|
|
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
|
|
the driver used to overwrite grf0 then use implicit move by send instruction
to move contents of grf0 to mrf1. However, we must not overwrite grf0 since
it's still used later for fb write.
Instead, do the move directly do mrf1 (we could use implicit move from another
grf reg to mrf1 but since we need a mov to encode the data anyway it doesn't
seem to make sense).
I think the dp_READ/WRITE_16 functions may suffer from the same issue.
While here also remove unnecessary msg_reg_nr parameter from the dataport
functions since always message register 1 is used.
|
|
|
|
glsl compiler will not generate OPCODE_SWZ, and as a first step it would
be translated away to a MOV anyway (why?), but later internally this opcode is
generated (for EXT_texture_swizzling).
|
