summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* i965: Use _mesa_is_image_unit_valid() instead of gl_image_unit::_Valid.Francisco Jerez2015-10-213-6/+10
| | | | | | | | | gl_image_unit::_Valid will be removed in a future commit. Tested-by: Ye Tian <[email protected]> CC: "11.0" <[email protected]> Reviewed-by: Ian Romanick <[email protected]> (cherry picked from commit 2d97a78b37ddf325d90e056f5eefee0548092530)
* mesa: Skip redundant texture completeness checking during image validation.Francisco Jerez2015-10-211-1/+2
| | | | | | | | | | | | | | The call to _mesa_test_texobj_completeness() is unnecessary if the texture is already known to be complete. If the texture object is dirtied in the meantime _BaseComplete and _MipmapComplete will be reset to false. _mesa_is_image_unit_valid() will start to be called more frequently in a future commit, so it seems desirable to avoid the unnecessary work. Tested-by: Ye Tian <[email protected]> CC: "11.0" <[email protected]> Reviewed-by: Ian Romanick <[email protected]> (cherry picked from commit 25d3338be37ddbfe676716034ec5f29e27323704)
* mesa: Expose function to calculate whether a shader image unit is valid.Francisco Jerez2015-10-212-4/+15
| | | | | | | | | | | | | | A future commit will remove all texture object-dependent derived state from the image unit struct to make validation unnecessary on texture state changes. Instead of checking gl_image_unit::_Valid drivers will be required to call this function when needed to find out whether an image unit is in a valid state and whether access from the shader is allowed. Tested-by: Ye Tian <[email protected]> CC: "11.0" <[email protected]> Reviewed-by: Ian Romanick <[email protected]> (cherry picked from commit 5152db415f4047569822d648fda09bdde4171d6d)
* i965: Don't tell the hardware about our UAV access.Francisco Jerez2015-10-216-19/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hardware documentation relating to the UAV HW-assisted coherency mechanism and UAV access enable bits is scarce and sometimes contradictory, and there's quite some guesswork behind this commit, so let me summarize the background first: HSW and later hardware have infrastructure to support a stricter form of data coherency between shader invocations from separate primitives. The mechanism is controlled by the "Accesses UAV" bits on 3DSTATE_VS, _HS, _DS, _GS and _PS (or _PS_EXTRA on BDW+), and the "UAV Coherency Required" bit on the 3DPRIMITIVE command. Regardless of whether "UAV Coherency Required" is set, the hardware fixed-function units will increment a per-stage semaphore for each request received if "Accesses UAV" is set for the same or any lower stage. An implicit DC flush is emitted by the lowermost stage with "Accesses UAV" set once it's done processing the request, this also happens regardless of the value of "UAV Coherency Required". The completion of the DC flush will cause the same stage and all previous ones to decrement the semaphore, marking the UAV accesses for the primitive as coherent with L3. The "UAV Coherency Required" 3DPRIMITIVE bit will cause a pipeline stall before any threads are dispatched for the first FF stage with "Accesses UAV" set until the semaphore is cleared for the same stage. Effectively this guarantees that UAV memory accesses performed by previous primitives from any stage will be strictly ordered (and thanks to the implicit DC flush visible in memory) with UAV accesses from the following primitives. None of this is required by the usual image, atomic counter and SSBO GL APIs which have very relaxed cross-primitive coherency and ordering requirements, so we don't actually ever set the "UAV Coherency Required" bit -- Ordering with respect to shader invocations from previous stages on the same primitive where there is a data dependency is of course already guaranteed as the spec requires, regardless of this mechanism being enabled. We do set the "Accesses UAV" bits though since my commit ac7664e493655e290783c23a0412b9c70936da50 (which this patch partially reverts), mainly because of comments like the following from the BDW PRM: > 3DSTATE_GS >[...] > 12 Accesses UAV > Format: Enable > This field must be set when GS has a UAV access. There are similar comments in the documentation for the other 3DSTATE_*S commands. The "must" part is misleading and unjustified AFAIK. Most of the "Accesses UAV" bits don't seem to have any side effects other than the implicit DC flushes and the related book-keeping in anticipation for a subsequent primitive with "UAV Coherency Required" set, so in most cases they are unnecessary and may incur a performance penalty. There is an exception though. On Gen8+ the PS_EXTRA UAV access bit influences the calculation of the PS UAV-only and ThreadDispatchEnable signals which on previous generations were set explicitly by the driver, so we cannot always avoid enabling it on the PS stage. The primary motivation for this change is that in fact the hardware coherency mechanism is buggy and will cause a rather non-deterministic hang on Gen8 when VS is the only stage with "Accesses UAV" set and the processing of a request terminates immediately after the implicit DC flush is sent for a previous primitive with no additional vertices being emitted for the second primitive, what will cause the hardware to skip sending a second DC flush and cause the VS to stall indefinitely waiting for a response from the DC (BDWGFX HSD 1912017). This hardware bug can be reproduced on current master with the spec@arb_shader_image_load_store@host-mem-barrier@Indirect/RaW piglit subtest (if you have the patience to run it a few dozen times). The proposed workaround is to insert CS STALLs speculatively between 3DPRIMITIVE commands when "Accesses UAV" is enabled for the VS stage only. Because this would affect one of the hottest paths in the driver and likely decrease performance even further due to the unnecessary serialization, and because we don't actually need the implicit DC flushes, it seems better to just disable them. Cc: 11.0 <[email protected]> (cherry picked from commit 5346c1167064d6429c6338974c6342f8346fd34b)
* mesa: add GL_UNSIGNED_INT_24_8 to _mesa_pack_depth_spanTapani Pälli2015-10-211-0/+15
| | | | | | | | | | | | Patch adds missing type (used with NV_read_depth) so that it gets handled correctly. This fixes errors seen with following CTS test: ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Cc: "11.0" <[email protected]> (cherry picked from commit d8d0e4a81e42678cc8c8b876dfee24d5c2f4ba38)
* nouveau: make sure there's always room to emit a fenceIlia Mirkin2015-10-218-41/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I started seeing a lot of situations on nv30 where fence emission wouldn't fit into the previous buffer (causing assertions). This ensures that whenever checking for space, we always leave a bit of extra room for the fence emission commands. Adjusts the nv30 and nvc0 fence emission logic to bypass the space checking as well. Signed-off-by: Ilia Mirkin <[email protected]> Cc: [email protected] Reviewed-by: Samuel Pitoiset <[email protected]> (cherry picked from commit 47d11990b2ca3eb666b8ac81fee7f7eb5019eba1) Squashed with commit nouveau: avoid emitting new fences unnecessarily Right now we emit on every kick, but this is only necessary if something will ever be able to observe that the fence completed. If there are no refs, leave the fence alone and emit it another day. This also happens to work around an issue for the kick handler -- a kick can be a result of e.g. nouveau_bo_wait or explicit kick, or it can be due to lack of space in the pushbuf. We want the emit to happen in the current batch, so we want there to always be enough space. However an explicit kick could take the reserved space for the implicitly-triggered kick's fence emission if it happened right after. With the new mechanism, hopefully there's no way to cause two fences to be emitted into the same reserved space. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]> Fixes: 47d11990b (nouveau: make sure there's always room to emit a fence) Cc: [email protected] (cherry picked from commit 8053c9208f30964d89dc4e262fdf2148f0664696) Squashed with commit nv50,nvc0: don't base decisions on available pushbuf space We still have to push everything out, might as well kick earlier and flip pushbufs when we know we'll need it. This resolves some issues with the new policy of making sure that we always leave a bit of room at the end for fences. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]> Fixes: 47d11990b (nouveau: make sure there's always room to emit a fence) Cc: [email protected] (cherry picked from commit 9fe458335ffd35366ef0f4b741aad0cdb3503783) Squashed with commit nouveau: avoid double-emitting fence The act of ensuring that there is space can cause a flush to happen, which will emit the current screen fence. If that is the fence we're trying to wait on, then it will have been emitted as a result of doing the PUSH_SPACE. Don't attempt to emit it a second time. Signed-off-by: Ilia Mirkin <[email protected]> Fixes: 8053c9208f (nouveau: avoid emitting new fences unnecessarily) Cc: [email protected] (cherry picked from commit bf97f8d467ad1d485c2327da3f4fe1f9e1dc7379)
* Revert "nouveau: make sure there's always room to emit a fence"Emil Velikov2015-10-104-8/+2
| | | | | | | | | | | | This reverts commit 30570b262971c881366deab58caf8d8d48d7d79d. As mentioned by Ilia Mirkin: Please remove this one from your list of cherry-picked patches. While it fixes real issues on nv30 (and probably the other generations too), it appears to introduce some new ones on nvc0. I've figured out what's causing it, but haven't figured out a proper fix. Not sure I'll be able to before you do a release.
* mesa: Correctly handle GL_BGRA_EXT in ES3 format_and_type checksJason Ekstrand2015-10-101-2/+19
| | | | | | | | | | | | | | | | | | | | | | The EXT_texture_format_BGRA8888 extension (which mesa supports unconditionally) adds a new format and internal format called GL_BGRA_EXT. Previously, this was not really handled at all in _mesa_ex3_error_check_format_and_type. When the checks were tightened in commit f15a7f3c, we accidentally tightened things too far and GL_BGRA_EXT would always cause an error to be thrown. There were two primary issues here. First, is that _mesa_es3_effective_internal_format_for_format_and_type didn't handle the GL_BGRA_EXT format. Second is that it blindly uses _mesa_base_tex_format which returns GL_RGBA for GL_BGRA_EXT. This commit fixes both of these issues as well as adds explicit checks that GL_BGRA_EXT is only ever used with GL_BGRA_EXT and GL_UNSIGNED_BYTE. Signed-off-by: Jason Ekstrand <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92265 Reviewed-by: Ian Romanick <[email protected]> Cc: "11.0" <[email protected]> (cherry picked from commit 6ad9ebb073fc4ed245ef8e9db4479a52e818cb92)
* st/dri: Use packed RGB formatsMichel Dänzer2015-10-072-17/+17
| | | | | | | | | | | | Fixes Gallium based DRI drivers failing to load on big endian hosts because they can't find any matching fbconfigs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71789 Signed-off-by: Michel Dänzer <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Tested-by: Ilia Mirkin <[email protected]> (cherry picked from commit 87c3c9acd29655d6c8778ea732f559eebeddd5f6) Nominated-by: Ilia Mirkin <[email protected]>
* egl: restore surface type before linking config to its displayVarad Gautam2015-10-071-0/+2
| | | | | | | | | | | | | | | commit c2c2e9a (egl: implement EGL_KHR_gl_colorspace (v2)) leaves _EGLConfig->SurfaceType set incorrectly before calling _eglLinkConfig(), and the bad value is passed around to platform_android. set it to zero as earlier. v2: Set SurfaceType to 0, rather than surface_type (Suggested by Emil) Cc: [email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91596 Signed-off-by: Varad Gautam <[email protected]> Reviewed-by: Emil Velikov <[email protected]> (cherry picked from commit f988eff37991272b3e685112136a8b2ae06386bf)
* nouveau: make sure there's always room to emit a fenceIlia Mirkin2015-10-074-2/+8
| | | | | | | | | | | | | I started seeing a lot of situations on nv30 where fence emission wouldn't fit into the previous buffer (causing assertions). This ensures that whenever checking for space, we always leave a bit of extra room for the fence emission commands. Adjusts the nv30 and nvc0 fence emission logic to bypass the space checking as well. Signed-off-by: Ilia Mirkin <[email protected]> Cc: [email protected] Reviewed-by: Samuel Pitoiset <[email protected]> (cherry picked from commit 47d11990b2ca3eb666b8ac81fee7f7eb5019eba1)
* nv30: always go through translate module on big-endianIlia Mirkin2015-10-071-0/+4
| | | | | | | | | | | It seems like things are either coming in slighly wrong, or perhaps uploaded incorrectly, but either way passing them through the translate module seems to fix everything. Eventually we should figure out what's going wrong and fix it "for real", but this should do for now. Signed-off-by: Ilia Mirkin <[email protected]> Cc: [email protected] (cherry picked from commit 78ec9e28ec759bcaf9781bcbd2b8e051f7df7896)
* nv30: pretend to have packed texture/surface formatsIlia Mirkin2015-10-071-12/+12
| | | | | | | | | | This puts us in line with what the DDX/DRI2 st are expecting. It also happens to work... no idea why, but seems better to have it work than to ask lots of questions. Signed-off-by: Ilia Mirkin <[email protected]> Cc: [email protected] (cherry picked from commit 1fec05d1142921cdb5b01d94d886062c57905edc)
* egl/dri2: don't require a context for ClientWaitSync (v2)Marek Olšák2015-10-071-2/+7
| | | | | | | | | | | | The spec doesn't require it. This fixes a crash on Android. v2: don't set any flags if ctx == NULL v3: add the spec note Cc: 10.6 11.0 <[email protected]> Reviewed-by: Albert Freeman <[email protected]> Reviewed-by: Frank Binns <[email protected]> (cherry picked from commit 18123a732b8593bb7add03d1529ace464f46a7ac)
* st/dri: don't use _ctx in client_wait_syncMarek Olšák2015-10-071-2/+5
| | | | | | | | | | Not needed and it can be NULL. v2: fix dri2_get_fence_from_cl_event - thanks Albert Cc: 10.6 11.0 <[email protected]> Reviewed-by: Albert Freeman <[email protected]> (cherry picked from commit b78336085bce4d1f36c8d9c72fd3fa41643e3cd1)
* egl: rework handling EGL_CONTEXT_FLAGSMatthew Waters2015-10-071-5/+44
| | | | | | | | | | | | | | | | | | | As of version 15 of the EGL_KHR_create_context spec, debug contexts are allowed for ES contexts. We should allow creation instead of erroring. While we're here provide a more comprehensive checking for the other two flags - ROBUST_ACCESS_BIT_KHR and FORWARD_COMPATIBLE_BIT_KHR v2 [Emil Velikov] Rebase. Minor tweak in commit message. Cc: Boyan Ding <[email protected]> Cc: Chad Versace <[email protected]> Cc: "10.6 11.0" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91044 Signed-off-by: Matthew Waters <[email protected]> Signed-off-by: Emil Velikov <[email protected]> (cherry picked from commit 11cabc45b7124e51d5ead42db6dceb5a3755266b)
* radeon/llvm: Initialize gallivm targets when initializing the AMDGPU target v2Tom Stellard2015-10-071-0/+2
| | | | | | | | | | | | | | | This fixes a race condition in the glx-multithreaded-shader-compile test. v2: - Replace gallivm_init_llvm_{begin,end}() with gallivm_init_llvm_targets(). Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Mathias Fröhlich <[email protected]> Reviewed-by: Emil Velikov <[email protected]> CC: "10.6 11.0" <[email protected]> (cherry picked from commit a2e1e3d325a70604151ef093ed741e60d078a21a)
* gallivm: Allow drivers and state trackers to initialize gallivm LLVM targets v2Tom Stellard2015-10-073-8/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drivers and state trackers that use LLVM for generating code, must register the targets they use with LLVM's global TargetRegistry. The TargetRegistry is not thread-safe, so all targets must be added to the registry before it can be queried for target information. When drivers and state trackers initialize their own targets, they need a way to force gallivm to initialize its targets at the same time. Otherwise, there can be a race condition in some multi-threaded applications (e.g. glx-multihreaded-shader-compile in piglit), when one thread creates a context for a driver that uses LLVM (e.g. radeonsi) and another thread creates a gallivm context (glxContextCreate does this). The race happens when the driver thread initializes its LLVM targets and then starts using the registry before the gallivm thread has a chance to register its targets. This patch allows users to force gallivm to register its targets by calling the gallivm_init_llvm_targets() function. v2: - Use call_once and remove mutexes and static initializations. - Replace gallivm_init_llvm_{begin,end}() with gallivm_init_llvm_targets(). Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Mathias Fröhlich <[email protected]> Reviewed-by: Emil Velikov <[email protected]> CC: "10.6 11.0" <[email protected]> (cherry picked from commit 76cfd6f1da3748effb480e4f1151910af59fb88a)
* gallium/radeon: Use call_once() when initailizing LLVM targetsTom Stellard2015-10-071-13/+12
| | | | | | | | | Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Mathias Fröhlich <[email protected]> Reviewed-by: Emil Velikov <[email protected]> CC: "10.6 11.0" <[email protected]> (cherry picked from commit 3219b48ae5a5b1288bf1fc1325ebbc7ac9e236df)
* glx: Don't hard-code the name "libGL.so.1" in driOpenDriver (v3)Kyle Brenneman2015-10-072-1/+6
| | | | | | | | | | | | | | | | | Add a macro GL_LIB_NAME to hold the filename that configure comes up with based on the --with-gl-lib-name and --enable-mangling options. In driOpenDriver, use the GL_LIB_NAME macro instead of hard-coding "libGL.so.1". v2: Add an #ifndef/#define for GL_LIB_NAME so that non-autoconf builds will work. v3: Fix the library filename in the Makefile. Signed-off-by: Kyle Brenneman <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit d35391cfda13afdb19a47003af260e258575ef45)
* mapi: Make _glapi_get_stub work with "gl" or "mgl" prefix.Kyle Brenneman2015-10-071-1/+1
| | | | | | | | | | | | | | | | When USE_MGL_NAMESPACE is defined, _glapi_get_stub will check for the "m" prefix before trying to skip it, so that "glFoo" and "mglFoo" are equivalent. This should let it work with all the places where something calls _glapi_get_proc_offset with a hard-coded name that starts with the normal "gl" prefix. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55552 Signed-off-by: Kyle Brenneman <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit 798f260a2f553e339d7f5fc5120bb627893dc740)
* glx: Fix build errors with --enable-mangling (v2)Kyle Brenneman2015-10-072-2/+12
| | | | | | | | | | | | | | | | Rearranged the GLX_ALIAS macro in glextensions.h so that it will pick up the renames from glx_mangle.h. Fixed the alias attribute for glXGetProcAddress when USE_MGL_NAMESPACE is defined. v2: Add a comment clarifying why GLX_ALIAS needs two macros. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55552 Signed-off-by: Kyle Brenneman <[email protected]> Cc: "10.6 11.0" <[email protected]> Reviewed-by: Emil Velikov <[email protected]> (cherry picked from commit a27f2d991b1723c3349623401ce3c8f26dcdb28b)
* mesa: Add abs input modifier to base for POW in ffvertex_progDaniel Scharrer2015-10-071-3/+14
| | | | | | | | | | | | The result of POW for a negative base is undefined. Even when the result is multiplied by zero (which is the case here whenever the base is negative), the Inf and NaNs can propagate past that. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91342 Signed-off-by: Daniel Scharrer <[email protected]> Cc: "10.6 11.0" <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> (cherry picked from commit b3f9c5cc0fab6d770d220efd87ba3746c6673875)
* meta: Handle array textures in scaled MSAA blitsIan Romanick2015-10-071-15/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old code had some significant problems with respect to sampler2DArray textures. The biggest problem was that some of the code would use vec3 for the texture coordinate type, and other parts of the code would use vec2. The resulting shader would not even compile. Since there were not tests for this path, nobody noticed. The input to the fragment shader is always treated as a vec3. If the source data is only vec2, the vertex puller will supply 0 for the .z component. The texture coordinate passed to the fragment shader is always a vec2 that comes from the .xy part of the vertex shader input. The layer, taken from the .z of the vertex shader input is passed separately as a flat integer. If the generated fragment shader does not use the layer integer, the GLSL linker will eliminate all the dead code in the vertex shader. Fixes the new piglit tests "blit-scaled samples=2 with gl_texture_2d_multisample_array", etc. on i965. Note for stable maintainer: This patch may depend on 46037237, and that patch should be safe for stable. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Cc: Topi Pohjolainen <[email protected]> Cc: Jordan Justen <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit 9bd9cf1fa402bf948020ee5d560259a5cfd2a739)
* i915: Remember to call intel_prepare_render() before blittingVille Syrjälä2015-10-071-0/+5
| | | | | | | | | | | | | | | | | | Bring over the following fix from i965: commit fb3d62fe3d4fc40ba4ad9804d8b6f451316c9ae2 Author: Kenneth Graunke <[email protected]> Date: Tue Aug 6 14:36:09 2013 -0700 i965: Remember to call intel_prepare_render() before blitting. Fixes a crash in the following piglit tests: bin/fbo-sys-blit -auto bin/fbo-sys-sub-blit -auto Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Cc: "11.0" <[email protected]> (cherry picked from commit a1a3f0961b20907b6948959c1f224bb055bd4f3d)
* i915: Fix texcoord vs. varying collision in fragment programsVille Syrjälä2015-10-072-26/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i915 fragment programs utilize the texture coordinate registers for both texture coordinates and varyings. Unfortunately the code doesn't check if the same index might be in use for both. It just naively uses the index to pick a texture unit, which could lead to collisions. Add an extra mapping step to allocate non conflicting texture units for both uses. The issue can be reproduced with a pair of simple shaders like these: attribute vec4 in_mod; varying vec4 mod; void main() { mod = in_mod; gl_TexCoord[0] = gl_MultiTexCoord0; gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; } varying vec4 mod; uniform sampler2D tex; void main() { gl_FragColor = texture2D(tex, vec2(gl_TexCoord[0])) * mod; } Fixes many piglit tests on i915: glsl-link-varyings-2 glsl-orangebook-ch06-bump interpolation-none-gl_frontcolor-smooth-fixed interpolation-none-gl_frontcolor-smooth-none interpolation-none-gl_frontcolor-smooth-vertex interpolation-none-gl_frontsecondarycolor-smooth-fixed interpolation-none-gl_frontsecondarycolor-smooth-vertex interpolation-none-gl_frontsecondarycolor-smooth-none interpolation-none-other-flat-fixed interpolation-none-other-flat-none interpolation-none-other-flat-vertex interpolation-none-other-smooth-fixed interpolation-none-other-smooth-none interpolation-none-other-smooth-vertex v2 [idr]: Minor formatting tweaks. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Cc: "11.0" <[email protected]> (cherry picked from commit c349031c27b7f66151f07d785625c585e10a92c2)
* i830: Fix collision between I830_UPLOAD_RASTER_RULES and I830_UPLOAD_TEX(0)Ville Syrjälä2015-10-071-4/+4
| | | | | | | | | | | | | | | I830_UPLOAD_RASTER_RULES and I830_UPLOAD_TEX(0) are trying to occupy the same bit. Move the texture bits upwards a bit to make room for I830_UPLOAD_RASTER_RULES. Now the driver will actually upload the raster rules which is rather important to get the provoking vertex right. Fixes the appearance of glxgears teeth on gen2. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit 9504740f3e6698d860ac93310a33f51f01c10c4f)
* st/mesa: try PIPE_BIND_RENDER_TARGET when choosing float texture formatsBrian Paul2015-10-071-1/+5
| | | | | | | | | | | | | | For 8-bit RGB(A) texture formats we set the PIPE_BIND_RENDER_TARGET flag to try to get a hardware format which also supports rendering (for FBO textures). Do the same thing for floating point formats. This allows the Redway3D Flat demo to run. Cc: 10.6 11.0 <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> (cherry picked from commit cb758b892a7e62ff1f6187f2ca9ac543ff70a096)
* nouveau: wait to unref the transfer's bo until it's no longer usedIlia Mirkin2015-10-071-2/+3
| | | | | | | | | | | The bo will often come from a slab in which case it doesn't matter. But for larger allocations this will be in its own bo, and we have to make sure to wait until it's no longer used in order for it to be freed. Signed-off-by: Ilia Mirkin <[email protected]> Cc: [email protected] Tested-by: Marcin Ślusarz <[email protected]> (cherry picked from commit 1d8cba9b51b7a6e7dbf3f0d3f53b5c232fd0b5b2)
* nouveau: delay deleting buffer with unflushed fenceIlia Mirkin2015-10-072-2/+10
| | | | | | | | | | | | If there is an unflushed fence on the bo, then the resource may still be used in commands built up in the local pushbuf. Flushing can cause all sorts of unwanted effects, so just free the bo when the relevant fence is hit. Signed-off-by: Ilia Mirkin <[email protected]> Cc: [email protected] Tested-by: Marcin Ślusarz <[email protected]> (cherry picked from commit 3a6b9a7830c3df14ffcfbbf57c82ea08bd59ef04)
* nouveau: be more careful about freeing temporary transfer buffersIlia Mirkin2015-10-075-4/+30
| | | | | | | | | | Deleting a buffer does not flush the command stream. Make sure that we wait for the copies to finish before deleting the temporary bo. Signed-off-by: Ilia Mirkin <[email protected]> Cc: [email protected] Tested-by: Marcin Ślusarz <[email protected]> (cherry picked from commit d4e650b07bc80075f0d088e7d85df9efa45e11bd)
* i965/fs: Fix hang on IVB and VLV with image format mismatch.Francisco Jerez2015-10-071-4/+38
| | | | | | | | | | | | | | | | | | | | IVB and VLV hang sporadically when an untyped surface read or write message is used to access a surface of format other than RAW, as may happen when there is a mismatch between the format qualifier of the image uniform and the format of the actual image bound to the pipeline. According to the spec this condition gives undefined results but may not lead to program termination (which is one of the possible outcomes of the hang). Fix it by checking at runtime whether the surface is of the right type. Fixes the "arb_shader_image_load_store.invalid/format mismatch" piglit subtest. Reported-by: Mark Janes <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91718 CC: [email protected] Reviewed-by: Ian Romanick <[email protected]> (cherry picked from commit b61292296bd7e1876fdb64725a783a7e96f6c4c1)
* radeonsi: add scratch buffer to the buffer list when it's re-allocatedMarek Olšák2015-10-071-0/+1
| | | | | | Reviewed-by: Michel Dänzer <[email protected]> Cc: [email protected] (cherry picked from commit 9932142192f848ae9dbc644551653547640346b4)
* radeon/vce: fix vui time_scale zero errorLeo Liu2015-10-071-0/+3
| | | | | | | | | | if app pass 0 as frame_rate_num, it should not be encoded to the VUI. Signed-off-by: Leo Liu <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Christian König <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit 1e97b41893a4f53a71ee141a5e8a046fed7b49cd)
* mesa: fix mipmap generation for immutable, compressed texturesRoland Scheidegger2015-10-071-21/+15
| | | | | | | | | | | | | | | | | | | | | | If the immutable compressed texture didn't have the full mip pyramid, this didn't work, because it tried to generate mip levels for non-existing levels. _mesa_prepare_mipmap_level() would correctly handle this by returning FALSE if the mip level didn't exist, however we actually created the non-existing mip level right before that because we used _mesa_get_tex_image() before calling _mesa_prepare_mipmap_level(). It would then proceed to crash (we allocated the mip level, which is a bad idea on an immutable texture, but didn't initialize the values, leading to assertion failures or segfaults). Fix this by using _mesa_select_tex_image() instead and call it after _mesa_prepare_mipmap_level(), as that function will allocate missing mip levels for non-immutable textures already. This fixes a (2 year old) crash with astromenace which was hack-fixed in ubuntu packages instead: http://bugs.debian.org/718680 (I guess most apps do full mip chains - I believe this app not doing it is actually unintentional, always one level less than full mip chain...). Cc: "10.6 11.0" <[email protected]> Reviewed-by: Brian Paul <[email protected]> (cherry picked from commit 19604d30e1351868f7f54847c91ffec7b3fcd27e)
* gallium/u_blitter: handle allocation failuresMarek Olšák2015-10-071-0/+6
| | | | | | | Cc: 11.0 <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> (cherry picked from commit 7bbce21e458d912279159aa6ac122768c6c06551)
* radeonsi: handle dummy constant buffer allocation failureMarek Olšák2015-10-071-0/+2
| | | | | | | Cc: 11.0 <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> (cherry picked from commit ae418a7b5640aadb625bb7a7d6e4aa0a98ccb77f)
* radeonsi: don't forget to update scratch relocations for LS, HS, ES shadersMarek Olšák2015-10-071-2/+6
| | | | | | | Cc: 11.0 <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> (cherry picked from commit b737d9c1dce073aa36b21c33cb30fbae89c38153)
* radeonsi: skip drawing if updating the scratch buffer failsMarek Olšák2015-10-071-14/+49
| | | | | | | Cc: 11.0 <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> (cherry picked from commit d556346b3590e8d5601c0831577f08e7b1ccecec)
* radeonsi: skip drawing if PS fails to compile or uploadMarek Olšák2015-10-071-12/+3
| | | | | | | Cc: 11.0 <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> (cherry picked from commit 1f99b0be7e4e300c2b1761437f740a604ab036bc)
* radeonsi: skip drawing if VS, TCS, TES, GS fail to compile or uploadMarek Olšák2015-10-071-7/+23
| | | | | | | Cc: 11.0 <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> (cherry picked from commit 237d7cccce15b91590afa90020ff71324217fdb9)
* radeonsi: handle fixed-func TCS shader create failureMarek Olšák2015-10-071-2/+5
| | | | | | | Cc: 11.0 <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> (cherry picked from commit 9b6d9dd7d8d2779e2bd08787c26f51512b84f6d2)
* radeonsi: handle shader precompile failuresMarek Olšák2015-10-071-1/+6
| | | | | | | Cc: 11.0 <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> (cherry picked from commit 5dbadb02572f875f5d2f22327eab6b93de61337c)
* radeonsi: skip drawing if GS ring allocations failMarek Olšák2015-10-071-1/+16
| | | | | | | | | | | | Cc: 11.0 <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> (cherry picked from commit 263f5a2cf97e455e48dbd7728cb0ac10fd699746) [Emil Velikov: Track gs_rings over gsvs_ring. NULL check/FREE gs_rings.] Signed-off-by: Emil Velikov <[email protected]> Conflicts: src/gallium/drivers/radeonsi/si_state_shaders.c
* radeonsi: skip drawing if the tess factor ring allocation failsMarek Olšák2015-10-073-5/+18
| | | | | | | | | | | | Cc: 11.0 <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> (cherry picked from commit 22d3ccf5a814bfc768e373d0c983a356f4e4efe3) [Emil Velikov: Track tf_state over tf_ring. NULL check/FREE tf_state.] Signed-off-by: Emil Velikov <[email protected]> Conflicts: src/gallium/drivers/radeonsi/si_state_shaders.c
* radeonsi: add malloc fail paths to si_create_shader_stateMarek Olšák2015-10-071-0/+8
| | | | | | | Cc: 11.0 <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> (cherry picked from commit 5c219ab55239ceef3285262ff68a502e419061e0)
* radeonsi: report alloc failure from si_shader_binary_readMarek Olšák2015-10-071-1/+4
| | | | | | | Cc: 11.0 <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> (cherry picked from commit 394d67a58f949245e8b3fad400e9efaa5829ec84)
* gallium/radeon: add a fail path for depth MSAA texture readbackMarek Olšák2015-10-071-0/+5
| | | | | | | Cc: 11.0 <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> (cherry picked from commit dea834e639715caa9517a695a3fb04d5de9aa069)
* gallium/radeon: handle buffer alloc failures in r600_draw_rectangleMarek Olšák2015-10-071-0/+3
| | | | | | | Cc: 11.0 <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> (cherry picked from commit f95e695059c428a21a1e1a27d5cd5ccce2a97b0e)
* gallium/radeon: handle buffer_map staging buffer failures betterMarek Olšák2015-10-071-4/+3
| | | | | | | Cc: 11.0 <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> (cherry picked from commit 282b3780123bace557fc90127bd35b075ea0873e)
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-16 02:15:25 +0000