From Chapter 5 'Shared Objects and Multiple Contexts' of
the OpenGL 4.5 spec:
"Objects which contain references to other objects include
framebuffer, program pipeline, query, transform feedback,
and vertex array objects. Such objects are called container
objects and are not shared"
-
---
src/mesa/main/hash.c | 34 ++
src/mesa/main/hash.h | 5 +
2 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/hash.c b/src/mesa/main/hash.c
index b7a7bd9..a3772bd 100644
--- a/src/mesa/main/hash.c
+++ b/src/mesa/main/hash.c
@@ -404
---
src/mesa/main/arrayobj.c | 11 +--
src/mesa/main/attrib.c | 23 +++
src/mesa/main/mtypes.h | 16
src/mesa/main/varray.c | 2 +-
4 files changed, 9 insertions(+), 43 deletions(-)
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.
Shared context support for VAOs was dropped in 0b2750620b65.
From the ARB_vertex_array_object spec:
"This extension differs from GL_APPLE_vertex_array_object
in that client memory cannot be accessed through a
non-zero vertex array object. It also differs in that
vertex array objects
The previous commit removed the only other user of this function.
---
src/mesa/main/arrayobj.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index 1050201..c52a07b 100644
--- a/src/mesa/main/arrayobj
From the EXT_framebuffer_object spec:
"Framebuffer objects created with the commands defined
by the GL_EXT_framebuffer_object extension are defined
to be shared, while FBOs created with commands defined
by the OpenGL core or GL_ARB_framebuffer_object
extension are defined *not* to
Reviewed-by: Edward O'Callaghan
On 04/23/2017 11:13 PM, Giuseppe Bilotta wrote:
> ---
> src/compiler/nir/nir_array.h | 2 +-
> src/compiler/spirv/spirv_to_nir.c | 2 +-
> src/gallium/winsys/svga/drm/vmw_context.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
I tried to use OSMesa to do offscreen rendering, refer to the osdemo and the
tutorial here: http://www.alecjacobson.com/weblog/?p=2827
There are obvious serrations on the edge of the model.
I have tried these solution but all failed, can any one gieve me some
suggestions? the solution I have tri
Split out of "avoid redundant CB register updates" for easier review.
Signed-off-by: Constantine Kharlamov
---
src/gallium/drivers/r600/evergreen_state.c | 76 +++-
src/gallium/drivers/r600/r600_blit.c | 1 +
src/gallium/drivers/r600/r600_hw_context.c | 1 +
No regressions with piglit.
The "avoid redundant CB register updates" mentioned in the 1-st patch not yet
ready, so I decided to send the rest of the code. But just in case anyone has
thoughts: it supposed to finish the work started by 0c2eed0edec (which improved
a shared code of radeonsi/r600g, b
constified some variables, moved two variable declarations into the
cycle where they're used, and removed trailing whitespace.
Signed-off-by: Constantine Kharlamov
---
src/gallium/drivers/r600/evergreen_state.c | 4 +--
src/gallium/drivers/r600/r600_blit.c | 4 +--
src/gallium/drivers/r6
sb-based optimization was only used for older LLVM, whose support was removed
in 100796c15c3a1467d03abc424e6f1494da02f376 "gallium/radeon: drop support for
LLVM 3.5". Since then sbcl variable doesn't do anything.
Signed-off-by: Constantine Kharlamov
---
src/gallium/drivers/r600/r600_pipe.c
Kenneth Graunke writes:
> Curro pointed out that I should not just check for MACH, but use
> the reads_accumulator_implicitly() helper, which would also prevent
> the same bug with MAC and SADA2 (if we ever decide to use them).
>
> Cc: Francisco Jerez
> Cc: mesa-sta...@lists.freedesktop.org
Tha
Reviewed-by: Bas Nieuwenhuizen
On Sun, Apr 23, 2017 at 9:22 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This just updates this to use the same flags as radeonsi
> for consistency.
>
> Signed-off-by: Dave Airlie
> ---
> src/amd/common/ac_llvm_util.c | 2 +-
> 1 file changed, 1 insertion(+),
From: Dave Airlie
This just updates this to use the same flags as radeonsi
for consistency.
Signed-off-by: Dave Airlie
---
src/amd/common/ac_llvm_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
index 3687e
From: Dave Airlie
This is taken from radeonsi, and looks it should enable
output mods in llvm now.
Signed-off-by: Dave Airlie
---
src/amd/common/ac_nir_to_llvm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 4d2e4
On 2017-04-23T18:12:47 +
wrote:
>
> Hello.
>
> I have the following apitrace that seems to indicate a uniform variable
> being erroneously optimized out:
This one is my fault. Due to a preprocessing mishap, the values for the
surface albedo and specular values were being set to (0.0, 0.0, 0.
From: Dave Airlie
Noticed while looking at Sascha Willems deferred shaders.
This is a bit of an llvm workaround, llvm was producing this:
v_cvt_pkrtz_f16_f32_e64 v4, v7, v8 ; D2960004
00021107
v_cvt_pkrtz_f16_f32_e64 v6, v9, 1.0 ; D2960
Hello.
I have the following apitrace that seems to indicate a uniform variable
being erroneously optimized out:
http://ataxia.io7m.com/2017/04/23/r2.trace
Note the (rather large) shader sources at frame 1, call 8383
(glShaderSource). Trimming the sources to the relevant parts gives the
followi
Series is Reviewed-by: Ilia Mirkin
I'd like to get some testing on this to make sure that things do kinda
work, at least as well as on maxwell. Perhaps a deqp run, which has a
lot of compute/image/etc tests?
On Sun, Apr 23, 2017 at 11:19 AM, Boyan Ding wrote:
> Signed-off-by: Boyan Ding
> ---
Signed-off-by: Boyan Ding
---
src/gallium/drivers/nouveau/nvc0/nve4_compute.c | 105 ++--
src/gallium/drivers/nouveau/nvc0/nve4_compute.h | 67 +++
2 files changed, 166 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nve4_compute.c
b/
Signed-off-by: Boyan Ding
---
src/gallium/drivers/nouveau/nvc0/nve4_compute.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nve4_compute.h
b/src/gallium/drivers/nouveau/nvc0/nve4_compute.h
index 5fe58b9671..75b169323b 100644
--- a/src/ga
Pascal uses a new compute launch descriptor format that is not compatible
with previous generations. This series adds support for the new format,
thus enabling ARB_compute_shader for Pascal. The piglit tests for compute
shader all passed on my GP107.
The first two patches are cosmetic fixes discov
Signed-off-by: Boyan Ding
---
src/gallium/drivers/nouveau/nv_object.xml.h | 2 ++
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 6 ++
src/gallium/drivers/nouveau/nvc0/nve4_compute.c | 3 +++
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv_
Signed-off-by: Boyan Ding
---
src/gallium/drivers/nouveau/nv_object.xml.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv_object.xml.h
b/src/gallium/drivers/nouveau/nv_object.xml.h
index f200c9c9c9..1263bff450 100644
--- a/src/gallium/driver
---
src/compiler/nir/nir_array.h | 2 +-
src/compiler/spirv/spirv_to_nir.c | 2 +-
src/gallium/winsys/svga/drm/vmw_context.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/compiler/nir/nir_array.h b/src/compiler/nir/nir_array.h
index 4d7a532a7f..049
https://bugs.freedesktop.org/show_bug.cgi?id=100741
--- Comment #1 from Bartosz Tomczyk ---
I've bisected it and first bad commit is:
commit a5e733c6b52e93de3000647d075f5ca2f55fcb71
Author: Rob Clark
Date: Wed Oct 26 16:52:52 2016 -0400
mesa: drop current draw/read buffer when ctx is rel
https://bugs.freedesktop.org/show_bug.cgi?id=100693
--- Comment #9 from Hi-Angel ---
(In reply to Hi-Angel from comment #5)
> This is a funny one. I googled up that such a cast is used to make a compiler
> to not show a warning about a unused variable, and it's funny that for ICC it
> turned up i
28 matches
Mail list logo
