summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* glsl: Optionally lower TCS gl_PatchVerticesIn to a uniform.Kenneth Graunke2016-06-153-0/+6
| | | | | | | | | i965 has no special hardware for this, so the best way to implement this is to pass it in via a uniform. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Alejandro Piñeiro <[email protected]> Cc: [email protected]
* i965: Use a uniform for gl_PatchVerticesIn in the TES.Kenneth Graunke2016-06-151-0/+1
| | | | | | | | | | | | | | | | Fixes three GL44-CTS.tessellation_shader subtests: - max_patch_vertices - single.max_patch_vertices - tessellation_control_to_tessellation_evaluation.gl_PatchVerticesIn These use gl_PatchVerticesIn in the TES, but don't link against a TCS (which would allow the linker to lower it to a constant). We had no handling for the system value in the backend, so it would just assert fail. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Alejandro Piñeiro <[email protected]> Cc: [email protected]
* glsl: Optionally lower TES gl_PatchVerticesIn to a uniform.Kenneth Graunke2016-06-153-0/+9
| | | | | | | | | | i965 has no special hardware for this, so we need to pass this value in as a uniform (unless the TES is linked against a TCS, in which case the linker can just replace this with a constant). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Alejandro Piñeiro <[email protected]> Cc: [email protected]
* st_glsl_to_tgsi: don't read potentially uninitialized buffer variableNicolai Hähnle2016-06-151-1/+1
| | | | | | | | Found by -fsanitize=undefined. Note that this should be a harmless issue in practice because the inst->op check always dominates anyway. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]>
* mesa/main: fix integer overflows in _mesa_image_offsetNicolai Hähnle2016-06-151-4/+4
| | | | | | | Found using -fsanitize=undefined. Cc: "11.1 11.2 12.0" <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i965: remove type_size_vec4_times_4()Timothy Arceri2016-06-154-17/+3
| | | | | | | | type_size_vec4_times_4() was introduced as a fix in 8dcf807cb43383 however since 3810c1561 we can just use type_size_scalar() and get the actual number of outputs we need. Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Pass gl_constant_value union into _mesa_fetch_state().Kenneth Graunke2016-06-141-3/+5
| | | | | | | | | | | | | | | | | We've had some trouble in the past with copying integers around via float pointers, as the C compiler sometimes uses x87 floating point registers to load values on 32-bit systems. Passing the gl_constant_value union should be safer. To avoid churn, this patch creates a "GLfloat *value" variable so existing uses can stay the same. Not observed to fix anything, but I was in the area adding more integer state vars, and thought it'd be wise. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Dave Airlie <[email protected]> Cc: [email protected]
* i965: Check return value of screen->image.loader->getBuffers (v2)Tomasz Figa2016-06-141-6/+9
| | | | | | | | | | | | | | | | | | | | The images struct is an uninitialized local variable on the stack. If the callback returns 0, the struct might not have been updated and so should be considered uninitialized. Currently the code ignores the return value, which (depending on stack contents) might end up in reading a non-zero value from images.image_mask and dereferencing further fields. Another solution would be to initialize image_mask with 0, but checking the return value seems more sensible and it is what Gallium is doing. v2: fix typos in commit message, fix indentation, remove unnecessary parentheses and pointer dereference to keep line length reasonable. Cc: 11.2 12.0 <[email protected]> Signed-off-by: Tomasz Figa <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* mesa: Make use of u_bit_scan{,64}.Mathias Fröhlich2016-06-142-5/+5
| | | | | | Reviewed-by: Brian Paul <[email protected]> Tested-by: Brian Paul <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* mesa/gallium: Move u_bit_scan{,64} from gallium to util.Mathias Fröhlich2016-06-142-74/+1
| | | | | | | | | | | | | | | The functions are also useful for mesa. Introduce src/util/bitscan.{h,c}. Move ffs function implementations from src/mesa/main/imports.{h,c}. Move bit scan related functions from src/gallium/auxiliary/util/u_math.h. Merge platform handling with what is available from within mesa. v2: Try to fix MSVC compile. Reviewed-by: Brian Paul <[email protected]> Tested-by: Brian Paul <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* i965/compiler: Bring back the INTEL_PRECISE_TRIG environment variableJason Ekstrand2016-06-132-2/+4
| | | | | | | | | | | This was removed in d9546b0c5d and replced with the precise_trig driconf option. However, we still need precise trig in the Vulkan driver so this commit brings back the environment variable and compiler->precise_trig is effectively the logical OR of the two. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96484 Reviewed-by: Kenneth Graunke <[email protected]> Cc: "12.0" <[email protected]>
* i965: Defeat the register stride checker in pull uniform messages.Samuel Iglesias Gonsálvez2016-06-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pulling DF uniforms from pull constant buffer generates messages like: send(4) g12<1>DF g12<0,1,0>F sampler ld SIMD4x2 Surface = 1 Sampler = 0 mlen 1 rlen 1 which produces GPU hangs in Cherryview/Braswell: "For 64-bit Align1 operation or multiplication of dwords in CHV, source horizontal stride must be aligned to qword." This seems to be documented in the Cherryview PRM, Volume 7, Page 843: "When source or destination datatype is 64b or operation is integer DWord multiply, regioning in Align1 must follow these rules: 1. Source and Destination horizontal stride must be aligned to the same qword." We should set the destination type to UD, D, or F so that the register stride checker doesn't notice. The destination type of send messages is basically irrelevant anyway. Cc: "12.0" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95462 Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Defeat the register stride checker in URB reads.Kenneth Graunke2016-06-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pulling DF inputs from the URB generates messages like: send(8) g23<1>DF g1<8,8,1>UD urb 3 SIMD8 read mlen 1 rlen 2 { align1 1Q }; which makes the simulator angry: "For 64-bit Align1 operation or multiplication of dwords in CHV, source horizontal stride must be aligned to qword." This seems to be documented in the Cherryview PRM, Volume 7, Page 823: "When source or destination datatype is 64b or operation is integer DWord multiply, regioning in Align1 must follow these rules: 1. Source and Destination horizontal stride must be aligned to the same qword." Setting the source horizontal stride to QWord is insane, as it's the message header containing 8 URB handles in a single 32-bit DWord. Instead, we should whack the destination type to UD, D, or F so that the register stride checker doesn't notice. The destination type of send messages is basically irrelevant anyway. Cc: "12.0" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95462 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Fix issues with number of VS URB entries on Cherryview/Broxton.Kenneth Graunke2016-06-132-2/+5
| | | | | | | | | | | | | | | | Cherryview/Broxton annoyingly have a minimum number of VS URB entries of 34, which is not a multiple of 8. When the VS size is less than 9, the number of VS entries has to be a multiple of 8. Notably, BLORP programmed the minimum number of VS URB entries (34), with a size of 1 (less than 9), which is invalid. It seemed like this could be a problem in the regular URB code as well, so I went ahead and updated that to be safe. Cc: "12.0" <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965/fs: Fix regs_written for SIMD-lowered instructions some more.Francisco Jerez2016-06-131-3/+3
| | | | | | | | | | | | | | | | | ISTR having suggested this during review of the recent FP64 changes to the SIMD lowering pass, but it doesn't look like it was taken into account in the end. Using the fs_reg::component_size helper instead of this open-coded variant makes sure that the stride is taken into account correctly. Fixes at least the following piglit tests with spilling forced on (since otherwise regs_written would be calculated incorrectly and the spilling code would be rather confused about how much data needs to be spilled): spec.arb_gpu_shader_fp64.shader_storage.layout-std140-fp64-shader spec.arb_gpu_shader_fp64.shader_storage.layout-std140-fp64-mixed-shader Cc: <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Fix cross-primitive scratch corruption when changing the per-thread ↵Francisco Jerez2016-06-1317-18/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | allocation. I haven't found any mention of this in the hardware docs, but experimentally what seems to be going on is that when the per-thread scratch slot size is changed between two pipelined draw calls, shader invocations using the old and new scratch size setting may end up being executed in parallel, causing their scratch offset calculations to be based in a different partitioning of the scratch space, which can cause their thread-local scratch space to overlap leading to cross-thread scratch corruption. I've been experimenting with alternative workarounds, like emitting a PIPE_CONTROL with DC flush and CS stall between draw (or dispatch compute) calls using different per-thread scratch allocation settings, or avoiding reuse of the scratch BO if the per-thread scratch allocation doesn't exactly match the original. Both seem to be as effective as this workaround, but they have potential performance implications, while this should be basically for free. Fixes over 40 failures in our CI system with spilling forced on (including CTS, dEQP and Piglit failures) on a number of different platforms from Gen4 to Gen9. The 'glsl-max-varyings' piglit test seems to be able to reproduce this bug consistently in the vertex shader on at least Gen4, Gen8 and Gen9 with spilling forced on. Cc: <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Keep track of the per-thread scratch allocation in brw_stage_state.Francisco Jerez2016-06-138-49/+70
| | | | | | | | | | | | | | | | This will be used to find out what per-thread slot size a previously allocated scratch BO was used with in order to fix a hardware race condition without introducing additional stalls or memory allocations. Instead of calling brw_get_scratch_bo() manually from the various codegen functions, call a new helper function that keeps track of the per-thread scratch size and conditionally allocates a larger scratch BO. v2: Handle BO allocation manually instead of relying on brw_get_scratch_bo (Ken). Cc: <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Fix scratch overallocation if the original slot size was already a ↵Francisco Jerez2016-06-131-1/+1
| | | | | | | | | | | | | | power of two. The bitwise arithmetic trick used in brw_get_scratch_size() to clamp the scratch allocation to 1KB has the unintended side effect that it will cause us to allocate 2x the required amount of scratch space if the original per-thread scratch size happened to be already a power of two. Instead use the obvious MAX2 idiom to clamp the scratch allocation to the expected range. Cc: <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Make TexSubImage check negative dimensions sooner.Kenneth Graunke2016-06-131-19/+43
| | | | | | | | | | | | | | | | | | | Two dEQP tests expect INVALID_VALUE errors for negative width/height parameters, but get INVALID_OPERATION because they haven't actually created a destination image. This is arguably not a bug in Mesa, as there's no specified ordering of error conditions. However, it's also really easy to make the tests pass, and there's no real harm in doing these checks earlier. Fixes: dEQP-GLES3.functional.negative_api.texture.texsubimage3d_neg_width_height dEQP-GLES31.functional.debug.negative_coverage.get_error.texture.texsubimage3d_neg_width_height v2: Drop redundant check (caught by Anuj Phogat). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965: Fix encode_slm_size() to take a generation, not a device info.Kenneth Graunke2016-06-132-3/+4
| | | | | | | | | | | | | | | In the Vulkan driver, we have the generation number (a compile time constant) but not necessarily the brw_device_info struct. I meant to rework the function to take a generation number instead of a brw_device_info pointer to accomodate this. But I forgot, and left it taking a brw_device_info pointer, while making Vulkan pass the generation number (8, 9, ...) directly. This led to crashes. Brown paper bag fix for commit 87d062a94080373995170f51063a9649. Cc: "12.0" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96504 Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Don't leak scratch BOs for TCS/TES.Kenneth Graunke2016-06-131-0/+4
| | | | | | | These need to be freed too. Cc: "12.0" <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* Android: move libdrm settings to top-level Android.common.mkRob Herring2016-06-131-1/+0
| | | | | | | | | | | | | | Fix warnings like these due to HAVE_LIBDRM being inconsistently defined: external/libdrm/include/drm/drm.h:839:30: warning: redefinition of typedef 'drm_clip_rect_t' is a C11 feature [-Wtypedef-redefinition] typedef struct drm_clip_rect drm_clip_rect_t; HAVE_LIBDRM needs to be set project wide to fix this. This change also harmlessly links libdrm with everything, but simplifies the makefiles a bit. Signed-off-by: Rob Herring <[email protected]> Acked-by: Emil Velikov <[email protected]>
* st/mesa: inline _mesa_create_context() into its only callerEmil Velikov2016-06-133-46/+6
| | | | | | | | Inline the function into it's only caller. This way it's more obvious how the classic and gallium drivers (st/mesa) use _mesa_initialize_context. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* st/mesa: remove unneeded break from st_api_create_context()Emil Velikov2016-06-131-1/+0
| | | | | | | | We have return on the previous line, thus the break will never be reached. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* st/mesa: use c99 initializer for st_gl_apiEmil Velikov2016-06-131-13/+13
| | | | | Signed-off-by: Emil Velikov <[email protected]> Acked-by: Ian Romanick <[email protected]>
* gallium: remove st_api::get_proc_address hookEmil Velikov2016-06-131-7/+0
| | | | | | | It has been unused for a long time, plus makes the gallium dri modules require an extra glapi symbol relative to their classic counterparts. Signed-off-by: Emil Velikov <[email protected]>
* mesa: remove _mesa_init_get_hash()Emil Velikov2016-06-133-70/+0
| | | | | | | | | | | | | | The actual code of the function print_table_stats() is guarded by a ifdef GET_DEBUG, which was not been defined in years. The last fix in 2013 (7db6b5aa91a) indicates that it's rarely used/tested. Since the issue has gone unnoticed for a whole year (broken with 2ad4a475474). Let's remove it for now. We can always revive it at a later stage. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: kill off _mesa_do_init_remap_table()Emil Velikov2016-06-131-18/+7
| | | | | | | ... and inline its contents in _mesa_init_remap_table(). Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: use native types when possibleEmil Velikov2016-06-131-5/+6
| | | | | | | | All of the functions and related data is internal, so there's no point if using the GL types. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: make _mesa_map_function_spec() staticEmil Velikov2016-06-132-6/+3
| | | | | | | Used only locally. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: remove used _mesa_get_function_spec() and gl_function_remapEmil Velikov2016-06-132-27/+0
| | | | | | | Final user was killed with last commit. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: remove unused _mesa_map_function_array()Emil Velikov2016-06-132-47/+0
| | | | | | | | Unused as of commit 5a175127f38 ("dri: Remove all extension enabling utility functions") and the patch before the previous patch. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: remove unused function _mesa_map_static_functions()Emil Velikov2016-06-132-23/+0
| | | | | | | | Unused as of commit 5a175127f38 ("dri: Remove all extension enabling utility functions") Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* dri/common: remove unused libdri_test_stubs.laEmil Velikov2016-06-133-104/+1
| | | | | | | | | | ... and associated file(s). No longer needed since commit 057259655e7 ("i965: Don't link libmesa or libdri_test_stubs into tests") Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Use the correct number of threads for compute shaders.Kenneth Graunke2016-06-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We were programming the number of threads per subslice, when we should have been programming the total number of threads on the GPU as a whole. Thanks to Curro and Jordan for helping track this down! On Skylake GT3e: - Improves performance in Unreal's Elemental Demo by roughly 1.5-1.7x. - Improves performance in Synmark's Gl43CSDof by roughly 3.7x. - Improves performance in Synmark's Gl43GSCloth by roughly 1.18x. On Broadwell GT2: - Improves performance in Unreal's Elemental Demo by roughly 1.2-1.5x. - Improves performance in Synmark's Gl43CSDof by roughly 2.0x. - Improves performance in Synmark's Gl43GSCloth by 1.47035% +/- 0.255654% (n=25). On Haswell GT3e: - Improves performance in Unreal's Elemental Demo (in GL 4.3 mode) by roughly 1.10x. - Improves performance in Synmark's Gl43CSDof by roughly 1.18x. - Decreases performance in Synmark's Gl43CSCloth by -1.99484% +/- 0.432771% (n=64). On Ivybridge GT2: - Improves performance in Unreal's Elemental Demo (in GL 4.2 mode) by roughly 1.03x. - Improves performance in Synmark's G/43CSDof by roughly 1.25x. - No change in Synmark's Gl43CSCloth (n=28). Cc: "12.0" <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Assert that the scratch spaces are in range.Kenneth Graunke2016-06-121-0/+14
| | | | | | | | | | | | | | | I don't know that anything actually guarantees this, but if we exceed the limits, we may end up overflowing and trashing random buffers that happen to be nearby in the VMA space, leading to rendering corruption, hangs, or worse. We should really fix this properly. However, the pitfall has existed for ages, so for now we should at least detect it. Cc: "12.0" <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Fix CS scratch size calculations on Ivybridge and Baytrail.Kenneth Graunke2016-06-122-2/+10
| | | | | | | | | These are linear, not powers of two, and much more limited. Cc: "12.0" <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Fix Haswell CS per-thread scratch space encoding.Kenneth Graunke2016-06-122-3/+25
| | | | | | | | | | | | | | | | | | | | | | Most scratch stages use power of two sizes, in kilobytes, where 0 means 1kB. But compute shaders on Haswell have a minimum of 2kB, and use a representation where 0 = 2kB. This meant that we were effectively telling the hardware to allocate each thread twice as much space as we meant to, while simultaneously not allocating that much space in the buffer, leading to overflows. Note that the existing code is completely wrong for Ivybridge, but that will take additional work to sort out, so I've left it as is for now. A subsequent commit will take care of that. Together with the previous patches, this fixes rendering corruption on Synmark's Gl43CSDof on Haswell. Cc: "12.0" <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Account for poor address calculations in Haswell CS scratch size.Kenneth Graunke2016-06-121-1/+20
| | | | | | | | | | | | | | | | Curro figured this out by investigating the simulator. Apparently there's also a workaround in the Windows driver. I'm not sure it's actually documented anywhere. We were underallocating the scratch buffer by a factor of 128/70. v2: Rename threads_per_subslice to scratch_ids_per_subslice (suggested by Jordan Justen). Cc: "12.0" <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Allocate scratch space for the maximum number of compute threads.Kenneth Graunke2016-06-121-1/+3
| | | | | | | | | | | | | | | | | | | | We were allocating enough space for the number of threads per subslice, when we should have been allocating space for the number of threads in the entire GPU. Even though we currently run with a reduced thread count (due to a bug), we might still overflow the scratch buffer because the address calculation is based on the FFTID, which can depend on exactly which threads, EUs, and threads are executing. We need to allocate enough for every possible thread that could run. Fixes rendering corruption in Synmark's Gl43CSDof on Gen8+. Earlier platforms need additional bug fixes. Cc: "12.0" <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Set subslice_total on Gen7/7.5 platforms.Kenneth Graunke2016-06-121-1/+4
| | | | | | | | | | | | We'll use this for compute shader thread counts and scratch space calculations shortly. Note that subslices are referred to as "half slices" on Ivybridge. Cc: "12.0" <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Fix shared local memory size for Gen9+.Kenneth Graunke2016-06-122-9/+35
| | | | | | | | | | | | | | | | | | | | | Skylake changes the representation of shared local memory size: Size | 0 kB | 1 kB | 2 kB | 4 kB | 8 kB | 16 kB | 32 kB | 64 kB | ------------------------------------------------------------------- Gen7-8 | 0 | none | none | 1 | 2 | 4 | 8 | 16 | ------------------------------------------------------------------- Gen9+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | The old formula would substantially underallocate the amount of space. This fixes GPU hangs on Skylake when running with full thread counts. v2: Fix the Vulkan driver too, use a helper function, and fix the table in the comments and commit message. Cc: "12.0" <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* mesa: add drawbuffer argument to ClearNamedFramebufferfiIlia Mirkin2016-06-102-3/+3
| | | | | | | | | | | This was fixed in revision 47 of the ARB_dsa spec in Oct 22, 2015. Since it's horrible to have differing APIs across library versions, we should attempt to minimize the impact by backporting it as far as possible and hope no one notices. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]> Cc: "11.2 12.0" <[email protected]>
* st/mesa: tweak surface format mapping tableBrian Paul2016-06-101-9/+11
| | | | | | | | | | | 1. Try to choose R8G8B8A8 unorm/srgb formats before others in an effort to try to match component ordering for UINT/SINT/etc. 2. If we can't get a format such as PIPE_FORMAT_A16_UNORM, try PIPE_FORMAT_R16G16B16A16_UNORM before shallower formats. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Charmaine Lee <[email protected]>
* mesa: Fix region overlap conditions for rectangles with a shared edgeAnuj Phogat2016-06-101-4/+4
| | | | | | | | | | | | | | | | | | | | | | >From OpenGL 4.0 spec, section 4.3.2 "Copying Pixels": "The pixels corresponding to these buffers are copied from the source rectangle bounded by the locations (srcX0, srcY 0) and (srcX1, srcY 1) to the destination rectangle bounded by the locations (dstX0, dstY 0) and (dstX1, dstY 1). The lower bounds of the rectangle are inclusive, while the upper bounds are exclusive." So, the rectangles sharing just an edge shouldn't overlap. ----------- | | ------- --- | | | | | | ------- --- Cc: "12.0" <[email protected]> Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
* st/mesa: use base level size as "guess" when availableNicolai Hähnle2016-06-101-6/+27
| | | | | | | | | | | | | | | | | | | | When an applications specifies mip levels _before_ setting a mipmap texture filter, we will initially guess a single texture level. When the second level image is created, we try to allocate the full texture -- however, we get the base level size guess wrong if that size is odd. This leads to yet another re-allocation of the texture later during st_finalize_texture. Even worse, this re-allocation breaks a (reasonable) assumption made by st_generate_mipmaps, because the re-allocation in the finalization call will again allocate a single-level pipe texture (based on the non-mipmap texture filter!). As a result, mipmap generation fails in interesting ways. All of this can be avoided by just using the fact that we already know the size of the base level. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95529 Cc: 12.0 <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Wrap extensions.h declarations with extern "C".Jose Fonseca2016-06-101-0/+8
| | | | | | | This should fix the MSVC linker failures that arose with commit 5e2d25894b962aae9158261897e13843377e3b95. Trivial.
* st/mesa: fix type confusion with reladdrsIlia Mirkin2016-06-091-5/+5
| | | | | | | | | | | The reality is that this doesn't matter, because we manually emit the ARL to the sampler reladdr, and those arguments don't get an extra load later, so it's effectively just a boolean. However having the types be wrong is confusing and could trigger very odd bugs should usage change down the line. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i965/gen9: Don't change halign and valign to fit in fast copy blitAnuj Phogat2016-06-091-4/+2
| | | | | | | | | An update in graphics specs has deleted the halign and valign fields from XY_FAST_COPY_BLT command. See mesa commit 97f0f91. Cc: Ben Widawsky <[email protected]> Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* mesa: Add a helper function for shared code in get_tex_rgba_{un}compressedAnuj Phogat2016-06-091-45/+38
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Brian Paul <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 19:25:03 +0000