Add the missing wayland, null, android and haiku platforms.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Matt Turner <mattst88@gmail.com>
st/egl was the only one which had support for this platform.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Matt Turner <mattst88@gmail.com>
There's 2 reasons why we'd want to use the global context:
1) There still seems to be one memory "leak" left when using multiple llvm
contexts (it is not a true leak as the memory disappears into some still
addressable pool but nevertheless the memory consumption grows). See
http://cgit.freedesktop.org/~jrfonseca/llvm-jitstress/
2) These contexts get kinda big - even when disposing modules etc. after
compiling a shader the LLVMContext can easily be over 100kB. So when there's
lots of llvm contexts arounds it adds up.
The downside is that at least right now this is absolutely not thread safe,
so this only works safely in environments where multiple pipe contexts are not
used concurrently.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
reduces from 2664->2656.
Acked-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
this reduces it from 1088 -> 1080 bytes
Acked-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
this just removes 4 bytes from this object.
Acked-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This removes a hole, and puts the large allocation at the end,
Acked-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These 392->388 and 72->68.
Acked-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
reduces 40->32
but reduces use in context from 7680->6144.
Acked-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
gl_program : 1344->1336
gl_shader: 488->472
gl_shader_program: 352->344.
Acked-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reduces size from 184 to 176 bytes.
Acked-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
reduces size from 64 to 56 bytes.
Acked-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drops 80 bytes to 72.
Acked-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drops from 56 to 48 bytes,
drops gl_vertex_array_object from 4584 to 4320 bytes
Acked-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drops size from 520 -> 512 bytes,
which then makes gl_texture_attrib go from 99984 to 98440.
Acked-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
this drops the size from 52 bytes to 48 bytes.
Acked-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drops size from 28 bytes to 20.
Acked-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes a piglit regression
(shaders/glsl-fs-vec4-indexing-temp-dst-in-nested-loop-combined) with
my series for GVN.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
This is currently not a problem because the vec4 visitor happens to
mask out unused components from the destination, but it might become
an issue when we start using atomics without writeback message. In
any case it seems sensible to set it again here because the
consequences of setting the wrong writemask (random graphics memory
corruption) are difficult to debug and can easily go unnoticed.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
And calculate the message response size based on the number of
components rather than the other way around. This simplifies their
interface somewhat and allows the caller to request a writeback
message with more than one vector component in SIMD4x2 mode.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
This was telling the sampler to do texture fetches for *all* channels
in the non-constant surface index case, what could have reduced
throughput unnecessarily when some of the channels were disabled by
control flow.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
This is going to be useful because the Gen7+ uniform and varying pull
constant, texturing, typed and untyped surface read, write, and atomic
generation code on the vec4 and fs back-end all require the same logic
to handle conditionally indirect surface indices. In pseudocode:
| if (surface.file == BRW_IMMEDIATE_VALUE) {
| inst = brw_SEND(p, dst, payload);
| set_descriptor_control_bits(inst, surface, ...);
| } else {
| inst = brw_OR(p, addr, surface, 0);
| set_descriptor_control_bits(inst, ...);
| inst = brw_SEND(p, dst, payload);
| set_indirect_send_descriptor(inst, addr);
| }
This patch abstracts out this frequently recurring pattern so we can
now write:
| inst = brw_send_indirect_message(p, sfid, dst, payload, surface)
| set_descriptor_control_bits(inst, ...);
without worrying about handling the immediate and indirect surface
index cases explicitly.
v2: Rebase. Improve documentatation and commit message. (Topi)
Preserve UW destination type cargo-cult. (Topi, Ken, Matt)
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Both do_vs_prog and do_gs_prog initialize brw_stage_prog_data::nr_params to
the number of uniform *vectors* required by the shader rather than the number
of uniform components, contradicting the comment. This is inconsistent with
what the state upload code and scalar path expect but it happens to work until
Gen8 because vec4_visitor interprets it as a number of vectors on construction
and later on overwrites its original value with the number of uniform
components referenced by the shader.
Also there's no need to add the number of samplers, they're not actually
passed in as uniforms.
Fixes a memory corruption issue on BDW with SIMD8 VS.
Cc: "10.5" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Several steppings of Skylake fail when using SIMD16 with 3-source
instructions (such as MAD).
This implements WaDisableSIMD16On3SrcInstr and fixes ~190 Piglit
tests.
Based on a patch by Neil Roberts.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Neil Roberts <neil@linux.intel.com>
The places that were checking whether 3-source instructions are
supported have now been combined into a small helper function. This
will be used in the next patch to add an additonal restriction.
Based on a patch by Kenneth Graunke.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
brwContextInit now queries the GPU revision number via a new parameter
for DRM_I915_GETPARAM. This new parameter requires a kernel patch and
a patch to libdrm. If the kernel doesn't support it then it will
continue but set the revision number to -1. The intention is to use
this to implement workarounds that are only needed on certain
steppings of the GPU.
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Generate GL_INVALID_OPERATION and return NULL when the buffer object
hasn't been created. All callers expect this.
v2: Use a more concise error message.
Cc: Laura Ekstrand <laura@jlekstrand.net>
Reviewed-by: Laura Ekstrand <laura@jlekstrand.net>
This add primitive restart support to the prim conversion.
This involves changing the API for the translate functions
as we need to pass the prim restart index and the original
number of indices into the translate functions.
primitive restart is support for quads, quad strips
and polygons.
This deal with the case where the actual number of output
primitives is less than the initially calculated number,
by filling the rest of the output primitives with the restart
index, the other option is to reduce the output prim number,
but that will make the generator code a bit messier.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This should improve the performance of any shaders using the KIL
instruction. I'm a bit surprised we missed this.
Unfortunately, I have not been able to measure any performance
improvements from this patch. It does make ARB_fragment_program
behave similarly to GLSL code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This is already copied in two places, and I want to copy it to a third
place.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
So it turns out that this doesn't actually fix any bugs or add any features,
stictly speaking. However, it does avoid a lot of kludginess. Previously, if
you called
glCopyTextureSubImage3D(texcube, 0, 0, 0, zoffset = 3, ...
it would grab the texture image object for face = 0 in teximage.c instead of
the desired face = 3. But Line 274 of brw_blorp_blit.cpp would correct for
this by updating the slice to 3.
This commit does the correct thing before calling any drivers,
which should make the functionality much more robust and uniform across all
drivers.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
We use the idiom
ir_foo *x = y->as_foo();
if (x == NULL)
return;
all over the place. GCC generates some quite lovely code for this.
One such example:
340a5b: 83 7d 18 04 cmpl $0x4,0x18(%rbp)
340a5f: 0f 85 06 04 00 00 jne 340e6b
340a65: 48 85 ed test %rbp,%rbp
340a68: 0f 84 fd 03 00 00 je 340e6b
This case used as_expression() (ir_type_expression is 4). Note that it
checks the ir_type, then checks that the pointer isn't NULL. There is
some disconnect in GCC around the condition in the as_foo functions.
return ir_type == ir_type_##TYPE ? (ir_##TYPE *) this : NULL; \
It believes "this" could be NULL, so it emits check outside the function
just for fun.
This patch uses assume() to tell GCC that it need not bother with extra
NULL checking of the pointer returned by the as_foo functions.
text data bss dec hex filename
4836430 158688 26248 5021366 4c9eb6 i965_dri-before.so
4836173 158688 26248 5021109 4c9db5 i965_dri-after.so
v2: Replace 'if (this == NULL) unreachable("this cannot be NULL")' with
assume(this != NULL). Suggested by Ilia Mirkin.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Previously, we put all the uniforms into one big array. The problem with
this approach is that, as soon as there was one indirect array acces, the
backend would decide that the entire large array should be pull constants.
This commit splits the array in half: first direct-only uniforms and then
potentially-indirect uniforms. This may not be optimal, but it does let
the backend promote things to push constants.
Shader-db results on HSW:
total instructions in shared programs: 4114840 -> 4112172 (-0.06%)
instructions in affected programs: 43316 -> 40648 (-6.16%)
helped: 116
HURT: 0
v2: Set param_size[num_direct_uniforms] only if we have indirect uniforms.
This caused a bug that, strangely enough, only showed up on Broadwell
vertex shaders.
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
v2: Delete the set of indirectly accessed variables when we're done with it
v3: Rename from _packed to _scalar
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Previously, we just assigned variable locations in nir_lower_io. Now, we
force the user to assign variable locations for us. This gives the backend
a bit more control over where variables are placed.
v2: Rename from _packed to _scalar
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
We never did a single hash table lookup in the entire NIR code base that I
found so there was no real benifit to doing it that way. I suppose that
for linking, we'll probably want to be able to lookup by name but we can
leave building that hash table to the linker. In the mean time this was
causing problems with GLSL IR -> NIR because GLSL IR doesn't guarantee us
unique names of uniforms, etc. This was causing massive rendering isues in
the unreal4 Sun Temple demo.
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Different errors for type mismatches, size mismatches and matrix/
non-matrix mismatches. Use a common format of "uniformName"@location
in the messags.
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
On platforms that do not natively generate 0u and ~0u for Boolean
results, b2f expressions that look like
f = b2f(expr cmp 0)
will generate better code by pretending the expression is
f = ir_triop_sel(0.0, 1.0, expr cmp 0)
This is because the last instruction of "expr" can generate the
condition code for the "cmp 0". This avoids having to do the "-(b & 1)"
trick to generate 0u or ~0u for the Boolean result. This means code like
mov(16) g16<1>F 1F
mul.ge.f0(16) null g6<8,8,1>F g14<8,8,1>F
(+f0) sel(16) m6<1>F g16<8,8,1>F 0F
will be generated instead of
mul(16) g2<1>F g12<8,8,1>F g4<8,8,1>F
cmp.ge.f0(16) g2<1>D g4<8,8,1>F 0F
and(16) g4<1>D g2<8,8,1>D 1D
and(16) m6<1>D -g4<8,8,1>D 0x3f800000UD
v2: When the comparison is either == 0.0 or != 0.0 use the knowledge
that the true (or false) case already results in zero would allow better
code generation by possibly avoiding a load-immediate instruction.
v3: Apply the optimization even when neither comparitor is zero.
Shader-db results:
GM45 (0x2A42):
total instructions in shared programs: 3551002 -> 3550829 (-0.00%)
instructions in affected programs: 33269 -> 33096 (-0.52%)
helped: 121
Iron Lake (0x0046):
total instructions in shared programs: 4993327 -> 4993146 (-0.00%)
instructions in affected programs: 34199 -> 34018 (-0.53%)
helped: 129
No change on other platforms.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Tapani Palli <tapani.palli@intel.com>
