On Fri, 2016-12-09 at 16:49 +1100, Timothy Arceri wrote:
> Unless an if statement contains nested returns we can simply add
> any following instructions to the branch without the return.
> ---
> src/compiler/nir/nir_lower_returns.c | 36
> ++--
> 1 file changed, 30
On Thursday, December 8, 2016 9:17:04 PM PST Jason Ekstrand wrote:
> On Thu, Dec 8, 2016 at 8:41 PM, Roland Scheidegger
> wrote:
>
> > I'm wondering, isn't that actually a problem of the test, that is it
> > can't actually expect reasonable results with such input values?
> > Since within the sha
When 'evict_random_item' attempts to remove cache content to make more
space, it may try to remove from new cache directory it just created
which only has '.tmp' content at this phase and not proper cache files,
this will cause eviction to fail and 'test_put_and_get' subtest
assumptions about cache
Unless an if statement contains nested returns we can simply add
any following instructions to the branch without the return.
---
src/compiler/nir/nir_lower_returns.c | 36 ++--
1 file changed, 30 insertions(+), 6 deletions(-)
diff --git a/src/compiler/nir/nir_lowe
total instructions in shared programs: 8673389 -> 8673371 (-0.00%)
instructions in affected programs: 558 -> 540 (-3.23%)
helped: 2
HURT: 0
total cycles in shared programs: 73195178 -> 73195104 (-0.00%)
cycles in affected programs: 45680 -> 45606 (-0.16%)
helped: 2
HURT: 1
---
src/mesa/drivers/dr
On Thu, Dec 8, 2016 at 8:41 PM, Roland Scheidegger
wrote:
> I'm wondering, isn't that actually a problem of the test, that is it
> can't actually expect reasonable results with such input values?
> Since within the shader languages those functions which are composed of
> multiple other functions
I'm wondering, isn't that actually a problem of the test, that is it
can't actually expect reasonable results with such input values?
Since within the shader languages those functions which are composed of
multiple other functions are usually allowed to basically accumulate all
the errors of said f
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Dec 8, 2016, at 8:21 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Large points become pairs of triangles when rasterized, so we must feed
it three clip distances, one for each vertex.
The clip distance is not subject to spr
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Dec 8, 2016, at 8:21 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Clip distances need to be perspective-divided. This fixes all the
interpolation-*-{distance,vertex} piglits.
Signed-off-by: Ilia Mirkin mailto:imir...@alum.m
On Tuesday, December 6, 2016 5:34:02 PM PST Timothy Arceri wrote:
> This is a step towards using NIR optimisations over GLSL IR
> optimisations. Delaying adding built-in uniforms until after
> we convert to NIR gives it a chance to optimise them away.
>
> V2: move the new code back to brw_link_sha
On 07/12/16 07:16 PM, Nicolai Hähnle wrote:
> On 07.12.2016 08:50, Michel Dänzer wrote:
>> On 06/12/16 10:24 PM, Marek Olšák wrote:
>>> On Mon, Dec 5, 2016 at 10:05 AM, Michel Dänzer
>>> wrote:
On 03/12/16 05:38 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> This fixes random rad
Large points become pairs of triangles when rasterized, so we must feed
it three clip distances, one for each vertex.
The clip distance is not subject to sprite coord replacement, so there's
no interpolation of it. We just take its value and put it in the "z"
component of the barycentric-ready pla
Clip distances need to be perspective-divided. This fixes all the
interpolation-*-{distance,vertex} piglits.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/swr/rasterizer/core/binner.cpp | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/sw
On Thursday, December 8, 2016 5:41:02 PM PST Haixia Shi wrote:
> Clamp input scalar value to range [-10, +10] to avoid precision problems
> when the absolute value of input is too large.
>
> Fixes dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.* test
> failures.
>
> v2: added more
Sent from my iPad
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Clamp input scalar value to range [-10, +10] to avoid precision problems
when the absolute value of input is too large.
Fixes dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.* test
failures.
v2: added more explanation in the comment.
v3: fixed a typo in the comment.
Signed-off-by:
Clamp input scalar value to range [-10, +10] to avoid precision problems
when the absolute value of input is too large.
Fixes dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.* test
failures.
v2: added more explanation in the comment.
Signed-off-by: Haixia Shi
Cc: Jason Ekstrand ,
On Thu, Dec 8, 2016 at 5:03 PM, Haixia Shi wrote:
> Clamp input scalar value to range [-10, +10] to avoid precision problems
> when the absolute value of input is too large.
>
> Fixes dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.*
> test
> failures.
>
> Signed-off-by: Haixia Shi
BTW, the subject prefix thing goes for all your patches. Have a look
at other patches that touched these files for inspiration.
On Thu, Dec 8, 2016 at 8:27 PM, Ilia Mirkin wrote:
> Usually the subject prefix here would just be "mesa". Sometimes people
> might put "mesa/main". I don't think the "a
Reviewed-by: Ilia Mirkin
On Thu, Dec 8, 2016 at 7:26 AM, Lionel Landwerlin
wrote:
> Signed-off-by: Lionel Landwerlin
> ---
> docs/relnotes/13.1.0.html | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/docs/relnotes/13.1.0.html b/docs/relnotes/13.1.0.html
> index 5b8b016..4dce843 100644
While I'm not against it, not sure that this has much use... mostly
this would be for _mesa_enum_to_string() to work AFAIK. Also, for such
smaller exts, we tend to just stick them into gl_API.xml directly.
Lastly if you do want to keep it in a separate file, make sure to add
it to the list in Makef
Thanks!
Reviewed-by: Ilia Mirkin
On Thu, Dec 8, 2016 at 6:00 AM, Lionel Landwerlin
wrote:
> Suggested by Ilia.
>
> Signed-off-by: Lionel Landwerlin
> Cc: Ilia Mirkin
> ---
> src/mesa/main/extensions_table.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/mai
Usually the subject prefix here would just be "mesa". Sometimes people
might put "mesa/main". I don't think the "a: b:" thing is frequently
done in mesa. With that fixed up,
Reviewed-by: Ilia Mirkin
On Thu, Dec 8, 2016 at 6:00 AM, Lionel Landwerlin
wrote:
> Signed-off-by: Lionel Landwerlin
> C
Reviewed-by: Ilia Mirkin
On Thu, Dec 8, 2016 at 5:59 AM, Lionel Landwerlin
wrote:
> Suggested by Ilia.
>
> Signed-off-by: Lionel Landwerlin
> Cc: Ilia Mirkin
> ---
> src/mesa/drivers/dri/i965/gen8_ps_state.c | 5 ++---
> src/mesa/drivers/dri/i965/gen8_sf_state.c | 2 +-
> src/mesa/main/enable
Jason
Clamping to +- 10 sounds good to me. I have sent a patch to the mesa-dev
list.
Please port spirv_to_nir in a separate patch if you could, I'm afraid I'm
not really familiar with that part and don't know how to test it.
On Thu, Dec 8, 2016 at 4:54 PM, Jason Ekstrand wrote:
> On Thu, Dec 8
Clamp input scalar value to range [-10, +10] to avoid precision problems
when the absolute value of input is too large.
Fixes dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.* test
failures.
Signed-off-by: Haixia Shi
Cc: Jason Ekstrand ,
Cc: Stéphane Marchesin ,
Cc: Kenneth Graunk
On Thu, Dec 8, 2016 at 3:31 PM, Haixia Shi wrote:
> We're encountering failures in the latest version of dEQP (specifically,
> dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.highp_*)
> on all Intel devices.
>
> The problem is that when the abs value of input is too large (say 80),
On 9 December 2016 at 08:11, Bas Nieuwenhuizen wrote:
> Leftovers from anv?
>
> Signed-off-by: Bas Nieuwenhuizen
Reviewed-by: Dave Airlie
for the series.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/l
Matt Turner writes:
> On Thu, Dec 8, 2016 at 6:55 AM, Emil Velikov wrote:
>
>> former uses relative paths, while the latter absolute ones.
>> Skimming through - nothing obvious comes up on convincing autoconf to
>> generate/use the absolute ones.
>
>
> So the patch makes what amount to a cosmeti
https://bugs.freedesktop.org/show_bug.cgi?id=98595
--- Comment #17 from Marek Olšák ---
Macros are unaffected by extern "C".
--
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.
There seems to be a regression with this patch.
I noticed one mistake: nine_upload_create_buffer should initialize
buf->resource to NULL.
However someone reports crash after GTT memory exhaustion.
I can't find the mistake. Anyone ?
Axel
On 07/12/2016 23:55, Axel Davy wrote:
This new buffer
We're encountering failures in the latest version of dEQP (specifically,
dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.highp_*) on
all Intel devices.
The problem is that when the abs value of input is too large (say 80), the
function should return +/-1, but the actual shader outpu
This series is,
Reviewed-by: Edward O'Callaghan
On 12/09/2016 09:11 AM, Bas Nieuwenhuizen wrote:
> Leftovers from anv?
>
> Signed-off-by: Bas Nieuwenhuizen
> ---
> src/amd/vulkan/radv_private.h | 16
> 1 file changed, 16 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_priva
Am Donnerstag, 8. Dezember 2016, 16:59:27 CET schrieb Emil Velikov:
> On 8 December 2016 at 02:03, Tobias Droste wrote:
> > this renames MESA_LLVM to FOUND_LLVM and updates the config.log report
> > to say if LLVM is found or not, to make clear that this does not mean
> > that it is used.
> >
> >
Inspired by patches from Eric Engestrom.
Signed-off-by: Bas Nieuwenhuizen
Cc: Eric Engestrom
---
src/amd/vulkan/radv_device.c | 18 ++
src/amd/vulkan/radv_private.h | 7 +++
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/
Leftovers from anv?
Signed-off-by: Bas Nieuwenhuizen
---
src/amd/vulkan/radv_private.h | 16
1 file changed, 16 deletions(-)
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 4b72017..67da46a 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/am
Inspired by patches from Eric Engestrom.
Signed-off-by: Bas Nieuwenhuizen
Cc: Eric Engestrom
---
src/amd/vulkan/radv_device.c | 41 +
src/amd/vulkan/radv_private.h | 8
2 files changed, 21 insertions(+), 28 deletions(-)
diff --git a/src/amd/vu
Am Donnerstag, 8. Dezember 2016, 17:24:14 CET schrieb Emil Velikov:
> On 8 December 2016 at 02:03, Tobias Droste wrote:
> > This is actually not needed because the version is checked later.
> >
> > Line 2609:
> > if test "x$enable_gallium_llvm" == "xyes"; then
> >
> > llvm_require_version $L
Am Donnerstag, 8. Dezember 2016, 17:14:12 CET schrieb Emil Velikov:
> On 8 December 2016 at 02:03, Tobias Droste wrote:
> > Gallium code used HAVE_LLVM to check if it needs to compile code for
> > LLVM in header and source files.
> >
> > With the new logic HAVE_LLVM is always set. Use extra defin
Am Donnerstag, 8. Dezember 2016, 17:06:16 CET schrieb Emil Velikov:
> On 8 December 2016 at 02:03, Tobias Droste wrote:
> > This renames llvm_check_version_for to llvm_require_version and let it
> > set a variable to mark that LLVM will be used.
> >
> > Use this to make a usefull configure output
On Thu, Dec 8, 2016 at 3:43 PM, Rowley, Timothy O
wrote:
>
>> On Nov 24, 2016, at 2:29 PM, Ilia Mirkin wrote:
>>
>> Clip distances need to be perspective-divided. This fixes all the
>> interpolation-*-{distance,vertex} piglits.
>>
>> Also take this opportunity to fix clip distances for points ras
> On Nov 24, 2016, at 2:29 PM, Ilia Mirkin wrote:
>
> Clip distances need to be perspective-divided. This fixes all the
> interpolation-*-{distance,vertex} piglits.
>
> Also take this opportunity to fix clip distances for points rasterized
> as triangles - the clip distance is not subject to sp
On 7 December 2016 at 14:38, Eero Tamminen wrote:
> Hi,
>
> There are quite a few bugs in FDO bugzilla which mention glx-tls,
> you could list few of them in the commit message, e.g. this one:
> https://bugs.freedesktop.org/show_bug.cgi?id=72902
>
Good point - we have dozens of these, wher
On 8 December 2016 at 00:36, Eric Engestrom wrote:
> Nobody else makes use of this function.
> We can always re-export it if someone ever needs it.
>
> Signed-off-by: Eric Engestrom
This and 1/2 are
Reviewed-by: Emil Velikov
I'll push these early tomorrow morning, barring any objections.
Emil
_
On 8 December 2016 at 00:30, Eric Engestrom wrote:
> No functional change, just rewriting it in an easier-to-understand way.
>
I might be mislead by the diff, but it seems that there's functionality change.
> Signed-off-by: Eric Engestrom
> ---
> src/egl/drivers/dri2/platform_x11.c | 24 +++
https://bugs.freedesktop.org/show_bug.cgi?id=98869
--- Comment #4 from cosiek...@o2.pl ---
13.0.2 the same
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@l
https://bugs.freedesktop.org/show_bug.cgi?id=98869
--- Comment #3 from cosiek...@o2.pl ---
I tried to compile mesa-git from aur but it failed. I really won't be able to
compile it multiple times on this machine to search which commit broke it. Is
this a big problem? Will be this not be resolved if
From: Emil Velikov
Signed-off-by: Emil Velikov
---
configure.ac | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index a4327ad..606ea98 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2123,7 +2123,7 @@ dnl
dnl Gallium G3DVL configuration
dnl
From: Emil Velikov
Signed-off-by: Emil Velikov
---
configure.ac | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 4e4e965..a4327ad 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2095,6 +2095,18 @@ if test "x$enable_xa" = xy
From: Emil Velikov
Signed-off-by: Emil Velikov
---
configure.ac | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 602b2ce..4e4e965 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2095,6 +2095,12 @@ if test "x$enable_xa" = xyes; th
From: Emil Velikov
Unlike C we don't need the semicolon in our configure.
Signed-off-by: Emil Velikov
---
configure.ac | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/configure.ac b/configure.ac
index bc08639..c4c382c 100644
--- a/configure.ac
+++
From: Emil Velikov
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/omx/vid_dec.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/gallium/state_trackers/omx/vid_dec.h
b/src/gallium/state_trackers/omx/vid_dec.h
index 1ce3de7..7a10e75 100644
--- a/src/gallium/state_trackers/om
From: Emil Velikov
We'll need this to sanity check that the implementations (Vulkan, EGL,
VL targets) have at least one [supported] platform enabled in order to
build them.
No functionality change intended.
Signed-off-by: Emil Velikov
---
configure.ac | 140 +--
From: Emil Velikov
UNTESTED.
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/xvmc/context.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/xvmc/context.c
b/src/gallium/state_trackers/xvmc/context.c
index e9014c8..c239b3d 100644
---
From: Emil Velikov
A bit pedantic patch to fool proof should someone start thinkering
without knowing what they do.
Signed-off-by: Emil Velikov
---
configure.ac | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 01b905e..602b2ce 10
From: Emil Velikov
Signed-off-by: Emil Velikov
---
Should we bother with the !HAVE_PLATFORM_DRM && OMX_RENDER_NODE message
? Should we error out, or continue with the other platforms ?
---
src/gallium/state_trackers/omx/entrypoint.c | 10 ++
1 file changed, 10 insertions(+)
diff --git
From: Emil Velikov
Signed-off-by: Emil Velikov
---
configure.ac | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index 606ea98..bc08639 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2124,15 +2124,15 @@ dnl Gallium G3DVL configuration
dnl
From: Emil Velikov
Signed-off-by: Emil Velikov
---
configure.ac | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configure.ac b/configure.ac
index b2eb47f..01b905e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1954,6 +1954,9 @@ require_sha1_and_dri3() {
AC_MSG_ERROR([$1 Vu
From: Emil Velikov
Use the proper guard around the include and use void * instead of
Display *.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/vl/vl_winsys.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
b/src/gallium/auxiliary/vl/vl_winsys.
From: Emil Velikov
UNTESTED.
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/omx/entrypoint.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/omx/entrypoint.c
b/src/gallium/state_trackers/omx/entrypoint.c
index f68ede5..bf63520 1006
From: Emil Velikov
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/omx/vid_dec.h | 1 -
src/gallium/state_trackers/omx/vid_enc.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/src/gallium/state_trackers/omx/vid_dec.h
b/src/gallium/state_trackers/omx/vid_dec.h
index 90acf7b..1c
From: Emil Velikov
Follow the kernel approach and provide static inline stubs, when the
respective guard is not set. This gives us two big advantages:
- keeps the pre-processor guards out of the code
- we won't get compilation/link issues when doing incremental builds
while toggling DRI3/other
From: Emil Velikov
Since the VAAPI provides distinction between generic failure and
UNIMPLEMENTED we need to add a bit of ifdef guards through the code.
Note: current wayland support is partial (it does not implement
va_GetSurfaceBufferWl and va_GetImageBufferWl) thus effectively it is
identical
From: Emil Velikov
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/va/context.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/va/context.c
b/src/gallium/state_trackers/va/context.c
index 0f18399..1ff19a8 100644
--- a/src/galliu
From: Emil Velikov
... and make it const, since we shouldn't thinker with it.
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/va/context.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/va/context.c
b/src/gallium/state_trackers/va/c
From: Emil Velikov
Signed-off-by: Emil Velikov
---
Should we keep this here and feed the defines to all sources or apply
them locally ?
If we go with this approach, need to drop the other existing defines.
---
configure.ac | 5 +
1 file changed, 5 insertions(+)
diff --git a/configure.ac b
From: Emil Velikov
It's been like this since the code was introduced.
Fixes: 86eb4131a90 (st/va: add headless support, i.e. VA_DISPLAY_DRM)
Cc: "13.0"
Cc: Julien Isorce
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/va/context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
From: Emil Velikov
All the information required is provided via the respecive xcb packages.
Signed-off-by: Emil Velikov
---
configure.ac | 7 ---
1 file changed, 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4459103..006a70b 100644
--- a/configure.ac
+++ b/configure.ac
@@
From: Emil Velikov
Since day 1, Vulkan has depended on --with-egl-platforms to select the
platforms build.
With earlier commits, we've attributed for that internally by renaming
the [internal] conditionals in our build. At the same time having the
--enable-egl and --with-egl-platforms dependency
From: Emil Velikov
Vulkan supports only DRI3 enabled X11 platforms. Make it obvious,
should one consider building without it.
Cc: Jason Ekstrand
Signed-off-by: Emil Velikov
---
XXX: worth porting to stable... it would require previous commit and
the invasive
commit f79b1d325722f8aa3d0f76de56b
From: Emil Velikov
Cc: Eric Anholt
Signed-off-by: Emil Velikov
---
.travis.yml | 10 --
1 file changed, 10 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 3d107aa..4e4c53a 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -29,8 +29,6 @@ env:
- XORGMACROS_VERSION=util-macros
From: Emil Velikov
We'll be adding more common requirements, so there's no point in
duplicating things even more.
Signed-off-by: Emil Velikov
---
configure.ac | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/configure.ac b/configure.ac
index ed1f96a..997eea
From: Emil Velikov
Analogous to other platforms earlier, we will allow users to control
the platform for more than the EGL driver.
With later commit(s) we'll rename the configure option and update any
references throughout.
Signed-off-by: Emil Velikov
---
configure.ac| 6 +++---
src/e
Rather than having the XCB_DRI3 dependencies burried just do a once-off
check and add [all of] the respective CFLAGS/LIBS where needed.
As a nice side effect this helps us solve a couple of FIXMEs
Signed-off-by: Emil Velikov
---
configure.ac | 24 +---
From: Emil Velikov
The configure option is used by more than just EGL and with next commit
we'll rename it accordingly. Thus having the check will (and is atm)
incorrect.
Signed-off-by: Emil Velikov
---
configure.ac | 4
1 file changed, 4 deletions(-)
diff --git a/configure.ac b/configur
Hi all,
As you may already know in order to build Vulkan+Wayland/X11 one needs
to select --enable-egl alongside --with-egl-platforms=...
Admittedly this is not an issue since both options have sane defaults.
At the same time, it is quite confusing to have such a dependency. Thus
this series aims
On Dec 8, 2016 8:48 AM, "Lionel Landwerlin" wrote:
v2: add lod level argument (Jason)
return 0 for any lod level > 0 (Jason)
return 0 for any surface not 3D (Jason)
I'd rather have ISL assert these than just silently return 0. That way
it's clear they make no sense. We can have a dime
On 7 December 2016 at 20:20, Eric Anholt wrote:
> Emil Velikov writes:
>
>> From: Emil Velikov
>>
>> Having the "Entering|Leaving directory X" messages it not required nor
>> useful in vast majority of the cases.
>>
>> One can always have them printed by `make -w' or by overriding the
>> AM_MAKE
On 8 December 2016 at 18:23, Matt Turner wrote:
> On Thu, Dec 8, 2016 at 6:55 AM, Emil Velikov wrote:
>> On 8 December 2016 at 14:07, Nicolai Hähnle wrote:
>>> On 08.12.2016 12:30, Emil Velikov wrote:
On 7 December 2016 at 20:20, Eric Anholt wrote:
>
> Emil Velikov writes:
>>
On Thu, Dec 8, 2016 at 6:55 AM, Emil Velikov wrote:
> On 8 December 2016 at 14:07, Nicolai Hähnle wrote:
>> On 08.12.2016 12:30, Emil Velikov wrote:
>>>
>>> On 7 December 2016 at 20:20, Eric Anholt wrote:
Emil Velikov writes:
> From: Emil Velikov
>
> Having the "Ente
From: Emil Velikov
We should be using LIBS rather than the LDFLAGS variable. Furthermore
try to keep the linking to the final stage, rather than intermetent
static library.
Cc: Steven Toth
Signed-off-by: Emil Velikov
---
Steven please double-check things on your end.
---
configure.ac
From: Emil Velikov
Signed-off-by: Emil Velikov
---
configure.ac | 10 --
1 file changed, 10 deletions(-)
diff --git a/configure.ac b/configure.ac
index 2007098..b0bce9d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2068,7 +2068,6 @@ AC_SUBST([GBM_PC_LIB_PRIV])
dnl
dnl EGL configur
On 8 December 2016 at 02:03, Tobias Droste wrote:
> This is actually not needed because the version is checked later.
>
> Line 2609:
> if test "x$enable_gallium_llvm" == "xyes"; then
> llvm_require_version $LLVM_REQUIRED_GALLIUM "gallium"
> llvm_add_default_components "gallium"
>
> HAV
On 8 December 2016 at 02:03, Tobias Droste wrote:
> Make setting LLVM_LIBS a function, put it to the other LLVM related
> functions and call it if LLVM is used.
>
> Signed-off-by: Tobias Droste
Seems like a plain move but I haven't checked it exactly, so
Acked-by: Emil Velikov
-Emil
___
On 8 December 2016 at 02:03, Tobias Droste wrote:
> Gallium code used HAVE_LLVM to check if it needs to compile code for
> LLVM in header and source files.
>
> With the new logic HAVE_LLVM is always set. Use extra define to figure
> out if LLVM is used.
>
> Bugzilla: https://bugs.freedesktop.org/s
On 8 December 2016 at 02:03, Tobias Droste wrote:
> Make sure that HAVE_LLVM compiler define is only set if LLVM is
> actually used.
>
> Signed-off-by: Tobias Droste
Reviewed-by: Emil Velikov
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.o
On 8 December 2016 at 02:03, Tobias Droste wrote:
> This renames llvm_check_version_for to llvm_require_version and let it
> set a variable to mark that LLVM will be used.
>
> Use this to make a usefull configure output and to only check if the
> libs are found in LLVM if it is actually used.
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=99027
Mark Janes changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 8 December 2016 at 02:03, Tobias Droste wrote:
> this renames MESA_LLVM to FOUND_LLVM and updates the config.log report
> to say if LLVM is found or not, to make clear that this does not mean
> that it is used.
>
> Signed-off-by: Tobias Droste
> ---
> configure.ac | 21 ++---
>
v2: add lod level argument (Jason)
return 0 for any lod level > 0 (Jason)
return 0 for any surface not 3D (Jason)
Signed-off-by: Lionel Landwerlin
---
src/intel/Makefile.isl.am | 10 +-
src/intel/isl/isl.c| 28 +++
src/intel/isl/
With a 3d image of 2x2x3, vkGetImageSubresourceLayout currently reports :
VkSubresourceLayout = { offset = 0,
size = 160,
rowPitch = 16,
arrayPitch = 96,
depthPitch = 96 }
depthPitch should be 32.
Use t
On 8 December 2016 at 14:07, Nicolai Hähnle wrote:
> On 08.12.2016 12:30, Emil Velikov wrote:
>>
>> On 7 December 2016 at 20:20, Eric Anholt wrote:
>>>
>>> Emil Velikov writes:
>>>
From: Emil Velikov
Having the "Entering|Leaving directory X" messages it not required nor
usef
On 08.12.2016 12:30, Emil Velikov wrote:
On 7 December 2016 at 20:20, Eric Anholt wrote:
Emil Velikov writes:
From: Emil Velikov
Having the "Entering|Leaving directory X" messages it not required nor
useful in vast majority of the cases.
One can always have them printed by `make -w' or by
On 12/08/2016 02:23 PM, Alejandro Piñeiro wrote:
> On 08/12/16 10:59, Eduardo Lima Mitev wrote:
>> From OpenGL 4.5 Core Profile spec, section 18.3.2 (Copying Between Images),
>> page 517 of the PDF:
>>
>>"An INVALID_OPERATION error is generated if either object is a texture
>> and the textu
On 07.12.2016 23:05, Marek Olšák wrote:
From: Marek Olšák
It must be disabled until the kernel bug is fixed, and then we'll enable CE
based on the DRM version.
Cc: 12.0 13.0
Reviewed-by: Nicolai Hähnle
---
src/gallium/drivers/radeonsi/si_pipe.c | 5 -
1 file changed, 4 insertions(+)
On 07.12.2016 19:03, Ian Romanick wrote:
On 12/07/2016 09:44 AM, Marek Olšák wrote:
On Wed, Dec 7, 2016 at 6:42 PM, Ilia Mirkin wrote:
What's wrong with feeding it stack memory?
I don't really have an answer to that.
Does valgrind provide any clues? The usual problems are running out of
s
On 08/12/16 10:59, Eduardo Lima Mitev wrote:
> From OpenGL 4.5 Core Profile spec, section 18.3.2 (Copying Between Images),
> page 517 of the PDF:
>
>"An INVALID_OPERATION error is generated if either object is a texture
> and the texture is not complete (as defined in section 8.17), if the
From OpenGL 4.5 Core Profile spec, section 18.3.2 (Copying Between Images),
page 517 of the PDF:
"An INVALID_OPERATION error is generated if either object is a texture
and the texture is not complete (as defined in section 8.17), if the
source and destination internal formats are not co
https://bugs.freedesktop.org/show_bug.cgi?id=99027
--- Comment #2 from Timo Aaltonen ---
yeah, patching libepoxy fixed it
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing
Signed-off-by: Lionel Landwerlin
---
docs/relnotes/13.1.0.html | 1 +
1 file changed, 1 insertion(+)
diff --git a/docs/relnotes/13.1.0.html b/docs/relnotes/13.1.0.html
index 5b8b016..4dce843 100644
--- a/docs/relnotes/13.1.0.html
+++ b/docs/relnotes/13.1.0.html
@@ -45,6 +45,7 @@ Note: some of th
1 - 100 of 113 matches
Mail list logo
