- Jun 07, 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>
-
- Jun 03, 2015
-
-
Clearing can happen at a time when various state objects are incoherent and not ready for a draw. Some of the validation functions don't handle this well, so only flush the framebuffer state. This has the advantage of also not doing extra work. This works around some crashes that can happen when clearing. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> (cherry picked from commit aba33925)
-
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89131 Cc: 10.6 10.5 <mesa-stable@lists.freedesktop.org> Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit 25e9ae2b)
-
Starting with GEN8, there is documentation that the multisample state command must be emitted before the 3DSTATE_WM_HZ_OP command any time the multisample count changes. The 3DSTATE_WM_HZ_OP packet gets emitted as a result of a intel_hix_exec(), which is called upon a fast clear and/or a resolve. This can happen before the state atoms are checked, and so the multisample state must be put directly in the function. v1: - In v0, I was always emitting the command, but Ken came up with the condition to determine whether or not the sample count actually changed. - Ken's recommendation was to set brw->num_multisamples after emitting 3DSTATE_MULTISAMPLE. This doesn't work. I put my best guess as to why in the XXX (it was causing 7 regressions on BDW). v2: Flag NEW_MULTISAMPLE state. As Ken found, in state upload we check for the multisample change to determine whether or not to emit certain packets. Since the hiz code doesn't actually care about the number of multisamples, set the flag and let the later code take care of it. Jenkins results: http://otc-mesa-ci.jf.intel.com/view/dev/job/bwidawsk/136/ Fixes around 200 piglit tests on SKL. I'm somewhat surprised that it seems to have no impact on BDW as the restriction is needed there as well. Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Neil Roberts <neil@linux.intel.com> (v0) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v2) (cherry picked from commit e2d84d99)
-
Emil Velikov authored
The 10.5 codebase uses a compat/wrapper implementation for the string class. As such it already explicitly includes the string header. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
The problem is that the EDGEFLAG has to be toggled at vertex submission time. This can be done from either the draw or the regular paths. Avoid falling back to draw just because there's an edgeflag. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 3ec18152)
-
Commit 8acaf862 switched things over to use TEXCOORD instead of GENERIC, but did not update the nv30 swtnl draw paths. This teaches the draw logic about TEXCOORD. Among other things, this fixes a crash in demos/arbocclude when using swtnl. Curiously enough, the point-sprite piglit works without this. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 25be7046)
-
These are only used once per draw, so it makes sense to keep them in GART. Also take this opportunity to modernize the buffer mapping API usage. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit c3d36a2e)
-
Instead of always having it in the data, let the bo placement decide it. This fixes glxgears with swtnl forced on. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit fdad7dfb)
-
The map = assignment was missing. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 36004398)
-
This makes piglit mixing-clip-distance-and-clip-vertex-disallowed have 0 definitely lost blocks with valgrind. (Same non-0 number of possibly lost blocks though.) Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 5646f0f1)
-
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit bb973723)
-
This fixes glxgears with NV30_SWTNL=1 forced on. Probably fixes a bunch of other situations where we fall back to the swtnl path. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 14781637)
-
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 89585edf)
-
nv30_validate_clip depends on the rasterizer state. Also we should upload all the new clip planes on change since next time the plane data won't have changed, but the enables might. This fixes fixed-clip-enables and vs-clip-vertex-enables shader tests. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 7518fc3c)
-
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 9870ed05)
-
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 605ce36d)
-
There can be scenarios where the "indirect" arg of a PFETCH becomes known, and so the code will attempt to propagate it. Use this opportunity to just fold it into the first argument, and prevent the load propagation pass from touching PFETCH further. This fixes gs-input-array-vec4-index-rd.shader_test and vs-output-array-vec4-index-wr-before-gs.shader_test on nvc0 at least. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit fa7f9f12)
-
The 1024 is already reported everywhere, not sure where this 0x1ff came from. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 921917c8)
-
We build the entire message in the generator so all the MRF writes are implied. Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit 6ca67f62)
-
We forgot to convert to VFETCH in case of indirect access. Fix that. This avoids crashes on the new gs-input-array-vec4-index-rd and vs-output-array-vec4-index-wr-before-gs but they still fail. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 21730184)
-
When we get something like IN[ADDR[0].x+5], we will now guess that we should look at IN[5] for the "base" information. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 0bab3962)
-
In the case of a compare, the destination might be a predicate, but we still want to flush denorms. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit d1eea18a)
-
Emil Velikov authored
A nomination unadorned with a specific version is now interpreted as being aimed at the 10.6 branch, which was recently opened. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
- May 24, 2015
-
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
- May 23, 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>
-
- May 20, 2015
-
-
Emil Velikov authored
Gallium equivalent of commit 06ff751f(darwin: Fix install name of libOSMesa) Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit 36438f0d)
-
Passing -module to glibtool causes the resulting library to be called libSomething.so rather than libSomething.dylib on darwin. Regardless if libOSMesa is a library or a module, it has been used as the former for quite some time. Update the build to reflect that and resolve the naming issue. Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com> [Emil Velikov: Tweak the commit message.] Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit 06ff751f)
-
Fixes regression from commit 64b1dc44 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90147 Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com> Reviewed-by: Brian Paul <brianp@vmware.com> CC: Emil Velikov <emil.l.velikov@gmail.com> CC: jon.turney@dronecode.org.uk CC: ionic@macports.org (cherry picked from commit 5b2d3480) Nominated-by: Emil Velikov <emil.l.velikov@gmail.com> Squashed with commit swrast: Build fix for Solaris Fixes regression from commit 5b2d3480 Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com> (cherry picked from commit 31cd2d75)
-
Emil Velikov authored
The extension requires that the address of the core functions should be available via eglGetProcAddress. Currently the list is guarded by _EGL_GET_CORE_ADDRESSES, which was only set for the scons (windows) build. Unconditionally enable it for all the builds (automake, android and haiku) considering that the extension is not platform specific and is always enabled. v2: Drop the _EGL_GET_CORE_ADDRESSES macro altogether. Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit 448e01b2) Conflicts: src/egl/main/eglapi.c
-
This was causing corruption with hw binning on a306. Unlikely that it is a306 specific, but rather the smaller gmem size resulted in different tile configuration which was triggering the bug at certain resolutions. Signed-off-by: Rob Clark <robclark@freedesktop.org> Cc: "10.4" and "10.5" and "10.6" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 4925c356)
-
Whitelist adreno 306 (as found in msm8916/apq8016). Works pretty much out of the box, although the smaller GMEM size requires more tiles to fit 1920x1080, so bump up the max # of tiles as well. Since it is just whitelist + trivial change, it makes sense to land on all the active release branches. Note that a305c ends up with gpu-id "306", hence a306 ends up with gpu-id of "307". Apparently that is what happens when you let the marketing dept name things. Cc: "10.4" and "10.5" and "10.6" <mesa-stable@lists.freedesktop.org> Signed-off-by: Rob Clark <robclark@freedesktop.org> (cherry picked from commit fcc7d632)
-
Signed-off-by: Fredrik Höglund <fredrik@kde.org> Reviewed-by: Fredrik Höglund <fredrik@kde.org> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> (cherry picked from commit b4368ac0)
-
gl*FramebufferTexture should generate GL_INVALID_VALUE when the texture doesn't exist. [Fredrik: Split this change out from the next commit] Signed-off-by: Fredrik Höglund <fredrik@kde.org> Reviewed-by: Fredrik Höglund <fredrik@kde.org> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 69bdc9dc)
-
Signed-off-by: Fredrik Höglund <fredrik@kde.org> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 8ba7ad8a)
-
Generate GL_INVALID_OPERATION if the texture hasn't been created. Signed-off-by: Fredrik Höglund <fredrik@kde.org> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org> (cherry picked from commit f9f5c822)
-
This problem can easily be reproduced with a number of ARB_shader_image_load_store piglit tests, which use a buffer object as PBO for a pixel transfer operation and later on bind the same buffer to the pipeline as shader image -- The problem is not exclusive to images though, and is likely to affect other kinds of buffer objects that can be bound to the 3D pipeline, including vertex, index, uniform, atomic counter buffers, etc. CC: 10.5 <mesa-stable@lists.freedesktop.org> Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> (cherry picked from commit d247615e)
-
This aligns it to work similarly to nv50. However there's no library code there, so the whole thing can be freed. Here we end up with an allocated node that's not attached to a specific program. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86792 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: mesa-stable@lists.freedesktop.org (cherry picked from commit d06ce2f1)
-