Reviewed-by: Chris Forbes
On Sat, Jun 27, 2015 at 11:31 AM, Kenneth Graunke wrote:
> On Friday, June 26, 2015 04:17:39 PM Jason Ekstrand wrote:
>> On Fri, Jun 26, 2015 at 3:56 PM, Kenneth Graunke
>> wrote:
>> > Legacy user clipping (using gl_Position or gl_ClipVertex) is handled by
>> > turnin
Freedreno requires {a4xx,ir3}_SOURCES and NIR to build.
Signed-off-by: Varad Gautam
---
src/gallium/drivers/freedreno/Android.mk | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/freedreno/Android.mk
b/src/gallium/drivers/freedreno/Android.mk
index a671
Signed-off-by: Rhys Kidd
---
doxygen/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/doxygen/.gitignore b/doxygen/.gitignore
index abf56ac..a5f3921 100644
--- a/doxygen/.gitignore
+++ b/doxygen/.gitignore
@@ -1,3 +1,4 @@
+*.db
*.tag
*.tmp
agpgart
--
2.1.4
_
Signed-off-by: Rhys Kidd
---
doxygen/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/doxygen/Makefile b/doxygen/Makefile
index 0a95a35..01c2691 100644
--- a/doxygen/Makefile
+++ b/doxygen/Makefile
@@ -33,3 +33,4 @@ subset: $(SUBSET:.doxy=.tag)
clean:
-rm -rf $(FULL:.doxy=) $
A simple patch set for my first proposed Mesa contribution.
Modern doxygen uses a SQLite intermediate output file when producing
documentation from source code. Mesa's Makefile and .gitignore in doxygen/
could better handle this output file, which these two patches address.
Rhys Kidd (2):
doxyg
Jason Ekstrand writes:
> On Fri, Jun 26, 2015 at 3:34 PM, Francisco Jerez
> wrote:
>> Jason Ekstrand writes:
>>
>>> On Fri, Jun 26, 2015 at 3:03 PM, Francisco Jerez
>>> wrote:
Jason Ekstrand writes:
> On Fri, Jun 26, 2015 at 12:08 PM, Francisco Jerez
> wrote:
>> Jaso
https://bugs.freedesktop.org/show_bug.cgi?id=91123
Bug ID: 91123
Summary: [swrast] piglit egl-create-pbuffer-surface regression
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
On Friday, June 26, 2015 04:15:46 PM Jordan Justen wrote:
> On 2015-06-26 15:18:52, Kenneth Graunke wrote:
> > According to the "URB SIMD8 Write > Write Data Payload" documentation,
> > "The write data payload can be between 1 and 8 message phases long."
>
> Would a more precise PRM ref location b
On Fri, Jun 26, 2015 at 3:34 PM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> On Fri, Jun 26, 2015 at 3:03 PM, Francisco Jerez
>> wrote:
>>> Jason Ekstrand writes:
>>>
On Fri, Jun 26, 2015 at 12:08 PM, Francisco Jerez
wrote:
> Jason Ekstrand writes:
>
>> In C,
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 5653d6b..309f495 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src
first_non_payload_grf may be updated in assign_urb_setup for FS or
assign_vs_urb_setup for VS.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drive
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_context.h | 2 +-
src/mesa/drivers/dri/i965/brw_state_upload.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 51a1447
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_cs.cpp | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_cs.cpp
b/src/mesa/drivers/dri/i965/brw_cs.cpp
index 63e3b8d..bf43def 100644
--- a/src/mesa/drivers/dri/i965/brw_
With these environment overrides:
MESA_GL_VERSION_OVERRIDE=4.3
MESA_GLSL_VERSION_OVERRIDE=430
MESA_EXTENSION_OVERRIDE=GL_ARB_compute_shader
This series allows this piglit test to pass:
tests/spec/arb_compute_shader/execution/basic-texelFetch.shader_test
Note, these patches were applied on top
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 72aad96..0eb5361 100644
--- a/sr
On Friday, June 26, 2015 04:17:39 PM Jason Ekstrand wrote:
> On Fri, Jun 26, 2015 at 3:56 PM, Kenneth Graunke
> wrote:
> > Legacy user clipping (using gl_Position or gl_ClipVertex) is handled by
> > turning those into the modern gl_ClipDistance equivalents.
> >
> > This is unnecessary in Core Pro
Reviewed-by: Marek Olšák
Marek
On Sat, Jun 27, 2015 at 1:15 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This isn't pretty and I'd suggest it the pm4 interface builder
> could be tweaked to do this more efficently, but I'd need
> guidance on how that would look.
>
> This seems to pass the fe
On Fri, Jun 26, 2015 at 3:56 PM, Kenneth Graunke wrote:
> Legacy user clipping (using gl_Position or gl_ClipVertex) is handled by
> turning those into the modern gl_ClipDistance equivalents.
>
> This is unnecessary in Core Profile: if user clipping is enabled, but
> the shader doesn't write the co
On 2015-06-26 15:18:52, Kenneth Graunke wrote:
> According to the "URB SIMD8 Write > Write Data Payload" documentation,
> "The write data payload can be between 1 and 8 message phases long."
Would a more precise PRM ref location be possible?
Reviewed-by: Jordan Justen
> Apparently, the simulato
On 27 June 2015 at 09:03, Marek Olšák wrote:
> If you write VIEWPORT_INDEX at location 0, it overwrites POSITION
> which happens to be at location 0 too and that's why the test fails.
>
> The fix is not to call si_shader_io_get_unique_index (or its caller
> get_param_index) for LAYER and VIEWPORT_
From: Dave Airlie
This isn't pretty and I'd suggest it the pm4 interface builder
could be tweaked to do this more efficently, but I'd need
guidance on how that would look.
This seems to pass the few piglit tests I threw at it.
v2: handle passing layer/viewport index to fragment shader.
fix cras
If you write VIEWPORT_INDEX at location 0, it overwrites POSITION
which happens to be at location 0 too and that's why the test fails.
The fix is not to call si_shader_io_get_unique_index (or its caller
get_param_index) for LAYER and VIEWPORT_INDEX.
LAYER and VIEWPORT_INDEX should be ignored in
s
Adding new shader stages to a switch statement is less confusing than an
if-else-if ladder where all but the first case are fragment shader
specific (but don't claim to be).
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 59 +-
1 file
Legacy user clipping (using gl_Position or gl_ClipVertex) is handled by
turning those into the modern gl_ClipDistance equivalents.
This is unnecessary in Core Profile: if user clipping is enabled, but
the shader doesn't write the corresponding gl_ClipDistance entry,
results are undefined. Hence,
Reviewed-by: Jordan Justen
On 2015-06-22 11:18:55, Kenneth Graunke wrote:
> We were not emitting the LOD, which led to message lengths of 1 instead
> of 3. Setting has_lod makes us emit the LOD, but I had to make changes
> to avoid emitting the non-existent coordinate as well.
>
> Bugzilla: htt
Jason Ekstrand writes:
> On Fri, Jun 26, 2015 at 3:03 PM, Francisco Jerez
> wrote:
>> Jason Ekstrand writes:
>>
>>> On Fri, Jun 26, 2015 at 12:08 PM, Francisco Jerez
>>> wrote:
Jason Ekstrand writes:
> In C, if you partially initialize a structure, the rest of the struct gets
According to the "URB SIMD8 Write > Write Data Payload" documentation,
"The write data payload can be between 1 and 8 message phases long."
Apparently, the simulator considers it an error if you issue an URB
SIMD8 message with only a header and no actual data to write.
Signed-off-by: Kenneth Grau
On Fri, Jun 26, 2015 at 3:03 PM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> On Fri, Jun 26, 2015 at 12:08 PM, Francisco Jerez
>> wrote:
>>> Jason Ekstrand writes:
>>>
In C, if you partially initialize a structure, the rest of the struct gets
set to 0. C++, however, does no
Jason Ekstrand writes:
> On Fri, Jun 26, 2015 at 12:08 PM, Francisco Jerez
> wrote:
>> Jason Ekstrand writes:
>>
>>> In C, if you partially initialize a structure, the rest of the struct gets
>>> set to 0. C++, however, does not have this rule so GCC throws warnings
>>> whenver NIR_SRC_INIT o
There isn't any bugzilla entry for this yet. I just saw it in the source
code so far rather than in a misbehaving program.
Perhaps piglit could use a few tests for whether meta operations damage
context attributes.
On Fri, Jun 26, 2015 at 3:26 PM, Kenneth Graunke
wrote:
> On Friday, June 26, 20
On Fri, Jun 26, 2015 at 12:08 PM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> In C, if you partially initialize a structure, the rest of the struct gets
>> set to 0. C++, however, does not have this rule so GCC throws warnings
>> whenver NIR_SRC_INIT or NIR_DEST_INIT is used in C++.
>
>
On Thursday, June 25, 2015 02:29:13 PM Tapani Pälli wrote:
> Huh I see this went in already, I've noticed a problem and thought to
> share it.
>
> Currently program resource list (used by gl api shader queries) is
> generated in linker, before backend LinkShader call. What this means is
> that
On Friday, June 26, 2015 03:15:46 PM Mike Stroyan wrote:
> The meta code was setting a default depth range for all viewports
> and 'restoring' all viewports to depth range values saved from viewport 0.
> ---
> src/mesa/drivers/common/meta.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(
The meta code was setting a default depth range for all viewports
and 'restoring' all viewports to depth range values saved from viewport 0.
---
src/mesa/drivers/common/meta.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/
On 26 June 2015 at 07:43, Dave Airlie wrote:
> On 26 June 2015 at 07:11, Marek Olšák wrote:
>> Wait a moment, how did it fail with si_shader_io_get_unique_index? The
>> function shouldn't be called for ES with the viewport index, because
>> ES can't pass the output to GS. If it was called, ignori
Series LGTM. Reviewed-by: Brian Paul
On 06/26/2015 12:22 PM, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/docs/d3d11ddi.txt | 462 --
1 file changed, 462 deletions(-)
delete mode 100644 src/gallium/docs/d3d11ddi.txt
diff --git a/src/galli
On Mon, Jun 22, 2015 at 5:23 PM, Anuj Phogat wrote:
> On Mon, Jun 22, 2015 at 2:53 PM, Ben Widawsky wrote:
>> On Wed, Jun 10, 2015 at 03:30:47PM -0700, Anuj Phogat wrote:
>>> Buffers with Yf/Ys tiling end up using meta upload / download
>>> paths or the blitter for cases where they used tiled_mem
On Fri, Jun 19, 2015 at 4:48 PM, Anuj Phogat wrote:
> On Thu, Jun 18, 2015 at 5:26 AM, Iago Toral wrote:
>> On Tue, 2015-06-16 at 11:15 -0700, Anuj Phogat wrote:
>>> Without this patch, arb_color_buffer_float-readpixels test fails, when
>>> forced to use meta pbo path.
>>>
>>> Signed-off-by: Anuj
Currently used ctx->_ImageTransferState check is not sufficient
because it doesn't include the read color clamping enabled with
GL_CLAMP_READ_COLOR. So, use the helper function
_mesa_get_readpixels_transfer_ops().
Also, transfer operations don't affect glGetTexImage(). So, do
the check only for gl
On Fri, Jun 26, 2015 at 11:39 AM, Nanley Chery wrote:
> From: Nanley Chery
>
> Aligning with a non-power-of-two number is a general task that can be used in
> various places. This commit is required for the next one.
>
> v2: add greater than 0 assertion (Anuj).
> convert the macro to a static
As others pointed, volatile and atomic are slightly different things,
but you have point: atomic operations should probably take volatile
pointers as arguments.
This is what C11 did
http://en.cppreference.com/w/c/atomic/atomic_load
so I do believe that it makes sense to update p_atomic help
Jason Ekstrand writes:
> In C, if you partially initialize a structure, the rest of the struct gets
> set to 0. C++, however, does not have this rule so GCC throws warnings
> whenver NIR_SRC_INIT or NIR_DEST_INIT is used in C++.
I don't think that's right, in C++ initializers missing from an
ag
https://bugs.freedesktop.org/show_bug.cgi?id=91118
--- Comment #1 from Béla Gyebrószki ---
The following patch by Ilia Mirkin also fixes the crash for me:
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 79fa018..f7d8028 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/mai
An immediate has to be the second arg of an ADD operation. However we
were mistakenly propagating the modifier of the non-folded value to the
folded immediate argument.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91117
Signed-off-by: Ilia Mirkin
Cc: "10.5 10.6"
---
src/gallium/driver
On 06/26/2015 12:06 PM, Erik Faye-Lund wrote:
In order to save a small leak if mesa is continously loaded and
unloaded, let's free the locale when the shared object is unloaded.
Signed-off-by: Erik Faye-Lund
Reviewed-by: Matt Turner
---
src/mesa/main/context.c | 12 +++-
src/util/st
Jason Ekstrand writes:
> On Fri, Jun 26, 2015 at 8:52 AM, Francisco Jerez
> wrote:
>> Jason Ekstrand writes:
>>
>>> Reviewed-by: Topi Pohjolainen
>>> ---
>>> src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/src/mesa/drivers/dri
https://bugs.freedesktop.org/show_bug.cgi?id=91118
Bug ID: 91118
Summary: Skydrift (running in Wine) crashes on start
Product: Mesa
Version: 10.6
Hardware: Other
URL: http://store.steampowered.com/app/91100/
OS:
From: Nanley Chery
Aligning with a non-power-of-two number is a general task that can be used in
various places. This commit is required for the next one.
v2: add greater than 0 assertion (Anuj).
convert the macro to a static inline function.
Signed-off-by: Nanley Chery
---
src/mesa/drive
On Fri, Jun 26, 2015 at 8:52 AM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> Reviewed-by: Topi Pohjolainen
>> ---
>> src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
>> b/src/mesa/drivers/
In C, if you partially initialize a structure, the rest of the struct gets
set to 0. C++, however, does not have this rule so GCC throws warnings
whenver NIR_SRC_INIT or NIR_DEST_INIT is used in C++. Since nir.h contains
a static inline that uses NIR_SRC_INIT, every C++ file that includes nir.h
c
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_pipe_common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index c38155f..61d4f09 100644
--- a/src/gallium/drivers/radeon/r6
From: Marek Olšák
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index edce1fb..3b960c0 100644
--- a/src/gallium/winsys/radeon/
From: Marek Olšák
---
src/gallium/state_trackers/clover/core/event.cpp | 2 +-
src/gallium/state_trackers/nine/swapchain9.c | 2 +-
src/gallium/state_trackers/vdpau/presentation.c | 2 +-
src/gallium/state_trackers/xvmc/surface.c| 2 +-
src/mesa/state_tracker/st_cb_syncobj.c
From: Marek Olšák
This will be used by radeon and amdgpu winsyses.
Copied from the amdgpu winsys.
v2: use volatile and p_atomic_read
---
src/gallium/auxiliary/os/os_time.c | 36 +++-
src/gallium/auxiliary/os/os_time.h | 10 ++
2 files changed, 45 insertio
From: Marek Olšák
fence_finish(timeout=0) does the same thing
---
src/gallium/drivers/freedreno/freedreno_screen.c | 1 -
src/gallium/drivers/i915/i915_screen.c | 10 --
src/gallium/drivers/ilo/ilo_screen.c | 8
src/gallium/drivers/llvmpipe/lp_screen.c
From: Marek Olšák
---
src/gallium/docs/d3d11ddi.txt | 462 --
1 file changed, 462 deletions(-)
delete mode 100644 src/gallium/docs/d3d11ddi.txt
diff --git a/src/gallium/docs/d3d11ddi.txt b/src/gallium/docs/d3d11ddi.txt
deleted file mode 100644
index a703
From: Marek Olšák
I copied what fence_signalled does.
---
src/gallium/drivers/freedreno/freedreno_fence.c | 3 +++
src/gallium/drivers/i915/i915_screen.c | 3 +++
src/gallium/drivers/llvmpipe/lp_screen.c| 3 +++
src/gallium/drivers/nouveau/nouveau_screen.c| 3 +++
src/galliu
On Thu, Jun 25, 2015 at 4:16 PM, Anuj Phogat wrote:
> On Thu, Jun 25, 2015 at 3:22 PM, Nanley Chery wrote:
>> How about if I create a patch which puts the greater than 0 check into
>> is_power_of_two()?
>>
>> (value > 0) && (value & (value - 1)) == 0);
>>
> Not a bad idea except that you'll need
There's no point in calling _mesa_destroy_shader_compiler multiple
times on exit; the resources will only be released once anyway.
So let's move the atexit-call into the part that is only called
once.
Signed-off-by: Erik Faye-Lund
Reviewed-by: Matt Turner
---
src/mesa/main/context.c | 7 ++
This function is for deleting per-screen resources, and the shader
compiler resources are not of such nature. Besides, dri shouldn't
need to even know about the presence of a shader compiler.
These resources will already be released when mesa gets unloaded,
and that should be sufficient.
Signed-o
In order to save a small leak if mesa is continously loaded and
unloaded, let's free the locale when the shared object is unloaded.
Signed-off-by: Erik Faye-Lund
Reviewed-by: Matt Turner
---
src/mesa/main/context.c | 12 +++-
src/util/strtod.c | 8
src/util/strtod.h
_mesa_strtod and _mesa_strtof are only used from the GLSL compiler and
the ARB_[vertex|fragment]_program code, meaning that the locale doesn't
need to be initialized before the first OpenGL context gets initialized.
So let's use explicit initialization from the one-time init code instead
of depend
This function only gets called while mesa is unloading, so there's
no potential of racing or multiple calls at the same time. So let's
just get rid of the locking.
Signed-off-by: Erik Faye-Lund
Reviewed-by: Matt Turner
---
src/glsl/glsl_types.cpp | 8
1 file changed, 4 insertions(+), 4
All of these enums are now in use around in the code, so there's no need
to explicitly use them here any more.
Signed-off-by: Erik Faye-Lund
Reviewed-by: Matt Turner
---
src/mesa/main/context.c | 27 ---
1 file changed, 27 deletions(-)
diff --git a/src/mesa/main/context
Here's the third version of this series (previsou version was
posted as [1]). A couple of typos in patch 4 was fixed, an
incorrectly squashed hunk was removed from patch 5. And finally,
patch 7 was skipped completely.
[1]: <1435266326-13540-1-git-send-email-kusmab...@gmail.com>
Erik Faye-Lund (6)
On Fri, Jun 26, 2015 at 11:40 AM, Marek Olšák wrote:
> If p_atomic_read is fine, then this patch is fine too. So you're
> telling that this should work:
>
> while (p_atomic_read(var));
>
> I wouldn't be concerned about a memory barrier. This is only 1 int, so
> it should make its way into the sha
Grigori Goronzy writes:
> On 2015-06-09 22:52, Francisco Jerez wrote:
>>> +
>>> + if (blocking)
>>> + hev().wait();
>>> +
>>
>> hard_event::wait() may fail, so this should probably be done before the
>> ret_object() call to avoid leaks.
>
> Alright... C++ exceptions are a minefield. :)
>
On Fri, Jun 26, 2015 at 05:54:15PM +0100, Neil Roberts wrote:
> Since commit 104c8fc2c2aa5621261f8 the GLSL IR will be freed if NIR is
> being used. This was causing it to segfault if INTEL_DEBUG=wm is set.
> This patch just makes it avoid dumping the GLSL IR in that case.
> ---
> src/mesa/drivers
Since commit 104c8fc2c2aa5621261f8 the GLSL IR will be freed if NIR is
being used. This was causing it to segfault if INTEL_DEBUG=wm is set.
This patch just makes it avoid dumping the GLSL IR in that case.
---
src/mesa/drivers/dri/i965/brw_program.c | 11 +++
1 file changed, 7 insertions(+
Davin McCall writes:
> On 26/06/15 17:08, Eirik Byrkjeflot Anonsen wrote:
>> Davin McCall writes:
>>
>>> On 26/06/15 14:31, Eirik Byrkjeflot Anonsen wrote:
Erik Faye-Lund writes:
> On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall wrote:
>> On 26/06/15 12:03, Davin McCall wrote:
On Fri, Jun 26, 2015 at 12:40 PM, Marek Olšák wrote:
> If p_atomic_read is fine, then this patch is fine too. So you're
> telling that this should work:
>
> while (p_atomic_read(var));
No, this shouldn't work. I don't believe that anyone ever claimed it
ought to. But perhaps we have different ide
If p_atomic_read is fine, then this patch is fine too. So you're
telling that this should work:
while (p_atomic_read(var));
I wouldn't be concerned about a memory barrier. This is only 1 int, so
it should make its way into the shared cache eventually.
Marek
On Fri, Jun 26, 2015 at 6:25 PM, Ili
On 26/06/15 17:08, Eirik Byrkjeflot Anonsen wrote:
Davin McCall writes:
On 26/06/15 14:31, Eirik Byrkjeflot Anonsen wrote:
Erik Faye-Lund writes:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall wrote:
On 26/06/15 12:03, Davin McCall wrote:
... The stored value of 'n' is not accessed by an
Grigori Goronzy writes:
> On 2015-05-28 13:04, Grigori Goronzy wrote:
>> Work-group size should always be aligned to subgroup size; this is a
>> basic requirement, otherwise some work-items will be no-operation.
>>
>> It might make sense to refine the value according to a kernel's
>> resource us
On Fri, Jun 26, 2015 at 6:14 PM, Ilia Mirkin wrote:
> On Fri, Jun 26, 2015 at 12:03 PM, Emil Velikov
> wrote:
>> On 25 June 2015 at 23:10, Matt Turner wrote:
>>> On Thu, Jun 25, 2015 at 2:05 PM, Erik Faye-Lund wrote:
Back in March[1], I sent a patch porting _mesa_strto[df] to
C rathe
On Fri, Jun 26, 2015 at 6:03 PM, Emil Velikov wrote:
> On 25 June 2015 at 23:10, Matt Turner wrote:
>> On Thu, Jun 25, 2015 at 2:05 PM, Erik Faye-Lund wrote:
>>> Back in March[1], I sent a patch porting _mesa_strto[df] to
>>> C rather than C++. I fixed up the patch according to the
>>> criticism
p_atomic_read is fine as-is. The read is guaranteed to be atomic up to
a word size on x86 processors. I suspect other cpu's have similar
guarantees, and if not, then hopefully have other ops to perform the
read atomically.
On Fri, Jun 26, 2015 at 12:18 PM, Marek Olšák wrote:
> My question was how
Francisco Jerez writes:
> Erik Faye-Lund writes:
>
>> On Fri, Jun 26, 2015 at 4:01 PM, Francisco Jerez
>> wrote:
>>> Davin McCall writes:
>>>
On 26/06/15 14:31, Eirik Byrkjeflot Anonsen wrote:
> Erik Faye-Lund writes:
>
>> On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall wrote
My question was how to fix p_atomic_read? Would the volatile read that
I proposed work?
Marek
On Fri, Jun 26, 2015 at 5:59 PM, Ilia Mirkin wrote:
> The compiler doesn't know that there's another thread. And it won't
> start to assume that there might always be another thread because then
> it c
On Fri, Jun 26, 2015 at 12:03 PM, Emil Velikov wrote:
> On 25 June 2015 at 23:10, Matt Turner wrote:
>> On Thu, Jun 25, 2015 at 2:05 PM, Erik Faye-Lund wrote:
>>> Back in March[1], I sent a patch porting _mesa_strto[df] to
>>> C rather than C++. I fixed up the patch according to the
>>> criticis
Davin McCall writes:
> On 26/06/15 14:31, Eirik Byrkjeflot Anonsen wrote:
>> Erik Faye-Lund writes:
>>
>>> On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall wrote:
On 26/06/15 12:03, Davin McCall wrote:
> ... The stored value of 'n' is not accessed by any other type than the
> type of
My patch should fix those too.
Since this is glBlitFramebuffer, it shouldn't need any gallium states,
so the st_validate_state call is mostly useless and all unnecessary
operations should skipped. Sadly, there is little interest in such
optimizations nowadays, but I understand that people are busy
On 26 June 2015 at 13:54, Boyan Ding wrote:
> Can someone help me push this please?
>
Added Marek's r-b and pushed to master.
Thanks for the patch !
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/list
On 25 June 2015 at 23:10, Matt Turner wrote:
> On Thu, Jun 25, 2015 at 2:05 PM, Erik Faye-Lund wrote:
>> Back in March[1], I sent a patch porting _mesa_strto[df] to
>> C rather than C++. I fixed up the patch according to the
>> criticism, but unfortunately I dropped the ball before I sent
>> out
The compiler doesn't know that there's another thread. And it won't
start to assume that there might always be another thread because then
it could never optimize pointer derefs.
On Fri, Jun 26, 2015 at 11:55 AM, Marek Olšák wrote:
> I assumed the atomic operation in another thread would act as a
I assumed the atomic operation in another thread would act as a
barrier in this case. Is that right?
Marek
On Fri, Jun 26, 2015 at 5:47 PM, Ilia Mirkin wrote:
> On Fri, Jun 26, 2015 at 11:33 AM, Marek Olšák wrote:
>> I expect the variable will be changed using an atomic operation by the
>> CPU,
Jason Ekstrand writes:
> Reviewed-by: Topi Pohjolainen
> ---
> src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
> b/src/mesa/drivers/dri/i965/brw_fs.h
> index d4cc43d..d94a842 100644
> --- a/src/mesa/
On Fri, Jun 26, 2015 at 11:33 AM, Marek Olšák wrote:
> I expect the variable will be changed using an atomic operation by the
> CPU, or using a coherent store instruction by the GPU.
>
> If this is wrong and volatile is really required here, then
> p_atomic_read is wrong too. Should we fix it? For
On Fri, Jun 26, 2015 at 5:32 PM, Davin McCall wrote:
> On 26/06/15 15:29, Erik Faye-Lund wrote:
>
> On Fri, Jun 26, 2015 at 4:16 PM, Davin McCall wrote:
>
> On 26/06/15 14:53, Erik Faye-Lund wrote:
>
> On Fri, Jun 26, 2015 at 3:05 PM, Davin McCall wrote:
>
> [...]
>
> It is. In fact, it's not ev
Yeah, but there are a whole bunch of places, non-blit-related, where
we call st_validate_state that will hit this same problem.
On Fri, Jun 26, 2015 at 11:43 AM, Brian Paul wrote:
> If we really do need to call _mesa_update_state() for this, I think the
> right place would be in _mesa_blit_frameb
If we really do need to call _mesa_update_state() for this, I think the
right place would be in _mesa_blit_framebuffer(), not in the state tracker.
-Brian
On 06/26/2015 09:17 AM, Ilia Mirkin wrote:
So that obviously avoids the crash. I guess I was unsure if that was
the right way forward. The
On 26/06/15 14:53, Francisco Jerez wrote:
Davin McCall writes:
On 26/06/15 13:18, Francisco Jerez wrote:
Davin McCall writes:
On 26/06/15 11:08, Erik Faye-Lund wrote:
On Thu, Jun 25, 2015 at 1:48 AM, Davin McCall wrote:
This is an alternative to my earlier patch [1] (and it is now const
On 06/25/2015 05:11 PM, Matt Turner wrote:
On Mon, Mar 23, 2015 at 12:25 PM, Stefan Dösinger
wrote:
This fixes a GL error warning on r200 in Wine.
The GL_ARB_sampler_objects extension does not specify a dependency on
GL_ARB_shadow or GL_ARB_depth_texture for this value. Just set the value
and
On 26/06/15 15:29, Erik Faye-Lund wrote:
On Fri, Jun 26, 2015 at 4:16 PM, Davin McCall wrote:
On 26/06/15 14:53, Erik Faye-Lund wrote:
On Fri, Jun 26, 2015 at 3:05 PM, Davin McCall wrote:
[...]
It is. In fact, it's not even possible to violate strict-aliasing
without doing at least two oper
I expect the variable will be changed using an atomic operation by the
CPU, or using a coherent store instruction by the GPU.
If this is wrong and volatile is really required here, then
p_atomic_read is wrong too. Should we fix it? For example:
#define p_atomic_read(_v) (*(volatile int*)(_v))
Th
On Fri, Jun 26, 2015 at 5:25 PM, Francisco Jerez wrote:
> Erik Faye-Lund writes:
>
>> On Fri, Jun 26, 2015 at 4:53 PM, Francisco Jerez
>> wrote:
>>> Erik Faye-Lund writes:
>>>
On Fri, Jun 26, 2015 at 4:16 PM, Davin McCall wrote:
> On 26/06/15 14:53, Erik Faye-Lund wrote:
>>
>
Erik Faye-Lund writes:
> On Fri, Jun 26, 2015 at 4:01 PM, Francisco Jerez
> wrote:
>> Davin McCall writes:
>>
>>> On 26/06/15 14:31, Eirik Byrkjeflot Anonsen wrote:
Erik Faye-Lund writes:
> On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall wrote:
>> On 26/06/15 12:03, Davin McC
Erik Faye-Lund writes:
> On Fri, Jun 26, 2015 at 4:53 PM, Francisco Jerez
> wrote:
>> Erik Faye-Lund writes:
>>
>>> On Fri, Jun 26, 2015 at 4:16 PM, Davin McCall wrote:
On 26/06/15 14:53, Erik Faye-Lund wrote:
>
> On Fri, Jun 26, 2015 at 3:05 PM, Davin McCall wrote:
>>
>
On Fri, Jun 26, 2015 at 5:09 PM, Erik Faye-Lund wrote:
> On Fri, Jun 26, 2015 at 4:53 PM, Francisco Jerez
> wrote:
>> Erik Faye-Lund writes:
>>
>>> On Fri, Jun 26, 2015 at 4:16 PM, Davin McCall wrote:
On 26/06/15 14:53, Erik Faye-Lund wrote:
>
> On Fri, Jun 26, 2015 at 3:05 PM, Da
So that obviously avoids the crash. I guess I was unsure if that was
the right way forward. The way that I understand it, there's "direct"
state in the context, and there's derived state. And
_mesa_update_state() will update the derived state. Since the various
st atoms use derived state, doesn't i
1 - 100 of 237 matches
Mail list logo