| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
ARB_direct_state_access texture functions that operate on cube maps no longer
need to verify that cube map texture objects contain six texture images
because _mesa_cube_level_complete now does that for them.
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
| |
_mesa_cube_level_complete now verifies that a cube map texture object actually
has six texture images before proceeding.
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
From the SNB PRM, volume 4, part 1, page 193:
"The dual source render target messages only have SIMD8 forms due to
maximum message length limitations. SIMD16 pixel shaders must send two of
these messages to cover all of the pixels. Each message contains two colors
(4 channels each) for each pixel in the message payload."
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82831
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The next commit needs to know the shader stage in glsl_to_nir().
To facilitate that, we pass the gl_shader rather than the raw exec_list
of instructions. This has both the exec_list and the stage.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
glsl_to_nir, tgsi_to_nir, and prog_to_nir all want to know whether the
driver supports native integers. Presumably other passes may as well.
Adding this to nir_shader_compiler_options is an easy way to provide
that information, as it's accessible via nir_shader::options.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code in glsl_to_nir is entirely dead, as we translate from GLSL to
NIR at link time, when there isn't a _mesa_glsl_parse_state to pass,
so every caller passes NULL.
glsl_to_nir seems like the wrong place to try and create the shader
compiler options structure anyway - tgsi_to_nir, prog_to_nir, and other
translators all would have to duplicate that code. The driver should
set this up once with whatever settings it wants, and pass it in.
Eric also added a NirOptions field to ctx->Const.ShaderCompilerOptions[]
and left a comment saying: "The memory for the options is expected to be
kept in a single static copy by the driver." This suggests the plan was
to do exactly that. That pointer was not marked const, however, and the
dead code used a mix of static structures and ralloced ones.
This patch deletes the dead code in glsl_to_nir, instead making it take
the shader compiler options as a mandatory argument. It creates an
(empty) options struct in the i965 driver, and makes NirOptions point
to that. It marks the pointer const so that we can actually do so
without generating "discards const qualifier" compiler warnings.
Signed-off-by: Kenneth Graunke <[email protected]>
Acked-by: Jason Ekstrand <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
On Gen8+, AND/OR/XOR/NOT don't support the abs() source modifier, and
negate changes meaning to bitwise-not (~, not -). This isn't what NIR
expects, so we should resolve the source modifers via a MOV.
+30 Piglits (fs-op-bit{and,or,xor}-not-abs-*).
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
| |
This has no users.
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
this isn't hooked up to anything at all from what I can see.
Seems like a left over from commit 5d67d4fbebb(st/mesa: remove
st_TexImage(), use core Mesa code instead).
Reviewed-by: Emil Velikov <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
i915_debug_fp.c: In function ‘i915_disassemble_program’:
i915_debug_fp.c:302:11: warning: unused variable ‘size’ [-Wunused-variable]
GLuint size = program[0] & 0x1ff;
^
Signed-off-by: Vinson Lee <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If scratch space is needed for a shader stage we try to reuse the last scratch
buffer bound to that stage. If we can't, we free the old scratch buffer and
allocate a new one. This means we always keep the last scratch buffer for a
particular shader stage around for the entire life span of the context.
These buffers are being reported by Valgrind as definitely lost after
destroying the OpenGL context. For example, for the geometry shader stage:
==18350== 248 bytes in 1 blocks are definitely lost in loss record 85 of 150
==18350== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18350== by 0xA1B35D6: drm_intel_gem_bo_alloc_internal (intel_bufmgr_gem.c:724)
==18350== by 0xA1B383F: drm_intel_gem_bo_alloc (intel_bufmgr_gem.c:794)
==18350== by 0xA1AEFA3: drm_intel_bo_alloc (intel_bufmgr.c:52)
==18350== by 0x9D08E31: brw_get_scratch_bo (brw_program.c:226)
==18350== by 0x9D2A0F2: do_gs_prog (brw_vec4_gs.c:280)
==18350== by 0x9D2A635: brw_gs_precompile (brw_vec4_gs.c:401)
==18350== by 0x9D14F68: brw_shader_precompile(gl_context*, gl_shader_program*) (brw_shader.cpp:76)
==18350== by 0x9D157B8: brw_link_shader (brw_shader.cpp:269)
==18350== by 0x9B0941E: _mesa_glsl_link_shader (ir_to_mesa.cpp:3038)
==18350== by 0x99AE4ED: link_program (shaderapi.c:917)
==18350== by 0x99AF365: _mesa_LinkProgram (shaderapi.c:1385)
So make sure that by the time we destroy the context we check if we have live
scratch buffers for the various stages and release them if that is the case.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
Increase the device info .urb.size for CHV to match the default URB
size (192kB).
Reviewed-by: Kenneth Graunke <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
|
|
|
|
|
|
|
| |
Cc: 10.4, 10.5 <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89224
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
| |
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A while back I switched intel_blit_framebuffer to prefer Meta over the
BLT. This meant that Gen8 platforms would start using the 3D engine
for blits, just like we do on Gen6-7.5.
However, I hadn't considered Gen4-5 when making that change. The BLT
engine appears to be substantially faster on 965GM than using Meta to
drive the 3D engine. This isn't too surprising: original Gen4 doesn't
support tile offsets (that came on G45), and the level/layer fields
don't work for cubemap rendering, so for inconvenient miplevel
alignments, we end up blitting or copying data to/from temporaries
in order to render to it. We may as well just use the blitter.
I chose to use the BLT on Gen4-5 because they use the same ring for
both 3D and BLT; Gen6+ splits it out.
Fixes regressions on 965GM due to botched tile offset code (we should
fix those properly as well, but they're longstanding bugs - for now,
put things back to the status quo).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89430
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
Cc: "10.5" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
System headers may contain C++ declarations, which cannot be given C
linkage. For this reason, include statements should never occur
inside extern "C".
This patch moves the C linkage statements to enclose only the
declarations within a single header.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SSSE3 swizzling code was written for fast uploads to the GPU and
assumed the destination was always 16-byte aligned. When we began using
this code for fast downloads as well we didn't do anything to account
for the fact that the destination pointer given by glReadPixels() or
glGetTexImage() is not guaranteed to be suitably aligned.
With SSSE3 enabled (at compile-time), some applications would crash when
an SSE aligned-store instruction tried to store to an unaligned
destination (or an assertion that the destination is aligned would
trigger).
To remedy this, tell intel_get_memcpy() whether we're uploading or
downloading so that it can select whether to assume the destination or
source is aligned, respectively.
Cc: 10.5 <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89416
Tested-by: Uriy Zhuravlev <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
| |
Several patches added include statements where required by the m64
build. Some files are only compiled for m32, and require similar
changes.
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The header is included in ../xmlpool.h. With the latter of which used
directly in a number of places in mesa.
Note that we can also add it (alongside t_option.h) to noinst_HEADERS,
but neither solution fixes the issue that brough us here - namely:
Do not regenerate the headers, if it already exists.
Cc: "10.5" <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Not required. Additionally this had the side effect of generating the
file, despite it's existence.
Cc: "10.5" <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the files generated were not in the SOURCES variable, thus
although generated prior to compilation the dependency tracking was
incomplete. The latter of which resulted in the files missing from the
distribution tarball.
Cc: "10.5" <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The file is auto-generated, and #included by formats.c. Let's rename it
to reflect the latter. This will also help up fix the dependency
tracking by adding it to the _SOURCES variable, without the side effect
of it being compiled (twice).
v2: Update .gitignore to reflect the rename.
Cc: "10.4, 10.5" <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Drop the no longer present get_es{1,2}.c from the list.
v2: Keep the format_info.c rename hunk out of this patch.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
| |
THREADS is going away in the next commit.
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
| |
Acked-by: Matt Turner <[email protected]>
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
| |
Acked-by: Matt Turner <[email protected]>
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
| |
Acked-by: Matt Turner <[email protected]>
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
| |
Acked-by: Matt Turner <[email protected]>
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
| |
Acked-by: Matt Turner <[email protected]>
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
| |
Acked-by: Matt Turner <[email protected]>
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
| |
Instead of relying on glapi.h or some other header to provide it.
Acked-by: Matt Turner <[email protected]>
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
| |
Let's directly include c11/threads.h instead of relying on glapi.h
to provide it.
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The yoffset needs to be interpreted as a slice offset for 1D array
textures. This patch implements that by moving the yoffset into
zoffset similar to how it moves the height into depth.
Reviewed-by: Jason Ekstrand <[email protected]>
Cc: "10.5" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that a layered source PBO is interpreted as a single tall 2D image
it's quite easy to accept the image height packing option by just
creating an image that is tall enough to include the image padding.
I'm not sure whether the image height property should affect 1D_ARRAY
textures. My intuition and interpretation of the GL spec (which is a
bit vague) would be that it shouldn't. However the software fallback
path in Mesa uses the property for packing but not for unpacking. The
binary NVidia driver uses it for both. This patch doesn't use it for
either case so it is different from the software fallback. There is
some discussion about this here:
http://lists.freedesktop.org/archives/mesa-dev/2015-February/077925.html
This is tested by the texsubimage Piglit test with the array and pbo
arguments. Previously this test was skipping this code path because it
always sets the image height.
I've also tested it by modifying the getteximage-targets test. It
wasn't using this code path before because it was using the default
texture object so this code couldn't successfully create a frame
buffer. I also modified it to add some image padding with the image
height in the PBO.
Reviewed-by: Jason Ekstrand <[email protected]>
Cc: "10.5" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 546aba143d13ba3f993ead4cc30b2404abfc0202.
I think the changes to the calls to glBlitFramebuffer from this patch
are no different to what it was doing previously because it used to
set height to 1 before doing the blits. However it was introducing
some problems with the blit for layer 0 because this was no longer
special cased. It didn't fix problems with the yoffset which needs to
be interpreted as a slice offset. I think a better solution would be
to modify the original if statement to cope with the yoffset.
Conflicts:
src/mesa/drivers/common/meta_tex_subimage.c
Cc: "10.5" <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
| |
Cc: 10.5 <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89317
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
DRM_IOCTL_I915_GEM_WAIT takes an int64_t for the timeout value but
GL_ARB_sync takes an uint64_t. Further, the ioctl used to wait
indefinitely when passed a negative timeout, but it's been broken and
now returns immediately in that case. Thus, if an application passes
UINT64_MAX to wait forever, we overflow to -1LL and return immediately.
Work around this mess by clamping the wait timeout to INT64_MAX.
Signed-off-by: Kristian Høgsberg <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
| |
Define the macro in src/util/macros.h rather than in two different
places. Note that USED isn't actually used anywhere at this time.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
| |
Matching what we already do with autotools builds.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This classic driver is so far behind Gallium softpipe/llvmpipe based
one, that's hard to imagine ever being useful.
v2: Drop drivers/windows from src/mesa/Makefile.am:EXTRA_DIST per Emil
Velikov.
Reviewed-by: Emil Velikov <[email protected]>
v3: Update release notes.
|
|
|
|
|
|
|
|
|
|
| |
Correctly set _BaseFormat field when creating a gl_renderbuffer
with EGLImage storage.
Change-Id: I8c9f7302d18b617f54fa68304d8ffee087ed8a77
Signed-off-by: Frank Henigman <[email protected]>
Reviewed-by: Stéphane Marchesin <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
where possible.
The main objective of this change is to enable Linux developers to use
more of C99 throughout Mesa, with confidence that the portions that need
to be built with MSVC -- and only those portions --, stay portable.
This is achieved by using the appropriate -Werror= options only on the
places they need to be used.
Unfortunately we still need MSVC 2008 on a few portions of the code
(namely llvmpipe and its dependencies). I hope to eventually eliminate
this so that we can use C99 everywhere, but there are technical/logistic
challenges (specifically, newer Windows SDKs no longer bundle MSVC,
instead require a full installation of Visual Studio, and that has
hindered adoption of newer MSVC versions on our build processes.)
Thankfully we have more directy control over our OpenGL driver, which is
why we're now able to migrate to MSVC 2013 for most of the tree.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While using various debugging features (optimization debug, instruction dumping,
etc) this function is called in order to get a readable letter for the type of
unit.
On GEN8, two new units were added, the Qword and the Unsigned Qword (Q, and UQ
respectively). The existing assertion tries to determine that the argument
passed in is within the correct boundary, however, it was using UQ as the upper
limit instead of Q.
To my knowledge you can only hit this case with the branch I am currently
working on, so it doesn't fix any known issues.
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not really sure of the origins of the existing flag names. Modern docs have
some slightly different names. Having the correct names makes it easier to
determine if existing PIPE_CONTROL flag settings are correct, as well as making
adding new PIPE_CONTROLs easier.
This originally came up while I was trying to implement workarounds and spotted
some things called, "flush" which should have been called "invalidate."
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a fix for a regression introduced in commit a9f8296d ("i965/fs:
Preserve the CFG in a few more places.").
The errata this code works around is described in a comment before the function:
"[DevBW, DevCL] Errata: A destination register from a send can not be
used as a destination register until after it has been sourced by an
instruction with a different destination register.
The framebuffer write's sources must be in message registers, which SEND
instructions cannot have as a destination. There's no way for this
errata to affect anything at the end of the program. Just remove the
code.
Cc: 10.4, 10.5 <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84613
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
This takes "fbo-stencil blit GL_STENCIL_INDEX1/4/16" from crash to pass on
BDW.
Cc: 10.5 <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, there were bugs where if the app set a scissor it could affect
the area of the texture that was downloaded. There was also potential that
the framebuffer SRGB state could affect downloads. This ensures that those
will get saved/restored and can't affect the texture download.
Cc: 10.5 <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89292
Reviewed-by: Neil Roberts <[email protected]>
|
|
|
|
| |
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
| |
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
We could do better by tracking scratch reads and writes.
Cc: 10.5 <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88793
Reviewed-by: Jason Ekstrand <[email protected]>
|