- Apr 12, 2015
-
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Otherwise the scons build will fail. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89905 Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
- Apr 09, 2015
-
-
Emil Velikov authored
In case of using a distribution tarball (or a dirty git tree) one can have the generated sources locally. Make configure.ac error out otherwise, to alert that about the unmet requirement(s) of python/mako. v2: Check only for a single file for each dependency. Suggested-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit 4008975e)
-
- Apr 08, 2015
-
-
Increase the device info .urb.size for CHV to match the default URB size (192kB). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 970dc236)
-
When nvc0_push_vbo calls nouveau_scratch_done it does not mean scratch buffers can be freed immediately. It means "when hardware advances to this place in the command stream the scratch buffers can be freed". To fix it, just postpone scratch runout destruction after current fence is signalled. The bug existed for a very long time. Nobody noticed, because "scratch runout" code path is rarely executed. Fixes hang at the very beginning of first mission in "Serious Sam 3" on nve7/gk107. It manifested as: nouveau E[ PFIFO][0000:01:00.0] read fault at 0x000a9e0000 [PTE] from GR/GPC0/PE_2 on channel 0x007f853000 [Sam3[17056]] Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit f9e22955)
-
We limit y-tiling to 0x20 when depth is involved. However the function is run for each miplevel, and the hardware expects miplevel 0 to have the highest tiling settings. Perform the y-tiling limit on all levels of a 3d texture, not just the ones that have depth. Fixes: texelFetch fs sampler3D 98x129x1-98x129x9 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Tested-by: Nick Tenney <nick.tenney@gmail.com> # GT216 Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> (cherry picked from commit ae720c66)
-
Haswell hardware seems to ignore Render Stream Select bits from 3DSTATE_STREAMOUT packet when the SOL stage is disabled even if the PRM says otherwise. Because of this, all primitives are sent down the pipeline for rasterization, which is wrong. If SOL is enabled, Render Stream Select is honored and primitives bound to non-zero streams are discarded after stream output. Since the only purpose of primives sent to non-zero streams is to be recorded by transform feedback, we can simply discard all geometry bound to non-zero streams then transform feedback is disabled to prevent it from ever reaching the rasterization stage. Notice that this patch introduces a small change in the behavior we get when a geometry shader emits more vertices than the maximum declared: before, a vertex that was emitted to a non-zero stream when TF was disabled would still count for the purposes of checking that we don't exceed the maximum number of output vertices declared by the shader. With this change, these vertices are completely ignored and won't increase the output vertex count, making more room for other (hopefully more useful) vertices. Fixes piglit test arb_gpu_shader5-emitstreamvertex_nodraw on Haswell and Broadwell. v2 (Ken): Drop is_haswell check in favor of doing this unconditionally. Broadwell needs the workaround as well, and it doesn't hurt to do it in general. Also tweak comments - the Haswell PRM does actually mention this ("Command Reference: Instructions" page 797). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83962 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit 2042a2f9)
-
Fixes Piglit's arb_gpu_shader5-xfb-streams-without-invocations. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit f368d0fa)
-
Jordan added this in commit 741782b5 for Gen7 platforms. I missed this when adding the Broadwell code. Fixes Piglit's spec/arb_gpu_shader5/invocation-id-{basic,in-separate-gs} with MESA_EXTENSION_OVERRIDE=GL_ARB_gpu_shader5 set. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit f9e5dc0a)
-
Commit 1a170980 started writing to q->data[4]/[5] but kept the per-query space at 16, which meant that in some cases we would write past the end of the buffer. Rotate by 32, like nvc0 does. This ensures that we always have 32 bytes in front of us, and the data writes will go within the allocated space. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89679 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Tested-by: Nick Tenney <nick.tenney@gmail.com> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> (cherry picked from commit ba353935)
-
Emil Velikov authored
This will allow us to finally remove python from the build time dependencies list. Considering that you're building from a release tarball of course :-) Cc: Bernd Kuhls <bernd.kuhls@t-online.de> Reported-by: Bernd Kuhls <bernd.kuhls@t-online.de> Cc: "10.5" <mesa-stable@lists.freedesktop.org> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit a665b9b3)
-
v2: - Don't use _errs map Cc: 10.5 10.4 <mesa-stable@lists.freedesktop.org> Reviewed-by: Francisco Jerez <currojerez@riseup.net> (cherry picked from commit fda75580)
-
Fixes a crash in genymotion with several threads compiling shaders concurrently. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89746 Cc: 10.5 <mesa-stable@lists.freedesktop.org> Reviewed-by: Tom Stellard <thomas.stellard@amd.com> (cherry picked from commit d64adc3a) Conflicts: src/gallium/drivers/radeonsi/si_shader.c
-
The division is probably a holdover from the days when the fixed point inline functions generated by headergen were broken. Also reduce the maximum point size to 4092 (vs 4096), which is what the blob does. Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit 7fc5da8b)
-
The SZ2 field contains the layer size of a lower miplevel. It only contains 4 bits, which limits the maximum layer size it can describe. In situations where the next miplevel would be too big, the hardware appears to keep minifying the size until it hits one of that size. Unfortunately the hardware's ideas about sizes can differ from freedreno's which can still lead to issues. Minimize those by stopping to minify as soon as possible. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 738c8319)
-
Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit 58030a8f)
-
Multiply operations can have a post-factor on them, which other ops don't support. Only perform the peephole optimizations when there is no post-factor involved. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89758 Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit 49b86007)
-
Fixes the recently-sent gl-2.0-vertex-const-attr piglit test. Makes sure to revalidate arrays when only the current attribute has been updated via glVertexAttrib*. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89754 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 9d1b5feb)
-
Don't propagate ARRAYs This should fix: https://bugs.freedesktop.org/show_bug.cgi?id=89759 v2: just specify arrays so we get input propagation Signed-off-by: Dave Airlie <airlied@redhat.com> Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit 91e35334)
-
- Mar 28, 2015
-
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
- Mar 26, 2015
-
-
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 <siglesias@igalia.com> Reviewed-by: Kai Wasserbäch <kai@dev.carbon-project.org> (cherry picked from commit ced94253) Squashed with commit configure.ac: move AC_MSG_RESULT reporting back into the m4 macro The one who does AC_MSG_CHECKING should provide the AC_MSG_RESULT. Fixes: ced94253 (configure: Introduce new output variable to ax_check_python_mako_module.m4" Cc: "10.5" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89328 Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com> (cherry picked from commit 248eb54e)
-
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 <anuj.phogat@gmail.com> Khronos Bug#12957 Cc: "10.5" <mesa-stable@lists.freedesktop.org> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> (cherry picked from commit d8208312)
-
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" <mesa-stable@lists.freedesktop.org> Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit 1110113a)
-
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 <jan.vesely@rutgers.edu> Reviewed-by: Francisco Jerez <currojerez@riseup.net> Cc: 10.5 10.4 <mesa-stable@lists.freedesktop.org> (cherry picked from commit dfb1ae9d)
-
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 <tapani.palli@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89590 Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> Cc: 10.5 10.4 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 3cf99701)
-
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" <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit fd149628) [Emil Velikov: s/DIV_ROUND_UP/CEILING/] Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
- Mar 25, 2015
-
-
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 <mesa-stable@lists.freedesktop.org> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (cherry picked from commit a984abda)
-
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" <mesa-stable@lists.freedesktop.org> Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (cherry picked from commit cc5ddd58)
-
Emil Velikov authored
Squash this silly typo introduced with commit c63eb5dd(auxiliary/os: get the mmap/munmap wrappers working with android) Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit 55f0c0a2)
-
Emil Velikov authored
Required by fstat(), otherwise we'll error out due to implicit function declaration. Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89530 Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reported-by: Vadim Rutkovsky <vrutkovs@redhat.com> Tested-by: Vadim Rutkovsky <vrutkovs@redhat.com> (cherry picked from commit 771cd266)
-
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" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88534 Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit aead7fe2)
-
Fix a3xx texture layer-size. Signed-off-by: Rob Clark <robclark@freedesktop.org> Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> (cherry picked from commit e92bc6b3)
-
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 <imirkin@alum.mit.edu> Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> Reviewed-by: Rob Clark <robclark@freedesktop.org> (cherry picked from commit 620e29b7)
-
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 <imirkin@alum.mit.edu> Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> Reviewed-by: Rob Clark <robclark@freedesktop.org> (cherry picked from commit 89b26d5a)
-
The optimization done by commit 34ec1a24 did not take it into account. Fixes: dEQP-GLES3.functional.shaders.random.all_features.fragment.20 Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> (cherry picked from commit b43bbfa9)
-
Emil Velikov authored
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: https://bugs.freedesktop.org/show_bug.cgi?id=89680 Cc: mesa-stable@lists.freedesktop.org Cc: Alexander von Gluck IV <kallisti5@unixzen.com> Cc: Brian Paul <brianp@vmware.com> Acked-by: Jose Fonseca <jfonseca@vmware.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-