| Age | Commit message (Collapse) | Author |
|---|
|
Reported-by: Timo Aaltonen <tjaalton@ubuntu.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=83207
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Should match the functionality of the earlier generations, but untuned.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Turns out the "new" assembler that uses mesa's opcode emission hits the
path that automatically transforms MRF registers into GRF ones in the
exa_wm_src_projective shader.
The diff with the new assembler is:
$ intel-gen4disasm -g7 -
- { 0x00600041, 0x208077be, 0x008d03c0, 0x008d0180 },
+ { 0x00600041, 0x2e8077bd, 0x008d03c0, 0x008d0180 },
mul(8) m4<1>F g30<8,8,1>F g12<8,8,1>F { align1 };
mul(8) g116<1>F g30<8,8,1>F g12<8,8,1>F { align1 };
Of course, message registers are no more in gen7, so the shader is
trying to do something shaddy (ahem!).
Instead of using m4, let's make exa_wm_src_projective use g68 for v (aka
vl) which makes sense since:
1/ vh is g69
2/ exa_wm_src_affine uses g68 for vl already
This commit changes the generated assembly, here's the decoded diff:
$ intel-gen4disasm -g7 -
- { 0x00600041, 0x208077be, 0x008d03c0, 0x008d0180 },
+ { 0x00600041, 0x288077bd, 0x008d03c0, 0x008d0180 },
mul(8) m4<1>F g30<8,8,1>F g12<8,8,1>F { align1 };
mul(8) g68<1>F g30<8,8,1>F g12<8,8,1>F { align1 };
Cc: Kenneth Graunke <kenneth@whitecape.org>
Reported-by: Xiang, Haihao <haihao.xiang@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
This way, when a new intel-gen4asm is available (because one just hacked
on it and has installed a new version for instance) the shaders will be
recompiled. This helps catching regressions, testing the latest changes
in the assembler haven't broken too many things.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As we use pkg-config to determine whether to use intel-gen4asm, we
should also use it to locate the right version of intel-gen4asm to use.
This allows the user to install the assembler in a non-standard path for
cross-builds and similar.
Reported-by: Josh Tripplet <josh@freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55646
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Take advantage of a couple of new instructions introduced with Cantiga
to reduce the instruction count inside the shaders and improve
performance by around 10% in the fish-demo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
These are exactly the same as the ones for Sandybridge, but with message
registers translated (hopefully) in the same way as Haihao's new
programs (m1 == g65).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Redefine some M4 macros, also update the check for
intel-gen4asm to support Ivybridge
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
It is to prepare for Xv on Ivybridge. The difference from Sandybridge
is that all message payload must be in GRF registers instead of MRF registers
on Ivybridge. We will only redefine some M4 macros for Ivybridge
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
It is weird that some rendercheck cases only work fine with headerless write.
Need to update intel-gen4asm to support headerless write
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
To prepare for composite on Sandybridge
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Need to update intel-gen4asm to build these fragments
Signed--off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
The two fragments will be reused for sampling YUV surface
and send doesn't have implied move on Sandybridge
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
We only set up one sampler, because all of our sampling is the same. By
using a non-zero index for the other two samplers, we'd dereference (likely)
zeroed data, resulting in using NEAREST filtering. This was a regression in
40671132cb3732728703c6444f4577467fa9223f which incidentally switched from
having 6 samplers to 1.
Bug #22895, #19856
|
|
This file is not even referenced by any Makefile.am
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
Also check intel-gen4asm tool here for new -g option, which is
required to compile new programs.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
