From: Ian Romanick ian.d.roman...@intel.com
There exists hardware, such as i965, that does not implement the OpenGL
semantic for gl_VertexID. Instead, that hardware does not include the
value of basevertex in the gl_VertexID value.
SYSTEM_VALUE_VERTEX_ID_ZERO_BASE is the system value that
We'll need to emit another VERTEX_BUFFER_STATE for gl_BaseVertex;
pulling this into a helper function will save us from having to deal
with cross-generation differences in that code.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_draw_upload.c | 77
From: Ian Romanick ian.d.roman...@intel.com
v2: Additions to the documentation for SYSTEM_VALUE_VERTEX_ID. Quote
the GL_ARB_shader_draw_parameters spec and mention DirectX SV_VertexID.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
---
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git
This is more efficient.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/shader_query.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
You can't see it in the diff, but this is in a switch statement on
var-data.mode, in the ir_var_system_value case.
diff
From: Ian Romanick ian.d.roman...@intel.com
The next patch will use this function in a different file.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
---
src/glsl/linker.cpp | 9 +
src/glsl/linker.h | 3 +++
2 files changed, 8
This will be used for GL_ARB_shader_draw_parameters, as well as fixing
gl_VertexID, which is supposed to include gl_BaseVertex's value.
For indirect draws, we simply point at the indirect buffer; for normal
draws, we upload the value via the upload buffer.
Signed-off-by: Kenneth Graunke
Now that we have the data available, we need to expose it to the
shaders. We can reuse the same vertex element that we use for
gl_VertexID, but we need to back it by an actual vertex buffer.
A hardware restriction requires that vertex attributes coming from a
buffer (STORE_SRC) must come before
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.h | 8
src/mesa/drivers/dri/i965/brw_draw.c | 17 -
src/mesa/drivers/dri/i965/brw_draw.h | 2 ++
src/mesa/drivers/dri/i965/brw_draw_upload.c | 12
The lower_vertex_id pass converts uses of the gl_VertexID system value
to the gl_BaseVertex and gl_VertexIDMESA system values. Since
gl_VertexID is no longer accessed, it would not be considered active.
Of course, it should be, since the shader uses gl_VertexID.
Signed-off-by: Kenneth Graunke
From: Ian Romanick ian.d.roman...@intel.com
Converts gl_VertexID to (gl_VertexIDMESA + gl_BaseVertex). gl_VertexIDMESA
is backed by SYSTEM_VALUE_VERTEX_ID_ZERO_BASE, and gl_BaseVertex is backed
by SYSTEM_VALUE_BASE_VERTEX.
v2: Put the enum in struct gl_constants and propoerly resolve the scope
From: Ian Romanick ian.d.roman...@intel.com
Fixes the (new) piglit tests gles-3.0-drawarrays-vertexid,
gl-3.0-multidrawarrays-vertexid, and gl-3.2-basevertex-vertexid.
Fixes gles3conform failure in:
ES3-CTS.gtf.GL3Tests.transform_feedback.transform_feedback_vertex_id
Bugzilla:
From: Ian Romanick ian.d.roman...@intel.com
This system value represents the basevertex value passed to
glDrawElementsBaseVertex and related functions.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/main/mtypes.h | 15 ++-
On Friday, August 08, 2014 12:31:07 AM Kenneth Graunke wrote:
From: Ian Romanick ian.d.roman...@intel.com
This system value represents the basevertex value passed to
glDrawElementsBaseVertex and related functions.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
On Thursday, August 07, 2014 10:41:36 PM Roland Scheidegger wrote:
Am 07.08.2014 20:25, schrieb Jason Ekstrand:
Michel,
On Thu, Aug 7, 2014 at 12:04 AM, Michel Dänzer mic...@daenzer.net
mailto:mic...@daenzer.net wrote:
On 07.08.2014 02:02, Jason Ekstrand wrote:
Michael,
This adds support for Marek's new driconf parameter, which avoids
totally white rendering in Unigine Valley (which attempts to enable
the GL_ARB_sample_shading extension in an illegal place).
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.c | 3
On Wed, Aug 06, 2014 at 04:54:38PM -0700, Matt Turner wrote:
I think OpenVMS was the only platform that Mesa ran on that used a
non-IEEE representation for floats. We removed OpenVMS support a while
back, and this should alleviate the need to continue updating the
this-platform-uses-IEEE list.
Jason Ekstrand ja...@jlekstrand.net writes:
+ if (src_mt == dst_mt src_level == dst_level src_z == dst_z) {
+ /* If we are on the same miptree, same level, and same slice, then
+ * intel_miptree_map won't let us map it twice. We have to do a
+ * single map in read-write
From: Pekka Paalanen pekka.paala...@collabora.co.uk
The EGL_EXT_image_dma_buf_import specification was revised (according to
its revision history) on Dec 5th, 2013, for EGL to not take ownership of
the file descriptors.
Do not close the file descriptors passed in to eglCreateImageKHR with
Am 08.08.2014 09:37, schrieb Kenneth Graunke:
On Friday, August 08, 2014 12:31:07 AM Kenneth Graunke wrote:
From: Ian Romanick ian.d.roman...@intel.com
This system value represents the basevertex value passed to
glDrawElementsBaseVertex and related functions.
Signed-off-by: Ian Romanick
Tom Stellard t...@stellard.net writes:
On Thu, Aug 07, 2014 at 04:02:40PM +0300, Francisco Jerez wrote:
Jan Vesely jan.ves...@rutgers.edu writes:
This respin includes Francisco's approach of providing implicit
in the arg vector passed from clover, and Tom's idea of appending
implicit
The mesa parts of the series all look good to me.
We definitely want something like that in gallium too (draw fails the
vertex id tests sort of on purpose right now because we needed d3d10
behavior).
Oh and sort of off-topic but since you're familiar with it do you know
why the gl_PrimitiveIn of
On Fri, 8 Aug 2014 17:28:59 +0300
Pekka Paalanen ppaala...@gmail.com wrote:
From: Pekka Paalanen pekka.paala...@collabora.co.uk
The EGL_EXT_image_dma_buf_import specification was revised (according to
its revision history) on Dec 5th, 2013, for EGL to not take ownership of
the file
Bruno Jiménez brunoji...@gmail.com writes:
OpenCL 1.2 CL_MAP_WRITE_INVALIDATE_REGION sounds a lot like
PIPE_TRANSFER_DISCARD_RANGE:
From OpenCL 1.2 spec:
The contents of the region being mapped are to be discarded.
From p_defines.h:
Discards the memory within the mapped region.
This will decrement the reference count for buffers referenced in the
command stream will prevent us from leaking them.
CC: 10.2 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeonsi/si_compute.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This is required by the spec.
CC: 10.2 mesa-sta...@lists.freedesktop.org
---
src/gallium/state_trackers/clover/api/queue.cpp | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/api/queue.cpp
b/src/gallium/state_trackers/clover/api/queue.cpp
We were leaking the input buffer used for kernel arguments and since
we were allocating it using si_upload_const_buffer() we were leaking
1 MB per kernel invocation.
CC: 10.2 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeonsi/si_compute.c | 22 ++
1 file
There is a hard limit in older kernels of 256 MB for buffer allocations,
so report this value as MAX_MEM_ALLOC_SIZE and adjust MAX_GLOBAL_SIZE
to statisfy requirements of OpenCL.
CC: 10.2 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeon/r600_pipe_common.c | 32
CC: 10.2 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeonsi/si_compute.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index e8fc8eb..dff5ddd 100644
---
CC: 10.2 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r600/r600_pipe.c | 11 ++-
src/gallium/drivers/radeonsi/si_pipe.c | 7 +++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
CC: 10.2 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeonsi/si_compute.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index 42e4fec..482d475 100644
---
Hi,
This series contains fixes for applications which allocate large amounts
of memory.
The first two patches fix the values reported for
PIPE_COMPUTE_CAP_MAX_GLOBAL_SIZE, PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE,
and PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE so that applications don't
allocate more
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Tom Stellard thomas.stell...@amd.com writes:
This is required by the spec.
CC: 10.2 mesa-sta...@lists.freedesktop.org
---
src/gallium/state_trackers/clover/api/queue.cpp | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
On Fri, 2014-08-08 at 18:10 +0300, Francisco Jerez wrote:
Bruno Jiménez brunoji...@gmail.com writes:
OpenCL 1.2 CL_MAP_WRITE_INVALIDATE_REGION sounds a lot like
PIPE_TRANSFER_DISCARD_RANGE:
From OpenCL 1.2 spec:
The contents of the region being mapped are to be discarded.
From
On Fri, Aug 8, 2014 at 12:29 AM, Carl Worth cwo...@cworth.org wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
Note that '$' is a bit different, as it's not a part of the
preprocessor's character set, so using it might be interpreted as
undefined behavior.
Right. That could easily go either
https://bugs.freedesktop.org/show_bug.cgi?id=80183
--- Comment #7 from Roland Scheidegger srol...@vmware.com ---
(In reply to comment #2)
I found out that the problem is the line:
gl_ClipVertex = gl_ModelViewMatrix * gl_Vertex;
in the fragment shader. If I remove that line, it works as
From: Roland Scheidegger srol...@vmware.com
This is a purely cosmetic change.
---
src/gallium/auxiliary/draw/draw_llvm.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index
From: Roland Scheidegger srol...@vmware.com
The non-llvm path made sure that both clip and pre_clip_pos point to the data
output by position, not clipvertex, if user based clipping is disabled.
However, the llvm path did not, which apparently led to failures if
gl_ClipVertex was written but user
On Tuesday, July 01, 2014 04:04:56 PM Neil Roberts wrote:
FWIW, I relaxed the format restrictions in
brw_blorp_copytexsubimage, so it can handle general format
conversions as well (i.e. RGBA_FLOAT16 - RGBA_UNORM). There's
no reason we couldn't do that for BlitFramebuffer as well, I
From: Pali Rohár pali.ro...@gmail.com
Use both macros as in some cases using AC_CHECK_FUNCS alone may fail.
Thus HAVE_DLADDR will not be defined, and as a result most of the code
in megadriver_stub.c will not be compiled. Breakind the backwards
compat with between older libGL/xserver(s) and DRI
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
It might be useful in the commit message to explain why this change is
necessary.
On 08/08/2014 12:31 AM, Kenneth Graunke wrote:
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_context.h | 8
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 08/08/2014 12:31 AM, Kenneth Graunke wrote:
This will be used for GL_ARB_shader_draw_parameters, as well as fixing
gl_VertexID, which is supposed to include gl_BaseVertex's value.
For indirect draws, we simply point at the indirect
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 08/08/2014 12:31 AM, Kenneth Graunke wrote:
We'll need to emit another VERTEX_BUFFER_STATE for gl_BaseVertex;
pulling this into a helper function will save us from having to deal
with cross-generation differences in that code.
This patch is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
But it raises an interesting question. If we lower gl_VertexID to
gl_VertexIDMESA + gl_BaseVertex, are we going to report active
attributes incorrectly through the API?
On 08/08/2014 12:31 AM, Kenneth Graunke wrote:
This is more
(For what it's worth.)
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 08/08/2014 12:31 AM, Kenneth Graunke wrote:
Now that we have the data available, we need to expose it to the
shaders. We can reuse the same vertex element that we use for
gl_VertexID, but we need to back it by an
No idea why this was a problem, but the new code matches the existing
dlopen check.
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Aug 8, 2014 at 4:05 AM, Neil Roberts n...@linux.intel.com wrote:
Jason Ekstrand ja...@jlekstrand.net writes:
+ if (src_mt == dst_mt src_level == dst_level src_z == dst_z) {
+ /* If we are on the same miptree, same level, and same slice, then
+ * intel_miptree_map
The problem is that AC_CHECK_FUNCS would stick the LDFLAGS before the
conftest.c arg while AC_CHECK_LIB sticks the -ldl after conftest.c.
This apparently matters with newer gcc's. There's probably some
correct autoconf way of dealing with it, but... this works :)
On Fri, Aug 8, 2014 at 1:55 PM,
On 08/08/2014 12:31 AM, Kenneth Graunke wrote:
The lower_vertex_id pass converts uses of the gl_VertexID system value
to the gl_BaseVertex and gl_VertexIDMESA system values. Since
gl_VertexID is no longer accessed, it would not be considered active.
Of course, it should be, since the shader
On 08/08/2014 12:37 AM, Kenneth Graunke wrote:
On Friday, August 08, 2014 12:31:07 AM Kenneth Graunke wrote:
From: Ian Romanick ian.d.roman...@intel.com
This system value represents the basevertex value passed to
glDrawElementsBaseVertex and related functions.
Signed-off-by: Ian Romanick
https://bugs.freedesktop.org/show_bug.cgi?id=82327
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |cwo...@cworth.org
This, together with the meta path, provides a complete implemetation of
ARB_copy_image.
v2: Add a fallback memcpy path for when the texture is too big for the
blitter
v3: Properly support copying between two places on the same texture in the
memcpy fallback
v4: Properly handle blit
Am 08.08.2014 20:06, schrieb Ian Romanick:
On 08/08/2014 12:37 AM, Kenneth Graunke wrote:
On Friday, August 08, 2014 12:31:07 AM Kenneth Graunke wrote:
From: Ian Romanick ian.d.roman...@intel.com
This system value represents the basevertex value passed to
glDrawElementsBaseVertex and related
On 08/08/2014 11:02 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
This is a purely cosmetic change.
---
src/gallium/auxiliary/draw/draw_llvm.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
This adds the API entrypoint, error checking logic, and a driver hook for
the ARB_copy_image extension.
v2: Fix a typo in ARB_copy_image.xml and add it to the makefile
v3: Put ARB_copy_image.xml in the right place alphebetically in the
makefile and properly prefix the commit message
v4: Fixed
On 08/08/2014 11:02 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
The non-llvm path made sure that both clip and pre_clip_pos point to the data
output by position, not clipvertex, if user based clipping is disabled.
However, the llvm path did not, which apparently
On 08/08/2014 18:58, Ilia Mirkin wrote:
The problem is that AC_CHECK_FUNCS would stick the LDFLAGS before the
conftest.c arg while AC_CHECK_LIB sticks the -ldl after conftest.c.
This apparently matters with newer gcc's. There's probably some
The key difference seems to be that lto was enabled,
On Thu, 2014-08-07 at 16:02 +0300, Francisco Jerez wrote:
Jan Vesely jan.ves...@rutgers.edu writes:
This respin includes Francisco's approach of providing implicit
in the arg vector passed from clover, and Tom's idea of appending
implicit args after the kernel args.
Hmmm... Maybe it
On 08/08/14 20:09, Jon TURNEY wrote:
On 08/08/2014 18:58, Ilia Mirkin wrote:
The problem is that AC_CHECK_FUNCS would stick the LDFLAGS before the
conftest.c arg while AC_CHECK_LIB sticks the -ldl after conftest.c.
This apparently matters with newer gcc's. There's probably some
The key
The i965 driver uses a float pointer to point to the value of a uniform and
also as the destination within the batch buffer. However the same locations
can also be used to store values for integer uniforms. Previously the value
was being copied into the batch buffer with a regular assignment. This
Patches 1, 2, 3, and 5 though 12 are
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Admittedly, I wasn't exceptionally thorogh with patches 6 and 7. I'm
not worried about 6 getting a lot of use, and I expect we'll revisit 7
in the not too distant future (per previous discussions about the
On 08/08/2014 01:56 PM, Neil Roberts wrote:
The i965 driver uses a float pointer to point to the value of a uniform and
also as the destination within the batch buffer. However the same locations
can also be used to store values for integer uniforms. Previously the value
was being copied into
I've come up with a simpler solution. Patch coming soon.
-Brian
On 07/25/2014 04:00 AM, Popov, Pavel E wrote:
Hi Brian,
Could you commit the updated patch if it's ok?
Regards,
Pavel
-Original Message-
From: Popov, Pavel E
Sent: Wednesday, July 23, 2014 4:58 PM
To:
On 08/08/2014 01:06 AM, Kenneth Graunke wrote:
This adds support for Marek's new driconf parameter, which avoids
totally white rendering in Unigine Valley (which attempts to enable
the GL_ARB_sample_shading extension in an illegal place).
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/state_tracker/st_cb_bufferobjects.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c
b/src/mesa/state_tracker/st_cb_bufferobjects.c
index 3b4d28d..4143dff 100644
--- a/src/mesa/state_tracker/st_cb_bufferobjects.c
Silences MinGW warnings:
warning: unknown conversion type character ‘l’ in format [-Wformat]
warning: too many arguments for format [-Wformat-extra-args]
---
src/mesa/main/bufferobj.c | 33 +
src/mesa/main/varray.c| 13 -
2 files changed, 25
No need to return a value. Remove unused ctx parameter. Remove
_mesa_ prefix since it's static.
---
src/mesa/program/program.c | 69 ++--
1 file changed, 35 insertions(+), 34 deletions(-)
diff --git a/src/mesa/program/program.c
---
src/mesa/program/program.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/src/mesa/program/program.c b/src/mesa/program/program.c
index 9886b75..ef5bf6b 100644
--- a/src/mesa/program/program.c
+++ b/src/mesa/program/program.c
@@ -251,8 +251,9 @@
---
src/mesa/main/varray.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index 0356858..1454449 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -46,21 +46,22 @@
/**
Fixes failed assertion when _mesa_update_draw_buffers() was called
with GL_DRAW_BUFFER == GL_FRONT_AND_BACK. The piglit gl30basic hit
this.
Cc: 10.2 mesa-sta...@lists.freedesktop.org
---
src/mesa/main/buffers.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
There's no need to copy the array of DrawBuffer enums to a temp array.
---
src/mesa/main/buffers.c |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index 6b4fac9..140cf6e 100644
--- a/src/mesa/main/buffers.c
+++
---
src/mesa/main/enable.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index 0f3bcf0..417548a 100644
--- a/src/mesa/main/enable.c
+++ b/src/mesa/main/enable.c
@@ -313,7 +313,7 @@ _mesa_set_enable(struct gl_context
Am 08.08.2014 22:56, schrieb Neil Roberts:
The i965 driver uses a float pointer to point to the value of a uniform and
also as the destination within the batch buffer. However the same locations
can also be used to store values for integer uniforms. Previously the value
was being copied into
Am 08.08.2014 09:46, schrieb Kenneth Graunke:
On Thursday, August 07, 2014 10:41:36 PM Roland Scheidegger wrote:
Am 07.08.2014 20:25, schrieb Jason Ekstrand:
Michel,
On Thu, Aug 7, 2014 at 12:04 AM, Michel Dänzer mic...@daenzer.net
mailto:mic...@daenzer.net wrote:
On 07.08.2014 02:02,
On 08/08/2014 07:55 AM, Roland Scheidegger wrote:
The mesa parts of the series all look good to me.
So.. can we put your R-b on patches 1 through 7? :)
We definitely want something like that in gallium too (draw fails the
vertex id tests sort of on purpose right now because we needed d3d10
In particular, this caused problems where atomics operations were getting
eliminated.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 3 ++-
src/mesa/drivers/dri/i965/brw_vec4_cse.cpp | 3 ++-
2 files changed, 4 insertions(+), 2
On 08/08/2014 11:31 AM, Roland Scheidegger wrote:
Am 08.08.2014 20:06, schrieb Ian Romanick:
On 08/08/2014 12:37 AM, Kenneth Graunke wrote:
On Friday, August 08, 2014 12:31:07 AM Kenneth Graunke wrote:
From: Ian Romanick ian.d.roman...@intel.com
This system value represents the basevertex
Assuming patch 7 fixes the problem Pavel was seeing (and I'm not even
100% what problem that was), the series is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 08/08/2014 02:20 PM, Brian Paul wrote:
---
src/mesa/main/enable.c |4 ++--
1 file changed, 2 insertions(+), 2
Pavel,
Does this patch fix the problem you were trying to solve?
On 08/08/2014 02:20 PM, Brian Paul wrote:
Fixes failed assertion when _mesa_update_draw_buffers() was called
with GL_DRAW_BUFFER == GL_FRONT_AND_BACK. The piglit gl30basic hit
this.
Cc: 10.2 mesa-sta...@lists.freedesktop.org
Roland Scheidegger srol...@vmware.com writes:
Am 08.08.2014 22:56, schrieb Neil Roberts:
The i965 driver uses a float pointer to point to the value of a uniform and
also as the destination within the batch buffer. However the same locations
can also be used to store values for integer
Signed-off-by: Connor Abbott connor.abb...@intel.com
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index
Weird that I didn't notice this before. Thanks!
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Am 08.08.2014 23:47, schrieb Ian Romanick:
On 08/08/2014 11:31 AM, Roland Scheidegger wrote:
Am 08.08.2014 20:06, schrieb Ian Romanick:
On 08/08/2014 12:37 AM, Kenneth Graunke wrote:
On Friday, August 08, 2014 12:31:07 AM Kenneth Graunke wrote:
From: Ian Romanick ian.d.roman...@intel.com
Erik Faye-Lund kusmab...@gmail.com writes:
It seems to me like this is there to support non-ASCII identifiers and
strings, but GLSL doesn't support either. I'm not able to come up with
a conclusion here.
That's almost always the case with GLSL. The GLSL specification does
have its own section
---
src/xdemos/glinfo_common.c |5 +
1 file changed, 5 insertions(+)
diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c
index f536e98..d3acc19 100644
--- a/src/xdemos/glinfo_common.c
+++ b/src/xdemos/glinfo_common.c
@@ -573,6 +573,11 @@ print_limits(const char
https://bugs.freedesktop.org/show_bug.cgi?id=82327
Matt Turner matts...@gmail.com changed:
What|Removed |Added
QA Contact|
This lets us call dump_instructions() after register allocation without
failing an assertion.
This interacts trivially with my previous patch.
Signed-off-by: Connor Abbott connor.abb...@intel.com
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 4
1 file changed, 4 insertions(+)
Am 08.08.2014 23:38, schrieb Ian Romanick:
On 08/08/2014 07:55 AM, Roland Scheidegger wrote:
The mesa parts of the series all look good to me.
So.. can we put your R-b on patches 1 through 7? :)
Actually I'm not really qualified for the glsl parts in 4,5 but
1-3, 6, 7 are
Reviewed-by: Roland
Reviewed-by: Matt Turner matts...@gmail.com
I'll commit both of these tonight. (Does the vec4 backend have the
same problem?)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Friday, August 08, 2014 02:42:27 PM Jason Ekstrand wrote:
In particular, this caused problems where atomics operations were getting
eliminated.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 3 ++-
Am 08.08.2014 23:20, schrieb Brian Paul:
---
src/mesa/main/varray.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index 0356858..1454449 100644
--- a/src/mesa/main/varray.c
+++
On Fri, Aug 8, 2014 at 4:55 PM, Matt Turner matts...@gmail.com wrote:
Reviewed-by: Matt Turner matts...@gmail.com
I'll commit both of these tonight. (Does the vec4 backend have the
same problem?)
AFAICT, it has the same problem that this patch fixes but not the last
patch. I would fix send
On Friday, August 08, 2014 02:56:53 PM Eric Anholt wrote:
Roland Scheidegger srol...@vmware.com writes:
Am 08.08.2014 22:56, schrieb Neil Roberts:
The i965 driver uses a float pointer to point to the value of a uniform and
also as the destination within the batch buffer. However the same
On Fri, Aug 8, 2014 at 4:58 PM, Kenneth Graunke kenn...@whitecape.org
wrote:
On Friday, August 08, 2014 02:42:27 PM Jason Ekstrand wrote:
In particular, this caused problems where atomics operations were getting
eliminated.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
On Fri, Aug 8, 2014 at 4:58 PM, Kenneth Graunke kenn...@whitecape.org wrote:
On Friday, August 08, 2014 02:42:27 PM Jason Ekstrand wrote:
In particular, this caused problems where atomics operations were getting
eliminated.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
Am 08.08.2014 23:20, schrieb Brian Paul:
Silences MinGW warnings:
warning: unknown conversion type character ‘l’ in format [-Wformat]
warning: too many arguments for format [-Wformat-extra-args]
---
src/mesa/main/bufferobj.c | 33 +
src/mesa/main/varray.c
On Friday, August 08, 2014 05:05:35 PM Jason Ekstrand wrote:
On Fri, Aug 8, 2014 at 4:58 PM, Kenneth Graunke wrote:
It's also worth noting in your commit message that this is not actually
fixing a current bug, but rather preventing a regression once your patches
that convert atomics to
Am 08.08.2014 23:20, schrieb Brian Paul:
---
src/mesa/program/program.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/src/mesa/program/program.c b/src/mesa/program/program.c
index 9886b75..ef5bf6b 100644
--- a/src/mesa/program/program.c
+++
Other than that, is there some recommendation wrt whitespace around that
ugly format specifier? Some places seem to use it, some don't. Either
way it's ugly dunno which one is worse. Would be nice though if we'd be
consistent imho.
I've always seen spaces between the quotes and the specifier.
1 - 100 of 110 matches
Mail list logo
