summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* mesa: add OES_texture_buffer and EXT_texture_buffer supportIlia Mirkin2016-03-287-44/+55
| | | | | | | | Allow ES 3.1 contexts to access the texture buffer functionality. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: add OES_texture_buffer and EXT_texture_buffer extension to tableIlia Mirkin2016-03-282-0/+3
| | | | | | | | | | | We need to add a new bit since the GL ES exts require functionality from a combination of texture buffer extensions as well as images (for imageBuffer) support. Additionally, not all GPUs support all the texture buffer functionality (e.g. rgb32 isn't supported by nv50). Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: properly return GetTexLevelParameter queries for buffer texturesIlia Mirkin2016-03-281-2/+52
| | | | | | | | | | | | | This fixes all failures with dEQP tests in this area. While ARB_texture_buffer_object explicitly says that GetTexLevelParameter & co should not be supported, GL 3.1 reverses this decision and allows all of these queries there. Conversely, there is no text that forbids the buffer-specific queries from being used with non-buffer images. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: remove initialized field from uniform storageTimothy Arceri2016-03-293-43/+1
| | | | | | | | The only place this was used was in a gallium debug function that had to be manually enabled. Reviewed-by: Edward O'Callaghan <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i965: Set address rounding bits for GL_NEAREST filtering as well.Kenneth Graunke2016-03-281-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Yuanhan Liu decided these were useful for linear filtering in commit 76669381 (circa 2011). Prior to that, we never set them; it seems he tried to preserve that behavior for nearest filtering. It turns out they're useful for nearest filtering, too: setting these fixes the following dEQP-GLES3 tests: functional.fbo.blit.rect.nearest_consistency_mag functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_x functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_y functional.fbo.blit.rect.nearest_consistency_mag_reverse_dst_x functional.fbo.blit.rect.nearest_consistency_mag_reverse_dst_y functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_dst_x functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_dst_y functional.fbo.blit.rect.nearest_consistency_min functional.fbo.blit.rect.nearest_consistency_min_reverse_src_x functional.fbo.blit.rect.nearest_consistency_min_reverse_src_y functional.fbo.blit.rect.nearest_consistency_min_reverse_dst_x functional.fbo.blit.rect.nearest_consistency_min_reverse_dst_y functional.fbo.blit.rect.nearest_consistency_min_reverse_src_dst_x functional.fbo.blit.rect.nearest_consistency_min_reverse_src_dst_y functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_x functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_y functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_dst_x functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_dst_y functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_dst_x functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_dst_y functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_x functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_y functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_dst_x functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_dst_y functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_dst_x functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_dst_y Apparently, BLORP has always set these bits unconditionally. However, setting them unconditionally appears to regress tests using texture projection, 3D samplers, integer formats, and vertex shaders, all in combination, such as: functional.shaders.texture_functions.textureprojlod.isampler3d_vertex Setting them on Gen4-5 appears to regress Piglit's tests/spec/arb_sampler_objects/framebufferblit. Honestly, it looks like the real problem here is a lack of precision. I'm just hacking around problems here (as embarassing as it is). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Always use BRW_TEXCOORDMODE_CUBE when seamless filtering.Kenneth Graunke2016-03-281-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | When using seamless cube map mode and NEAREST filtering, we explicitly overrode the wrap modes to CLAMP_TO_EDGE. This was to implement the following spec text: "If NEAREST filtering is done within a miplevel, always apply apply wrap mode CLAMP_TO_EDGE." However, textureGather() ignores the sampler's filtering mode, and instead returns the four pixels that would be blended by LINEAR filtering. This implies that we should do proper seamless filtering, and include pixels from adjacent cube faces. It turns out that we can simply delete the NEAREST -> CLAMP_TO_EDGE overrides. Normal cube map sampling works by first selecting the face, and then nearest filtering fetches the closest texel. If the nearest texel was on a different face, then that face would have been chosen. So it should always be within the face anyway, which effectively performs CLAMP_TO_EDGE. Fixes 86 dEQP-GLES31.texture.gather.basic.cube.* tests. Signed-off-by: Kenneth Graunke <[email protected]> Suggested-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Fix brw_render_cache_set_check_flush's PIPE_CONTROLs.Kenneth Graunke2016-03-282-3/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our driver uses the brw_render_cache mechanism to track buffers we've rendered to and are about to sample from. Previously, we did a single PIPE_CONTROL with the following bits set: - Render Target Flush - Depth Cache Flush - Texture Cache Invalidate - VF Cache Invalidate - Instruction Cache Invalidate - CS Stall This combined both "top of pipe" invalidations and "bottom of pipe" flushes, which isn't how the hardware is intended to be programmed. The "top of pipe" invalidations may happen right away, without any guarantees that rendering using those caches has completed. That rendering may continue altering the caches. The "bottom of pipe" flushes do wait for the rendering to complete. The CS stall also prevents further work from happening until data is flushed out. What we wanted to do was wait for rendering complete, flush the new data out of the render and depth caches, wait, then invalidate any stale data in read-only caches. We can accomplish this by doing the "bottom of pipe" flushes with a CS stall, then the "top of pipe" flushes as a second PIPE_CONTROL. The flushes will wait until the rendering is complete, and the CS stall will prevent the second PIPE_CONTROL with the invalidations from executing until the first is done. Fixes dEQP-GLES3.functional.texture.specification.teximage2d_pbo subtests on Braswell and Skylake. These tests hit the meta PBO texture upload path, which binds the PBO as a texture and samples from it, while rendering to the destination texture. The tests then sample from the texture. For now, we leave Gen4-5 alone. It probably needs work too, but apparently it hasn't even been setting the (G45+) TC invalidation bit at all... v2: Add Sandybridge post-sync non-zero workaround, for safety. Cc: [email protected] Suggested-by: Francisco Jerez <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Francisco Jerez <[email protected]>
* i965: Whack UAV bit when FS discards and there are no color writes.Kenneth Graunke2016-03-281-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dEQP-GLES31.functional.fbo.no_attachments.* draws a quad with no framebuffer attachments, using a shader that discards based on gl_FragCoord. It uses occlusion queries to inspect whether pixels are rendered or not. Unfortunately, the hardware is not dispatching any pixel shaders, so discards never happen, and the full quad of pixels increments PS_DEPTH_COUNT, making the occlusion query results bogus. To understand why, we have to delve into the WM_INT internal signalling mechanism's formulas. The "WM_INT::Pixel Shader Kill Pixel" signal is defined as: 3DSTATE_WM::ForceKillPixel == ON || (3DSTATE_WM::ForceKillPixel != Off && !WM_INT::WM_HZ_OP && 3DSTATE_WM::EDSC_Mode != PREPS && (WM_INT::Depth Write Enable || WM_INT::Stencil Write Enable) && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (3DSTATE_PS_EXTRA::PixelShaderKillsPixels || 3DSTATE_PS_EXTRA:: oMask Present to RenderTarget || 3DSTATE_PS_BLEND::AlphaToCoverageEnable || 3DSTATE_PS_BLEND::AlphaTestEnable || 3DSTATE_WM_CHROMAKEY::ChromaKeyKillEnable)) Because there is no depth or stencil buffer, writes to those buffers are disabled. So the highlighted condition is false, making the whole "Kill Pixel" condition false. This then feeds into the following "WM_INT::ThreadDispatchEnable" condition: 3DSTATE_WM::ForceThreadDispatch != OFF && !WM_INT::WM_HZ_OP && 3DSTATE_PS_EXTRA::PixelShaderValid && (3DSTATE_PS_EXTRA::PixelShaderHasUAV || WM_INT::Pixel Shader Kill Pixel || WM_INT::RTIndependentRasterizationEnable || (!3DSTATE_PS_EXTRA::PixelShaderDoesNotWriteRT && 3DSTATE_PS_BLEND::HasWriteableRT) || (WM_INT::Pixel Shader Computed Depth Mode != PSCDEPTH_OFF && (WM_INT::Depth Test Enable || WM_INT::Depth Write Enable)) || (3DSTATE_PS_EXTRA::Computed Stencil && WM_INT::Stencil Test Enable) || (3DSTATE_WM::EDSC_Mode == 1 && (WM_INT::Depth Test Enable || WM_INT::Depth Write Enable || WM_INT::Stencil Test Enable))) Given that there's no depth/stencil testing, no writeable render target, and the hardware thinks kill pixel doesn't happen, all of these conditions are false. We have to whack some bit to make PS invocations happen. There are many options. Curro suggested using the UAV bit. There's some precedence in doing that - we set it for fragment shaders that do SSBO/image/atomic writes when no color buffer writes are enabled. We can simply include discard here too. Fixes 64 dEQP-GLES31.functional.fbo.no_attachments.* tests. v2: Add a comment suggested and written by Jason Ekstrand. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* mesa/st: Fix NULL access if no fragment shader is boundBas Nieuwenhuizen2016-03-281-2/+2
| | | | | Signed-off-by: Bas Nieuwenhuizen <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* st/mesa: only minify height if target != 1D array in st_finalize_textureMarek Olšák2016-03-281-1/+6
| | | | | | | | | | | The st_texture_object documentation says: "the number of 1D array layers will be in height0" We can't minify that. Spotted by luck. No app is known to hit this issue. Reviewed-by: Ilia Mirkin <[email protected]>
* mesa: optimize out the realloc from glCopyTexImagexD()Miklós Máté2016-03-271-0/+36
| | | | | | | | | | | v2: comment about the purpose of the code v3: also compare texFormat, add a perf debug message, formatting fixes Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Miklós Máté <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* st/mesa: fix handling the fallback textureMiklós Máté2016-03-271-3/+4
| | | | | | | | | | This fixes crash when post-processing is enabled in SW:KotOR. v2: fix const-ness v3: move assignment into the if() block Signed-off-by: Miklós Máté <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* st/mesa: enable GL_ATI_fragment_shaderMiklós Máté2016-03-271-0/+1
| | | | | Signed-off-by: Miklós Máté <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* st/mesa: implement GL_ATI_fragment_shaderMiklós Máté2016-03-2710-4/+1064
| | | | | | | | | | | | | v2: fix arithmetic for special opcodes, fix fog state, cleanup v3: simplify handling of special opcodes, fix rebinding with different textargets or fog equation, lots of formatting fixes v4: adapt to the compile early, fix later architecture, formatting fixes Signed-off-by: Miklós Máté <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* program: add ATI_fragment_shader to shader stages listMiklós Máté2016-03-271-0/+2
| | | | | Signed-off-by: Miklós Máté <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* mesa: optionally associate a gl_program to ATI_fragment_shaderMiklós Máté2016-03-275-2/+34
| | | | | | | | | the state tracker will use it Acked-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Miklós Máté <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* mesa/st: Remove GLSLVersion clampingEdward O'Callaghan2016-03-271-10/+5
| | | | | | | While here, remove itermediate glsl_feature_level variable. Signed-off-by: Edward O'Callaghan <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* glsl: reduce buffer block duplicationTimothy Arceri2016-03-262-39/+3
| | | | | | | | | | | | | This reduces some of the craziness required for handling buffer blocks. The problem is each shader stage holds its own information about a block in memory, we were copying that information to a program wide list but the per stage information remained meaning when a binding was updated we needed to update all versions of it. This changes the per stage blocks to instead point to a single version of the block information in the program list. Acked-by: Kenneth Graunke <[email protected]>
* mesa: Check glReadBuffer enums against the ES3 table.Kenneth Graunke2016-03-241-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | From the ES 3.2 spec, section 16.1.1 (Selecting Buffers for Reading): "An INVALID_ENUM error is generated if src is not BACK or one of the values from table 15.5." Table 15.5 contains NONE and COLOR_ATTACHMENTi. Mesa properly returned INVALID_ENUM for unknown enums, but it decided what was known by using read_buffer_enum_to_index, which handles all enums in every API. So enums that were valid in GL were making it past the "valid enum" check. Such targets would then be classified as unsupported, and we'd raise INVALID_OPERATION, but that's technically the wrong error code. Fixes dEQP-GLES31's functional.debug.negative_coverage.get_error.buffer.read_buffer v2: Only call read_buffer_enuM_to_index when required (Eduardo). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]>
* mesa: Handle negative length in glPushDebugGroup().Kenneth Graunke2016-03-241-0/+3
| | | | | | | | | | | | | The KHR_debug spec doesn't actually say we should handle this, but that is most likely an oversight - it says to check against strlen and generate errors if length is negative. It appears they just forgot to explicitly spell out that we should then proceed to actually handle it. Fixes crashes from uncaught std::string exceptions in many dEQP-GLES31.functional.debug.error_filters.* tests. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]>
* mesa: Make glDebugMessageInsert deal with negative length for all types.Kenneth Graunke2016-03-241-3/+4
| | | | | | | | | | | | | | | | | | | | From the KHR_debug spec, section 5.5.5 (Externally Generated Messages): "If <length> is negative, it is implied that <buf> contains a null terminated string. The error INVALID_VALUE will be generated if the number of characters in <buf>, excluding the null terminator when <length> is negative, is not less than the value of MAX_DEBUG_MESSAGE_LENGTH." This indicates that length should be set to strlen for all types, not just GL_DEBUG_TYPE_MARKER. We want it to be after validate_length() so we still generate appropriate errors. Fixes crashes from uncaught std::string exceptions in many dEQP-GLES31.functional.debug.error_filters.* tests. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]>
* mesa: Include null terminator in GL_DEBUG_NEXT_LOGGED_MESSAGE_LENGTH.Kenneth Graunke2016-03-241-1/+1
| | | | | | | | | | | | | | | | | | | From the KHR_debug spec: "Applications can query the number of messages currently in the log by obtaining the value of DEBUG_LOGGED_MESSAGES, and the string length (including its null terminator) of the oldest message in the log through the value of DEBUG_NEXT_LOGGED_MESSAGE_LENGTH." Because we weren't including the null terminator, many dEQP tests called glGetDebugMessageLog with a bufSize parameter that was 1 too small, and unable to contain the message, so we skipped returning it, failing many cases. Fixes 298 dEQP-GLES31.functional.debug.* tests. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Stephane Marchesin <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]>
* st/mesa: use RGBA instead of BGRA for SRGB_ALPHANicolai Hähnle2016-03-241-1/+1
| | | | | | | | | This fixes a regression introduced by commit a8eea696 "st/mesa: honour sized internal formats in st_choose_format (v2)". Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94657 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94671 Reviewed-by: Marek Olšák <[email protected]>
* mesa: replace gl_context->Multisample._Enabled with ↵Bas Nieuwenhuizen2016-03-2414-36/+43
| | | | | | | | | | | | _mesa_is_multisample_enabled. This removes any dependency on driver validation of the number of framebuffer samples. Signed-off-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Edward O'Callaghan <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Tested-by: Brian Paul <[email protected]>
* i965/peephole_ffma: Don't fuse exact addsJason Ekstrand2016-03-231-1/+3
| | | | Reviewed-by: Francisco Jerez <[email protected]>
* st/mesa: add missing MemoryBarrier bits and some explanationsNicolai Hähnle2016-03-231-1/+24
| | | | | Reviewed-by: Edward O'Callaghan <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* i965/fs: Don't constant-fold RCPJason Ekstrand2016-03-221-15/+0
| | | | | | No shader-db changes on Broadwell Reviewed-by: Matt Turner <[email protected]>
* i965: Remove the RCP+RSQ algebraic optimizationsJason Ekstrand2016-03-222-22/+0
| | | | | | | | | NIR already has this optimization and it can do much better than the little peephole in the backend. No shader-db change on Haswell or Broadwell. Reviewed-by: Matt Turner <[email protected]>
* i965: Have NIR lower flrp on pre-GEN6 vec4 backendIan Romanick2016-03-221-2/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we were doing the lowering by hand in vec4_visitor::emit_lrp. By doing it in NIR, we have the opportunity for NIR to do additional optimization of the expanded code. This also enables optimizations added by the next commit. shader-db results: G4X / Ironlake total instructions in shared programs: 4024401 -> 4016538 (-0.20%) instructions in affected programs: 447686 -> 439823 (-1.76%) helped: 2623 HURT: 0 total cycles in shared programs: 84375846 -> 84328296 (-0.06%) cycles in affected programs: 16964960 -> 16917410 (-0.28%) helped: 2556 HURT: 41 Unsurprisingly, no changes on later platforms. v2: Formatting and comment changes suggested by Matt. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* swrast: fix discarded const warning in s_texture.cBrian Paul2016-03-221-1/+1
| | | | Signed-off-by: Brian Paul <[email protected]>
* i965: fix invalid memory writeMarc-André Lureau2016-03-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed some heap corruption running virgl tests, and valgrind helped me to track it down to the following error: ==29272== Invalid write of size 4 ==29272== at 0x90283D4: push_loop_stack (brw_eu_emit.c:1307) ==29272== by 0x9029A7D: brw_DO (brw_eu_emit.c:1750) ==29272== by 0x90554B0: fs_generator::generate_code(cfg_t const*, int) (brw_fs_generator.cpp:1999) ==29272== by 0x904491F: brw_compile_fs (brw_fs.cpp:5685) ==29272== by 0x8FC5DC5: brw_codegen_wm_prog (brw_wm.c:137) ==29272== by 0x8FC7663: brw_fs_precompile (brw_wm.c:638) ==29272== by 0x8FA4040: brw_shader_precompile(gl_context*, gl_shader_program*) (brw_link.cpp:51) ==29272== by 0x8FA4A9A: brw_link_shader (brw_link.cpp:260) ==29272== by 0x8DEF751: _mesa_glsl_link_shader (ir_to_mesa.cpp:3006) ==29272== by 0x8C84325: _mesa_link_program (shaderapi.c:1042) ==29272== by 0x8C851D7: _mesa_LinkProgram (shaderapi.c:1515) ==29272== by 0x4E4B8E8: add_shader_program (vrend_renderer.c:880) ==29272== Address 0xf2f3cb0 is 0 bytes after a block of size 112 alloc'd ==29272== at 0x4C2AA98: calloc (vg_replace_malloc.c:711) ==29272== by 0x8ED11F7: ralloc_size (ralloc.c:113) ==29272== by 0x8ED1282: rzalloc_size (ralloc.c:134) ==29272== by 0x8ED14C0: rzalloc_array_size (ralloc.c:196) ==29272== by 0x9019C7B: brw_init_codegen (brw_eu.c:291) ==29272== by 0x904F565: fs_generator::fs_generator(brw_compiler const*, void*, void*, void const*, brw_stage_prog_data*, unsigned int, bool, gl_shader_stage) (brw_fs_generator.cpp:124) ==29272== by 0x9044883: brw_compile_fs (brw_fs.cpp:5675) ==29272== by 0x8FC5DC5: brw_codegen_wm_prog (brw_wm.c:137) ==29272== by 0x8FC7663: brw_fs_precompile (brw_wm.c:638) ==29272== by 0x8FA4040: brw_shader_precompile(gl_context*, gl_shader_program*) (brw_link.cpp:51) ==29272== by 0x8FA4A9A: brw_link_shader (brw_link.cpp:260) ==29272== by 0x8DEF751: _mesa_glsl_link_shader (ir_to_mesa.cpp:3006) if_depth_in_loop is an array of size p->loop_stack_array_size, and push_loop_stack() will access if_depth_in_loop[p->loop_stack_depth+1], thus the condition to grow the array should be p->loop_stack_array_size <= (p->loop_stack_depth + 1) (it's currently off by 2...) This can be reproduced by running the following test with virgl test server: LIBGL_ALWAYS_SOFTWARE=y GALLIUM_DRIVER=virpipe bin/shader_runner ./tests/shaders/glsl-fs-unroll-explosion.shader_test -auto Signed-off-by: Marc-André Lureau <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* st/mesa: add support for internalformat query2.Dave Airlie2016-03-222-10/+45
| | | | | | | | Add code to handle GL_INTERNALFORMAT_PREFERRED. Add code to deal with GL_RENDERBUFFER being passes into ChooseTextureFormat. Reviewed-by: Alejandro Piñeiro <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* i965: Fix assert conditions for src/dst x/y offsetsAnuj Phogat2016-03-211-3/+3
| | | | | | Cc: [email protected] Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* swrast: Move assert for 'slice' in to check_map_teximageAnuj Phogat2016-03-211-1/+1
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Alejandro Piñeiro <[email protected]>
* i965/blorp: Make BlitFramebuffer() do sRGB encoding in ES 3.x.Kenneth Graunke2016-03-211-1/+4
| | | | | | | | | | | | | | | | | | According to the ES 3.0 and GL 4.4 specifications, glBlitFramebuffer is supposed to perform sRGB decoding and encoding whenever sRGB formats are in use. The ES 3.0 specification is completely clear, and has always stated this. However, the GL specification has changed behavior in 4.1, 4.2, and 4.4. The original behavior stated that no sRGB encoding should occur. The 4.4 behavior matches ES 3.0's wording. However, implementing the new behavior appears to break applications such as Left 4 Dead 2. This patch changes Meta to apply the ES 3.x rules in ES 3.x, but leaves OpenGL alone for now, to avoid breaking applications. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* i965/blorp: Refactor sRGB encoding/decoding.Kenneth Graunke2016-03-214-11/+23
| | | | | | | | | | | | Because the rules for sRGB are so insane, we change brw_blorp_miptrees to take decode_srgb and encode_srgb flags, which control linearization of the source and destination separately. This should make it easy to implement whatever crazy combination of rules people throw at us. For now, it should be equivalent. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* meta: Make BlitFramebuffer() do sRGB encoding in ES 3.x.Kenneth Graunke2016-03-213-9/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | According to the ES 3.0 and GL 4.4 specifications, glBlitFramebuffer is supposed to perform sRGB decoding and encoding whenever sRGB formats are in use. The ES 3.0 specification is completely clear, and has always stated this. However, the GL specification has changed behavior in 4.1, 4.2, and 4.4. The original behavior stated that no sRGB encoding should occur. The 4.4 behavior matches ES 3.0's wording. However, implementing the new behavior appears to break applications such as Left 4 Dead 2. This patch changes Meta to apply the ES 3.x rules in ES 3.x, but leaves OpenGL alone for now, to avoid breaking applications. Meta implements several other functions in terms of BlitFramebuffer, and many of those explicitly do not perform sRGB encoding. So, this patch explicitly disables sRGB encoding in those other functions, preserving the existing (correct) behavior. If you're from the future and are reading this, hi! Welcome to the "fun" of debugging sRGB problems! Best of luck! Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* st/mesa: translate additional flags in MemoryBarrierNicolai Hähnle2016-03-211-3/+18
| | | | | | | | Re-order flags in the order in which they appear in the OpenGL spec in the description of MemoryBarrier(). Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* st/mesa: emit sampler view decls in drawpixels codeBrian Paul2016-03-212-1/+19
| | | | | | | v2: support both TGSI_TEXTURE_2D and _RECT Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Charmaine Lee <[email protected]>
* st/mesa: emit sampler view declaration in bitmap shaderBrian Paul2016-03-211-0/+4
| | | | | | | | | | | | | In June 2015, Rob Clark started updating the tgsi utility code to emit SVIEW declarations in various shaders (for polygon stipple, blitting, etc). These patches do the same for the Mesa state tracker. The VMware driver will use this. v2: support both TGSI_TEXTURE_2D and _RECT Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Charmaine Lee <[email protected]>
* st/mesa: emit sampler view declarations for ARB vert/frag programsBrian Paul2016-03-211-0/+22
| | | | | Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Charmaine Lee <[email protected]>
* st/mesa: use correct TGSI texture target in drawpix fragment shaderBrian Paul2016-03-213-4/+11
| | | | | Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Charmaine Lee <[email protected]>
* st/mesa: use correct TGSI texture target in bitmap fragment shaderBrian Paul2016-03-213-3/+11
| | | | | | | | | Depending on the driver's support for NPOT textures, we might use a RECT texture instead of 2D texture. We should propogate that info to the fragment shader's TEX instruction. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Charmaine Lee <[email protected]>
* gallium/tgsi: pass TGSI tex target to tgsi_transform_tex_inst()Brian Paul2016-03-212-7/+7
| | | | | | | Instead of hard-coded 2D tex target in tgsi_transform_tex_2d_inst() Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Charmaine Lee <[email protected]>
* st/mesa: use the texture view's format for render-to-textureNicolai Hähnle2016-03-211-7/+15
| | | | | | | | | | Aside from the bug below, it fixes a simplistic test I've written locally, and I see no regression in Piglit for radeonsi. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94595 Cc: "11.0 11.1 11.2" <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* tgsi: Add support for global / private / input MEMORYHans de Goede2016-03-211-1/+1
| | | | | | | | | | | | | | | | Extend the MEMORY file support to differentiate between global, private and shared memory, as well as "input" memory. "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a special memory type is added for this, since the actual storage of these (e.g. UBO-s) may differ per implementation. The uploading of kernel parameters is handled by launch_grid, "MEMORY[x], INPUT" allows drivers to use an access mechanism for parameter reads which matches with the upload method. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> (v1) Reviewed-by: Samuel Pitoiset <[email protected]> (v2)
* st/mesa: report correct precision information for low/medium/high intsIlia Mirkin2016-03-201-0/+7
| | | | | | | | | | | | | | | | | When we have native integers, these have full precision. Whether they're low/medium/high isn't piped through the TGSI yet, but eventually those might have differing precisions. For now they're just 32-bit ints. Fixes the following dEQP tests: dEQP-GLES3.functional.state_query.shader.precision_vertex_highp_int dEQP-GLES3.functional.state_query.shader.precision_fragment_highp_int which expected highp ints to have full 32-bit precision, not the default 23-bit float precision. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Dave Airlie <[email protected]>
* st/mesa: only minify depth for 3d targetsIlia Mirkin2016-03-201-1/+4
| | | | | | | | | | | | | | | | We make sure that that image depth matches the level's depth before copying it into place. However we should only be minifying the first level's depth for 3d textures - array textures have the same depth for all levels. This fixes tests such as dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.* and I suspect account for a number of other odd situations I've run into where level > 0 of array textures was messed up. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Dave Airlie <[email protected]> Cc: "11.1 11.2" <[email protected]>
* st/mesa: set TGSI property NEXT_SHADERMarek Olšák2016-03-191-0/+36
| | | | Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: Disallow GL_FRAMEBUFFER_ATTACHMENT_OBJECT_NAME on winsys FBO.Kenneth Graunke2016-03-191-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | Fixes: dEQP-GLES3.functional.negative_api.state.get_framebuffer_attachment_parameteriv Apparently, GL_FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is not allowed when GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is GL_FRAMEBUFFER_DEFAULT, and is expected to result in a GL_INVALID_ENUM error. No GL specification actually defines what GL_FRAMEBUFFER_DEFAULT means. It probably means the window system FBO. It also doesn't mention the behavior of any queries for that type. Various ARB folks seem fairly confused about it too. For now, just do something vaguely like what dEQP expects. I think we probably need to check the visual bits against 0 for the attachment, but we haven't been doing that thusfar, and given how confusingly this is specified, I can't imagine anyone relying on it. v2: Improve comments, move error condition above the _mesa_get_fb0_attachment call, add forgotten "return" (all suggested/caught by Jordan Justen). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-27 22:00:14 +0000