Trailing white spaces will be now always highlighted, not just in
prog-mode.
Also, the White Space package, which is available since GNU Emacs 22,
is loaded and activated locally in prog-mode.
Additionally, using White Space variables, we set highlighting through
faces on wrong indentation and the maximum length of a coding line.
Notice that:
- The highlighting for the characters beyond the set length of a
coding line is not activated by default, only for wrong
indentations.
- If the White Space package is not available, errors on loading or
activation are ignored.
- If the White Space mode is not activated the set variables would
not have any effect.
v2: Removed too long lines trail highlighting, as suggested by Ilia
Mirkin.
Signed-off-by: Andres Gomez <agomez@igalia.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
According to the spec for vkGetPhysicalDeviceImageFormatProperties:
"If format is not a supported image format, or if the combination of format,
type, tiling, usage, and flags is not supported for images, then
vkGetPhysicalDeviceImageFormatProperties returns VK_ERROR_FORMAT_NOT_SUPPORTED."
Makes the following Vulkan CTS tests report 'Not Supported' instead of crashing:
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_unorm
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_snorm
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_uscaled
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_sscaled
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_uint
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_sint
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8_srgb
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_unorm
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_snorm
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_uscaled
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_sscaled
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_uint
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_sint
dEQP-VK.api.image_clearing.clear_color_image.1d_b8g8r8a8_srgb
dEQP-VK.api.image_clearing.clear_color_image.1d_r4g4_unorm_pack8
dEQP-VK.api.image_clearing.clear_color_image.1d_r8_srgb
dEQP-VK.api.image_clearing.clear_color_image.1d_r8g8_srgb
dEQP-VK.api.image_clearing.clear_color_image.1d_r8g8b8_srgb
dEQP-VK.api.image_clearing.clear_color_image.1d_b5g5r5a1_unorm_pack16
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Move to pass by value since most events are very small in size.
We can look at pass by reference but will need to create multiple
versions to handle temp objects.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Added events for tracking early/late Depth and stencil events,
TE patch info, GS prim info, and FrontEnd/BackEnd DrawEnd events.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
- Do proper culling of wireframe triangles (including non-culling of
degenerates)
- Fix degenerate culling of CCW front-facing triangles in wireframe and
conservative rast
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Alpha from render target 0 should always be used for alpha test for all
render targets, according to GL and DX9 specs. Previously we were using
alpha from the current render target.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Buffer events ourselves and then when that's full or we're destroying
the context then write the contents to file. Previously, we're relying
ofstream to buffer for us.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
* All format combinations coded
* Fully emulated on AVX2 and AVX
* Known issue: the MSAA sample locations need to be adjusted for 8x2
Set ENABLE_AVX512_SIMD16 and USD_8x2_TILE_BACKEND to 1 in knobs.h to enable
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Karol Herbst's fuzzing efforts noticed that we would segfault on:
void bug() {
2(0);
}
We just need to bail if the function name isn't an identifier.
Based on a bug fix by Karol Herbst.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97422
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Karol Herbst's fuzzing efforts discovered that we would hit the
following assert:
assert(dummy_instructions.is_empty());
when processing an illegal array size expression of
float[(1=1)?1:1] t;
In do_assignment, we realized we needed an rvalue for (1 = 1), and
generated a temporary variable and assignment from the RHS. We've
already flagged an error (non-lvalue in assignment), and return a bogus
value as the rvalue. But process_array_size sees the bogus value, which
happened to be a constant expression, and rightly assumes that
processing a constant expression shouldn't have generated any code.
instructions.
To handle this, make do_assignment not generate any temps or assignments
when it's already raised an error - just return an error value directly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98694
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We don't allow the last thread switch to be inside control flow, to be
sure that we hit the last state exactly once. If the last texturing was
in control flow, fall back to single threaded.
We have two major requirements: Make sure that only the bottom half of the
physical reg space is used, and make sure that none of our values are live
in an accumulator across a switch.
We have had no reason to separate ability to store in an accumulator from
ability to store in B, but with FS threading, we need to be able to force
values to be stored only in the physical regfiles.
This will eventually be generated at the QIR level, so that
vc4_qir_schedule.c can arrange the separation of tex_strb from tex_result
correctly. It will also be important so that register allocation set the
register classes appropriately for values that are live across the switch.
This is a port of commit a4a59172482d50318a5ae7f99021bcf0125e0f53:
Add guards to prevent dereferencing NULL dynamic pipeline state. Asserts
of pCreateInfo members are moved to the earliest points at which they
should not be NULL.
This fixes a segfault, related to pColorBlendState, seen in Talos Principle
which I've observed after startup is completed and when exiting the menus,
depending on when Vulkan rendering is selected.
v2: moved the NULL check in radv_pipeline_init_blend_state to after the
declarations.
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Fixes fallout from acc23b04 ("ralloc: remove memset from ralloc_size").
We were still depending on zero'd allocations in a couple of places.
Signed-off-by: Rob Clark <robdclark@gmail.com>
There is currently no protection against walking a hash (using
_mesa_HashWalk()) and modifying it at the same time, for instance by inserting
or deleting elements. This leads to segfaults in multithreaded code if e.g.
someone calls glTexImage2D (which may have to walk the list of FBOs) while
another thread is calling glDeleteFramebuffers on another thread with the two
contexts sharing lists.
The reason for this is that _mesa_HashWalk() doesn't actually take the mutex
that normally protects the hash; it takes an entirely different mutex.
Thus, walks are only protected against other walks, and there is also no
outer lock taking this. There is an old comment saying that this is to fix
problems with deadlock if the callback needs to take a mutex; we solve this
by changing the mutex to be recursive.
A demonstration Helgrind hit from a real application:
==13412== Possible data race during write of size 8 at 0x3498C6A8 by thread #1
==13412== Locks held: 2, at addresses 0x1AF09530 0x2B3DF400
==13412== at 0x1F040C99: _mesa_hash_table_remove (hash_table.c:395)
==13412== by 0x1EE98174: _mesa_HashRemove_unlocked (hash.c:350)
==13412== by 0x1EE98174: _mesa_HashRemove (hash.c:365)
==13412== by 0x1EE2372D: _mesa_DeleteFramebuffers (fbobject.c:2669)
==13412== by 0x6105AA4: movit::ResourcePool::cleanup_unlinked_fbos(void*) (resource_pool.cpp:473)
==13412== by 0x610615B: movit::ResourcePool::release_fbo(unsigned int) (resource_pool.cpp:442)
[...]
==13412== This conflicts with a previous read of size 8 by thread #20
==13412== Locks held: 2, at addresses 0x1AF09558 0x1AF73318
==13412== at 0x1F040CD9: _mesa_hash_table_next_entry (hash_table.c:415)
==13412== by 0x1EE982A8: _mesa_HashWalk (hash.c:426)
==13412== by 0x1EED6DFD: _mesa_update_fbo_texture.part.33 (teximage.c:2683)
==13412== by 0x1EED9410: _mesa_update_fbo_texture (teximage.c:3043)
==13412== by 0x1EED9410: teximage (teximage.c:3073)
==13412== by 0x1EEDA28F: _mesa_TexImage2D (teximage.c:3105)
==13412== by 0x166A68: operator() (mixer.cpp:454)
There are many more interactions than just these two possible.
Cc: 11.2 12.0 13.0 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Steinar H. Gunderson <steinar+mesa@gunderson.no>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This fixes a NULL pointer dereference for intrinsics with more than
one function attribute introduced in commit 2fdaf38.
The fix is ported from the lp_build_intrinsic changes in commit 8bdd52c.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
The function returns "void" rather than int. We could rework that, yet
again there will be no benefit since all the callers have no use of it.
Fixes: 9ca6711faa ("Revert "wayland: Block for the frame callback in
get_back_bo not dri2_swap_buffers"")
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Now that we have switched to using nir_shader_gather_info() we
can remove the hacks and just use the system variable.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This takes us one step closer to being able to drop the GLSL IR
optimisation passes during linking in favour of the NIR passes.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Andres Gomez
Iago Toral Quiroga
Vedran Miletić
Tim Rowley
Emil Velikov
Juan A. Suarez Romero
Kenneth Graunke
Jonas Pfeil
Eric Anholt
Darren Salt
Rob Clark
Steinar H. Gunderson
Daniel Scharrer
Laurent Carlier
Brian Paul
Timothy Arceri