| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
As pointed out by Shervin Sharifi.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Certain platforms support the ability to sample from a texture, and write it out
to the file RT - thus saving a costly send instructions (note that this is a
potnential win if one wanted to backport to a tag that didn't have the patch
from Topi which removed excess MOVs from LOAD_PAYLOAD - 97caf5fa04dbd2),
v2: Modify the algorithm. Instead of iterating in reverse through blocks and
insts, since the last block/inst is the only thing which can benefit. Rebased
on top of Ken's patching modifying is_last_send
v3: Rebased over almost 2 months, and Incorporated feedback from Matt:
Some comment typo fixes and rewordings.
Whitespace
Move the optimization pass outside of the optimize loop
v4: Some cosmetic changes requested from Ken. These changes ensured that the
optimization function always returned true when an optimization occurred, and
false when one did not. This behavior did not exist with the original patch. As
a result, having the separate helper function which Matt did not like no longer
made sense, and so now I believe everyone should be happy.
Benchmark (n=20) %diff
*OglBatch5 -1.4
*OglBatch7 -1.79
OglFillTexMulti 5.57
OglFillTexSingle 1.16
OglShMapPcf 0.05
OglTexFilterAniso 3.01
OglTexFilterTri 1.94
No piglit regressions:
(http://otc-gfxtest-01.jf.intel.com:8080/view/dev/job/bwidawsk/112/)
[*] I believe my measurements are incorrect for Batch5-7. If I add this new
optimization, but never emit the new instruction I see similar results.
v5: Remove declaration of combine_tex_header since v4 dropped that function
(Ben)
Remove check for impossible case of an empty block (Matt)
Set dest earlier to avoid extra special-casing in generate_tex (Matt)
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based originally on a patch from Ken in May 2014 of the same title. Things
changed enough that I didn't feel comfortable leaving his authorship.
v2: Replace fp->UsesKill with wm_prog_data->uses_kill. Since Ken took the time
to also explain the difference to me, here is his explanation for posterity:
"fp->UsesKill indicates that a ARB_fragment_program shader uses the KIL
instruction, or that a GLSL shader uses the "discard" insntruction
(which are analogous).
On Gen4-5, we sometimes have to simulate OpenGL's "Alpha Test" feature
by emitting shader code that implicitly does a "discard" instruction.
In the key setup, we do:
/* key->alpha_test_func means simulating alpha testing via discards,
* so the shader definitely kills pixels.
*/
prog_data.uses_kill = fp->program.UsesKill || key->alpha_test_func;
Even though the shader may not technically contain a "discard", we need
to act as if it does.
I've also been trying to move the i965 state setup code to use
brw_wm_prog_key for everything, rather than poking at core Mesa's
gl_program/gl_fragment_program/gl_shader/gl_shader_program structures.
--Ken"
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an instruction has a side effect, it impacts the available options when
reordering an instruction. As the EOT flag is an implied write to the render
target in the FS, it can be considered a side effect.
This patch shouldn't actually have any impact on the current code since the EOT
flag implies that the opcode is already one with side effects,
FS_OPCODE_FB_WRITE. The next patch however will introduce an optimization
whereby the EOT flag can occur with an opcode SHADER_OPCODE_TEX, and as that
instruction will perform the same implied write to the render target, it cannot
be reordered.
v2: Remove extra whitespace (Matt)
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
| |
Consistently just use C99's __func__ everywhere.
No functional changes.
Acked-by: Matt Turner <[email protected]>
Signed-off-by: Marius Predut <[email protected]>
|
|
|
|
|
|
|
|
| |
Consistently just use C99's __func__ everywhere.
No functional changes.
Acked-by: Matt Turner <[email protected]>
Signed-off-by: Marius Predut <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Consistently just use C99's __func__ everywhere.
The patch was verified with Microsoft Visual studio 2013
redistributable package(RTM version number: 18.0.21005.1)
Next MSVC versions intends to support __func__.
No functional changes.
Acked-by: Matt Turner <[email protected]>
Signed-off-by: Marius Predut <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Consistently just use C99's __func__ everywhere.
The patch was verified with Microsoft Visual studio 2013
redistributable package(RTM version number: 18.0.21005.1)
Next MSVC versions intends to support __func__.
No functional changes.
Acked-by: Matt Turner <[email protected]>
Signed-off-by: Marius Predut <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Consistently just use C99's __func__ everywhere.
The patch was verified with Microsoft Visual studio 2013
redistributable package(RTM version number: 18.0.21005.1)
Next MSVC versions intends to support __func__.
No functional changes.
Acked-by: Matt Turner <[email protected]>
Signed-off-by: Marius Predut <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consistently just use C99's __func__ everywhere.
The patch was verified with Microsoft Visual studio 2013
redistributable package(RTM version number: 18.0.21005.1)
Next MSVC versions intends to support __func__.
No functional changes.
Acked-by: Matt Turner <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Signed-off-by: Marius Predut <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consistently just use C99's __func__ everywhere.
The patch was verified with Microsoft Visual studio 2013
redistributable package(RTM version number: 18.0.21005.1)
Next MSVC versions intends to support __func__.
No functional changes.
Acked-by: Matt Turner <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Signed-off-by: Marius Predut <[email protected]>
|
|
|
|
|
|
|
|
|
| |
a * b is equivalent to -a * -b, and the previous code was failing at
that.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89961
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit e93566a15c61c33faa changed the message header code needed to
make Skylake use SIMD4x2 so that it uses a register with width 4
instead of 8 as the source register in the send message. However it
also changed the width for the dest in the MOV instruction which is
used to initialise the header register with the values from g0. The
width of the destination is used to determine the exec size in
brw_set_dest so this would end up making the MOV have an exec size of
4. I think this would end up leaving the top half of the register
uninitialised. The top half of the header has meaningful values so
this probably isn't a good idea.
This patch just casts the dest register for the MOV instruction back
to a vec8 to fix it. It doesn't cause any changes to a Piglit run.
Reviewed-by: Ben Widawsky <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit b616164 added an optimization of b2f generation of a comparison.
It also included an extra optimization of one of the comparison values
is a constant of zero. The trick was that some value was known to be
zero, so that value could be used in the SEL instruction instead of
potentially loading 0.0 into a register.
This change switched the order of the arguments to the SEL, and, for
some unknown reason, I thought that the predicate should therefore
only be inverted for the == case. Clearly, it should always be
inverted.
Fixes piglit fs-notEqual-of-expression.shader_test and
fs-equal-of-expression.shader_test.
v2: Don't do the "register already has zero" optimization for the '== 0'
case. In that case, the register does not have zero when we want to
produce a zero result.
Signed-off-by: Ian Romanick <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89722
Reviewed-by: Kenneth Graunke <[email protected]> [v1]
Tested-by: Lu Hua <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
new_prim was declared as a stack variable within a nested scope; we
tried to retain a pointer to that data beyond the scope, which is bogus.
GCC with -O1 eliminated most of the code that set new_prim's fields.
Move the declaration to fix the bug.
v2: Also fix new_ib (thanks to Matt Turner and Ben Widawsky).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81025
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ben Widawsky <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I finally managed to dig up some information on our mysterious GPU hangs.
A wiki page from the Crestline validation team mentions that they found
a GPU hang in "Serious Sam 2" (on Windows) with remarkably similar
conditions to the ones we've seen in Google Chrome and glmark2.
Apparently, if WM_STATE has "PS Use Source Depth" enabled, CC_STATE has
most depth state disabled, and you issue a CONSTANT_BUFFER command and
immediately draw, the depth interpolator makes a small mistake that
leads to hangs.
Most of the traces I looked at contained a CONSTANT_BUFFER packet
immediately followed by 3DPRIMITIVE, or at least very few packets.
It appears they also have "PS Use Source Depth" enabled - either at the
hang, or a little before it. So I think this is our bug.
The workaround is to emit a non-pipelined state packet after issuing a
CONSTANT_BUFFER packet. This is really similar to the workaround I
developed in commit c4fd0c9052dd391d6f2e9bb8e6da209dfc7ef35b.
v2: Fix word-wrapping issues.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Francisco Jerez <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
| |
In commit 4ebeb71573ad44f7657810dc5dd2c9030e3e63db, I deleted the
emit_shader_time_end() call in emit_urb_writes(). But I failed to add
it to run_vs(), as I intended. So no data was recorded at all.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We create textures internally for texsubimage, and we use
the values from sub image to create a new texture, however
we don't align these to valid sizes, and cube map arrays
must have an array size aligned to 6.
This fixes texsubimage cube_map_array on CAYMAN at least,
(it was causing GPU hang and bad values), it probably
also fixes it on radeonsi and evergreen.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89957
Tested-by: Tom Stellard <[email protected]>
Cc: [email protected]
Reviewed-by: Marek Olšák <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we can subimage upload a number of cube map array layers,
that aren't a complete cube map array, we should specify things
as a 2D array and blit from that.
Suggested by Ilia Mirkin as an alternate fix for texsubimage
cube map array issues.
seems to work just as well.
Cc: [email protected]
Reviewed-by: Marek Olšák <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change fixes a regression with timer queries introduced with
commit 3eb6258. There the pending batchbuffer is flushed
only if glEndQuery is executed. This present change adds such
a flush to glQueryCounter which also schedules a value query
just like glEndQuery does. The patch fixes GPU timer queries
going mad from within osgviewer.
Reviewed-by: Kenneth Graunke <[email protected]>
Signed-off-by: Mathias Froehlich <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
| |
Coverity is confused by the "float < int / 2" expression and suggests
casting MAX_GLUINT to unsigned, which I believe it was supposed to have
been already.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
Commit e16c5c90 was replacing 'region' with 'mt', leaving this
nonsensical code.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow glEGLImageTargetRenderbufferStorageOES and
glEGLImageTargetTexture2DOES for dma_buf EGLImages if the image is
a single RGBA8 unorm plane. This is safe, despite fast color clears,
because i965 disables allocation of auxiliary buffers for EGLImages.
Chrome OS needs this, because its compositor uses dma_buf EGLImages for
its scanout buffers.
Testing:
- Tested on Ivybridge Chromebook Pixel with WebGL Aquarium and
YouTube.
- No Piglit regressions on Broadwell with `piglit run -p gbm
tests/quick.py`, with my Piglit patches that update the
EGL_EXT_image_dma_buf_import tests.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EGL does not yet have extensions to manage the flushing and invalidating
of driver-internal aux buffers. So we must disable aux buffers of
dma_buf-backed EGLImages in order to safely render into them.
This patch is obviously needed for renderbufers. It's also needed for
textures because the user can attach the texture to a framebuffer and
because the driver sometimes renders to textures for internal reasons.
Testing:
- Tested on Ivybridge Chromebook Pixel with WebGL Aquarium and
YouTube.
- No Piglit regressions on Broadwell with `piglit run -p gbm
tests/quick.py`.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Add parameter 'bool disable_aux_buffers'.
This is a refactor patch. The patch changes no behavior because the new
parameter is false in every call.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new field disables allocation of auxiliary buffers, such as the HiZ
buffer and MCS buffer. This is useful for sharing the miptree bo with an
external client that doesn't understand auxiliary buffers.
We need this field to safely render to a buffer that was imported with
EGL_EXT_image_dma_buf_import, because EGL does not yet have extensions
to manage flushing and invalidating auxiliary buffers.
Nothing yet enables this field. That's left to follow-up patches.
Testing:
- Tested on Ivybridge Chromebook Pixel with WebGL Aquarium and
YouTube.
- No Piglit regressions on Broadwell with `piglit run -p gbm
tests/quick.py`.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Every caller of this function uses it to determine if the current
miptree needs a hiz buffer to be allocated. Strangely, the function
doesn't take a miptree argument. So, this function effectively decides
if and when a miptree's hiz buffer gets allocated without inspecting the
miptree itself. Luckily, the driver behaves correctly despite the
brw_is_hiz_depth_format's quirk.
I will soon make some changes to the miptree that will require
inspecting the miptree to determine if it needs a hiz buffer. So this
patch renames
brw_is_hiz_depth_format -> intel_miptree_wants_hiz_buffer
and gives it a miptree parameter.
This patch shouldn't change any behavior.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
| |
It's not used outside intel_mipmap_tree.c.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
| |
It's not used outside of intel_mipmap_tree.c, nor should it ever be.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
| |
I'm not sure what was the original intention, but currently
USE_EXTERNAL_DXTN_LIB always ends up defined, one way or another.
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Now that we store a copy of the NIR shader, and don't immediately free
it, we can use it in annotations as well.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we translated into NIR and did all the optimizations and
lowering as part of running fs_visitor. This meant that we did all of
that work twice for fragment shaders - once for SIMD8, and again for
SIMD16. We also had to redo it every time we hit a state based
recompile.
We now generate NIR once at link time. ARB programs don't have linking,
so we instead generate it at ProgramStringNotify time.
Mesa's fixed function vertex program handling doesn't bother to inform
the driver about new programs at all (which is rather mean), so we
generate NIR at the last minute, if it hasn't happened already.
shader-db runs ~9.4% faster on my i7-5600U, with a release build.
v2: Check NirOptions != NULL in ProgramStringNotify(). Don't bother
using _mesa_program_enum_to_shader_stage as we already know it.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Storing this here is pretty sketchy - I don't know if any driver other
than i965 will want to use it. But this will make it a lot easier to
generate NIR code at link time. We'll probably rework it anyway.
(Ian suggested making nir_assign_var_locations_scalar_direct_first
simply modify the nir_shader's fields, rather than passing pointers
to them. If this stays long term, we should do that. But Jason and
I suspect we'll be reworking this area again in the near future.)
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
| |
This makes it so emit_nir_code() doesn't modify the GLSL IR.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
| |
If it were null, we'd have just derefernced it two lines above.
|
| |
|
|
|
|
| |
Commit eb9bd3a1 changed the type of this field to uint16_t.
|
|
|
|
|
|
|
|
|
|
| |
Originally you had to have one or the other. But actually I don't want
either. (Or rather I want whatever is the minimum # of instructions.)
TODO: not sure where the best place to insert a check that driver hasn't
set *both* lower_negate and lower_sub?
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GLSL IR vs. NIR shader-db results on i965:
total instructions in shared programs: 2889747 -> 2890782 (0.04%)
instructions in affected programs: 2425446 -> 2426481 (0.04%)
helped: 3698
HURT: 5341
GLSL IR vs. NIR shader-db results on g4x:
total instructions in shared programs: 2547252 -> 2550440 (0.13%)
instructions in affected programs: 1984482 -> 1987670 (0.16%)
helped: 2844
HURT: 4776
GLSL IR vs. NIR shader-db results on Iron Lake:
total instructions in shared programs: 4053381 -> 4063828 (0.26%)
instructions in affected programs: 3026601 -> 3037048 (0.35%)
helped: 4110
HURT: 8331
GAINED: 1287
LOST: 9
GLSL IR vs. NIR shader-db results on Sandy Bridge:
total instructions in shared programs: 5307041 -> 5236666 (-1.33%)
instructions in affected programs: 3442908 -> 3372533 (-2.04%)
helped: 11829
HURT: 5604
GAINED: 33
LOST: 18
GLSL IR vs. NIR shader-db results on Ivy Bridge:
total instructions in shared programs: 4926333 -> 4857017 (-1.41%)
instructions in affected programs: 3144042 -> 3074726 (-2.20%)
helped: 11559
HURT: 4774
GAINED: 46
LOST: 25
GLSL IR vs. NIR shader-db results on Bay Trail:
total instructions in shared programs: 4926333 -> 4857017 (-1.41%)
instructions in affected programs: 3144042 -> 3074726 (-2.20%)
helped: 11559
HURT: 4774
GAINED: 46
LOST: 25
GLSL IR vs. NIR shader-db results on Haswell:
total instructions in shared programs: 4392487 -> 4293476 (-2.25%)
instructions in affected programs: 2800180 -> 2701169 (-3.54%)
helped: 13073
HURT: 3383
GAINED: 46
LOST: 23
GLSL IR vs. NIR shader-db results on Broadwell (FS only):
total instructions in shared programs: 4378113 -> 4283025 (-2.17%)
instructions in affected programs: 2743209 -> 2648121 (-3.47%)
helped: 12470
HURT: 3609
GAINED: 64
LOST: 27
Signed-off-by: Jason Ekstrand <[email protected]>
Acked-by: Matt Turner <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've started using NirOptions != NULL to mean "we're using NIR for this
stage." However, when INTEL_USE_NIR=1, we set it for a bunch of stages
that still use the vec4 backend, and thus definitely aren't using NIR.
For example, if INTEL_USE_NIR=1 we disable the GLSL IR cubemap
normalization pass, even for vertex shaders and geometry shaders. This
is wrong, but breaks a very uncommon case.
When I started deleting GLSL IR for stages where we claimed to be using
NIR, this bug quickly became apparent.
For now, only set it for fragment shaders, and vertex shaders if
brw->scalar_vs is set.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The disassembly currently has the swizzle after the type for 3src source
operands, and the other way around for 2src. Flip the type and swizzle
around for 3src so that the output matches 2src.
Reviewed-by: Matt Turner <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
|
|
|
|
|
|
|
|
| |
This function was getting a bit large and unwieldy.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Nothing actually wanted brw_shader fields - we just had to type
shader->base all over the place for no reason.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
We don't actually need a gl_program struct. We only used it to
translate prog->Target (i.e. GL_VERTEX_PROGRAM) to the gl_shader_stage
(i.e. MESA_SHADER_VERTEX). We may as well just pass that.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
I want to use this in some code that doesn't currently include mtypes.h.
It seems like a better place for it anyway.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
prog_to_nir should not modify the incoming Mesa IR program - just
translate it.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Skylake the order of the arguments for sample messages with the LD
type are u, v, lod, r whereas previously they were u, lod, v, r.
This fixes 144 Piglit tests including ones that directly use
texelFetch and also some using the meta stencil blit path which
appears to use texelFetch in its shader.
v2: Fix sampling 1D textures
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
On Gen7/8 for RAW surface format, the depth field (surf[3]) in surface
state means [30:21] bits of number of entries which is different from
other surface format which uses [26:21] bits field.
Signed-off-by: Zhenyu Wang <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Jason pointed out that variable dereferences in NIR are really part of
their parent instruction, and should have the same lifetime.
Unlike in GLSL IR, they're not used very often - just for intrinsic
variables, call parameters & return, and indirect samplers for
texturing. Also, nir_deref_var is the top-level concept, and
nir_deref_array/nir_deref_record are child nodes.
This patch attempts to allocate nir_deref_vars out of their parent
instruction, and any sub-dereferences out of their parent deref.
It enforces these restrictions in the validator as well.
This means that freeing an instruction should free its associated
dereference chain as well. The memory sweeper pass can also happily
ignore them.
v2: Rename make_deref to evaluate_deref and make it take a nir_instr *
instead of void *. This involves adding &instr->instr everywhere.
(Requested by Jason Ekstrand.)
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
| |
This allows those formats to work with the meta PBO upload path.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|