We need to cache this for i965 but gallium drivers will have
already saved this as part of the parameter list.
This should help with cache compression times.
---
src/compiler/glsl/shader_cache.cpp | 58 +-
src/mesa/main/mtypes.h | 7 +
2 files
We will have already loaded the uniforms when the parameter list
was restored from cache.
---
src/mesa/program/ir_to_mesa.cpp| 14 +-
src/mesa/program/ir_to_mesa.h | 3 ++-
src/mesa/state_tracker/st_glsl_to_nir.cpp | 3 ++-
src/mesa/state_tracker/st_glsl_to_
On 03/03/17 14:27, Timothy Arceri wrote:
Previously we were deleting the entire cache if a user switched
between 32 and 64 bit applications.
V2: make the check more generic, it should now work with any
platform we are likely to support.
---
src/util/disk_cache.c | 19 +++
1 fi
Previously we were deleting the entire cache if a user switched
between 32 and 64 bit applications.
V2: make the check more generic, it should now work with any
platform we are likely to support.
---
src/util/disk_cache.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/sr
On 03/02/2017 04:12 PM, Timothy Arceri wrote:
The number of tokens in never used and the pointer is NULL checked
so just pass NULL.
---
src/gallium/drivers/svga/svga_state_fs.c | 3 +--
src/gallium/drivers/svga/svga_state_vs.c | 6 ++
2 files changed, 3 insertions(+), 6 deletions(-)
diff
Previously, the cache would be removed if created by an application for a
different architecture, e.g. i386 rather than amd64 on a multiarch
installation. This is due to use of the libraries' build datestamps.
This makes use of the canonicalisation done by config.sub.
---
configure.ac |
On Thu, Mar 2, 2017 at 5:41 PM, Kenneth Graunke wrote:
> On Wednesday, March 1, 2017 6:09:30 PM PST Ilia Mirkin wrote:
>> So, I have a few conflicting thoughts:
>>
>> (a) I hate having to saddle the code with impossible conditions. This
>> change may seem minor but it's an admission that non-sensi
Reviewed-by: Jeremy Huddleston Sequoia
Seems like the right change to me. I was always a bit perplexed as to why that
was there in the first place, so I'm glad to see it get the boot where not
needed.
Sent from my iPhone...
> On Mar 2, 2017, at 11:02, Emil Velikov wrote:
>
> From: Emil Vel
On 03/03/17 00:16, Grazvydas Ignotas wrote:
On Thu, Mar 2, 2017 at 8:36 AM, Timothy Arceri wrote:
On 02/03/17 17:17, Ilia Mirkin wrote:
On Thu, Mar 2, 2017 at 1:08 AM, Timothy Arceri
wrote:
Previously we were deleting the entire cache if a user switched
between 32 and 64 bit applicatio
On 03/03/17 11:53, Marek Olšák wrote:
OK.
I also wonder if 1GB isn't too conservative. Today’s games take up a
lot of space. My installed games occupy 480 GB. I could certainly
spare 10 GB for a shader cache if it improves gaming experience. For
example, my ccache size is set to 27 GB, because 1
See detailed explanation of why this is needed in commit eb60a89bc3a.
This spot was missed/overlooked. Basically as a result of the fact
that BEGIN_* ends up calling PUSH_SPACE, which in turn adds an extra 8
to the requested amount, we have to be mindful of that when doing bare
nouveau_pushbuf_spac
---
src/gallium/drivers/swr/swr_context.cpp| 2 +-
src/gallium/drivers/swr/swr_context.h | 25 +-
src/gallium/drivers/swr/swr_draw.cpp | 50 +--
src/gallium/drivers/swr/swr_fence_work.cpp | 21 ++
src/gallium/drivers/swr/swr_fence_work.h | 3 +
src/gallium/drivers/swr/swr_s
---
src/gallium/drivers/swr/rasterizer/core/frontend.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/swr/rasterizer/core/frontend.cpp
b/src/gallium/drivers/swr/rasterizer/core/frontend.cpp
index c150c51..18728e5 100644
--- a/src/gallium/drivers/swr/
---
docs/features.txt | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/docs/features.txt b/docs/features.txt
index 67d177d..df1860d 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -78,18 +78,18 @@ GL 3.1, GLSL 1.40 --- all DONE: freedreno, i965, nv50
GS implementation uses the masked.{gather,store} intrinsics,
introduced in llvm-3.9.0.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index a3d1a00..260e717 100644
--- a/configure.ac
+++ b/configure.ac
@@ -106,7 +106,7 @@ LLVM_REQUI
Probably still some problems (some hidden by tranform feedback bugs),
but an additional 1719 piglit tests pass, and the VTK tests using
geometry shaders now pass.
Tim Rowley (4):
configure.ac: increase required swr llvm to 3.9.0
swr: implement geometry shaders
swr: [rasterizer core] fix prim
OK.
I also wonder if 1GB isn't too conservative. Today’s games take up a
lot of space. My installed games occupy 480 GB. I could certainly
spare 10 GB for a shader cache if it improves gaming experience. For
example, my ccache size is set to 27 GB, because 1 or 5 or 10 GB
wasn't enough for my use
On Mon, Feb 06, 2017 at 03:55:49PM -0800, Kenneth Graunke wrote:
> If a HiZ op is the first thing in the batch, we should make sure
> to select the render pipeline and emit state base address before
> proceeding.
>
> I believe 3DSTATE_WM_HZ_OP creates 3DPRIMITIVEs internally, and
> dispatching tho
On Thu, Mar 2, 2017 at 6:37 PM, Samuel Pitoiset
wrote:
> Replying here.
>
> Yes, it makes sense, but looks like Roy still has some rendering issues with
> Pidgin even with that patch. Maybe something else is also broken in
> nvc0_validate_suf()?
Could be. Could also be an unrelated issue. Either
https://bugs.freedesktop.org/show_bug.cgi?id=100028
higu...@gmx.net changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Since blob is intended for serializing data, it's not a good idea to
leave padding holes with uninitialized data, which may leak heap
contents and hurt compression if the blob is later compressed, like
done by shader cache. Clear it.
Signed-off-by: Grazvydas Ignotas
---
I don't know why blob both
https://bugs.freedesktop.org/show_bug.cgi?id=68504
Matt Turner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Reviewed-by: Timothy Arceri
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Replying here.
Yes, it makes sense, but looks like Roy still has some rendering issues
with Pidgin even with that patch. Maybe something else is also broken in
nvc0_validate_suf()?
Either way:
Acked-by: Samuel Pitoiset
On 03/01/2017 05:09 PM, Ilia Mirkin wrote:
When binding as textures, t
https://bugs.freedesktop.org/show_bug.cgi?id=100028
--- Comment #3 from Jan Vesely ---
(In reply to higuita from comment #2)
> Ok, thanks... but building mesa-git i get this, that is similar to what i
> get just by removing the bad llvm flag:
>
>
> Making all in amd
> make[3]: Entering director
The number of tokens in never used and the pointer is NULL checked
so just pass NULL.
---
src/gallium/drivers/svga/svga_state_fs.c | 3 +--
src/gallium/drivers/svga/svga_state_vs.c | 6 ++
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_state_fs.c
The number of tokens in never used and the pointer is NULL checked
so just pass NULL.
---
src/gallium/state_trackers/nine/nine_ff.c | 3 +--
src/gallium/state_trackers/nine/nine_shader.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/nine/nin
On 03/02/2017 08:36 PM, Mark Janes wrote:
Samuel Pitoiset writes:
Well, I have just tested it with mesa git-ca7d2025a7 (just before
be8aa76afd - glsl: remove unecessary flags.q.subroutine_def) and it also
fails. While git-be8aa76afd introduces a compile-time error:
"Failed to compile vertex
Thanks!
Reviewed-by: Timothy Arceri
On 03/03/17 09:46, Grazvydas Ignotas wrote:
Valgrind reports that the shader cache writes uninitialized data to disk.
Turns out ureg_get_tokens() is returning the count of allocated tokens
instead of how many are actually used, so the cache writes out unused
https://bugs.freedesktop.org/show_bug.cgi?id=100028
--- Comment #2 from higu...@gmx.net ---
Ok, thanks... but building mesa-git i get this, that is similar to what i get
just by removing the bad llvm flag:
Making all in amd
make[3]: Entering directory
'/tmp/mesa-d7d64f1091006fb6faa48705c53f19ff5
Reviewed-by: Lionel Landwerlin
Makes sense
On 02/03/17 19:06, Matt Turner wrote:
Depending on the generated Makefile means that all generated sources are
recreated after ./configure.
---
src/intel/Makefile.genxml.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/int
Valgrind reports that the shader cache writes uninitialized data to disk.
Turns out ureg_get_tokens() is returning the count of allocated tokens
instead of how many are actually used, so the cache writes out unused
space at the end. Use the real count instead.
This change should not cause regressi
On 2017-03-02 10:08, Timothy Arceri wrote:
On 02/03/17 18:45, Tobias Droste wrote:
Hi Timothy,
if you plan to support multiple compression algorithms, shouldn't
"struct
cache_entry_file_data" contain some info about what compression
algorithm was
used to compress the data? Or is this already
On 03/03/17 01:49, Emil Velikov wrote:
Hi Tim,
On 2 March 2017 at 01:36, Timothy Arceri wrote:
This reduces the cache size for Deus Ex from ~160M to ~30M for
radeonsi.
I'm also seeing the following improvements in minimum fps in the
Shadow of Mordor benchmark:
no-cache:
On Mar 2, 2017 7:32 PM, "Emil Velikov" wrote:
On 2 March 2017 at 18:58, Robert Bragg wrote:
> Adds R/b from Dylan and Makefile fixups from Emil, including fixing race
with
> parallel make builds (thanks). Just holding fast on the use of #pragma
once
> though :-)
>
I think you want the "required=
On 03/03/17 07:47, Timothy Arceri wrote:
On 03/03/17 03:39, Marek Olšák wrote:
On Thu, Mar 2, 2017 at 5:36 PM, Mike Lothian wrote:
I'm guessing when the code runs the 32bit and 64bit have different build
times so invalidate the cache and create a new one
On Thu, 2 Mar 2017 at 16:25 Marek
On Thu, Mar 02, 2017 at 11:03:44AM -0800, Jason Ekstrand wrote:
> On Mar 2, 2017 10:57 AM, "Nanley Chery" wrote:
>
> On Wed, Mar 01, 2017 at 04:46:42PM -0800, Jason Ekstrand wrote:
> > I didn't re-read every patch, just the ones I made comments on. Assuming
> > only the commented patches made re
On 03/03/17 03:39, Marek Olšák wrote:
On Thu, Mar 2, 2017 at 5:36 PM, Mike Lothian wrote:
I'm guessing when the code runs the 32bit and 64bit have different build
times so invalidate the cache and create a new one
On Thu, 2 Mar 2017 at 16:25 Marek Olšák wrote:
On Thu, Mar 2, 2017 at 3:03
The bounce buffer cache is suitable for small caches of temporary GPU
pixel buffers. It's useful for state-trackers that have a more detailed
knowledge of when it's suitable to cache buffers than drivers have and
where the buffers are not accessed by the CPU.
Testing done: Replaced the vdpau state
Import the bicubic filter fragment shader into the compositor, and modify
it to use shader uniform input instead of hardcoding video- and
destination dimensions. This will help enable correct handling of compositor
features such as blending, rotation and additional overlays. It will also save
a bun
Provide a 3D implementation that can be partly overridden by
the video drivers. The implementation is based on the vl compositor- and the
vdpau mixer code. A driver that wants to utilize a dedicated hardware
postprocessor can typically replace the render method and then use the
bounce buffer cache
Makes it possible for drivers to provide a single implementation
for multiple state-trackers and to utilize dedicated post-processing
engines. The API is very similar to the vl compositor, but also includes
a generic filter mechanism.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
Admittedly, it's actually rather painful give how many different bits we
have to build, to set LDADD, CFLAGS, CPPFLAGS, etc for each one.
---
src/Makefile.am | 5 -
src/intel/Makefile.am| 8 ++
src/intel/Makefile.sources | 65 +
src/intel/Makefile.vulkan.am
---
src/intel/vulkan/anv_private.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index f148b35..c7c7170 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -63,9 +63,9 @@ struct ge
Reviewed-by: Emil Velikov
---
src/intel/Makefile.isl.am | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/intel/Makefile.isl.am b/src/intel/Makefile.isl.am
index 5a317f5..ee2215d 100644
--- a/src/intel/Makefile.isl.am
+++ b/src/intel/Makefile.isl.am
@@ -74,7 +74,6 @@ TESTS += $(check_PROGRAM
Previously, we were depending on EGL for generating the headers and
providing the protocol symbols. However, since neither Vulkan driver
actually wants to link against EGL, this is kind-of pointless. It also
creates a weird build dependency.
---
src/amd/vulkan/Makefile.am | 3 ---
src/
Reviewed-by: Emil Velikov
---
src/Makefile.am | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index 7001528..a558755 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -75,6 +75,11 @@ endif
# include only conditionally ?
SUBDIR
---
src/intel/vulkan/anv_wsi_wayland.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/intel/vulkan/anv_wsi_wayland.c
b/src/intel/vulkan/anv_wsi_wayland.c
index 5d49671..690fd30 100644
--- a/src/intel/vulkan/anv_wsi_wayland.c
+++ b/src/intel/vulkan/anv_wsi_wayland.c
@@ -22,7 +22,6 @@
*/
This series applies on top of a patch that move the i965 back-end compiler
to src/intel/compiler. I don't expect to actually push this for a while
but at least we now have the patches. This gives Emil and others a chance
to provide review feedback.
The v2 contains various fixes from Emil.
Jason
Reviewed-by: Lionel Landwerlin
Reviewed-by: Emil Velikov
---
src/Makefile.am| 4 --
src/intel/Makefile.am | 2 +
src/intel/{tools/Makefile.am => Makefile.tools.am} | 56 +++---
3 files changed, 19 insertions(+), 4
On Thu, Mar 2, 2017 at 10:21 AM, Kenneth Graunke
wrote:
> On Wednesday, March 1, 2017 10:40:24 PM PST Jason Ekstrand wrote:
> > We used to have an assert in mark_surface_used to protect us from this
> > but it's gone now. Instead, we'll assert right before we try to memcpy
> > the contents of su
On Thu, Mar 2, 2017 at 5:41 AM, Emil Velikov
wrote:
> Cc: Mauro Rossi
> Cc: Tapani Pälli
> Cc: Jason Ekstrand
> ---
> All, here is a 5min attempt to fix the Android build. Tapani, Mauro do
> give it a test since I've done an educated guess here.
>
> Pull Jason's branch and apply on top.
> http
On Thu, Mar 2, 2017 at 12:13 PM, Jason Ekstrand
wrote:
> On Thu, Mar 2, 2017 at 4:19 AM, Emil Velikov
> wrote:
>
>> On 2 March 2017 at 05:28, Jason Ekstrand wrote:
>> > ---
>> > src/intel/vulkan/tests/block_pool_no_free.c| 2 +-
>> > src/intel/vulkan/tests/state_pool.c|
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
src/gallium/state_trackers/va/context.c| 21 ++---
src/gallium/state_trackers/va/postproc.c | 30 +-
src/gallium/state_trackers/va/surface.c| 23 +--
src/galliu
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
src/gallium/state_trackers/vdpau/device.c| 11 +-
src/gallium/state_trackers/vdpau/mixer.c | 522 ---
src/gallium/state_trackers/vdpau/output.c| 114 ++---
src/gallium/state_trackers/vdpau/pr
This patch series introduces a postprocessor abstraction. It could be promoted
to a gallium interface but for now it's implemented as a utility. The idea
is that a driver wanting to implement the whole or part of the postprocessing
pipeline using video hardware can do that. It also significantly si
It's now incorporated into vl_compositor.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
src/gallium/auxiliary/Makefile.sources | 2 -
src/gallium/auxiliary/vl/vl_bicubic_filter.c | 461 ---
src/gallium/auxiliary/vl/vl_bicubic_filter.h | 63
3
On Thu, Mar 2, 2017 at 4:19 AM, Emil Velikov
wrote:
> On 2 March 2017 at 05:28, Jason Ekstrand wrote:
> > ---
> > src/intel/vulkan/tests/block_pool_no_free.c| 2 +-
> > src/intel/vulkan/tests/state_pool.c| 2 +-
> > src/intel/vulkan/tests/state_pool_free_list_only.c | 2
On Thu, Mar 2, 2017 at 4:15 AM, Emil Velikov
wrote:
> On 2 March 2017 at 05:28, Jason Ekstrand wrote:
> > Previously, we were depending on EGL for generating the headers and
> > providing the protocol symbols. However, since neither Vulkan driver
> > actually wants to link against EGL, this is
On Thu, Mar 2, 2017 at 4:15 AM, Emil Velikov
wrote:
> On 2 March 2017 at 05:28, Jason Ekstrand wrote:
> > Previously, we were depending on EGL for generating the headers and
> > providing the protocol symbols. However, since neither Vulkan driver
> > actually wants to link against EGL, this is
On Thu, Mar 02, 2017 at 07:02:44PM +, Emil Velikov wrote:
> Jeremy, others,
>
> Afaict pthread-stubs expands to a simple .pc on your platforms, but a
> confirmation will be greatly appreciated.
Hurd is not really "my" platform, but yes, I agree that with its
current libc, pthreads-stubs is me
On 2 March 2017 at 19:02, Matt Turner wrote:
> I was just going through old bugs and found this. I asked you to look
> into this years ago, and then never did my part. Sorry for that.
>
Bth, I forgot about it as well :-\
> On Wed, Sep 2, 2015 at 1:34 PM, Emil Velikov wrote:
>> Some drivers do no
Samuel Pitoiset writes:
> Well, I have just tested it with mesa git-ca7d2025a7 (just before
> be8aa76afd - glsl: remove unecessary flags.q.subroutine_def) and it also
> fails. While git-be8aa76afd introduces a compile-time error:
>
> "Failed to compile vertex shader
> /home/hakzsam/programming
On 2 March 2017 at 18:58, Robert Bragg wrote:
> Adds R/b from Dylan and Makefile fixups from Emil, including fixing race with
> parallel make builds (thanks). Just holding fast on the use of #pragma once
> though :-)
>
I think you want the "required=True" for all the fields, but feel free
to do at
On March 2, 2017 09:57:22 Emil Velikov wrote:
On 2 March 2017 at 17:44, Jason Ekstrand wrote:
On March 2, 2017 05:05:37 Emil Velikov wrote:
On 2 March 2017 at 05:28, Jason Ekstrand wrote:
---
src/intel/vulkan/anv_wsi_wayland.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/inte
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Mar 1, 2017, at 10:58 PM, Bruce Cherniak
mailto:bruce.chern...@intel.com>> wrote:
Recent change to st/mesa state update logic caused major regressions to
swr validation code.
swr uses the same validation logic (swr_update_derived)
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Feb 25, 2017, at 9:17 PM, Bruce Cherniak
mailto:bruce.chern...@intel.com>> wrote:
---
docs/features.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/features.txt b/docs/features.txt
index d9528e9..c42581a
Depending on the generated Makefile means that all generated sources are
recreated after ./configure.
---
src/intel/Makefile.genxml.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
index 2ed2741..20e4b15 100644
--- a
From: Emil Velikov
On platforms that require it, we bump the requirement to 0.4 or later.
Due to an issue with the project [design] any version earlier than it,
is bound to cause issues. For the specifics see the pthread-stubs README
Cc: Uli Schlachter
Cc: Jonathan Gray
Cc: Jean-Sébastien Pédr
From: Emil Velikov
The project is a thing only for BSD platforms. Or in other words - for
any other platforms building/installing pthread-stubs results only in a
pthread-stub.pc file.
And even where it provides a DSO, there's a fundamental design issue
with it - see the pthread-stubs mailing lis
Well, I have just tested it with mesa git-ca7d2025a7 (just before
be8aa76afd - glsl: remove unecessary flags.q.subroutine_def) and it also
fails. While git-be8aa76afd introduces a compile-time error:
"Failed to compile vertex shader
/home/hakzsam/programming/piglit/tests/spec/arb_shader_subrou
On Mar 2, 2017 10:57 AM, "Nanley Chery" wrote:
On Wed, Mar 01, 2017 at 04:46:42PM -0800, Jason Ekstrand wrote:
> I didn't re-read every patch, just the ones I made comments on. Assuming
> only the commented patches made real changes, the series is
>
> Reviewed-by: Jason Ekstrand
>
> I really li
I was just going through old bugs and found this. I asked you to look
into this years ago, and then never did my part. Sorry for that.
On Wed, Sep 2, 2015 at 1:34 PM, Emil Velikov wrote:
> Some drivers do not support certain targets - for example nouveau
> doesn't do VAAPI, while freedreno doesn'
Adds R/b from Dylan and Makefile fixups from Emil, including fixing race with
parallel make builds (thanks). Just holding fast on the use of #pragma once
though :-)
Br,
- Robert
--- >8 --- (git am --scissors)
Avoiding lots of error prone boilerplate and easing our ability to add +
maintain suppo
On 03/02/2017 07:56 PM, Ilia Mirkin wrote:
Perhaps you ran the gpu profile?
Nope, tests/all.gpu
On Thu, Mar 2, 2017 at 1:50 PM, Samuel Pitoiset
wrote:
I wonder why piglit didn't report me that failure because I ran it with -t
subroutine before sending the patch...
On 03/02/2017 06:56 P
On Wed, Mar 01, 2017 at 04:46:42PM -0800, Jason Ekstrand wrote:
> I didn't re-read every patch, just the ones I made comments on. Assuming
> only the commented patches made real changes, the series is
>
> Reviewed-by: Jason Ekstrand
>
> I really like the direction things are going.
>
Thanks!
Perhaps you ran the gpu profile?
On Thu, Mar 2, 2017 at 1:50 PM, Samuel Pitoiset
wrote:
> I wonder why piglit didn't report me that failure because I ran it with -t
> subroutine before sending the patch...
>
>
> On 03/02/2017 06:56 PM, Mark Janes wrote:
>>
>> This patch regresses:
>> piglit.spec.
"mesa/main:" maybe?
Other than that:
Reviewed-by: Samuel Pitoiset
On 03/02/2017 06:53 PM, Alejandro Piñeiro wrote:
Equivalent *TexSubImage* methods generates INVALID_ENUM.
From OpenGL 4.5 spec, section 8.6 Alternate Texture Image
Specification Commands:
"An INVALID_ENUM error is generate
I wonder why piglit didn't report me that failure because I ran it with
-t subroutine before sending the patch...
On 03/02/2017 06:56 PM, Mark Janes wrote:
This patch regresses:
piglit.spec.arb_shader_subroutine.linker.no-overloads_vert
The program in the test should fail to link, but does not
On Wed, Mar 1, 2017 at 7:44 PM, Michel Dänzer wrote:
> P.S. It would be better to put the mesa-announce list only in Bcc on
> this kind of e-mails, to prevent accidental followups there. Reply-to:
> mesa-dev seems useless for that.
GMail seems to ignore Reply-to.
Putting mesa-announce@ in Bcc se
On Wednesday, March 1, 2017 10:40:24 PM PST Jason Ekstrand wrote:
> We used to have an assert in mark_surface_used to protect us from this
> but it's gone now. Instead, we'll assert right before we try to memcpy
> the contents of surf_offset into the binding table.
> ---
> src/mesa/drivers/dri/i9
v2: Rebase onto latest changes
Signed-off-by: Nanley Chery
---
src/intel/vulkan/anv_cmd_buffer.c | 5 ++---
src/intel/vulkan/anv_descriptor_set.c | 26 +-
src/intel/vulkan/anv_private.h| 9 +++--
3 files changed, 22 insertions(+), 18 deletions(-)
diff -
Thanks you. Ok for the no commit access hint.
On 3/2/17, Emil Velikov wrote:
> On 26 February 2017 at 21:58, Gregory Hainaut
> wrote:
>> On 2/25/17, Edward O'Callaghan wrote:
>>> Acked-by: Edward O'Callaghan
>>>
>>> On 02/25/2017 07:45 AM, Gregory Hainaut wrote:
At least, the extension is
Equivalent *TexSubImage* methods generates INVALID_ENUM.
From OpenGL 4.5 spec, section 8.6 Alternate Texture Image
Specification Commands:
"An INVALID_ENUM error is generated by *TexSubImage* if target does
not match the command, as shown in table 8.15."
And:
"An INVALID_OPERATION err
On 2 March 2017 at 17:44, Jason Ekstrand wrote:
> On March 2, 2017 05:05:37 Emil Velikov wrote:
>
>> On 2 March 2017 at 05:28, Jason Ekstrand wrote:
>>>
>>> ---
>>> src/intel/vulkan/anv_wsi_wayland.c | 1 -
>>> 1 file changed, 1 deletion(-)
>>>
>>> diff --git a/src/intel/vulkan/anv_wsi_wayland.
This patch regresses:
piglit.spec.arb_shader_subroutine.linker.no-overloads_vert
The program in the test should fail to link, but does not.
Samuel Pitoiset writes:
> Previously, when q.subroutine was set to 1, a new subroutine
> declaration was added to the AST, while 0 meant a subroutine
> d
On 2 March 2017 at 17:42, Jason Ekstrand wrote:
>
> I think that general message style sounds fine.
>
Ack.
>
> How's this? Trying a new Android email app.
>
Perfect and thanks for the email client suggestion. Glad we have one
that is flexible enough.
-Emil
_
On March 2, 2017 05:05:37 Emil Velikov wrote:
On 2 March 2017 at 05:28, Jason Ekstrand wrote:
---
src/intel/vulkan/anv_wsi_wayland.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/intel/vulkan/anv_wsi_wayland.c
b/src/intel/vulkan/anv_wsi_wayland.c
index 5d49671..690fd30 100644
---
On March 2, 2017 09:28:08 Emil Velikov wrote:
On 2 March 2017 at 16:39, Jason Ekstrand wrote:
On Mar 2, 2017 3:38 AM, "Emil Velikov" wrote:
On 1 March 2017 at 20:06, Jason Ekstrand wrote:
On Wed, Mar 1, 2017 at 10:35 AM, Emil Velikov
wrote:
Hello list,
The candidate for the Mesa 17.0.
On 26 February 2017 at 21:58, Gregory Hainaut wrote:
> On 2/25/17, Edward O'Callaghan wrote:
>> Acked-by: Edward O'Callaghan
>>
>> On 02/25/2017 07:45 AM, Gregory Hainaut wrote:
>>> At least, the extension is exported (gallium capability
>>> PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT is 1)
>>>
>>>
On 2 March 2017 at 16:39, Jason Ekstrand wrote:
> On Mar 2, 2017 3:38 AM, "Emil Velikov" wrote:
>
> On 1 March 2017 at 20:06, Jason Ekstrand wrote:
>> On Wed, Mar 1, 2017 at 10:35 AM, Emil Velikov
>> wrote:
>>>
>>> Hello list,
>>>
>>> The candidate for the Mesa 17.0.1 is now available. Currentl
https://bugs.freedesktop.org/show_bug.cgi?id=100037
Bug ID: 100037
Summary: [vmwgfx] Invalid SVGA3D command: 1202
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: c
On Thu, Mar 2, 2017 at 5:36 PM, Mike Lothian wrote:
> I'm guessing when the code runs the 32bit and 64bit have different build
> times so invalidate the cache and create a new one
>
> On Thu, 2 Mar 2017 at 16:25 Marek Olšák wrote:
>>
>> On Thu, Mar 2, 2017 at 3:03 PM, Mike Lothian wrote:
>> > Is
On Mar 2, 2017 3:38 AM, "Emil Velikov" wrote:
On 1 March 2017 at 20:06, Jason Ekstrand wrote:
> On Wed, Mar 1, 2017 at 10:35 AM, Emil Velikov
> wrote:
>>
>> Hello list,
>>
>> The candidate for the Mesa 17.0.1 is now available. Currently we have:
>> - 60 queued
>> - 9 nominated (outstanding)
>
Could the solution be keeping X number of cache's and delete the oldest
ones, I guess we'd need at least 2
On Thu, 2 Mar 2017 at 16:36 Mike Lothian wrote:
> I'm guessing when the code runs the 32bit and 64bit have different build
> times so invalidate the cache and create a new one
>
> On Thu, 2
I'm guessing when the code runs the 32bit and 64bit have different build
times so invalidate the cache and create a new one
On Thu, 2 Mar 2017 at 16:25 Marek Olšák wrote:
> On Thu, Mar 2, 2017 at 3:03 PM, Mike Lothian wrote:
> > Is this because the 32bit and 64bit versions have slightly differe
On 02/03/2017 17:24, Marek Olšák wrote:
On Thu, Mar 2, 2017 at 3:03 PM, Mike Lothian wrote:
Is this because the 32bit and 64bit versions have slightly different time
stamps used in the cache directory name? I was under the impression that the
cache itself could be shared between 32bit & 64bit?
Reviewed-by: Marek Olšák
Marek
On Wed, Mar 1, 2017 at 8:21 PM, Eric Anholt wrote:
> From: Jonas Pfeil
>
> The header of ralloc needs to be aligned, because the compiler assumes
> that malloc returns will be aligned to 8/16 bytes depending on the
> platform, leading to degraded performance or a
On Thu, Mar 2, 2017 at 7:08 AM, Timothy Arceri wrote:
> ---
> docs/envvars.html | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/docs/envvars.html b/docs/envvars.html
> index 9f1f708..aa56cd1 100644
> --- a/docs/envvars.html
> +++ b/docs/envvars.html
> @@ -112,21 +112,
On Thu, Mar 2, 2017 at 3:03 PM, Mike Lothian wrote:
> Is this because the 32bit and 64bit versions have slightly different time
> stamps used in the cache directory name? I was under the impression that the
> cache itself could be shared between 32bit & 64bit?
>
> I guess this only matters for the
1 - 100 of 134 matches
Mail list logo
