AgeCommit message (Collapse)AuthorFilesLines
2015-03-28Add release notes for the 10.5.2 releasemesa-10.5.2Emil Velikov1-0/+129
Signed-off-by: Emil Velikov <>
2015-03-28Update version to 10.5.2Emil Velikov1-1/+1
Signed-off-by: Emil Velikov <>
2015-03-28cherry-ignore: add commit non applicable for 10.5Emil Velikov1-0/+3
Signed-off-by: Emil Velikov <>
2015-03-26configure: Introduce new output variable to ax_check_python_mako_module.m4Samuel Iglesias Gonsalvez2-3/+9
This output variables gives more flexibility for future changes in autoconf to detect if it is needed to auto-generate files and check for the auto-generation dependencies. It is still returning error when Python is not installed. Signed-off-by: Samuel Iglesias Gonsalvez <> Reviewed-by: Kai Wasserbäch <> (cherry picked from commit ced9425327be6cb557a4a1217a1dac29b18d1a09) Squashed with commit move AC_MSG_RESULT reporting back into the m4 macro The one who does AC_MSG_CHECKING should provide the AC_MSG_RESULT. Fixes: ced9425327b (configure: Introduce new output variable to ax_check_python_mako_module.m4" Cc: "10.5" <> Bugzilla: Signed-off-by: Emil Velikov <> Reviewed-by: Samuel Iglesias Gonsalvez <> (cherry picked from commit 248eb54eb6117cc5a863ba2deaa14c3bee0b5d41)
2015-03-26glsl: Generate link error for non-matching gl_FragCoord redeclarationsAnuj Phogat1-13/+2
in different fragment shaders. This also applies to a case when gl_FragCoord is redeclared with no layout qualifiers in one fragment shader and not declared but used in other fragment shader. Signed-off-by: Anuj Phogat <> Khronos Bug#12957 Cc: "10.5" <> Reviewed-by: Chris Forbes <> (cherry picked from commit d8208312a3a200b4e6d71ce533d835b2d705234a)
2015-03-26mapi: Make private copies of name strings provided by client.Mario Kleiner1-1/+1
glXGetProcAddress("glFoo") ends up in stub_add_dynamic() to create dynamic stubs for dynamic functions. stub_add_dynamic() doesn't store the caller provided name string "Foo" in a mesa private copy, but just stores a pointer to the "glFoo" string passed to glXGetProcAddress - a pointer into arbitrary memory outside mesa's control. If the caller passes some dynamically allocated/changing memory buffer to glXGetProcAddress(), or the caller gets unmapped from memory, e.g., some dynamically loaded application plugin which uses OpenGL, this ends badly - with a dangling pointer. strdup() the name string provided by the client to avoid this problem. Cc: "10.3 10.4 10.5" <> Signed-off-by: Mario Kleiner <> Reviewed-by: Brian Paul <> (cherry picked from commit 1110113a7f0b6f9b21dd26dee8e95a021041c71c)
2015-03-26clover: Return 0 as storage size for local kernel args that are not set v2Tom Stellard1-1/+1
The storage size for local kernel args can be queried before the arguments are set by using the CL_KERNEL_LOCAL_MEM_SIZE param of clGetKernelWorkGroupInfo(). The spec says that if local kernel arguments have not been specified, then we should assume their size is 0. v2: - Implement using c++11 member initialization. Reviewed-by: Jan Vesely <> Reviewed-by: Francisco Jerez <> Cc: 10.5 10.4 <> (cherry picked from commit dfb1ae9d914b7723ef50fdd2efe811feebc045ad)
2015-03-26glsl: fix names in lower_constant_arrays_to_uniformsTapani Pälli1-3/+1
Patch changes lowering pass to use unique name for each uniform so that arrays from different stages cannot end up having same name. v2: instead of global counter, use pointer to achieve unique name (Kenneth Graunke) Signed-off-by: Tapani Pälli <> Bugzilla: Reviewed-by: Chris Forbes <> Cc: 10.5 10.4 <> (cherry picked from commit 3cf99701ba6c9e56c9126fdbb74107a31ffcbcfb)
2015-03-26i965: Set nr_params to the number of uniform components in the VS/GS path.Francisco Jerez3-15/+4
Both do_vs_prog and do_gs_prog initialize brw_stage_prog_data::nr_params to the number of uniform *vectors* required by the shader rather than the number of uniform components, contradicting the comment. This is inconsistent with what the state upload code and scalar path expect but it happens to work until Gen8 because vec4_visitor interprets it as a number of vectors on construction and later on overwrites its original value with the number of uniform components referenced by the shader. Also there's no need to add the number of samplers, they're not actually passed in as uniforms. Fixes a memory corruption issue on BDW with SIMD8 VS. Cc: "10.5" <> Reviewed-by: Kenneth Graunke <> (cherry picked from commit fd149628e142af769c1c0ec037bc297d8a3e871f) [Emil Velikov: s/DIV_ROUND_UP/CEILING/] Signed-off-by: Emil Velikov <>
2015-03-25radeonsi: increase coords array size for radeon_llvm_emit_prepare_cube_coordsMarek Olšák2-2/+2
radeon_llvm_emit_prepare_cube_coords uses coords[4] in some cases (TXB2 etc.) Discovered by Coverity. Reported by Ilia Mirkin. Cc: 10.5 10.4 <> Reviewed-by: Michel Dänzer <> (cherry picked from commit a984abdad39df2d8ceb4c46e11f4ce1344c36c86)
2015-03-25glx: Handle out-of-sequence swap completion events correctly. (v2)Mario Kleiner1-2/+7
The code for emitting INTEL_swap_events swap completion events needs to translate from 32-Bit sbc on the wire to 64-Bit sbc for the events and handle wraparound accordingly. It assumed that events would be sent by the server in the order their corresponding swap requests were emitted from the client, iow. sbc count should be always increasing. This was correct for DRI2. This is not always the case under the DRI3/Present backend, where the Present extension can execute presents and send out completion events in a different order than the submission order of the present requests, due to client code specifying targetMSC target vblank counts which are not strictly monotonically increasing. This confused the wraparound handling. This patch fixes the problem by handling 32-Bit wraparound in both directions. As long as successive swap completion events real 64-Bit sbc's don't differ by more than 2^30, this should be able to do the right thing. How this is supposed to work: awire->sbc contains the low 32-Bits of the true 64-Bit sbc of the current swap event, transmitted over the wire. glxDraw->lastEventSbc contains the low 32-Bits of the 64-Bit sbc of the most recently processed swap event. glxDraw->eventSbcWrap is a 64-Bit offset which tracks the upper 32-Bits of the current sbc. The final 64-Bit output sbc aevent->sbc is computed from the sum of awire->sbc and glxDraw->eventSbcWrap. Under DRI3/Present, swap completion events can be received slightly out of order due to non-monotic targetMsc specified by client code, e.g., present request submission: Submission sbc: 1 2 3 targetMsc: 10 11 9 Reception of completion events: Completion sbc: 3 1 2 The completion sequence 3, 1, 2 would confuse the old wraparound handling made for DRI2 as 1 < 3 --> Assumes a 32-Bit wraparound has happened when it hasn't. The client can queue multiple present requests, in the case of Mesa up to n requests for n-buffered rendering, e.g., n = 2-4 in the current Mesa GLX DRI3/Present implementation. In the case of direct Pixmap presents via xcb_present_pixmap() the number n is limited by the amount of memory available. We reasonably assume that the number of outstanding requests n is much less than 2 billion due to memory contraints and common sense. Therefore while the order of received sbc's can be a bit scrambled, successive 64-Bit sbc's won't deviate by much, a given sbc may be a few counts lower or higher than the previous received sbc. Therefore any large difference between the incoming awire->sbc and the last recorded glxDraw->lastEventSbc will be due to 32-Bit wraparound and we need to adapt glxDraw->eventSbcWrap accordingly to adjust the upper 32-Bits of the sbc. Two cases, correponding to the two if-statements in the patch: a) Previous sbc event was below the last 2^32 boundary, in the previous glxDraw->eventSbcWrap epoch, the new sbc event is in the next 2^32 epoch, therefore the low 32-Bit awire->sbc wrapped around to zero, or close to zero --> awire->sbc is apparently much lower than the glxDraw->lastEventSbc recorded for the previous epoch --> We need to increment glxDraw->eventSbcWrap by 2^32 to adjust the current epoch to be one higher than the previous one. --> Case a) also handles the old DRI2 behaviour. b) Previous sbc event was above closest 2^32 boundary, but now a late event from the previous 2^32 epoch arrives, with a true sbc that belongs to the previous 2^32 segment, so the awire->sbc of this late event has a high count close to 2^32, whereas glxDraw->lastEventSbc is closer to zero --> awire->sbc is much greater than glXDraw->lastEventSbc. --> We need to decrement glxDraw->eventSbcWrap by 2^32 to adjust the current epoch back to the previous lower epoch of this late completion event. We assume such a wraparound to a higher (a) epoch or lower (b) epoch has happened if awire->sbc and glxDraw->lastEventSbc differ by more than 2^30 counts, as such a difference can only happen on wraparound, or if somehow 2^30 present requests would be pending for a given drawable inside the server, which is rather unlikely. v2: Explain the reason for this patch and the new wraparound handling much more extensive in commit message, no code change wrt. initial version. Cc: "10.3 10.4 10.5" <> Signed-off-by: Mario Kleiner <> Reviewed-by: Michel Dänzer <> (cherry picked from commit cc5ddd584d17abd422ae4d8e83805969485740d9)
2015-03-25auxiliary/os: fix the android build - s/drm_munmap/os_munmap/Emil Velikov1-2/+2
Squash this silly typo introduced with commit c63eb5dd5ec(auxiliary/os: get the mmap/munmap wrappers working with android) Cc: "10.4 10.5" <> Signed-off-by: Emil Velikov <> Reviewed-by: Brian Paul <> (cherry picked from commit 55f0c0a29f788c5df4820e81c0cf93613ccedf5e)
2015-03-25loader: include <sys/stat.h> for non-sysfs buildsEmil Velikov1-1/+1
Required by fstat(), otherwise we'll error out due to implicit function declaration. Cc: "10.4 10.5" <> Bugzilla: Signed-off-by: Emil Velikov <> Reported-by: Vadim Rutkovsky <> Tested-by: Vadim Rutkovsky <> (cherry picked from commit 771cd266b9d00bdcf2cf7acaa3c8363c358d7478)
2015-03-25c11/threads: Use PTHREAD_MUTEX_RECURSIVE by defaultFelix Janda1-6/+1
Previously PTHREAD_MUTEX_RECURSIVE_NP had been used on linux for compatibility with old glibc. Since mesa defines __GNU_SOURCE__ on linux PTHREAD_MUTEX_RECURSIVE is also available since at least 1998. So we can unconditionally use the portable version PTHREAD_MUTEX_RECURSIVE. Cc: "10.5" <> Bugzilla: Reviewed-by: Emil Velikov <> (cherry picked from commit aead7fe2e2b6c89258f80a25299f4ec0fece2d95)
2015-03-25freedreno: update generated headersRob Clark5-6/+6
Fix a3xx texture layer-size. Signed-off-by: Rob Clark <> Cc: "10.4 10.5" <> (cherry picked from commit e92bc6b38e90339a394e95a562bcce35c3ee9696)
2015-03-25freedreno: fix slice pitch calculationsIlia Mirkin1-1/+1
For example if width were 65, the first slice would get 96 while the second would get 32. However the hardware appears to expect the second pitch to be 64, based on halving the 96 (and aligning up to 32). This fixes texelFetch piglit tests on a3xx below a certain size. Going higher they break again, but most likely due to unrelated reasons. Signed-off-by: Ilia Mirkin <> Cc: "10.4 10.5" <> Reviewed-by: Rob Clark <> (cherry picked from commit 620e29b74821fd75b24495ab2bfddea53fc75350)
2015-03-25freedreno/a3xx: use the same layer size for all slicesIlia Mirkin1-1/+8
We only program in one layer size per texture, so that means that all levels must share one size. This makes the piglit test bin/texelFetch fs sampler2DArray have the same breakage as its non-array version instead of being completely off, and makes bin/ext_texture_array-gen-mipmap start passing. Signed-off-by: Ilia Mirkin <> Cc: "10.4 10.5" <> Reviewed-by: Rob Clark <> (cherry picked from commit 89b26d5a360ebde11a69f2cdefa66e4d6a2a13fd)
2015-03-25glsl: optimize (0 cmp x + y) into (-x cmp y).Samuel Iglesias Gonsalvez1-3/+12
The optimization done by commit 34ec1a24d did not take it into account. Fixes: dEQP-GLES3.functional.shaders.random.all_features.fragment.20 Signed-off-by: Samuel Iglesias Gonsalvez <> Reviewed-by: Ian Romanick <> Reviewed-by: Matt Turner <> Cc: "10.4 10.5" <> (cherry picked from commit b43bbfa90ace596c8b2e0b3954a5f69924726c59)
2015-03-25st/egl: don't ship the dri2.c link at the tarballEmil Velikov3-3/+2
During 'make dist' the path of the symbolic link (x11/dri2.c) becomes too long, and tar converts it to hard one. To make it more complicated on Haiku tar errors out (due to lack of hardlink support) rather than falling back to the next best thing. So remove the symlink from git, and disable the scons x11_drm egl code. The offending code is not build with either automake nor android. Brian, Jose would you have any objections against this ? I was playing around to get the symlink resolved, although I could not get the dependency tracking resolved, so env.Command() was never executed :-\ Bugzilla: Cc: Cc: Alexander von Gluck IV <> Cc: Brian Paul <> Acked-by: Jose Fonseca <> Signed-off-by: Emil Velikov <>
2015-03-25automake: add missing egl files to the tarballEmil Velikov2-1/+6
Namely the Haiku EGL driver backend and the SConscript for the dri2 EGL driver backend. Cc: Alexander von Gluck IV <> Cc: Signed-off-by: Emil Velikov <> (cherry picked from commit 5dc573e5de0eb49bc8622558789ebc4adf03926c)
2015-03-13docs: Add sha256 sums for the 10.5.1 releaseEmil Velikov1-1/+2
Signed-off-by: Emil Velikov <>
2015-03-13Add release notes for the 10.5.1 releasemesa-10.5.1Emil Velikov1-0/+216
Signed-off-by: Emil Velikov <>
2015-03-13Update version to 10.5.1Emil Velikov1-1/+1
Signed-off-by: Emil Velikov <>
2015-03-12freedreno/ir3: fix failed assert in groupingRob Clark1-27/+44
Turns out there are scenarios where we need to insert mov's in "front" of an input. Triggered by shaders like: VERT DCL IN[0] DCL IN[1] DCL OUT[0], POSITION DCL OUT[1], GENERIC[9] DCL SAMP[0] DCL TEMP[0], LOCAL 0: MOV TEMP[0].xy, IN[1].xyyy 1: MOV TEMP[0].w, IN[1].wwww 2: TXF TEMP[0], TEMP[0], SAMP[0], 1D_ARRAY 3: MOV OUT[1], TEMP[0] 4: MOV OUT[0], IN[0] 5: END Signed-off-by: Rob Clark <> (cherry picked from commit 27648efa2070e8db111908314d8b924d3717dbb0)
2015-03-12freedreno/ir3: handle flat bypass for a4xxRob Clark8-5/+99
We may not need this for later a4xx patchlevels, but we do at least need this for patchlevel 0. Bypass bary.f for fetching varyings when flat shading is needed (rather than configure via cmdstream). This requires a special dummy bary.f w/ (ei) flag to signal to scheduler when all varyings are consumed. And requires shader variants based on rasterizer flatshade state to handle TGSI_INTERPOLATE_COLOR. Signed-off-by: Rob Clark <> (cherry picked from commit e9f2abe349886ae5423c7c31d201e7d587a3695a)
2015-03-12freedreno/ir3: add support for memory (cat6) instructionsRob Clark3-1/+8
Scheduled basically the same as texture (cat5) instructions, using (sy) flag for synchronization. Signed-off-by: Rob Clark <> (cherry picked from commit 9d732d3125e1b39788a642a5723aeb54cb1983f3)
2015-03-12freedreno/ir3: fix up cat6 instruction encodingsRob Clark3-139/+121
I think there is at least one more sub-encoding, but these two should be enough to cover the common load/store instructions. Signed-off-by: Rob Clark <> (cherry picked from commit 20b50a071271e2caf8a4c3d4fd72f877af8a18d9)
2015-03-12freedreno/a4xx: aniso filteringRob Clark1-4/+6
Signed-off-by: Rob Clark <> (cherry picked from commit dd70e786747f7e4800f4bba245373c5ffa3baeee)
2015-03-12freedreno: update generated headersRob Clark5-5/+20
Signed-off-by: Rob Clark <> (cherry picked from commit c70097ae8655d84a900cb27d165ca59d66411e29)
2015-03-12freedreno/a4xx: set PC_PRIM_VTX_CNTL.VAROUT properlyRob Clark1-1/+6
Fixes xonotic, some webgl stuff, and really pretty much anything with more than 4 varyings. Signed-off-by: Rob Clark <> (cherry picked from commit 51e335742e55d6725fd5c4558158769a32f70f22)
2015-03-12freedreno: update generated headersRob Clark7-16/+45
Signed-off-by: Rob Clark <> (cherry picked from commit fb1301e40abbac1de973563cacd2c7f31aa6bb4f) Conflicts: src/gallium/drivers/freedreno/a3xx/a3xx.xml.h
2015-03-12freedreno/a4xx: bit of cleanupRob Clark4-33/+27
Signed-off-by: Rob Clark <> (cherry picked from commit bdf023482a6fd07adef090fb66a4aaaac22810fc)
2015-03-12freedreno/a2xx: fix increment in assertRob Clark1-1/+2
Bugzilla: Signed-off-by: Rob Clark <> (cherry picked from commit 68552266535747bad1eff34d856c43158398b9bf)
2015-03-11i965: Fix out-of-bounds accesses into pull_constant_loc arrayIago Toral Quiroga1-2/+7
The piglit test glsl-fs-uniform-array-loop-unroll.shader_test was designed to do an out of bounds access into an uniform array to make sure that we handle that situation gracefully inside the driver, however, as Ken describes in bug 79202, Valgrind reports that this is leading to an out-of-bounds access in fs_visitor::demote_pull_constants(). Before accessing the pull_constant_loc array we should make sure that the uniform we are trying to access is valid. Bugzilla: Reviewed-by: Matt Turner <> (cherry picked from commit 6ac1bc90c4a7a6f32901a9782e14b090f6fe5270) Nominated-by: Matt Turner <>
2015-03-11i965/fs: Don't issue FB writes for bound but unwritten color targets.Kenneth Graunke1-3/+9
We used to loop over all color attachments, and emit FB writes for each one, even if the shader didn't write to a corresponding output variable. Those color attachments would be filled with garbage (undefined values). Football Manager binds a framebuffer with 4 color attachments, but draws to it using a shader that only writes to gl_FragData[0..2]. This meant that color attachment 3 would be filled with garbage, resulting in rendering artifacts. Now we skip writing to it, fixing rendering. Writes to gl_FragColor initialize outputs[0..nr_color_regions-1] to GRFs, while writes to gl_FragData[i] initialize outputs[i]. Thanks to Jason Ekstrand for tracking this down. Bugzilla: Signed-off-by: Kenneth Graunke <> Reviewed-by: Jason Ekstrand <> Cc: (cherry picked from commit e95969cd9548033250ba12f2adf11740319b41e7) Conflicts: src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
2015-03-11i965/fs: Make emit_shader_time_end() insert before EOT.Kenneth Graunke2-23/+18
Previously, we emitted the shader-time epilogue from emit_fb_writes(), during the middle of looping through color regions (or emit_urb_writes for the VS). This is duplicated several times and rather awkward. I need to fix a bug in our FB write handling, and it will be a lot easier if we move emit_shader_time_end() out of there. Now, we simply emit FB writes/URB writes, and subsequently have emit_shader_time_end() insert instructions before the final SEND with EOT. Not only is this simpler, it's actually a slight improvement: we now include the MOVs to set up the final FB write payload in our shader-time measurements. Note that INTEL_DEBUG=shader_time only exists on Gen7+, and uses send-from-GRF. (In the past, we might have hit trouble where both attempt to use MRFs for messages; that's not a problem now.) v2: Rebase on v3 of the previous patch and other shader_time fixes. Signed-off-by: Kenneth Graunke <> Reviewed-by: Topi Pohjolainen <> [v1] Acked-by: Matt Turner <> Cc: (cherry picked from commit 4ebeb71573ad44f7657810dc5dd2c9030e3e63db) Conflicts: src/mesa/drivers/dri/i965/brw_fs.cpp
2015-03-11i965/fs: Make get_timestamp() pass back the MOV rather than emitting it.Kenneth Graunke2-5/+16
This makes another part of the INTEL_DEBUG=shader_time code emittable at arbitrary locations, rather than just at the end of the instruction stream. v2: Don't lose smear! Caught by Topi Pohjolainen. v3: Don't set smear on the destination of the MOV. Thanks Topi! Signed-off-by: Kenneth Graunke <> Reviewed-by: Matt Turner <> Cc: (cherry picked from commit e43af8d09f919d02b5ac0810c1c0f1783cbef6ef)
2015-03-11i965/fs: Make emit_shader_time_write return rather than emit.Kenneth Graunke2-10/+8
Instead of emit_shader_time_write, we now do emit(SHADER_TIME_ADD(...)). The advantage is that we can also insert a shader time write at an arbitrary location in the instruction stream, rather than being restricted to emitting at the end. Signed-off-by: Kenneth Graunke <> Reviewed-by: Topi Pohjolainen <> Reviewed-by: Matt Turner <> Cc: (cherry picked from commit bea854c7f33cc10b8292f931f114afc4f88a8dd4)
2015-03-11i965/fs: Set smear on shader_time diff register.Kenneth Graunke1-0/+1
The ADD(diff, diff, fs_reg(-2u)) instruction reads diff, which is a width 1 register. We need to read it as <0,1,0> with a subreg of 0, which is what smear accomplishes. Fixes assertion: brw_eu_emit.c:285: validate_reg: Assertion `hstride == 0' failed. Bugzilla: Signed-off-by: Kenneth Graunke <> Reviewed-by: Matt Turner <> Cc: (cherry picked from commit f1adc45dbe649cdd4538fb96f6d2a27328bbfba1) Conflicts: src/mesa/drivers/dri/i965/brw_fs.cpp
2015-03-11i965/fs: Set force_writemask_all on shader_time instructions.Kenneth Graunke1-2/+7
These computations don't have anything to do with the currently executing channels, so they should use force_writemask_all. This fixes assert failures. Bugzilla: Signed-off-by: Kenneth Graunke <> Reviewed-by: Matt Turner <> Cc: (cherry picked from commit ef9cc7d0c176669c03130abf576f2b700be39514) Conflicts: src/mesa/drivers/dri/i965/brw_fs.cpp
2015-03-11r300g: fix sRGB->sRGB blitsMarek Olšák1-0/+9
Cc: 10.5 10.4 <> (cherry picked from commit c939231e7223510408a446400ad23b8b5ce2922e)
2015-03-11r300g: fix a crash when resolving into an sRGB textureMarek Olšák1-3/+5
Cc: 10.5 10.4 <> (cherry picked from commit 9953586af2254f83a610d4cd284f52f37fa18b98)
2015-03-11r300g: fix RGTC1 and LATC1 SNORM formatsMarek Olšák2-31/+17
Cc: 10.5 10.4 <> (cherry picked from commit 74a757f92f7377f59c0feb7f84c7518f9a167631)
2015-03-11r300g: Fix the ATI1N swizzle (RGTC1 and LATC1)Stefan Dösinger1-1/+3
This fixes the GL_COMPRESSED_RED_RGTC1 part of piglit's rgtc-teximage-01 test as well as the precision part of Wine's 3dc format test (fd.o bug 89156). The Z component seems to contain a lower precision version of the result, probably a temporary value from the decompression computation. The Y and W component contain different data that depends on the input values as well, but I could not make sense of them (Not that I tried very hard). GL_COMPRESSED_SIGNED_RED_RGTC1 still seems to have precision problems in piglit, and both formats are affected by a compiler bug if they're sampled by the shader with a swizzle other than .xyzw. Wine uses .xxxx, which returns random garbage. Bugzilla: Signed-off-by: Marek Olšák <> Cc: 10.5 10.4 <> (cherry picked from commit f710b99071fe4e3c2ee88cdcb6bb5c10298e014e)
2015-03-11freedreno/ir3: fix silly typo for binning pass shadersRob Clark1-1/+1
Was resulting in gl_PointSize write being optimized out, causing particle system type shaders to hang if hw binning enabled. Fixes neverball, OGLES2ParticleSystem, etc. Signed-off-by: Rob Clark <> (cherry picked from commit 60096ed906e5ebfdce41024c7af69f03b96dbe82)
2015-03-11freedreno/ir3: get the # of miplevels from getinfoIlia Mirkin1-0/+20
This fixes ARB_texture_query_levels to actually return the desired value. Signed-off-by: Ilia Mirkin <> Reviewed-by: Rob Clark <> Cc: "10.4 10.5" <> (cherry picked from commit cb3eb43ad690a7355429ba8dcd40120646c55b9c)
2015-03-11freedreno/ir3: fix array count returned by TXQIlia Mirkin1-2/+42
Signed-off-by: Ilia Mirkin <> Reviewed-by: Rob Clark <> Cc: "10.4 10.5" <> (cherry picked from commit 8ac957a51c67fc095db9539df6482b9533b1d05c)
2015-03-11freedreno: move fb state copy after checking for size changeIlia Mirkin1-2/+2
Fixes: 1f3ca56b ("freedreno: use util_copy_framebuffer_state()") Signed-off-by: Ilia Mirkin <> Reviewed-by: Rob Clark <> Cc: "10.4 10.5" <> (cherry picked from commit f3dfe6513c26d1ce50b3b0fc830d4d8ff7f6b922)
2015-03-11glsl: Mark array access when copying to a temporary for the ?: operator.Kenneth Graunke1-0/+6
Piglit's spec/glsl-1.20/compiler/structure-and-array-operations/ array-selection.vert test contains the following code: gl_Position = (pick_from_a_or_b ? a : b)[i]; where "a" and "b" are uniform vec4[2] variables. ast_to_hir creates a temporary vec4[2] variable, conditional_tmp, and generates an if-block to copy one or the other: (declare (temporary) (array vec4 2) conditional_tmp) (if (var_ref pick_from_a_or_b) ((assign () (var_ref conditional_tmp) (var_ref a))) ((assign () (var_ref conditional_tmp) (var_ref b)))) However, we failed to update max_array_access for "a" and "b", so it remained 0 - here, the whole array is being accessed. At link time, update_array_sizes() used this bogus information to change the types of "a" and "b" to vec4[1]. We then had assignments from a vec4[1] to a vec4[2], which is highly illegal. This tripped assertions in nir_split_var_copies with scalar VS. Signed-off-by: Kenneth Graunke <> Reviewed-by: Jason Ekstrand <> Cc: (cherry picked from commit 9f1e250e77ebd9255bbd9a83bd68c9e4068c2aab)
2015-03-11meta: Fix the y offset for 1D_ARRAY in _mesa_meta_pbo_TexSubImageNeil Roberts1-0/+8
The yoffset needs to be interpreted as a slice offset for 1D array textures. This patch implements that by moving the yoffset into zoffset similar to how it moves the height into depth. Reviewed-by: Jason Ekstrand <> Cc: "10.5" <> (cherry picked from commit 7286a6899176a8b26aa794097288eff941f5178c)