[Mesa-dev] [Bug 91034] New account request
https://bugs.freedesktop.org/show_bug.cgi?id=91034 Bug ID: 91034 Summary: New account request Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: sarah.a.sh...@linux.intel.com QA Contact: mesa-dev@lists.freedesktop.org Created attachment 116603 -- https://bugs.freedesktop.org/attachment.cgi?id=116603action=edit Public GPG key I've recently joined the Intel OTC graphics team. Please create a shell account on freedesktop.org for me. Name: Sarah Sharp Email: sarah.a.sh...@linux.intel.com Preferred account name: sarah GPG key fingerprint = 6ECC 8026 CD5B 35AC C5A9 1BAE 1306 58C2 E2D4 6739 -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] i965/gen9: Add XY_FAST_COPY_BLT support to intelEmitCopyBlit()
On Wed, Jun 10, 2015 at 3:34 PM, Anuj Phogat anuj.pho...@gmail.com wrote:
This patch enables using XY_FAST_COPY_BLT only for Yf/Ys tiled buffers.
It can be later turned on for other tiling patterns (X,Y) too.
V3: Flush in between sequential fast copy blits.
Fix src/dst alignment requirements.
Make can_fast_copy_blit() helper.
Use ffs(), is_power_of_two()
Move overlap computation inside intel_miptree_blit().
V4: Use _mesa_regions_overlap() function.
Simplify horizontal and vertical alignment computations.
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Cc: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/intel_blit.c | 295
++-
src/mesa/drivers/dri/i965/intel_blit.h | 2 +
src/mesa/drivers/dri/i965/intel_copy_image.c | 2 +
src/mesa/drivers/dri/i965/intel_reg.h| 16 ++
4 files changed, 268 insertions(+), 47 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_blit.c
b/src/mesa/drivers/dri/i965/intel_blit.c
index 5afc771..800ed7e 100644
--- a/src/mesa/drivers/dri/i965/intel_blit.c
+++ b/src/mesa/drivers/dri/i965/intel_blit.c
@@ -27,6 +27,7 @@
#include main/mtypes.h
+#include main/blit.h
#include main/context.h
#include main/enums.h
#include main/colormac.h
@@ -43,6 +44,23 @@
#define FILE_DEBUG_FLAG DEBUG_BLIT
+#define SET_TILING_XY_FAST_COPY_BLT(tiling, tr_mode, type) \
+({ \
+ switch (tiling) { \
+ case I915_TILING_X: \
+ CMD |= type ## _TILED_X; \
+ break; \
+ case I915_TILING_Y: \
+ if (tr_mode == INTEL_MIPTREE_TRMODE_YS)\
+ CMD |= type ## _TILED_64K; \
+ else \
+ CMD |= type ## _TILED_Y;\
+ break; \
+ default: \
+ unreachable(not reached);\
+ } \
+})
+
static void
intel_miptree_set_alpha_to_one(struct brw_context *brw,
struct intel_mipmap_tree *mt,
@@ -75,6 +93,10 @@ static uint32_t
br13_for_cpp(int cpp)
{
switch (cpp) {
+ case 16:
+ return BR13_32323232;
+ case 8:
+ return BR13_16161616;
case 4:
return BR13_;
break;
@@ -89,6 +111,66 @@ br13_for_cpp(int cpp)
}
}
+static uint32_t
+get_tr_horizontal_align(uint32_t tr_mode, uint32_t cpp, bool is_src) {
+ /* Alignment tables for YF/YS tiled surfaces. */
+ const uint32_t align_2d_yf[] = {64, 64, 32, 32, 16};
+ const uint32_t align_2d_ys[] = {256, 256, 128, 128, 64};
+ const uint32_t bpp = cpp * 8;
+ const uint32_t shift = is_src ? 17 : 10;
+ uint32_t align;
+ int i = 0;
+
+ if (tr_mode == INTEL_MIPTREE_TRMODE_NONE)
+ return 0;
+
+ /* Compute array index. */
+ assert (bpp = 8 bpp = 128 is_power_of_two(bpp));
+ i = ffs(bpp / 8) - 1;
+
+ align = tr_mode == INTEL_MIPTREE_TRMODE_YF ?
+ align_2d_yf[i] :
+ align_2d_ys[i];
+
+ assert(is_power_of_two(align));
+
+ /* XY_FAST_COPY_BLT doesn't support horizontal alignment of 16. */
+ if (align == 16)
+ align = 32;
+
+ return (ffs(align) - 6) shift;
+}
+
+static uint32_t
+get_tr_vertical_align(uint32_t tr_mode, uint32_t cpp, bool is_src) {
+ /* Vertical alignment tables for YF/YS tiled surfaces. */
+ const unsigned align_2d_yf[] = {64, 32, 32, 16, 16};
+ const unsigned align_2d_ys[] = {256, 128, 128, 64, 64};
+ const uint32_t bpp = cpp * 8;
+ const uint32_t shift = is_src ? 15 : 8;
+ uint32_t align;
+ int i = 0;
+
+ if (tr_mode == INTEL_MIPTREE_TRMODE_NONE)
+ return 0;
+
+ /* Compute array index. */
+ assert (bpp = 8 bpp = 128 is_power_of_two(bpp));
+ i = ffs(bpp / 8) - 1;
+
+ align = tr_mode == INTEL_MIPTREE_TRMODE_YF ?
+ align_2d_yf[i] :
+ align_2d_ys[i];
+
+ assert(is_power_of_two(align));
+
+ /* XY_FAST_COPY_BLT doesn't support vertical alignments of 16 and 32. */
+ if (align == 16 || align == 32)
+ align = 64;
+
+ return (ffs(align) - 7) shift;
+}
+
/**
* Emits the packet for switching the blitter from X to Y tiled or back.
*
@@ -281,9 +363,11 @@ intel_miptree_blit(struct brw_context *brw,
src_pitch,
src_mt-bo, src_mt-offset,
src_mt-tiling,
+
Re: [Mesa-dev] [PATCH 25/46] glsl: lower gl_TessLevel* from float[n] to vecn.
On Wednesday, June 17, 2015 01:01:21 AM Marek Olšák wrote:
From: Fabian Bieler fabianbie...@fastmail.fm
Similar to gl_ClipDistance - gl_ClipDistanceMESA
---
src/glsl/Makefile.sources | 1 +
src/glsl/ir_optimization.h | 1 +
src/glsl/link_varyings.cpp | 51 +++-
src/glsl/link_varyings.h| 13 +-
src/glsl/linker.cpp | 4 +
src/glsl/lower_tess_level.cpp | 462
src/mesa/drivers/dri/i965/brw_context.c | 1 +
src/mesa/main/mtypes.h | 1 +
8 files changed, 521 insertions(+), 13 deletions(-)
create mode 100644 src/glsl/lower_tess_level.cpp
diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
index d784a81..b3b84d6 100644
--- a/src/glsl/Makefile.sources
+++ b/src/glsl/Makefile.sources
@@ -154,6 +154,7 @@ LIBGLSL_FILES = \
lower_packed_varyings.cpp \
lower_named_interface_blocks.cpp \
lower_packing_builtins.cpp \
+ lower_tess_level.cpp \
lower_texture_projection.cpp \
lower_variable_index_to_cond_assign.cpp \
lower_vec_index_to_cond_assign.cpp \
diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
index e6939f3..688a5e1 100644
--- a/src/glsl/ir_optimization.h
+++ b/src/glsl/ir_optimization.h
@@ -132,6 +132,7 @@ bool optimize_split_arrays(exec_list *instructions, bool
linked);
bool lower_offset_arrays(exec_list *instructions);
void optimize_dead_builtin_variables(exec_list *instructions,
enum ir_variable_mode other);
+bool lower_tess_level(gl_shader *shader);
bool lower_vertex_id(gl_shader *shader);
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 373d337..d439b62 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -318,7 +318,7 @@ tfeedback_decl::init(struct gl_context *ctx, const void
*mem_ctx,
this-location = -1;
this-orig_name = input;
- this-is_clip_distance_mesa = false;
+ this-is_mesa_var = none;
This seems like a bad name...is_foo suggests a boolean (rather than an
enum), and mesa_var is pretty generic. Perhaps calling it
lowered_builtin_array_variable would be better?
this-skip_components = 0;
this-next_buffer_separator = false;
this-matched_candidate = NULL;
@@ -367,8 +367,15 @@ tfeedback_decl::init(struct gl_context *ctx, const void
*mem_ctx,
*/
if
(ctx-Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].LowerClipDistance
strcmp(this-var_name, gl_ClipDistance) == 0) {
- this-is_clip_distance_mesa = true;
+ this-is_mesa_var = clip_distance;
}
+
+ if (ctx-Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].LowerTessLevel
+ (strcmp(this-var_name, gl_TessLevelOuter) == 0))
+ this-is_mesa_var = tess_level_outer;
+ if (ctx-Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].LowerTessLevel
+ (strcmp(this-var_name, gl_TessLevelInner) == 0))
+ this-is_mesa_var = tess_level_inner;
Using ShaderCompilerOptions[MESA_SHADER_VERTEX] for LowerTessLevel seems
odd - perhaps LowerClipDistance and LowerTessLevel really shouldn't be
per-stage options, and just live in ctx-Const? *shrug*
}
@@ -415,9 +422,22 @@ tfeedback_decl::assign_location(struct gl_context *ctx,
this-matched_candidate-type-fields.array-matrix_columns;
const unsigned vector_elements =
this-matched_candidate-type-fields.array-vector_elements;
- unsigned actual_array_size = this-is_clip_distance_mesa ?
- prog-LastClipDistanceArraySize :
- this-matched_candidate-type-array_size();
+ unsigned actual_array_size;
+ switch (this-is_mesa_var) {
+ case clip_distance:
+ actual_array_size = prog-LastClipDistanceArraySize;
+ break;
+ case tess_level_outer:
+ actual_array_size = 4;
+ break;
+ case tess_level_inner:
+ actual_array_size = 2;
+ break;
+ case none:
+ default:
+ actual_array_size = this-matched_candidate-type-array_size();
+ break;
+ }
if (this-is_subscripted) {
/* Check array bounds. */
@@ -428,7 +448,7 @@ tfeedback_decl::assign_location(struct gl_context *ctx,
actual_array_size);
return false;
}
- unsigned array_elem_size = this-is_clip_distance_mesa ?
+ unsigned array_elem_size = this-is_mesa_var ?
1 : vector_elements * matrix_cols;
fine_location += array_elem_size * this-array_subscript;
this-size = 1;
@@ -437,7 +457,7 @@ tfeedback_decl::assign_location(struct gl_context *ctx,
}
this-vector_elements = vector_elements;
this-matrix_columns = matrix_cols;
- if (this-is_clip_distance_mesa)
+ if (this-is_mesa_var)
this-type = GL_FLOAT;
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Thu, Jun 18, 2015 at 12:04 PM, Rob Clark robdcl...@gmail.com wrote: It is only vaguely an issue at the moment because the priority-queue scheduler that replaced what is on master does very badly with wide/shallow shaders, ie. like glsl-fs-convolution-1... ie. shaders with a lot of instructions at minimum depth.. (but I have some ideas to fix that) P.S. what does your heuristic currently look like? I was working on i965 scheduling, and after some discussion, this is what I did: http://cgit.freedesktop.org/~cwabbott0/mesa/commit/?h=i965-schedid=2d46e424327082bbc67758d05e6e102cbcd56d89 it's called delay in that code for some reason instead of depth (or, even better, critical path length), but you should get the idea... choose the earliest thing we can schedule, and then among those pick the thing with the largest depth. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/14] meta: Fix transfer operations check in meta pbo path for readpixels
On Thu, Jun 18, 2015 at 5:26 AM, Iago Toral ito...@igalia.com 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 Phogat anuj.pho...@gmail.com
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/common/meta_tex_subimage.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/common/meta_tex_subimage.c
b/src/mesa/drivers/common/meta_tex_subimage.c
index d2474f5..00364f8 100644
--- a/src/mesa/drivers/common/meta_tex_subimage.c
+++ b/src/mesa/drivers/common/meta_tex_subimage.c
@@ -273,12 +273,14 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx,
GLuint dims,
format == GL_COLOR_INDEX)
return false;
- if (ctx-_ImageTransferState)
- return false;
-
-
That test uses glReadPixels so it should call this with tex_image set to
NULL and it should flow through the if you have below. The call to
_mesa_get_readpixels_transfer_ops that you add below looks like it does
what we want for a pixel read from a framebuffer instead of simply
checking ctx-_ImageTransferState directly. I suppose this is what fixes
the test, right?
Right. Using _mesa_get_readpixels_transfer_ops() in place of simple
ctx-_ImageTransferState check takes care of setting IMAGE_CLAMP_BIT
in ctx-_ImageTransferState when GL_CLAMP_READ_COLOR is set.
I'll add some explanation in commit message.
The patch also removes the ctx-_ImageTransferState check for the case
where we are reading from a real texture (tex_image != NULL), that seems
unrelated to fixing arb_color_buffer_float-readpixels... Looking at the
texture read code from getteximage.c it seems like this should be fine
since that file does not seem to use that field for anything either, so
I guess the check might not valid in this case.
After another look I realized that glGetTexImage() do need transfer
operations check to fall back to software path. It's the lack of piglit
tests that I couldn't catch it. Thanks for noticing it. I'll send out a v2.
I think it would be nice if you updated the changelog to explain these
things.
Iago
+ /* Don't use meta path for readpixels in below conditions. */
if (!tex_image) {
rb = ctx-ReadBuffer-_ColorReadBuffer;
+
+ if (_mesa_get_readpixels_transfer_ops(ctx, rb-Format, format,
+type, GL_FALSE))
+ return false;
+
if (_mesa_need_rgb_to_luminance_conversion(rb-Format, format))
return false;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] egl/main: expose the EGL_RECORDABLE_ANDROID extension
Chih-Wei Huang cwhu...@android-x86.org writes:
The commit message needs some explanation: Why are we doing this? What
does EGL_ANDROID_recordable get us, if we don't have any configs
exposing it? What tests do we have for it?
Signed-off-by: Chih-Wei Huang cwhu...@linux.org.tw
---
src/egl/main/eglconfig.c | 5 -
src/egl/main/eglconfig.h | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/egl/main/eglconfig.c b/src/egl/main/eglconfig.c
index cf65c69..d9971ed 100644
--- a/src/egl/main/eglconfig.c
+++ b/src/egl/main/eglconfig.c
@@ -245,7 +245,10 @@ static const struct {
/* extensions */
{ EGL_Y_INVERTED_NOK,ATTRIB_TYPE_BOOLEAN,
ATTRIB_CRITERION_EXACT,
-EGL_DONT_CARE }
+EGL_DONT_CARE },
+ { EGL_RECORDABLE_ANDROID,ATTRIB_TYPE_BOOLEAN,
+ATTRIB_CRITERION_EXACT,
+EGL_DONT_CARE },
};
diff --git a/src/egl/main/eglconfig.h b/src/egl/main/eglconfig.h
index 84cb227..7121b3d 100644
--- a/src/egl/main/eglconfig.h
+++ b/src/egl/main/eglconfig.h
@@ -86,6 +86,7 @@ struct _egl_config
/* extensions */
EGLint YInvertedNOK;
+ EGLint RecordableAndroid;
};
@@ -133,6 +134,7 @@ _eglOffsetOfConfig(EGLint attr)
ATTRIB_MAP(EGL_CONFORMANT,Conformant);
/* extensions */
ATTRIB_MAP(EGL_Y_INVERTED_NOK,YInvertedNOK);
+ ATTRIB_MAP(EGL_RECORDABLE_ANDROID,RecordableAndroid);
#undef ATTRIB_MAP
default:
return -1;
You're not exposing the extension in _eglCreateExtensionsString(), and
nobody should use (or be able to use) the extension without that.
It also looks like you're missing the bits _eglIsConfigAttribValid()
code to see if the extension is exposed before supporting the new enum.
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/gen8: Use HALIGN_16 for single sample mcs buffers
On Fri, Jun 19, 2015 at 10:05 AM, Mark Janes mark.a.ja...@intel.com wrote:
Tested-by: Mark Janes mark.a.ja...@intel.com
Ben Widawsky benjamin.widaw...@intel.com writes:
The original code meant to do this, but was only checking num_samples == 1 to
figure out if a surface was fast clear capable. However, we can allocate
single
sample miptrees with num_samples == 0 (when it's an internally created
buffer).
This fixes a bunch of the piglit tests on gen8. Other gens should have been
fine.
Here is the order of events that allowed this to slip through:
t0: I wrote halign patches and tested them. These alignment assertions are
for
gen8 fast clear surfaces, basically.
t1: I pushed bogus perf patch which made fast clears never happen
t2: Reworked halign patches based on Chad's feedback and introduced the bug
this
patch fixes.
t2.5: I tested reworked patches, but assertion wasn't hit because of t1.
t3. Matt fixed issue in t1 which made fast clears happen here:
commit 22af95af8316f2888a3935cdf774ff0997b3dd42
Author: Matt Turner matts...@gmail.com
Date: Thu Jun 18 16:14:50 2015 -0700
i965: Add missing braces around if-statement.
This logic should match that of the v1 of my halign patch series.
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: Matt Turner matts...@gmail.com
Reported-by: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 80c52f2..6aa969a 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -501,7 +501,7 @@ intel_miptree_create_layout(struct brw_context *brw,
* 6 | ? |?
*/
if (intel_miptree_is_fast_clear_capable(brw, mt)) {
- if (brw-gen = 9 || (brw-gen == 8 num_samples == 1))
+ if (brw-gen = 9 || (brw-gen == 8 num_samples = 1))
layout_flags |= MIPTREE_LAYOUT_FORCE_HALIGN16;
} else if (brw-gen = 9 num_samples 1) {
layout_flags |= MIPTREE_LAYOUT_FORCE_HALIGN16;
--
2.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: add EXT_polygon_offset_clamp support to gen4/gen5
On Fri, Jun 19, 2015 at 4:36 PM, Matt Turner matts...@gmail.com wrote:
From: Ilia Mirkin imir...@alum.mit.edu
Reviewed-by: Matt Turner matts...@gmail.com
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
mattst88: Changed BRW_CONDITIONAL_G - BRW_CONDITIONAL_GE (see commit
3b7f683f)
Somewhat worryingly, I wasn't able to break any of the piglit tests by
inverting
the cmod on the CMP in brw_clip_unfilled.c.
The piglit tests only cover filled poly's, unfortunately. Those were
hard enough to work out, I wasn't up to the task of writing ones that
dealt with unfilled polys.
src/mesa/drivers/dri/i965/brw_clip.c | 1 +
src/mesa/drivers/dri/i965/brw_clip.h | 1 +
src/mesa/drivers/dri/i965/brw_clip_unfilled.c | 14 ++
src/mesa/drivers/dri/i965/brw_context.h | 2 ++
src/mesa/drivers/dri/i965/brw_misc_state.c| 8
src/mesa/drivers/dri/i965/brw_wm_state.c | 11 +++
src/mesa/drivers/dri/i965/intel_extensions.c | 2 +-
7 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
b/src/mesa/drivers/dri/i965/brw_clip.c
index 3a73c64..2d5abc7 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -223,6 +223,7 @@ brw_upload_clip_prog(struct brw_context *brw)
/* _NEW_POLYGON, _NEW_BUFFERS */
key.offset_units = ctx-Polygon.OffsetUnits *
ctx-DrawBuffer-_MRD * 2;
key.offset_factor = ctx-Polygon.OffsetFactor *
ctx-DrawBuffer-_MRD;
+ key.offset_clamp = ctx-Polygon.OffsetClamp *
ctx-DrawBuffer-_MRD;
}
if (!ctx-Polygon._FrontBit) {
diff --git a/src/mesa/drivers/dri/i965/brw_clip.h
b/src/mesa/drivers/dri/i965/brw_clip.h
index 4e38f2f..54c7682 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.h
+++ b/src/mesa/drivers/dri/i965/brw_clip.h
@@ -62,6 +62,7 @@ struct brw_clip_prog_key {
GLfloat offset_factor;
GLfloat offset_units;
+ GLfloat offset_clamp;
};
diff --git a/src/mesa/drivers/dri/i965/brw_clip_unfilled.c
b/src/mesa/drivers/dri/i965/brw_clip_unfilled.c
index 6baf620..9a4d2a9 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_unfilled.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_unfilled.c
@@ -188,6 +188,12 @@ static void copy_bfc( struct brw_clip_compile *c )
GLfloat bc = dir.y * iz;
offset = ctx-Polygon.OffsetUnits * DEPTH_SCALE;
offset += MAX2( abs(ac), abs(bc) ) * ctx-Polygon.OffsetFactor;
+ if (ctx-Polygon.OffsetClamp isfinite(ctx-Polygon.OffsetClamp)) {
+if (ctx-Polygon.OffsetClamp 0)
+ offset = MAX2( offset, ctx-Polygon.OffsetClamp );
+else
+ offset = MIN2( offset, ctx-Polygon.OffsetClamp );
+ }
offset *= MRD;
*/
static void compute_offset( struct brw_clip_compile *c )
@@ -211,6 +217,14 @@ static void compute_offset( struct brw_clip_compile *c )
brw_MUL(p, vec1(off), vec1(off), brw_imm_f(c-key.offset_factor));
brw_ADD(p, vec1(off), vec1(off), brw_imm_f(c-key.offset_units));
+ if (c-key.offset_clamp isfinite(c-key.offset_clamp)) {
+ brw_CMP(p,
+ vec1(brw_null_reg()),
+ c-key.offset_clamp 0 ? BRW_CONDITIONAL_GE :
BRW_CONDITIONAL_L,
+ vec1(off),
+ brw_imm_f(c-key.offset_clamp));
+ brw_SEL(p, vec1(off), vec1(off), brw_imm_f(c-key.offset_clamp));
+ }
}
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 58119ee..7331276 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1394,6 +1394,8 @@ struct brw_context
*/
drm_intel_bo *multisampled_null_render_target_bo;
uint32_t fast_clear_op;
+
+ float offset_clamp;
} wm;
struct {
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 5a4515b..08885d9 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -884,14 +884,6 @@ brw_upload_invariant_state(struct brw_context *brw)
brw_select_pipeline(brw, BRW_RENDER_PIPELINE);
- if (brw-gen 6) {
- /* Disable depth offset clamping. */
- BEGIN_BATCH(2);
- OUT_BATCH(_3DSTATE_GLOBAL_DEPTH_OFFSET_CLAMP 16 | (2 - 2));
- OUT_BATCH_F(0.0);
- ADVANCE_BATCH();
- }
-
if (brw-gen = 8) {
BEGIN_BATCH(3);
OUT_BATCH(CMD_STATE_SIP 16 | (3 - 2));
diff --git a/src/mesa/drivers/dri/i965/brw_wm_state.c
b/src/mesa/drivers/dri/i965/brw_wm_state.c
index 0cd4390..e436175 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_state.c
@@ -31,6 +31,7 @@
+#include intel_batchbuffer.h
#include intel_fbo.h
#include brw_context.h
#include brw_state.h
@@ -251,6 +252,16 @@ brw_upload_wm_unit(struct brw_context *brw)
}
brw-ctx.NewDriverState |=
[Mesa-dev] [Bug 91034] New account request
https://bugs.freedesktop.org/show_bug.cgi?id=91034 --- Comment #1 from Sarah Sharp sarah.a.sh...@linux.intel.com --- Created attachment 116604 -- https://bugs.freedesktop.org/attachment.cgi?id=116604action=edit Public ssh key -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/11] confiigure: drop unused variable GBM_BACKEND_DIRS
Emil Velikov emil.l.veli...@gmail.com writes: Signed-off-by: Emil Velikov emil.l.veli...@gmail.com s/confiigure/configure/ in the subject. After that, and some cleanup of the commit message in 4, patches 1-8 will be: Reviewed-by: Eric Anholt e...@anholt.net I find 9/10 weird -- if the DRI drivers need libglapi, why aren't they just linking libglapi? signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 02/18] i965/fs: Fix fs_inst::regs_read() for uniform pull constant loads
Previously, fs_inst::regs_read() fell back to depending on the register width for the second source. This isn't really correct since it isn't a SIMD8 value at all, but a SIMD4x2 value. This commit changes it to explicitly be always one register. Reviewed-by: Iago Toral Quiroga ito...@igalia.com v2: Use mlen for determining the number of registers written --- src/mesa/drivers/dri/i965/brw_fs.cpp | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp index 17a940b..6d25ba4 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp @@ -758,6 +758,12 @@ fs_inst::regs_read(int arg) const return mlen; break; + case FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD_GEN7: + /* The payload is actually storred in src1 */ + if (arg == 1) + return mlen; + break; + case FS_OPCODE_LINTERP: if (arg == 0) return exec_size / 4; -- 2.4.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01.9/18] i965/fs: Actually set/use the mlen for gen7 uniform pull constant loads
Previously, we were allocating the payload with different sizes per gen and
then figuring out the mlen in the generator based on gen. This meant,
among other things, that the higher level passes knew nothing about it.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 14 +-
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 6 ++
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 37b6d0d..17a940b 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2952,14 +2952,18 @@ fs_visitor::lower_uniform_pull_constant_loads()
assert(const_offset_reg.file == IMM
const_offset_reg.type == BRW_REGISTER_TYPE_UD);
const_offset_reg.fixed_hw_reg.dw1.ud /= 4;
- fs_reg payload = fs_reg(GRF, alloc.allocate(1));
- /* We have to use a message header on Skylake to get SIMD4x2 mode.
- * Reserve space for the register.
- */
+ fs_reg payload;
if (devinfo-gen = 9) {
+/* We have to use a message header on Skylake to get SIMD4x2
+ * mode. Reserve space for the register.
+*/
+payload = fs_reg(GRF, alloc.allocate(2));
payload.reg_offset++;
-alloc.sizes[payload.reg] = 2;
+inst-mlen = 2;
+ } else {
+payload = fs_reg(GRF, alloc.allocate(1));
+inst-mlen = 1;
}
/* This is actually going to be a MOV, but since only the first dword
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 8eb3ace..7a79b39 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -1068,12 +1068,10 @@
fs_generator::generate_uniform_pull_constant_load_gen7(fs_inst *inst,
struct brw_reg src = offset;
bool header_present = false;
- int mlen = 1;
if (devinfo-gen = 9) {
/* Skylake requires a message header in order to use SIMD4x2 mode. */
src = retype(brw_vec4_grf(offset.nr - 1, 0), BRW_REGISTER_TYPE_UD);
- mlen = 2;
header_present = true;
brw_push_insn_state(p);
@@ -1104,7 +1102,7 @@
fs_generator::generate_uniform_pull_constant_load_gen7(fs_inst *inst,
0, /* LD message ignores sampler unit */
GEN5_SAMPLER_MESSAGE_SAMPLE_LD,
1, /* rlen */
- mlen,
+ inst-mlen,
header_present,
BRW_SAMPLER_SIMD_MODE_SIMD4X2,
0);
@@ -1134,7 +1132,7 @@
fs_generator::generate_uniform_pull_constant_load_gen7(fs_inst *inst,
0, /* LD message ignores sampler unit */
GEN5_SAMPLER_MESSAGE_SAMPLE_LD,
1, /* rlen */
- mlen,
+ inst-mlen,
header_present,
BRW_SAMPLER_SIMD_MODE_SIMD4X2,
0);
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 44/46] glsl: fix locations of 2-dimensional varyings without varying packing
On Wednesday, June 17, 2015 01:01:40 AM Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
---
src/glsl/link_varyings.cpp | 37 -
1 file changed, 28 insertions(+), 9 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 5fa9ddf..6bd8dba 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -750,7 +750,9 @@ namespace {
class varying_matches
{
public:
- varying_matches(bool disable_varying_packing, bool consumer_is_fs);
+ varying_matches(bool disable_varying_packing,
+ gl_shader_stage producer_type,
+ gl_shader_stage consumer_type);
Could we perhaps call these producer_stage and consumer-stage?
Either way,
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Fri, Jun 19, 2015 at 6:21 PM, Connor Abbott cwabbo...@gmail.com wrote:
On Thu, Jun 18, 2015 at 12:04 PM, Rob Clark robdcl...@gmail.com wrote:
On Thu, Jun 18, 2015 at 2:34 PM, Connor Abbott cwabbo...@gmail.com wrote:
On Thu, Jun 18, 2015 at 11:19 AM, Rob Clark robdcl...@gmail.com wrote:
On Thu, Jun 18, 2015 at 1:27 PM, Connor Abbott cwabbo...@gmail.com wrote:
On Thu, Jun 18, 2015 at 9:42 AM, Rob Clark robdcl...@gmail.com wrote:
On Thu, Jun 18, 2015 at 11:01 AM, Connor Abbott cwabbo...@gmail.com
wrote:
(really I want phi's for variables too.. the way I turn arrays into
fanin/collect fanout/split works on the backend for dealing with
arrays in ssa form (other than making instruction graph large) but
the
way I go from nir to ir3 currently assumes I get nir phi's everywhere
I need an ir3 phi)
Right... we explicitly decided not to support SSA form for arrays in
NIR, since it seemed like a pretty bad idea. SSA form assumes that
inserting copies for the things you're SSA-ifying is relatively
inexpensive, and both SSA-based register allocation and algorithms for
converting out of SSA make no guarantees about not inserting
potentially unnecessary copies. This is a good compromise for smaller
things, but not for your array of (say) 64 things where inserting an
extra copy is rather disastrous. You can do it if you want and shoot
yourself in the foot, but NIR isn't going to help you there -- we
won't write a to-SSA pass for something which doesn't make much sense
in the first place.
in ir3 my solution is to add sufficient dependencies between
instructions so the array accesses don't get re-ordered and they all
collapse down to a single name per array element/slot
It's not about getting reordered, it's about interference. The problem
is that as soon as you do basically any optimization at all (even copy
propagation), you can wind up with a situation where the sources and
destination of a phi node interfere with each other and you have to
insert extra mov's. And even if you keep everything exactly the same,
with an SSA-based register allocator, there's always the chance that
it'll screw up anyways and allocate something over your array and
force you to insert a mov. You could force the array to be allocated
to a single hardware register, but then it's not really an SSA value
anymore -- it's a hardware register, and you can't treat it like an
SSA value anymore in your allocator, and so adding phi nodes and
whatnot for it in your IR doesn't make much sense.
But the point I'm trying to make is that I need the links from src to
dest that I get in SSA form for *scheduling* (for example, to know how
many delay slots are needed between two instructions). For things
like if/else, I would need to consider number of cycles since either
possible assigner. For everything else, the phi nodes (in ir3, not in
nir) give me this. Arrays are not special (since they are allocated
in registers) when it comes to cycle counts.
BR,
-R
Except that they still are special, and you need to account for that
when you set up scheduling dependencies for them. For example, imagine
that you have an array A accessed in a loop:
while (...) {
... = A[i];
A[i] = ...;
}
if you lower the array to SSA, this will give you something like:
while (...) {
A_1 = phi(A_0, A_2);
... = A_1[i];
A_2 = Update(A_1, i, ...); /* makes a copy with the i'th element
changed */
}
and when you set up scheduling dependencies, you'll miss the false
write-after-read dependency between the access and the update, meaning
you could end up with:
while (...) {
A_1 = phi(A_0, A_2);
A_2 = Update(A_1, i, ...);
... = A_1[i];
}
and now the number of instructions in your shader has exploded since
you have to insert a copy somewhere. You could add all the false
dependencies by yourself, and force it into the same register, but by
that point you've already given up all the advantages that SSA has to
offer and inserting phi nodes is a rather pointless exercise.
except, like I said, for the purpose of scheduling realizing that
there are two dependency paths to consider for figuring out the
required number of delay slots..
No, there aren't. There's the dependency between the read and the
write (in my example), which serializes things and makes it one path.
In other words, the stuff before the write must happen before the
write, even if in SSA those are two different values.
that wasn't really the case I was talking about.. but rather:
if (...) {
...
arr[i] = a + b;
} else {
arr[i] = c + d;
}
... = arr[i];
In that case, everything is in a seperate basic block and the
scheduler still doesn't need to have the phi nodes. This is already a
well-known problem that i965, as well as basically every other backend
ever, has solved without doing what you want to do.
The hardware doesn't care that they are in different basic blocks.
The
[Mesa-dev] [PATCH] i965: add EXT_polygon_offset_clamp support to gen4/gen5
From: Ilia Mirkin imir...@alum.mit.edu
Reviewed-by: Matt Turner matts...@gmail.com
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
mattst88: Changed BRW_CONDITIONAL_G - BRW_CONDITIONAL_GE (see commit 3b7f683f)
Somewhat worryingly, I wasn't able to break any of the piglit tests by inverting
the cmod on the CMP in brw_clip_unfilled.c.
src/mesa/drivers/dri/i965/brw_clip.c | 1 +
src/mesa/drivers/dri/i965/brw_clip.h | 1 +
src/mesa/drivers/dri/i965/brw_clip_unfilled.c | 14 ++
src/mesa/drivers/dri/i965/brw_context.h | 2 ++
src/mesa/drivers/dri/i965/brw_misc_state.c| 8
src/mesa/drivers/dri/i965/brw_wm_state.c | 11 +++
src/mesa/drivers/dri/i965/intel_extensions.c | 2 +-
7 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c
b/src/mesa/drivers/dri/i965/brw_clip.c
index 3a73c64..2d5abc7 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -223,6 +223,7 @@ brw_upload_clip_prog(struct brw_context *brw)
/* _NEW_POLYGON, _NEW_BUFFERS */
key.offset_units = ctx-Polygon.OffsetUnits *
ctx-DrawBuffer-_MRD * 2;
key.offset_factor = ctx-Polygon.OffsetFactor *
ctx-DrawBuffer-_MRD;
+ key.offset_clamp = ctx-Polygon.OffsetClamp *
ctx-DrawBuffer-_MRD;
}
if (!ctx-Polygon._FrontBit) {
diff --git a/src/mesa/drivers/dri/i965/brw_clip.h
b/src/mesa/drivers/dri/i965/brw_clip.h
index 4e38f2f..54c7682 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.h
+++ b/src/mesa/drivers/dri/i965/brw_clip.h
@@ -62,6 +62,7 @@ struct brw_clip_prog_key {
GLfloat offset_factor;
GLfloat offset_units;
+ GLfloat offset_clamp;
};
diff --git a/src/mesa/drivers/dri/i965/brw_clip_unfilled.c
b/src/mesa/drivers/dri/i965/brw_clip_unfilled.c
index 6baf620..9a4d2a9 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_unfilled.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_unfilled.c
@@ -188,6 +188,12 @@ static void copy_bfc( struct brw_clip_compile *c )
GLfloat bc = dir.y * iz;
offset = ctx-Polygon.OffsetUnits * DEPTH_SCALE;
offset += MAX2( abs(ac), abs(bc) ) * ctx-Polygon.OffsetFactor;
+ if (ctx-Polygon.OffsetClamp isfinite(ctx-Polygon.OffsetClamp)) {
+if (ctx-Polygon.OffsetClamp 0)
+ offset = MAX2( offset, ctx-Polygon.OffsetClamp );
+else
+ offset = MIN2( offset, ctx-Polygon.OffsetClamp );
+ }
offset *= MRD;
*/
static void compute_offset( struct brw_clip_compile *c )
@@ -211,6 +217,14 @@ static void compute_offset( struct brw_clip_compile *c )
brw_MUL(p, vec1(off), vec1(off), brw_imm_f(c-key.offset_factor));
brw_ADD(p, vec1(off), vec1(off), brw_imm_f(c-key.offset_units));
+ if (c-key.offset_clamp isfinite(c-key.offset_clamp)) {
+ brw_CMP(p,
+ vec1(brw_null_reg()),
+ c-key.offset_clamp 0 ? BRW_CONDITIONAL_GE : BRW_CONDITIONAL_L,
+ vec1(off),
+ brw_imm_f(c-key.offset_clamp));
+ brw_SEL(p, vec1(off), vec1(off), brw_imm_f(c-key.offset_clamp));
+ }
}
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 58119ee..7331276 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1394,6 +1394,8 @@ struct brw_context
*/
drm_intel_bo *multisampled_null_render_target_bo;
uint32_t fast_clear_op;
+
+ float offset_clamp;
} wm;
struct {
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 5a4515b..08885d9 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -884,14 +884,6 @@ brw_upload_invariant_state(struct brw_context *brw)
brw_select_pipeline(brw, BRW_RENDER_PIPELINE);
- if (brw-gen 6) {
- /* Disable depth offset clamping. */
- BEGIN_BATCH(2);
- OUT_BATCH(_3DSTATE_GLOBAL_DEPTH_OFFSET_CLAMP 16 | (2 - 2));
- OUT_BATCH_F(0.0);
- ADVANCE_BATCH();
- }
-
if (brw-gen = 8) {
BEGIN_BATCH(3);
OUT_BATCH(CMD_STATE_SIP 16 | (3 - 2));
diff --git a/src/mesa/drivers/dri/i965/brw_wm_state.c
b/src/mesa/drivers/dri/i965/brw_wm_state.c
index 0cd4390..e436175 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_state.c
@@ -31,6 +31,7 @@
+#include intel_batchbuffer.h
#include intel_fbo.h
#include brw_context.h
#include brw_state.h
@@ -251,6 +252,16 @@ brw_upload_wm_unit(struct brw_context *brw)
}
brw-ctx.NewDriverState |= BRW_NEW_GEN4_UNIT_STATE;
+
+ /* _NEW_POLGYON */
+ if (brw-wm.offset_clamp != ctx-Polygon.OffsetClamp) {
+ BEGIN_BATCH(2);
+ OUT_BATCH(_3DSTATE_GLOBAL_DEPTH_OFFSET_CLAMP 16 | (2 - 2));
+ OUT_BATCH_F(ctx-Polygon.OffsetClamp);
+ ADVANCE_BATCH();
+
+ brw-wm.offset_clamp = ctx-Polygon.OffsetClamp;
+ }
}
const struct
Re: [Mesa-dev] [PATCH 05/14] meta: Abort meta pbo path if readpixels need signed-unsigned conversion
On Fri, Jun 19, 2015 at 1:40 PM, Anuj Phogat anuj.pho...@gmail.com wrote: On Tue, Jun 16, 2015 at 9:21 PM, Jason Ekstrand ja...@jlekstrand.net wrote: On Jun 16, 2015 11:15, Anuj Phogat anuj.pho...@gmail.com wrote: Without this patch, piglit test fbo_integer_readpixels_sint_uint fails, when forced to use the meta pbo path. Signed-off-by: Anuj Phogat anuj.pho...@gmail.com Cc: mesa-sta...@lists.freedesktop.org --- src/mesa/drivers/common/meta_tex_subimage.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/drivers/common/meta_tex_subimage.c b/src/mesa/drivers/common/meta_tex_subimage.c index 00364f8..84cbc50 100644 --- a/src/mesa/drivers/common/meta_tex_subimage.c +++ b/src/mesa/drivers/common/meta_tex_subimage.c @@ -283,6 +283,9 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx, GLuint dims, if (_mesa_need_rgb_to_luminance_conversion(rb-Format, format)) return false; + + if (_mesa_need_signed_unsigned_int_conversion(rb-Format, format, type)) + return false; Hrm... This seems fishy. Isn't glBlitFramebuffers supposed to handle format conversion with integers? If so we should probably fix it rather than just skip it for the meta pbo path. As discussed offline, here is relevant text for glBlitFrameBuffer() from OpenGL 4.5 spec, section 18.3.1: An INVALID_OPERATION error is generated if format conversions are not supported, which occurs under any of the following conditions: -The read buffer contains fixed-point or floating-point values and any draw buffer contains neither fixed-point nor floating-point values. -The read buffer contains unsigned integer values and any draw buffer does not contain unsigned integer values. - The read buffer contains signed integer values and any draw buffer does not contain signed integer values. I'll add a comment here explaining the reason to avoid meta path. Thanks! With that added, Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com } /* For arrays, use a tall (height * depth) 2D texture but taking into -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 02/18] i965/fs: Fix fs_inst::regs_read() for uniform pull constant loads
On Fri, Jun 19, 2015 at 1:18 PM, Jason Ekstrand ja...@jlekstrand.net wrote: Previously, fs_inst::regs_read() fell back to depending on the register width for the second source. This isn't really correct since it isn't a SIMD8 value at all, but a SIMD4x2 value. This commit changes it to explicitly be always one register. Reviewed-by: Iago Toral Quiroga ito...@igalia.com v2: Use mlen for determining the number of registers written --- src/mesa/drivers/dri/i965/brw_fs.cpp | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp index 17a940b..6d25ba4 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp @@ -758,6 +758,12 @@ fs_inst::regs_read(int arg) const return mlen; break; + case FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD_GEN7: + /* The payload is actually storred in src1 */ stored just has one r ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Fri, Jun 19, 2015 at 6:45 PM, Connor Abbott cwabbo...@gmail.com wrote: On Thu, Jun 18, 2015 at 12:04 PM, Rob Clark robdcl...@gmail.com wrote: It is only vaguely an issue at the moment because the priority-queue scheduler that replaced what is on master does very badly with wide/shallow shaders, ie. like glsl-fs-convolution-1... ie. shaders with a lot of instructions at minimum depth.. (but I have some ideas to fix that) P.S. what does your heuristic currently look like? I was working on i965 scheduling, and after some discussion, this is what I did: http://cgit.freedesktop.org/~cwabbott0/mesa/commit/?h=i965-schedid=2d46e424327082bbc67758d05e6e102cbcd56d89 it's called delay in that code for some reason instead of depth (or, even better, critical path length), but you should get the idea... choose the earliest thing we can schedule, and then among those pick the thing with the largest depth. current heuristic is just depth. But if we have a large # of instructions with depth==1 those end up getting scheduled first increasing the register pressure.. (although on thinking about it, seems like I have something backwards, maybe I end up taking from the head of the depth sorted list instead of tail.. I should check that.. I hadn't really spent any time at all playing w/ the heuristic yet.. I just noticed that glsl-fs-convolution was a good example case of where I end up doing badly at the moment) BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Thu, Jun 18, 2015 at 12:04 PM, Rob Clark robdcl...@gmail.com wrote:
On Thu, Jun 18, 2015 at 2:34 PM, Connor Abbott cwabbo...@gmail.com wrote:
On Thu, Jun 18, 2015 at 11:19 AM, Rob Clark robdcl...@gmail.com wrote:
On Thu, Jun 18, 2015 at 1:27 PM, Connor Abbott cwabbo...@gmail.com wrote:
On Thu, Jun 18, 2015 at 9:42 AM, Rob Clark robdcl...@gmail.com wrote:
On Thu, Jun 18, 2015 at 11:01 AM, Connor Abbott cwabbo...@gmail.com
wrote:
(really I want phi's for variables too.. the way I turn arrays into
fanin/collect fanout/split works on the backend for dealing with
arrays in ssa form (other than making instruction graph large) but the
way I go from nir to ir3 currently assumes I get nir phi's everywhere
I need an ir3 phi)
Right... we explicitly decided not to support SSA form for arrays in
NIR, since it seemed like a pretty bad idea. SSA form assumes that
inserting copies for the things you're SSA-ifying is relatively
inexpensive, and both SSA-based register allocation and algorithms for
converting out of SSA make no guarantees about not inserting
potentially unnecessary copies. This is a good compromise for smaller
things, but not for your array of (say) 64 things where inserting an
extra copy is rather disastrous. You can do it if you want and shoot
yourself in the foot, but NIR isn't going to help you there -- we
won't write a to-SSA pass for something which doesn't make much sense
in the first place.
in ir3 my solution is to add sufficient dependencies between
instructions so the array accesses don't get re-ordered and they all
collapse down to a single name per array element/slot
It's not about getting reordered, it's about interference. The problem
is that as soon as you do basically any optimization at all (even copy
propagation), you can wind up with a situation where the sources and
destination of a phi node interfere with each other and you have to
insert extra mov's. And even if you keep everything exactly the same,
with an SSA-based register allocator, there's always the chance that
it'll screw up anyways and allocate something over your array and
force you to insert a mov. You could force the array to be allocated
to a single hardware register, but then it's not really an SSA value
anymore -- it's a hardware register, and you can't treat it like an
SSA value anymore in your allocator, and so adding phi nodes and
whatnot for it in your IR doesn't make much sense.
But the point I'm trying to make is that I need the links from src to
dest that I get in SSA form for *scheduling* (for example, to know how
many delay slots are needed between two instructions). For things
like if/else, I would need to consider number of cycles since either
possible assigner. For everything else, the phi nodes (in ir3, not in
nir) give me this. Arrays are not special (since they are allocated
in registers) when it comes to cycle counts.
BR,
-R
Except that they still are special, and you need to account for that
when you set up scheduling dependencies for them. For example, imagine
that you have an array A accessed in a loop:
while (...) {
... = A[i];
A[i] = ...;
}
if you lower the array to SSA, this will give you something like:
while (...) {
A_1 = phi(A_0, A_2);
... = A_1[i];
A_2 = Update(A_1, i, ...); /* makes a copy with the i'th element
changed */
}
and when you set up scheduling dependencies, you'll miss the false
write-after-read dependency between the access and the update, meaning
you could end up with:
while (...) {
A_1 = phi(A_0, A_2);
A_2 = Update(A_1, i, ...);
... = A_1[i];
}
and now the number of instructions in your shader has exploded since
you have to insert a copy somewhere. You could add all the false
dependencies by yourself, and force it into the same register, but by
that point you've already given up all the advantages that SSA has to
offer and inserting phi nodes is a rather pointless exercise.
except, like I said, for the purpose of scheduling realizing that
there are two dependency paths to consider for figuring out the
required number of delay slots..
No, there aren't. There's the dependency between the read and the
write (in my example), which serializes things and makes it one path.
In other words, the stuff before the write must happen before the
write, even if in SSA those are two different values.
that wasn't really the case I was talking about.. but rather:
if (...) {
...
arr[i] = a + b;
} else {
arr[i] = c + d;
}
... = arr[i];
In that case, everything is in a seperate basic block and the
scheduler still doesn't need to have the phi nodes. This is already a
well-known problem that i965, as well as basically every other backend
ever, has solved without doing what you want to do.
That said, having to re-invent the to-ssa pass in my backend is
something I was hoping to avoid.. so I'm thinking of other
alternatives. But
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Fri, Jun 19, 2015 at 6:21 PM, Connor Abbott cwabbo...@gmail.com wrote: and the RA has to split live-ranges of other things and deal with arrays specially too in order to not introduce extra array copies. If I did spilling/rematerialization.. but I don't. If you force every array into a specific register range, and assume that every array is live since the beginning of the program, then you may not have to do that. But then, again, this means that inserting phi nodes doesn't help you at all in the register allocator. If you're doing anything else, then you certainly will have to split live ranges, even without spilling, since you may run into a situation where the array becomes live, but there isn't a big enough slot to fit it in even if the register pressure is low enough for everything to fit. In any case, you'll have to know the original array where each value came from in order to not accidentally generate copies, so why bother inserting phi nodes at all? I don't disagree with you.. fragmentation of the register space could be an issue.. it just isn't the biggest issue right now (and because of the hard requirement of ensuring sufficient instruction cycles between producer and consumer, any mov's inserted in RA would require re-scheduling) Anyways, that is basically an different topic. BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/14] mesa: Fix conditions to test signed, unsigned integer format
On Thu, Jun 18, 2015 at 11:41 PM, Iago Toral ito...@igalia.com wrote:
On Thu, 2015-06-18 at 09:19 -0700, Anuj Phogat wrote:
On Thu, Jun 18, 2015 at 7:09 AM, Iago Toral ito...@igalia.com wrote:
On Tue, 2015-06-16 at 11:15 -0700, Anuj Phogat wrote:
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/main/readpix.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index caa2648..a9416ef 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -160,10 +160,12 @@ _mesa_readpixels_needs_slow_path(const struct
gl_context *ctx, GLenum format,
srcType = _mesa_get_format_datatype(rb-Format);
if ((srcType == GL_INT
+ _mesa_is_enum_format_integer(format)
(type == GL_UNSIGNED_INT ||
type == GL_UNSIGNED_SHORT ||
type == GL_UNSIGNED_BYTE)) ||
(srcType == GL_UNSIGNED_INT
+ _mesa_is_enum_format_integer(format)
(type == GL_INT ||
type == GL_SHORT ||
type == GL_BYTE))) {
As far as I understand this code we are trying to see if we can use
memcpy to directly copy the contents of the framebuffer to the
destination buffer. In that case, as long as the src/dst types have
different sign we can't just use memcpy, right? In fact it looks like we
might need to expand the checks to include the cases where srcType is
GL_(UNSIGNED_)SHORT and GL_(UNSIGNED_)BYTE as well.
srcType returned by _mesa_get_format_datatype() is one of:
GL_UNSIGNED_NORMALIZED
GL_SIGNED_NORMALIZED
GL_UNSIGNED_INT
GL_INT
GL_FLOAT
So, the suggested checks for srcType are not required.
Oh, right, although I think that does not invalidate my point: can we
memcpy from a GL_UNSIGNED_NORMALIZED to a format with type GL_FLOAT or
GL_SIGNED_NORMALIZED? It does not look like these checks here are
thorough.
Helper function _mesa_need_signed_unsigned_int_conversion() is
meant to do the checks only for integer formats. May be add another
function to do the missing checks for other formats?
In any case, that's beyond the point of your patch. Talking specifically
about your patch: can we memcpy, for example, from a _signed_ integer
format like MESA_FORMAT_R_SINT8 to an _unsigned_ format (integer or
not)? I don't think we can, in which case your patch would not look
correct to me.
Reading integer format to a non integer format is not allowed in
glReadPixels. That's why those cases are not relevant here and
we just check for integer formats. From ext_texture_integer:
INVALID_OPERATON is generated by ReadPixels if format is
an integer format and the color buffer is not an integer format, or
if format is not an integer format and the color buffer is an
integer format.
Also, as I said in my previous e-mail, I feel like these checks here do
not add anything, at least when this function is called from
readpixels_can_use_memcpy, since even if we return true here, we will
later call _mesa_format_matches_format_and_type and that would check
that the formats match anyway before going through the memcpy path. Even
the other use of this function in Gallium would call
_mesa_format_matches_format_and_type before it calls this... That's why
I think we probably want to remove these checks from this function and
rely on _mesa_format_matches_format_and_type exclusively to check
allowed formats and types.
It does seem like calling _mesa_need_signed_unsigned_int_conversion()
is redundant in case of readpixels_can_use_memcpy(). Thanks for noticing
it. Feel free to submit a patch to remove the redundant check.
But, I still need _mesa_need_signed_unsigned_int_conversion() and changes
in this patch for one of my later patches fixing meta PBO path for glReadPixels.
Do you still have any concerns about this patch?
That said, I think this code is not necessary with the call to
_mesa_format_matches_format_and_type that we do immediately after this,
since that will check that the framebuffer format exactly matches the
destination format anyway, which is a much tighter check than this. In
fact, a quick piglit run without these checks does not seem to break any
tests on i965. Gallium uses these two functions in a slightly different
way in st_cb_readpixels.c though, so I wonder if their use case requires
these checks to exist in this function anyway.
Iago
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/14] meta: Abort meta pbo path if readpixels need signed-unsigned conversion
On Tue, Jun 16, 2015 at 9:21 PM, Jason Ekstrand ja...@jlekstrand.net wrote: On Jun 16, 2015 11:15, Anuj Phogat anuj.pho...@gmail.com wrote: Without this patch, piglit test fbo_integer_readpixels_sint_uint fails, when forced to use the meta pbo path. Signed-off-by: Anuj Phogat anuj.pho...@gmail.com Cc: mesa-sta...@lists.freedesktop.org --- src/mesa/drivers/common/meta_tex_subimage.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/drivers/common/meta_tex_subimage.c b/src/mesa/drivers/common/meta_tex_subimage.c index 00364f8..84cbc50 100644 --- a/src/mesa/drivers/common/meta_tex_subimage.c +++ b/src/mesa/drivers/common/meta_tex_subimage.c @@ -283,6 +283,9 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx, GLuint dims, if (_mesa_need_rgb_to_luminance_conversion(rb-Format, format)) return false; + + if (_mesa_need_signed_unsigned_int_conversion(rb-Format, format, type)) + return false; Hrm... This seems fishy. Isn't glBlitFramebuffers supposed to handle format conversion with integers? If so we should probably fix it rather than just skip it for the meta pbo path. As discussed offline, here is relevant text for glBlitFrameBuffer() from OpenGL 4.5 spec, section 18.3.1: An INVALID_OPERATION error is generated if format conversions are not supported, which occurs under any of the following conditions: -The read buffer contains fixed-point or floating-point values and any draw buffer contains neither fixed-point nor floating-point values. -The read buffer contains unsigned integer values and any draw buffer does not contain unsigned integer values. - The read buffer contains signed integer values and any draw buffer does not contain signed integer values. I'll add a comment here explaining the reason to avoid meta path. } /* For arrays, use a tall (height * depth) 2D texture but taking into -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/11] glapi fixes - build whole of mesa with
On 19/06/15 20:56, Emil Velikov wrote: Hi all, A lovely series inspired (more like 'was awaken to send these out') by Pal Rohár, who was having issues when building xlib-libgl (plus the now enabled gles*) So here, we teach the final two static glapi users about shared-glapi, plus some related fixes. After this is done we can finally start transitioning to shared-only glapi, with some more details as mentioned in one of the patches: XXX: With this one done, we can finally transition with enforcing shared-glapi, and - link the dri modules against libglapi.so, add --no-undefined to the LDFLAGS - drop the dlopen(libglapi.so/libGL.so, RTLD_GLOBAL) workarounds in the loaders - libGL, libEGL and libgbm. - start killing off/cleaning up the dispatch ? The caveats: 1) up to what stage do we care about static libraries - libgl (either dri or xlib based) - osmesa - libEGL 2) how about other platforms (scons) ? - currently the scons uses static glapi, - would we need the dlopen(...) on windows ? Hope everyone is excited about this one as I am :-) Maybe I missed the context of this changes, but why this matters or is an improvement? I understand the rationale for EGL and DRI. But I'm asking specifically about xlib libgl, osmesa, and Windows ICD drivers. At a glance, for osmesa and xlib-libgl, forcing to split into multiple .so seems a step backwards. Rather than making these easy to use and embedded, it adds complexity, plus potentially prevents using os mesa and libgl-xlib along side with the system's true libGL.so. Finally, it's not clear whether this would force Windows OpenGL ICD drivers to be split into two multiple DLLs, but I'm afraid that's a big show stopper. In summary, having the ability of using a shared glapi sounds great, but forcing shared glapi everywhere, sounds a bad idea. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/11] glapi fixes - build whole of mesa with
On 19 June 2015 at 21:26, Jose Fonseca jfons...@vmware.com wrote: On 19/06/15 20:56, Emil Velikov wrote: Hi all, A lovely series inspired (more like 'was awaken to send these out') by Pal Rohár, who was having issues when building xlib-libgl (plus the now enabled gles*) So here, we teach the final two static glapi users about shared-glapi, plus some related fixes. After this is done we can finally start transitioning to shared-only glapi, with some more details as mentioned in one of the patches: XXX: With this one done, we can finally transition with enforcing shared-glapi, and - link the dri modules against libglapi.so, add --no-undefined to the LDFLAGS - drop the dlopen(libglapi.so/libGL.so, RTLD_GLOBAL) workarounds in the loaders - libGL, libEGL and libgbm. - start killing off/cleaning up the dispatch ? The caveats: 1) up to what stage do we care about static libraries - libgl (either dri or xlib based) - osmesa - libEGL 2) how about other platforms (scons) ? - currently the scons uses static glapi, - would we need the dlopen(...) on windows ? Hope everyone is excited about this one as I am :-) Maybe I missed the context of this changes, but why this matters or is an improvement? If one goes the extra mile (which this series doesn't) - one configure option less, substantial some code de-duplication and consistent use of the code amongst all components provided. This way any improvements/cleanups made to the shared glapi will be available to osmesa/xlib-libgl. I understand the rationale for EGL and DRI. But I'm asking specifically about xlib libgl, osmesa, and Windows ICD drivers. You and Brian being one of the few few people that use/work on the latter three, I'm really glad that to hear any feedback. Note that this series does not force anything - just allows one to use shared-glapi with the final remaining GL* providers - xlib-libgl. OSMESA already has that capability. At a glance, for osmesa and xlib-libgl, forcing to split into multiple .so seems a step backwards. Rather than making these easy to use and embedded, it adds complexity, plus potentially prevents using os mesa and libgl-xlib along side with the system's true libGL.so. I would say that the biggest complexity is within the presence of both static and shared glapi and the ton of spaghetti code and gets conditionally build. After all, you know better than me the monsters that lie in src/mapi. I'm not sure that having an extra .so makes things that harder to use or embed, although I do see the concern. Needless to say this is one of the reasons why I've been sitting on these for so long. I had most of them for well over 3 months anticipating the interesting discussion and/or bikeshed (even some on my end :-P) Finally, it's not clear whether this would force Windows OpenGL ICD drivers to be split into two multiple DLLs, but I'm afraid that's a big show stopper. As mentioned above, nothing is forced and the scons/windows topics are more than welcome for discussions. I'm secretly hoping thst someone will come along with a genius hack which we can use to fold the shared glapi back into the original library. In summary, having the ability of using a shared glapi sounds great, but forcing shared glapi everywhere, sounds a bad idea. I'm suspecting that people might be keen on the following idea - use static glapi for osmesa/xlib-libgl and shared one everywhere else? I fear that this will lead to further separation/bit-rot between the different implementations, but it seems like the bester compromise. Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] abundance of branches in mesa.git
Hello, There are a *ton* of branches in the upstream mesa git. Here is a full list: origin/10.0 origin/10.1 origin/10.2 origin/10.3 origin/10.4 origin/10.5 origin/10.6 origin/7.10 origin/7.11 origin/7.8 origin/7.8-gles origin/7.9 origin/8.0 origin/9.0 origin/9.1 origin/9.2 origin/965-glsl origin/965-ttm origin/HEAD - origin/master origin/R300_DRIVER origin/amdgpu origin/arb_copy_buffer origin/arb_fbo origin/arb_fbo_cleanup origin/arb_fbo_indirect origin/arb_geometry_shader4 origin/arb_half_float_vertex origin/arb_map_buffer_range origin/arb_robustness origin/arb_sampler_objects origin/arb_sync origin/arb_vertex_array_object origin/asm-shader-rework-1 origin/asm-shader-rework-2 origin/asm-shader-rework-3 origin/auto-cherry-for-8.0 origin/autoconf origin/broadwell origin/cxx-1-branch origin/d3d1x-addons origin/direct_state_access origin/draw-instanced origin/draw-ply origin/dri2-swapbuffers origin/drm-gem origin/egl-drm origin/embedded-1-branch origin/embedded-2-branch origin/experimental-1 origin/ext-provoking-vertex origin/flex-and-bison-required origin/floating origin/fp64_floor origin/frontbuffer-removal origin/gallium-0.1 origin/gallium-0.1-dri origin/gallium-0.1-dri2 origin/gallium-0.2 origin/gallium-array-textures origin/gallium-buffer-usage-cleanup origin/gallium-clip-state origin/gallium-compute origin/gallium-context-transfers-2 origin/gallium-cylindrical-wrap origin/gallium-double-opcodes origin/gallium-drm-driver-descriptor origin/gallium-dynamicstencilref origin/gallium-fb-dimensions origin/gallium-float--format origin/gallium-format-cleanup origin/gallium-front-ccw origin/gallium-gpu4-texture-opcodes origin/gallium-integer-opcodes origin/gallium-llvmpipe origin/gallium-mesa-7.4 origin/gallium-msaa origin/gallium-new-formats origin/gallium-newclear origin/gallium-no-nvidia-opcodes origin/gallium-no-rhw-position origin/gallium-no-texture-blanket origin/gallium-nopointsizeminmax origin/gallium-render-condition-predicate origin/gallium-resource-sampling origin/gallium-resources origin/gallium-sampler-view origin/gallium-softpipe-winsys origin/gallium-st-api origin/gallium-st-api-dri origin/gallium-stream-out origin/gallium-sw-api origin/gallium-tgsi-semantic-cleanup origin/gallium-userbuf origin/gallium-util-format-is-supported origin/gallium-vertexelementcso origin/gallium_draw_llvm origin/gallivm-call origin/glapi-reorg origin/gles3 origin/glsl-compiler-1 origin/glsl-continue-return origin/glsl-continue-return-7-5 origin/glsl-pp-rework-1 origin/glsl-pp-rework-2 origin/glsl-to-tgsi origin/glsl2 origin/glsl2-llvm origin/glsl2-lower-variable-indexing origin/graw-tests origin/hw_gl_select origin/i915tex-pageflip origin/i915tex-zone-rendering origin/i915tex_branch origin/i915tex_privbuffers origin/index-swtnl-0.1 origin/indirect-vbo origin/intel-2008-q3 origin/intel-2008-q4 origin/kasanen-post-process origin/kasanen-post-process-v2 origin/llvm-cliptest-viewport origin/llvm-context origin/llvmpipe-duma origin/llvmpipe-rast-64 origin/llvmpipe-wider-regs origin/loader-v4 origin/lp-line-rast origin/lp-offset-twoside origin/lp-setup-llvm origin/lp-surface-tiling origin/map-tex-branch origin/map-texture-image-v4 origin/map-texture-image-v5 origin/master origin/mesa origin/mesa_20040127_branch origin/mesa_20040309_branch origin/mesa_20050114_branch origin/mesa_3_2_dev origin/mesa_3_3_texture_env_combine2 origin/mesa_3_4_branch origin/mesa_4_0_branch origin/mesa_5_0_branch origin/mesa_6_0_branch origin/mesa_6_2_branch origin/mesa_6_4_branch origin/mesa_7_0_branch origin/mesa_7_2_branch origin/mesa_7_4_branch origin/mesa_7_4_idr_staging origin/mesa_7_5_branch origin/mesa_7_6_branch origin/mesa_7_7_branch origin/nv50-compiler origin/nvc0 origin/openchrome-branch origin/opengl-es origin/opengl-es-v2 origin/openvg-1.0 origin/outputswritten64 origin/pipe-video origin/primitive-restart origin/r300-bufmgr origin/r500-support origin/r6xx-r7xx-support origin/r6xx-rewrite origin/radeon-rewrite origin/remove-copyteximage-hook origin/remove-driver-date origin/remove-max-width origin/remove-max-width-2 origin/remove-redundant-helpers origin/renderbuffer-cleanups-v2 origin/shader-file-reorg origin/shader-work origin/softpipe_0_1_branch origin/sprite-coord origin/st-mesa-per-context-shaders origin/st-vbo origin/texfilter_float_branch origin/texformat-xrgb origin/texman_0_1_branch origin/texmem-1.0 origin/texmem_0_2_branch origin/texmem_0_3_branch origin/texture_rg origin/texture_rg-2 origin/thalloc origin/vbo_0_1_branch origin/vtx-0-1-branch origin/vtx-0-2-branch origin/xa_branch The vast, vast, *vast*, majority of these appear to be old
Re: [Mesa-dev] [PATCH 1/2] [RFC] i965/vec4: Reward spills in if/else/endif blocks
I don't think this is doing what you think it's doing. This code is
for calculating the *cost* of spills, so a higher cost means a lower
priority for choosing the register. We increase the cost for things
inside loops because we don't want to spill inside loops, and by doing
the same thing for if's you're actually discouraging spills inside an
if block.
On Fri, Jun 19, 2015 at 5:21 PM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
If we have a register that needs spilling in an if/else block, there is a
chance
that we may not need to spill if we do[n't] take the branch.
The downside of this patch is the case where the register being spilled ends
up
in both if/else blocks. For that case, preferring this path will increase code
size with no possible performance benefit.
Same patch for FS coming up.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
index b9db908..b345f27 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
@@ -309,10 +309,12 @@ vec4_visitor::evaluate_spill_costs(float *spill_costs,
bool *no_spill)
switch (inst-opcode) {
+ case BRW_OPCODE_ENDIF:
case BRW_OPCODE_DO:
loop_scale *= 10;
break;
+ case BRW_OPCODE_IF:
case BRW_OPCODE_WHILE:
loop_scale /= 10;
break;
--
2.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] [RFC] i965/vec4: Reward spills in if/else/endif blocks
On Fri, Jun 19, 2015 at 08:04:51PM -0700, Matt Turner wrote: On Fri, Jun 19, 2015 at 6:53 PM, Connor Abbott cwabbo...@gmail.com wrote: I don't think this is doing what you think it's doing. This code is for calculating the *cost* of spills, so a higher cost means a lower priority for choosing the register. We increase the cost for things inside loops because we don't want to spill inside loops, and by doing the same thing for if's you're actually discouraging spills inside an if block. Top quoting is bad, m'kay. But, I think it is doing what he thinks since he increases costs for ENDIF and decreases costs for IF. That is, it's backwards from DO/WHILE. Why this is a good thing to do... I don't know. I'd expect some data along with this patch in order to evaluate it properly. Well, I think the theory was described in the patch, so I'm not sure if you're disagreeing with the theory, or you missed the theory (you spill less of the time because you don't always take both branches). As for data... I made the patch RFC for a reason :-). I noticed a lot of the previous spilling related patches used shader-db as a measure, however, I don't think that's a good measure for spills in many cases (do/while is exactly such an example). As I mentioned in the commit as well, there are certainly cases where I could see shader size increasing, but not actual execution time. So if there are real benchmarks I can run, which spill, I am happy to do that - but I don't see any value in me spending time doing anything else. I see shader-db as a good thing to run to make sure it doesn't blow up every test, and that's about all. I'm content to leave this as an RFC indefinitely. I'm under the impression optimizing the spill cases aren't super critical anyway. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] [RFC] i965/vec4: Reward spills in if/else/endif blocks
On Fri, Jun 19, 2015 at 6:53 PM, Connor Abbott cwabbo...@gmail.com wrote: I don't think this is doing what you think it's doing. This code is for calculating the *cost* of spills, so a higher cost means a lower priority for choosing the register. We increase the cost for things inside loops because we don't want to spill inside loops, and by doing the same thing for if's you're actually discouraging spills inside an if block. Top quoting is bad, m'kay. But, I think it is doing what he thinks since he increases costs for ENDIF and decreases costs for IF. That is, it's backwards from DO/WHILE. Why this is a good thing to do... I don't know. I'd expect some data along with this patch in order to evaluate it properly. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] [RFC] i965/vec4: Reward spills in if/else/endif blocks
If we have a register that needs spilling in an if/else block, there is a chance
that we may not need to spill if we do[n't] take the branch.
The downside of this patch is the case where the register being spilled ends up
in both if/else blocks. For that case, preferring this path will increase code
size with no possible performance benefit.
Same patch for FS coming up.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
index b9db908..b345f27 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
@@ -309,10 +309,12 @@ vec4_visitor::evaluate_spill_costs(float *spill_costs,
bool *no_spill)
switch (inst-opcode) {
+ case BRW_OPCODE_ENDIF:
case BRW_OPCODE_DO:
loop_scale *= 10;
break;
+ case BRW_OPCODE_IF:
case BRW_OPCODE_WHILE:
loop_scale /= 10;
break;
--
2.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] [RFC] i965/fs: Reward spills in if/else/endif blocks
Just like the previous patch but for the FS.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 2 ++
1 file changed, 2 insertions(+)
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 cd78816..d53449a 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
@@ -805,10 +805,12 @@ fs_visitor::choose_spill_reg(struct ra_graph *g)
switch (inst-opcode) {
+ case BRW_OPCODE_ENDIF:
case BRW_OPCODE_DO:
loop_scale *= 10;
break;
+ case BRW_OPCODE_IF:
case BRW_OPCODE_WHILE:
loop_scale /= 10;
break;
--
2.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 02/18] i965/fs: Fix fs_inst::regs_read() for uniform pull constant loads
On Fri, Jun 19, 2015 at 1:51 PM, Matt Turner matts...@gmail.com wrote: On Fri, Jun 19, 2015 at 1:18 PM, Jason Ekstrand ja...@jlekstrand.net wrote: Previously, fs_inst::regs_read() fell back to depending on the register width for the second source. This isn't really correct since it isn't a SIMD8 value at all, but a SIMD4x2 value. This commit changes it to explicitly be always one register. Reviewed-by: Iago Toral Quiroga ito...@igalia.com v2: Use mlen for determining the number of registers written --- src/mesa/drivers/dri/i965/brw_fs.cpp | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp index 17a940b..6d25ba4 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp @@ -758,6 +758,12 @@ fs_inst::regs_read(int arg) const return mlen; break; + case FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD_GEN7: + /* The payload is actually storred in src1 */ stored just has one r Thanks! Fixed locally. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 2/2] nvc0: use NV_VRAM_DOMAIN() macro
On Fri, Jun 19, 2015 at 10:55 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Fri, Jun 19, 2015 at 6:02 AM, Alexandre Courbot acour...@nvidia.com
wrote:
Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
VRAM domains for chips that do not have dedicated video memory.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
src/gallium/drivers/nouveau/nouveau_buffer.c | 6 ++
src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_compute.c| 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_context.c| 4 ++--
src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_program.c| 8
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 17
+++--
src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_tex.c| 2 +-
src/gallium/drivers/nouveau/nvc0/nve4_compute.c| 2 +-
11 files changed, 26 insertions(+), 23 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c
b/src/gallium/drivers/nouveau/nouveau_buffer.c
index 32fa65c8a51c..bb7676cffbc0 100644
--- a/src/gallium/drivers/nouveau/nouveau_buffer.c
+++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
@@ -658,13 +658,11 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
switch (buffer-base.usage) {
case PIPE_USAGE_DEFAULT:
case PIPE_USAGE_IMMUTABLE:
- buffer-domain = NOUVEAU_BO_VRAM;
- break;
case PIPE_USAGE_DYNAMIC:
/* For most apps, we'd have to do staging transfers to avoid sync
* with this usage, and GART - GART copies would be suboptimal.
*/
This comment only applies to USAGE_DYNAMIC. With the removal of the
hunk above, that makes it seem like it applies to all 3. Just keep
both hunks and update both of them.
Other than that this patch seems straightforward enough, with the
above fixed, the series is
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
Will fix that and resend. Thanks for the review!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Nouveau] [PATCH v3 0/2] nouveau: support for custom VRAM domains
On Fri, Jun 19, 2015 at 9:38 PM, Ben Skeggs skeg...@gmail.com wrote: On 19 June 2015 at 21:51, Martin Peres martin.pe...@free.fr wrote: On 19/06/2015 13:02, Alexandre Courbot wrote: New revision of this patchset that prevents VRAM objects from being allocated on VRAM-less systems like Tegra. This is required for Mesa to work on such systems. Changes since v2: - Use vram_size to detect systems without VRAM and set the correct domain instead of expecting each chip to set its domain explicitly. This question may have been asked a ton of times, but what is the difference with the nvac (Ion)? Would the nvac have some reserved memory for its usage by the bios which would then be used as VRAM? PFB on the dGPU IGPs has facilities to fake VRAM from an area of stolen system memory reserved by the SBIOS. GK20A/GM20B do not do this, and require direct (or, via a mmu, whatever) access to system memory. Exactly. While dGPU do actually carve out a range of system memory to be exclusively used as fake VRAM, Tegra GPUs have access to the whole system memory which is shared with the other IPs of the SoC, which requires a different management strategy. Hence the choice to simply wipe out the concept of VRAM and use everything as system memory. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] [RFC] i965/vec4: Reward spills in if/else/endif blocks
I'm not seeing where it does anything other than what I say. Beforehand the cost
is increased (*=) from DO-WHILE. Now it should be decreased (/= 10) from
IF-ENDIF. The factor of 10 probably needs to be modified since I suspect
Can you help me see what I'm not seeing?
On Fri, Jun 19, 2015 at 06:53:28PM -0700, Connor Abbott wrote:
I don't think this is doing what you think it's doing. This code is
for calculating the *cost* of spills, so a higher cost means a lower
priority for choosing the register. We increase the cost for things
inside loops because we don't want to spill inside loops, and by doing
the same thing for if's you're actually discouraging spills inside an
if block.
On Fri, Jun 19, 2015 at 5:21 PM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
If we have a register that needs spilling in an if/else block, there is a
chance
that we may not need to spill if we do[n't] take the branch.
The downside of this patch is the case where the register being spilled
ends up
in both if/else blocks. For that case, preferring this path will increase
code
size with no possible performance benefit.
Same patch for FS coming up.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
index b9db908..b345f27 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp
@@ -309,10 +309,12 @@ vec4_visitor::evaluate_spill_costs(float
*spill_costs, bool *no_spill)
switch (inst-opcode) {
+ case BRW_OPCODE_ENDIF:
case BRW_OPCODE_DO:
loop_scale *= 10;
break;
+ case BRW_OPCODE_IF:
case BRW_OPCODE_WHILE:
loop_scale /= 10;
break;
--
2.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: update developer info
On Friday, June 19, 2015 01:14:07 PM Timothy Arceri wrote: Just link directly to the piglit repo the old link has outdated information. Add note about updating patchwork when sending patch revisions. --- docs/devinfo.html | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/docs/devinfo.html b/docs/devinfo.html index 0da18b9..6779ab4 100644 --- a/docs/devinfo.html +++ b/docs/devinfo.html @@ -244,7 +244,7 @@ to update the tests themselves. p Whenever possible and applicable, test the patch with -a href=http://people.freedesktop.org/~nh/piglit/;Piglit/a to +a href=http://cgit.freedesktop.org/piglit;Piglit/a to check for regressions. /p @@ -266,6 +266,12 @@ re-sending the whole series). Using --in-reply-to makes it harder for reviewers to accidentally review old patches. /p +p +When submitting follow-up patches you should also login to +a href=https://patchwork.freedesktop.org;patchwork/a and change the +state of your old patches to Superseded. +/p + h3Reviewing Patches/h3 p I might link to http://piglit.freedesktop.org/ instead - it's the actual Piglit website. (There's not much more than the git link, though - either are definitely better than linking to ~nh!) signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/46] mesa: add tessellation shader getters.
On Wednesday, June 17, 2015 01:01:11 AM Marek Olšák wrote:
From: Fabian Bieler fabianbie...@fastmail.fm
Tessellation dependencies added by Marek.
---
src/mesa/main/get.c | 1 +
src/mesa/main/get_hash_params.py | 28 ++
src/mesa/main/shaderapi.c| 84
3 files changed, 113 insertions(+)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 1bc9b5d..6f2e1ec 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -400,6 +400,7 @@ EXTRA_EXT(INTEL_performance_query);
EXTRA_EXT(ARB_explicit_uniform_location);
EXTRA_EXT(ARB_clip_control);
EXTRA_EXT(EXT_polygon_offset_clamp);
+EXTRA_EXT(ARB_tessellation_shader);
static const int
extra_ARB_color_buffer_float_or_glcore[] = {
diff --git a/src/mesa/main/get_hash_params.py
b/src/mesa/main/get_hash_params.py
index 513d5d2..6d393cc 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -820,6 +820,34 @@ descriptor=[
# GL_EXT_polygon_offset_clamp
[ POLYGON_OFFSET_CLAMP_EXT, CONTEXT_FLOAT(Polygon.OffsetClamp),
extra_EXT_polygon_offset_clamp ],
+
+# GL_ARB_tessellation_shader
+ [ PATCH_VERTICES, CONTEXT_INT(TessCtrlProgram.patch_vertices),
extra_ARB_tessellation_shader ],
+ [ PATCH_DEFAULT_OUTER_LEVEL,
CONTEXT_FLOAT4(TessCtrlProgram.patch_default_outer_level),
extra_ARB_tessellation_shader ],
+ [ PATCH_DEFAULT_INNER_LEVEL,
CONTEXT_FLOAT2(TessCtrlProgram.patch_default_inner_level),
extra_ARB_tessellation_shader ],
+ [ MAX_TESS_GEN_LEVEL, CONTEXT_INT(Const.MaxTessGenLevel),
extra_ARB_tessellation_shader ],
+ [ MAX_PATCH_VERTICES, CONTEXT_INT(Const.MaxPatchVertices),
extra_ARB_tessellation_shader ],
+ [ MAX_TESS_CONTROL_UNIFORM_COMPONENTS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_CTRL].MaxUniformComponents),
extra_ARB_tessellation_shader ],
+ [ MAX_TESS_EVALUATION_UNIFORM_COMPONENTS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_EVAL].MaxUniformComponents),
extra_ARB_tessellation_shader ],
+ [ MAX_TESS_CONTROL_TEXTURE_IMAGE_UNITS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_CTRL].MaxTextureImageUnits),
extra_ARB_tessellation_shader ],
+ [ MAX_TESS_EVALUATION_TEXTURE_IMAGE_UNITS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_EVAL].MaxTextureImageUnits),
extra_ARB_tessellation_shader ],
+ [ MAX_TESS_CONTROL_OUTPUT_COMPONENTS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_CTRL].MaxOutputComponents),
extra_ARB_tessellation_shader ],
+ [ MAX_TESS_PATCH_COMPONENTS, CONTEXT_INT(Const.MaxTessPatchComponents),
extra_ARB_tessellation_shader ],
+ [ MAX_TESS_CONTROL_TOTAL_OUTPUT_COMPONENTS,
CONTEXT_INT(Const.MaxTessControlTotalOutputComponents),
extra_ARB_tessellation_shader ],
+ [ MAX_TESS_EVALUATION_OUTPUT_COMPONENTS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_EVAL].MaxOutputComponents),
extra_ARB_tessellation_shader ],
+ [ MAX_TESS_CONTROL_INPUT_COMPONENTS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_CTRL].MaxInputComponents),
extra_ARB_tessellation_shader ],
+ [ MAX_TESS_EVALUATION_INPUT_COMPONENTS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_EVAL].MaxInputComponents),
extra_ARB_tessellation_shader ],
+ [ MAX_TESS_CONTROL_UNIFORM_BLOCKS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_CTRL].MaxUniformBlocks),
extra_ARB_tessellation_shader ],
+ [ MAX_TESS_EVALUATION_UNIFORM_BLOCKS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_EVAL].MaxUniformBlocks),
extra_ARB_tessellation_shader ],
+ [ MAX_COMBINED_TESS_CONTROL_UNIFORM_COMPONENTS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_CTRL].MaxCombinedUniformComponents),
extra_ARB_tessellation_shader ],
+ [ MAX_COMBINED_TESS_EVALUATION_UNIFORM_COMPONENTS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_EVAL].MaxCombinedUniformComponents),
extra_ARB_tessellation_shader ],
+# Dependencies on GL_ARB_tessellation_shader
+ [ MAX_TESS_CONTROL_ATOMIC_COUNTER_BUFFERS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_CTRL].MaxAtomicBuffers),
extra_ARB_shader_atomic_counters ],
+ [ MAX_TESS_CONTROL_ATOMIC_COUNTERS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_CTRL].MaxAtomicCounters),
extra_ARB_shader_atomic_counters ],
+ [ MAX_TESS_EVALUATION_ATOMIC_COUNTER_BUFFERS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_EVAL].MaxAtomicBuffers),
extra_ARB_shader_atomic_counters ],
+ [ MAX_TESS_EVALUATION_ATOMIC_COUNTERS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_EVAL].MaxAtomicCounters),
extra_ARB_shader_atomic_counters ],
+ [ MAX_TESS_CONTROL_IMAGE_UNIFORMS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_CTRL].MaxImageUniforms),
extra_ARB_shader_image_load_store],
+ [ MAX_TESS_EVALUATION_IMAGE_UNIFORMS,
CONTEXT_INT(Const.Program[MESA_SHADER_TESS_EVAL].MaxImageUniforms),
extra_ARB_shader_image_load_store],
Shouldn't these last four should actually be ARB_tessellation_shader
*and* ARB_shader_atomic_counters/ARB_shader_image_load_store?
Do we also need to check for core profile? (It's been
Re: [Mesa-dev] [PATCH v3 2/2] nvc0: use NV_VRAM_DOMAIN() macro
On Fri, Jun 19, 2015 at 6:02 AM, Alexandre Courbot acour...@nvidia.com wrote:
Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
VRAM domains for chips that do not have dedicated video memory.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
src/gallium/drivers/nouveau/nouveau_buffer.c | 6 ++
src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_compute.c| 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_context.c| 4 ++--
src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_program.c| 8
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 17 +++--
src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_tex.c| 2 +-
src/gallium/drivers/nouveau/nvc0/nve4_compute.c| 2 +-
11 files changed, 26 insertions(+), 23 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c
b/src/gallium/drivers/nouveau/nouveau_buffer.c
index 32fa65c8a51c..bb7676cffbc0 100644
--- a/src/gallium/drivers/nouveau/nouveau_buffer.c
+++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
@@ -658,13 +658,11 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
switch (buffer-base.usage) {
case PIPE_USAGE_DEFAULT:
case PIPE_USAGE_IMMUTABLE:
- buffer-domain = NOUVEAU_BO_VRAM;
- break;
case PIPE_USAGE_DYNAMIC:
/* For most apps, we'd have to do staging transfers to avoid sync
* with this usage, and GART - GART copies would be suboptimal.
*/
This comment only applies to USAGE_DYNAMIC. With the removal of the
hunk above, that makes it seem like it applies to all 3. Just keep
both hunks and update both of them.
Other than that this patch seems straightforward enough, with the
above fixed, the series is
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/17] i965/fs: Explicitly set the exec_size on the add(32) in interpolation setup
On Jun 19, 2015 5:09 AM, Iago Toral ito...@igalia.com wrote: On Thu, 2015-06-18 at 17:50 -0700, Jason Ekstrand wrote: Soon we will start using the builder to explicitly set all the execution sizes. We could make a 32-wide builder, but the builder asserts that we never grow it which is usually a reasonable assumption. Sinc this one instruction is a bit of an odd-ball, we just set the exec_size explicitly. So if I understand it right, the only point of this change is making explicit that this instruction has a different execution size to ensure that we notice it when we rewrite the code to set explicit execution sizes with the new builder, right? No, it's more that there is no good way to set it to SIMD32 with the builder because changing dispatch width in the builder can only go down and not up. In retrospect, I should have explicitly created the fs_inst rather than using the builder to emit it 16-wide and changing it later. The reason this patch can stand on it's own is because, at this point in the series, the builder still uses the exec size guessing based on register widths. --- src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp index 4770838..b00825e 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp @@ -1357,10 +1357,11 @@ fs_visitor::emit_interpolation_setup_gen6() */ fs_reg int_pixel_xy(GRF, alloc.allocate(dispatch_width / 8), BRW_REGISTER_TYPE_UW, dispatch_width * 2); - abld.exec_all() - .ADD(int_pixel_xy, - fs_reg(stride(suboffset(g1_uw, 4), 1, 4, 0)), - fs_reg(brw_imm_v(0x11001010))); + fs_inst *add = abld.exec_all() + .ADD(int_pixel_xy, + fs_reg(stride(suboffset(g1_uw, 4), 1, 4, 0)), + fs_reg(brw_imm_v(0x11001010))); + add-exec_size = dispatch_width * 2; this-pixel_x = vgrf(glsl_type::float_type); this-pixel_y = vgrf(glsl_type::float_type); ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glsl: Fix counting of varyings.
When input and output varyings started to be counted separately (commit
42305fb5) the is_varying_var function wasn't updated to return true for
output varyings or input varyings for stages other than the fragment
shader), effectively making the varying limit to never be checked.
With this change, color, texture coord, and generic varyings are not
counted, but others are ignored. It is assumed the hardware will handle
special varyings internally (ie, optimistic rather than pessimistic), to
avoid causing regressions where things were working somehow.
This fixes `glsl-max-varyings --exceed-limits` with softpipe/llvmpipe,
which was asserting because we were getting varyings beyond
VARYING_SLOT_MAX in st_glsl_to_tgsi.cpp.
It also prevents the assertion failure with
https://bugs.freedesktop.org/show_bug.cgi?id=90539 but the tests still
fails due to the link error.
This change also adds a few assertions to catch this sort of errors
earlier, and potentially prevent buffer overflows in the future (no
buffer overflow was detected here though).
However, this change causes several tests to regress:
spec/glsl-1.10/execution/varying-packing/simple ivec3 array
spec/glsl-1.10/execution/varying-packing/simple ivec3 separate
spec/glsl-1.10/execution/varying-packing/simple uvec3 array
spec/glsl-1.10/execution/varying-packing/simple uvec3 separate
spec/arb_gpu_shader_fp64/varying-packing/simple dmat3 array
spec/glsl-1.50/execution/geometry/max-input-components
spec/glsl-1.50/execution/variable-indexing/gs-input-array-vec4-index-rd
spec/glsl-1.50/execution/variable-indexing/vs-output-array-vec4-index-wr-before-gs
But this all seem to be issues either in the way we count varyings
(e.g., geometry inputs get counted multiple times) or in the tests
themselves, or limitations in the varying packer, and deserve attention
on their own right.
---
src/glsl/link_varyings.cpp | 70 --
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +
2 files changed, 58 insertions(+), 14 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 278a778..7649720 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -190,6 +190,8 @@ cross_validate_outputs_to_inputs(struct gl_shader_program
*prog,
*/
const unsigned idx = var-data.location - VARYING_SLOT_VAR0;
+ assert(idx MAX_VARYING);
+
if (explicit_locations[idx] != NULL) {
linker_error(prog,
%s shader has multiple outputs explicitly
@@ -1031,25 +1033,63 @@ varying_matches::match_comparator(const void
*x_generic, const void *y_generic)
/**
* Is the given variable a varying variable to be counted against the
* limit in ctx-Const.MaxVarying?
- * This includes variables such as texcoords, colors and generic
- * varyings, but excludes variables such as gl_FrontFacing and gl_FragCoord.
+ *
+ * OpenGL specification states:
+ *
+ * Each output variable component used as either a vertex shader output or
+ * fragment shader input counts against this limit, except for the components
+ * of gl_Position. A program containing only a vertex and fragment shader
+ * that accesses more than this limit's worth of components of outputs may
+ * fail to link, unless device-dependent optimizations are able to make the
+ * program fit within available hardware resources.
+ *
*/
static bool
var_counts_against_varying_limit(gl_shader_stage stage, const ir_variable *var)
{
- /* Only fragment shaders will take a varying variable as an input */
- if (stage == MESA_SHADER_FRAGMENT
- var-data.mode == ir_var_shader_in) {
- switch (var-data.location) {
- case VARYING_SLOT_POS:
- case VARYING_SLOT_FACE:
- case VARYING_SLOT_PNTC:
- return false;
- default:
- return true;
- }
+ assert(var-data.mode == ir_var_shader_in || var-data.mode ==
ir_var_shader_out);
+
+ /* FIXME: It looks like we're currently counting each input multiple times
+* on geometry shaders. See piglit
+* spec/glsl-1.50/execution/geometry/max-input-components */
+ if (stage == MESA_SHADER_GEOMETRY) {
+ return false;
+ }
+
+ switch (var-data.location) {
+ case VARYING_SLOT_POS:
+ return false;
+ case VARYING_SLOT_COL0:
+ case VARYING_SLOT_COL1:
+ case VARYING_SLOT_FOGC:
+ case VARYING_SLOT_TEX0:
+ case VARYING_SLOT_TEX1:
+ case VARYING_SLOT_TEX2:
+ case VARYING_SLOT_TEX3:
+ case VARYING_SLOT_TEX4:
+ case VARYING_SLOT_TEX5:
+ case VARYING_SLOT_TEX6:
+ case VARYING_SLOT_TEX7:
+ return true;
+ case VARYING_SLOT_PSIZ:
+ case VARYING_SLOT_BFC0:
+ case VARYING_SLOT_BFC1:
+ case VARYING_SLOT_EDGE:
+ case VARYING_SLOT_CLIP_VERTEX:
+ case VARYING_SLOT_CLIP_DIST0:
+ case VARYING_SLOT_CLIP_DIST1:
+ case VARYING_SLOT_PRIMITIVE_ID:
+ case VARYING_SLOT_LAYER:
+ case VARYING_SLOT_VIEWPORT:
+ case VARYING_SLOT_FACE:
+ case
[Mesa-dev] [PATCH 1/2] glsl: Specify the shader stage in linker errors due to too many in/outputs.
---
src/glsl/link_varyings.cpp | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 7b2d4bd..278a778 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -1540,13 +1540,15 @@ check_against_output_limit(struct gl_context *ctx,
const unsigned output_components = output_vectors * 4;
if (output_components max_output_components) {
if (ctx-API == API_OPENGLES2 || prog-IsES)
- linker_error(prog, shader uses too many output vectors
+ linker_error(prog, %s shader uses too many output vectors
(%u %u)\n,
+ _mesa_shader_stage_to_string(producer-Stage),
output_vectors,
max_output_components / 4);
else
- linker_error(prog, shader uses too many output components
+ linker_error(prog, %s shader uses too many output components
(%u %u)\n,
+ _mesa_shader_stage_to_string(producer-Stage),
output_components,
max_output_components);
@@ -1579,13 +1581,15 @@ check_against_input_limit(struct gl_context *ctx,
const unsigned input_components = input_vectors * 4;
if (input_components max_input_components) {
if (ctx-API == API_OPENGLES2 || prog-IsES)
- linker_error(prog, shader uses too many input vectors
+ linker_error(prog, %s shader uses too many input vectors
(%u %u)\n,
+ _mesa_shader_stage_to_string(consumer-Stage),
input_vectors,
max_input_components / 4);
else
- linker_error(prog, shader uses too many input components
+ linker_error(prog, %s shader uses too many input components
(%u %u)\n,
+ _mesa_shader_stage_to_string(consumer-Stage),
input_components,
max_input_components);
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 22/46] glsl: add the patch in/out qualifier
On Wednesday, June 17, 2015 01:01:18 AM Marek Olšák wrote:
From: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/ast.h| 1 +
src/glsl/ast_to_hir.cpp | 45
src/glsl/ast_type.cpp | 3 +-
src/glsl/builtin_variables.cpp| 8 ++--
src/glsl/glsl_lexer.ll| 2 +-
src/glsl/glsl_parser.yy | 15 ---
src/glsl/glsl_parser_extras.cpp | 2 +
src/glsl/glsl_types.cpp | 5 +++
src/glsl/glsl_types.h | 6 +++
src/glsl/ir.cpp | 2 +
src/glsl/ir.h | 1 +
src/glsl/ir_print_visitor.cpp | 5 ++-
src/glsl/ir_reader.cpp| 2 +
src/glsl/ir_set_program_inouts.cpp| 69
+++
src/glsl/link_varyings.cpp| 15 ++-
src/glsl/lower_named_interface_blocks.cpp | 1 +
src/glsl/lower_packed_varyings.cpp| 1 +
17 files changed, 161 insertions(+), 22 deletions(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 26ad3bf..87e1354 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -434,6 +434,7 @@ struct ast_type_qualifier {
unsigned out:1;
unsigned centroid:1;
unsigned sample:1;
+ unsigned patch:1;
unsigned uniform:1;
unsigned smooth:1;
unsigned flat:1;
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 53daf13..837bac7 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2461,6 +2461,9 @@ apply_type_qualifier_to_variable(const struct
ast_type_qualifier *qual,
var-data.stream = qual-stream;
}
+ if (qual-flags.q.patch)
+ var-data.patch = 1;
+
if (qual-flags.q.attribute state-stage != MESA_SHADER_VERTEX) {
var-type = glsl_type::error_type;
_mesa_glsl_error(loc, state,
@@ -3119,6 +3122,17 @@ handle_tess_ctrl_shader_output_decl(struct
_mesa_glsl_parse_state *state,
num_vertices = state-out_qualifier-vertices;
}
+ if (!var-type-is_array() !var-data.patch) {
+ _mesa_glsl_error(loc, state,
+ tessellation control shader outputs must be arrays);
+
+ /* To avoid cascading failures, short circuit the checks below. */
+ return;
+ }
Seems like this block should have gone in patch 20 and just the
!var-data.patch part added here. But it's already a huge patch, so I
suppose it doesn't matter so much...
+
+ if (var-data.patch)
+ return;
+
if (var-type-is_unsized_array()) {
if (num_vertices != 0)
var-type = glsl_type::get_array_instance(var-type-fields.array,
@@ -3940,6 +3954,33 @@ ast_declarator_list::hir(exec_list *instructions,
}
+ /* From section 4.3.4 of the GLSL 4.00 spec:
+ *Input variables may not be declared using the patch in qualifier
+ *in tessellation control or geometry shaders.
+ *
+ * From section 4.3.6 of the GLSL 4.00 spec:
+ *It is an error to use patch out in a vertex, tessellation
+ *evaluation, or geometry shader.
+ *
+ * This doesn't explicitly forbid using them in a fragment shader, but
+ * that's probably just an oversight.
+ */
+ if (state-stage != MESA_SHADER_TESS_EVAL
+ this-type-qualifier.flags.q.patch
+ this-type-qualifier.flags.q.in) {
+
+ _mesa_glsl_error(loc, state, 'patch in' can only be used in a
+ tessellation evaluation shader);
+ }
+
+ if (state-stage != MESA_SHADER_TESS_CTRL
+ this-type-qualifier.flags.q.patch
+ this-type-qualifier.flags.q.out) {
+
+ _mesa_glsl_error(loc, state, 'patch out' can only be used in a
+ tessellation control shader);
+ }
+
/* Precision qualifiers exists only in GLSL versions 1.00 and = 1.30.
*/
if (this-type-qualifier.precision != ast_precision_none) {
@@ -5463,6 +5504,7 @@ ast_process_structure_or_interface_block(exec_list
*instructions,
interpret_interpolation_qualifier(qual, var_mode, state, loc);
fields[i].centroid = qual-flags.q.centroid ? 1 : 0;
fields[i].sample = qual-flags.q.sample ? 1 : 0;
+ fields[i].patch = qual-flags.q.patch ? 1 : 0;
/* Only save explicitly defined streams in block's field */
fields[i].stream = qual-flags.q.explicit_stream ? qual-stream :
-1;
@@ -5794,6 +5836,8 @@ ast_interface_block::hir(exec_list *instructions,
earlier_per_vertex-fields.structure[j].centroid;
fields[i].sample =
earlier_per_vertex-fields.structure[j].sample;
+fields[i].patch =
+ earlier_per_vertex-fields.structure[j].patch;
}
}
@@
Re: [Mesa-dev] [PATCH 03/46] mesa: add tessellation shader structs
On Wednesday, June 17, 2015 01:00:59 AM Marek Olšák wrote:
From: Fabian Bieler fabianbie...@fastmail.fm
Marek: remove unused members, cleanup
---
src/mesa/main/mtypes.h | 105
+
1 file changed, 105 insertions(+)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 086f553..12789f1 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2163,6 +2163,29 @@ struct gl_vertex_program
};
+/** Tessellation control program object */
+struct gl_tess_ctrl_program
+{
+ struct gl_program Base; /** base class */
+
+ /* output layout */
+ GLint VerticesOut;
+};
+
+
+/** Tessellation evaluation program object */
+struct gl_tess_eval_program
+{
+ struct gl_program Base; /** base class */
+
+ /* input layout */
+ GLenum PrimitiveMode; /* GL_TRIANGLES, GL_QUADS or GL_ISOLINES */
+ GLenum Spacing; /* GL_EQUAL, GL_FRACTIONAL_EVEN, GL_FRACTIONAL_ODD
*/
+ GLenum VertexOrder; /* GL_CW or GL_CCW */
+ bool PointMode;
+};
+
+
/** Geometry program object */
struct gl_geometry_program
{
@@ -2265,6 +2288,27 @@ struct gl_vertex_program_state
GLboolean _Overriden;
};
+/**
+ * Context state for tessellation control programs.
+ */
+struct gl_tess_ctrl_program_state
+{
+ /** Currently bound and valid shader. */
+ struct gl_tess_ctrl_program *_Current;
+
+ GLint patch_vertices;
+ GLfloat patch_default_outer_level[4];
+ GLfloat patch_default_inner_level[2];
+};
+
+/**
+ * Context state for tessellation evaluation programs.
+ */
+struct gl_tess_eval_program_state
+{
+ /** Currently bound and valid shader. */
+ struct gl_tess_eval_program *_Current;
+};
/**
* Context state for geometry programs.
@@ -2445,6 +2489,41 @@ struct gl_shader
bool pixel_center_integer;
/**
+* Tessellation Control shader state from layout qualifiers.
+*/
+ struct {
+ /**
+ * 0 - vertices not declared in shader, or
+ * 1 .. GL_MAX_PATCH_VERTICES
+ */
+ GLint VerticesOut;
+ } TessCtrl;
+
+ /**
+* Tessellation Evaluation shader state from layout qualifiers.
+*/
+ struct {
+ /**
+ * GL_TRIANGLES, GL_QUADS, GL_ISOLINES or PRIM_UNKNOWN if it's not set
+ * in this shader.
+ */
+ GLenum PrimitiveMode;
+ /**
+ * GL_EQUAL, GL_FRACTIONAL_ODD, GL_FRACTIONAL_EVEN, or 0 if it's not
set
+ * in this shader.
+ */
+ GLenum Spacing;
+ /**
+ * GL_CW, GL_CCW, or 0 if it's not set in this shader.
+ */
+ GLenum VertexOrder;
+ /**
+ * 1, 0, or -1 if it's not set in this shader.
+ */
+ int PointMode;
+ } TessEval;
+
+ /**
* Geometry shader state from GLSL 1.50 layout qualifiers.
*/
struct {
@@ -2668,6 +2747,30 @@ struct gl_shader_program
enum gl_frag_depth_layout FragDepthLayout;
/**
+* Tessellation Control shader state from layout qualifiers.
+*/
+ struct {
+ /**
+ * 0 - vertices not declared in shader, or
+ * 1 .. GL_MAX_PATCH_VERTICES
+ */
+ GLint VerticesOut;
+ } TessCtrl;
+
+ /**
+* Tessellation Evaluation shader state from layout qualifiers.
+*/
+ struct {
+ /** GL_TRIANGLES, GL_QUADS or GL_ISOLINES */
+ GLenum PrimitiveMode;
+ /** GL_EQUAL, GL_FRACTIONAL_ODD or GL_FRACTIONAL_EVEN */
+ GLenum Spacing;
+ /** GL_CW or GL_CCW */
+ GLenum VertexOrder;
+ bool PointMode;
+ } TessEval;
Seems a little odd that we've basically represented this same struct 2-3
times now. Perhaps give it an actual type and reuse it? Though I
suppose it doesn't matter much...
+
+ /**
* Geometry shader state - copied into gl_geometry_program by
* _mesa_copy_linked_program_data().
*/
@@ -4201,6 +4304,8 @@ struct gl_context
struct gl_fragment_program_state FragmentProgram;
struct gl_geometry_program_state GeometryProgram;
struct gl_compute_program_state ComputeProgram;
+ struct gl_tess_ctrl_program_state TessCtrlProgram;
+ struct gl_tess_eval_program_state TessEvalProgram;
struct gl_ati_fragment_shader_state ATIFragmentShader;
struct gl_pipeline_shader_state Pipeline; /** GLSL pipeline shader
object state */
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nvc0: create screen fence objects with coherent attribute
On 19/06/2015 11:56, Alexandre Courbot wrote: This is required on non-coherent architectures to ensure the value of the fence is correct at all times. Failure to do this results in the display freezing for a few seconds every now and then on Tegra. The NOUVEAU_BO_COHERENT is a no-op for coherent architectures, so behavior on x86 should not be affected by this patch. Signed-off-by: Alexandre Courbot acour...@nvidia.com --- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c index 5936d05a5b93..307cf5f9cd75 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c @@ -610,6 +610,7 @@ nvc0_screen_create(struct nouveau_device *dev) struct nouveau_pushbuf *push; uint64_t value; uint32_t obj_class; + uint32_t flags; int ret; unsigned i; @@ -660,8 +661,11 @@ nvc0_screen_create(struct nouveau_device *dev) screen-base.base.get_video_param = nouveau_vp3_screen_get_video_param; screen-base.base.is_video_format_supported = nouveau_vp3_screen_video_supported; - ret = nouveau_bo_new(dev, NOUVEAU_BO_GART | NOUVEAU_BO_MAP, 0, 4096, NULL, -screen-fence.bo); + flags = NOUVEAU_BO_GART | NOUVEAU_BO_MAP; + if (dev-drm_version = 0x01000202) + flags |= NOUVEAU_BO_COHERENT; Don't forget that you also need to require an up to date version of libdrm if you don't want to fail at compilation time :) Not sure what the policy would be here. You may be able to ask for a release. With the bump in the required version of libdrm, this patch is: Reviewed-by: Martin Peres martin.pe...@free.fr + + ret = nouveau_bo_new(dev, flags, 0, 4096, NULL, screen-fence.bo); if (ret) goto fail; nouveau_bo_map(screen-fence.bo, 0, NULL); ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glapi: gl_table.py: remove unused variable 'es'
None of the three build systems ever set it, as such we can clear things
up a bit.
Cc: Dylan Baker dylanx.c.ba...@intel.com
Cc: Jose Fonseca jfons...@vmware.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/mapi/glapi/gen/gl_table.py | 57 ++
1 file changed, 8 insertions(+), 49 deletions(-)
diff --git a/src/mapi/glapi/gen/gl_table.py b/src/mapi/glapi/gen/gl_table.py
index 3f02902..e25971a 100644
--- a/src/mapi/glapi/gen/gl_table.py
+++ b/src/mapi/glapi/gen/gl_table.py
@@ -33,10 +33,9 @@ import license
class PrintGlTable(gl_XML.gl_print_base):
-def __init__(self, es=False):
+def __init__(self):
gl_XML.gl_print_base.__init__(self)
-self.es = es
self.header_tag = '_GLAPI_TABLE_H_'
self.name = gl_table.py (from Mesa)
self.license = license.bsd_license_template % ( \
@@ -76,10 +75,9 @@ class PrintGlTable(gl_XML.gl_print_base):
class PrintRemapTable(gl_XML.gl_print_base):
-def __init__(self, es=False):
+def __init__(self):
gl_XML.gl_print_base.__init__(self)
-self.es = es
self.header_tag = '_DISPATCH_H_'
self.name = gl_table.py (from Mesa)
self.license = license.bsd_license_template % (
@@ -123,7 +121,6 @@ class PrintRemapTable(gl_XML.gl_print_base):
functions = []
abi_functions = []
-alias_functions = []
count = 0
for f in api.functionIterateByOffset():
if not f.is_abi():
@@ -132,11 +129,6 @@ class PrintRemapTable(gl_XML.gl_print_base):
else:
abi_functions.append([f, -1])
-if self.es:
-# remember functions with aliases
-if len(f.entry_points) 1:
-alias_functions.append(f)
-
print '/* total number of offsets below */'
print '#define _gloffset_COUNT %d' % (len(abi_functions + functions))
print ''
@@ -144,18 +136,11 @@ class PrintRemapTable(gl_XML.gl_print_base):
for f, index in abi_functions:
print '#define _gloffset_%s %d' % (f.name, f.offset)
-if self.es:
-remap_table = esLocalRemapTable
-
-print '#define %s_size %u' % (remap_table, count)
-print 'static int %s[ %s_size ];' % (remap_table, remap_table)
-print ''
-else:
-remap_table = driDispatchRemapTable
+remap_table = driDispatchRemapTable
-print '#define %s_size %u' % (remap_table, count)
-print 'extern int %s[ %s_size ];' % (remap_table, remap_table)
-print ''
+print '#define %s_size %u' % (remap_table, count)
+print 'extern int %s[ %s_size ];' % (remap_table, remap_table)
+print ''
for f, index in functions:
print '#define %s_remap_index %u' % (f.name, index)
@@ -182,23 +167,6 @@ class PrintRemapTable(gl_XML.gl_print_base):
print '}'
print
-if alias_functions:
-print ''
-print '/* define aliases for compatibility */'
-for f in alias_functions:
-for name in f.entry_points:
-if name != f.name:
-print '#define CALL_%s(disp, parameters) CALL_%s(disp,
parameters)' % (name, f.name)
-print '#define GET_%s(disp) GET_%s(disp)' % (name,
f.name)
-print '#define SET_%s(disp, fn) SET_%s(disp, fn)' %
(name, f.name)
-print ''
-
-for f in alias_functions:
-for name in f.entry_points:
-if name != f.name:
-print '#define %s_remap_index %s_remap_index' % (name,
f.name)
-print ''
-
return
@@ -215,12 +183,6 @@ def _parser():
default='table',
metavar=mode,
help=Generate either a table or a remap_table)
-parser.add_argument('-c', '--es-version',
-choices=[None, 'es1', 'es2'],
-default=None,
-metavar=ver,
-dest='es',
-help=filter functions for es)
return parser.parse_args()
@@ -231,12 +193,9 @@ def main():
api = gl_XML.parse_GL_API(args.file_name)
if args.mode == table:
-printer = PrintGlTable(args.es)
+printer = PrintGlTable()
elif args.mode == remap_table:
-printer = PrintRemapTable(args.es)
-
-if args.es is not None:
-api.filter_functions_by_api(args.es)
+printer = PrintRemapTable()
printer.Print(api)
--
2.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glapi: remap_helper.py: remove unused argument 'es'
Identical to the previous commit - unused by neither the Autotools,
Android or SCons build.
XXX: There are no more users of gl_api.filter_functions_by_api(). Should
we just nuke it ?
Cc: Dylan Baker dylanx.c.ba...@intel.com
Cc: Jose Fonseca jfons...@vmware.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/mapi/glapi/gen/remap_helper.py | 8
1 file changed, 8 deletions(-)
diff --git a/src/mapi/glapi/gen/remap_helper.py
b/src/mapi/glapi/gen/remap_helper.py
index 94ae193..edc6c3e 100644
--- a/src/mapi/glapi/gen/remap_helper.py
+++ b/src/mapi/glapi/gen/remap_helper.py
@@ -174,12 +174,6 @@ def _parser():
metavar=input_file_name,
dest='file_name',
help=An xml description file.)
-parser.add_argument('-c', '--es-version',
-choices=[None, 'es1', 'es2'],
-default=None,
-metavar='ver',
-dest='es',
-help='A GLES version to support')
return parser.parse_args()
@@ -188,8 +182,6 @@ def main():
args = _parser()
api = gl_XML.parse_GL_API(args.file_name)
-if args.es is not None:
-api.filter_functions_by_api(args.es)
printer = PrintGlRemap()
printer.Print(api)
--
2.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/2] nouveau: support for custom VRAM domains
On 19/06/2015 13:02, Alexandre Courbot wrote: New revision of this patchset that prevents VRAM objects from being allocated on VRAM-less systems like Tegra. This is required for Mesa to work on such systems. Changes since v2: - Use vram_size to detect systems without VRAM and set the correct domain instead of expecting each chip to set its domain explicitly. This question may have been asked a ton of times, but what is the difference with the nvac (Ion)? Would the nvac have some reserved memory for its usage by the bios which would then be used as VRAM? In any case, the patchseries sounds simple-enough to be maintainable. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Nouveau] [PATCH v3 0/2] nouveau: support for custom VRAM domains
On 19 June 2015 at 21:51, Martin Peres martin.pe...@free.fr wrote: On 19/06/2015 13:02, Alexandre Courbot wrote: New revision of this patchset that prevents VRAM objects from being allocated on VRAM-less systems like Tegra. This is required for Mesa to work on such systems. Changes since v2: - Use vram_size to detect systems without VRAM and set the correct domain instead of expecting each chip to set its domain explicitly. This question may have been asked a ton of times, but what is the difference with the nvac (Ion)? Would the nvac have some reserved memory for its usage by the bios which would then be used as VRAM? PFB on the dGPU IGPs has facilities to fake VRAM from an area of stolen system memory reserved by the SBIOS. GK20A/GM20B do not do this, and require direct (or, via a mmu, whatever) access to system memory. Ben. In any case, the patchseries sounds simple-enough to be maintainable. ___ Nouveau mailing list nouv...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/17] i965/fs: Report the right value in fs_inst::regs_read() for PIXEL_X/Y
Reviewed-by: Iago Toral Quiroga ito...@igalia.com On Thu, 2015-06-18 at 17:50 -0700, Jason Ekstrand wrote: --- src/mesa/drivers/dri/i965/brw_fs.cpp | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp index ce56657..4f98d63 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp @@ -769,6 +769,12 @@ fs_inst::regs_read(int arg) const return 1; break; + case FS_OPCODE_PIXEL_X: + case FS_OPCODE_PIXEL_Y: + if (arg == 0) + return 2; + break; + default: if (is_tex() arg == 0 src[0].file == GRF) return mlen; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] egl/dri2: load libglapi.0.dylib on osx
On 19 June 2015 at 00:14, Julien Isorce julien.iso...@gmail.com wrote: On 18 June 2015 at 19:29, Emil Velikov emil.l.veli...@gmail.com wrote: On 18 June 2015 at 06:53, Julien Isorce julien.iso...@gmail.com wrote: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90903 Signed-off-by: Julien Isorce j.iso...@samsung.com --- src/egl/drivers/dri2/egl_dri2.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c index a1cbd43..90b9648 100644 --- a/src/egl/drivers/dri2/egl_dri2.c +++ b/src/egl/drivers/dri2/egl_dri2.c @@ -2354,6 +2354,8 @@ dri2_load(_EGLDriver *drv) #ifdef HAVE_SHARED_GLAPI #ifdef HAVE_ANDROID_PLATFORM const char *libname = libglapi.so; +#elif defined(__APPLE__) + const char *libname = libglapi.0.dylib; #else Is this enough to get dri modules (suspecting only swrast atm) working with EGL ? Well at least es2_info and es2gears_x11 are working (with both GALLIUM_DRIVER=softpipe and llvmpipe). I have attached a screenshot: https://bugs.freedesktop.org/attachment.cgi?id=116583 Great news. Thanks for the confirmation. Note that currently libEGL already explicitly links against libglapi, so imho we can just drop the whole thing. Haven't really looked but do we use glFlush() as a workaround or it's something required by the EGL standard ? No idea but without the patch you get: EGL_LOG_LEVEL=debug es2_info libEGL debug: Native platform type: x11 (autodetected) libEGL debug: added egl_dri2 to module array libEGL warning: DRI2: failed to find _glapi_get_proc_address libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize Error: eglInitialize() failed I never meant that it will work as is, but mentioned a few things about simplifying/cleaning-up the whole thing. I have some ancient fixes in the area that I'll respin and send out in a few hours. Cheers Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New stable-branch 10.5 candidate pushed
On 18/06/15 23:35, Jason Ekstrand wrote: We should also pull in Chris' 3-patch drawbuffers series if it applies: http://lists.freedesktop.org/archives/mesa-dev/2015-June/085851.html Seems like these never made it to mesa-stable nor have 10.5 in the commit msg. So... I've missed them :-( It's a bit late for 10.5.8, but I will scoop them up immediately after the release. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nvc0: create screen fence objects with coherent attribute
This is required on non-coherent architectures to ensure the value of the fence is correct at all times. Failure to do this results in the display freezing for a few seconds every now and then on Tegra. The NOUVEAU_BO_COHERENT is a no-op for coherent architectures, so behavior on x86 should not be affected by this patch. Signed-off-by: Alexandre Courbot acour...@nvidia.com --- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c index 5936d05a5b93..307cf5f9cd75 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c @@ -610,6 +610,7 @@ nvc0_screen_create(struct nouveau_device *dev) struct nouveau_pushbuf *push; uint64_t value; uint32_t obj_class; + uint32_t flags; int ret; unsigned i; @@ -660,8 +661,11 @@ nvc0_screen_create(struct nouveau_device *dev) screen-base.base.get_video_param = nouveau_vp3_screen_get_video_param; screen-base.base.is_video_format_supported = nouveau_vp3_screen_video_supported; - ret = nouveau_bo_new(dev, NOUVEAU_BO_GART | NOUVEAU_BO_MAP, 0, 4096, NULL, -screen-fence.bo); + flags = NOUVEAU_BO_GART | NOUVEAU_BO_MAP; + if (dev-drm_version = 0x01000202) + flags |= NOUVEAU_BO_COHERENT; + + ret = nouveau_bo_new(dev, flags, 0, 4096, NULL, screen-fence.bo); if (ret) goto fail; nouveau_bo_map(screen-fence.bo, 0, NULL); -- 2.4.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/46] drirc: drop support for Heaven 3.0, fixes tessellation in 4.0
I made some comments, but assuming those are taken care of, patches 1-22 are: Reviewed-by: Kenneth Graunke kenn...@whitecape.org I plan on reviewing the rest, but probably not tonight. Thanks for picking this up! signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/17] i965/fs: Explicitly set the exec_size on the add(32) in interpolation setup
On Thu, 2015-06-18 at 17:50 -0700, Jason Ekstrand wrote: Soon we will start using the builder to explicitly set all the execution sizes. We could make a 32-wide builder, but the builder asserts that we never grow it which is usually a reasonable assumption. Sinc this one instruction is a bit of an odd-ball, we just set the exec_size explicitly. So if I understand it right, the only point of this change is making explicit that this instruction has a different execution size to ensure that we notice it when we rewrite the code to set explicit execution sizes with the new builder, right? --- src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp index 4770838..b00825e 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp @@ -1357,10 +1357,11 @@ fs_visitor::emit_interpolation_setup_gen6() */ fs_reg int_pixel_xy(GRF, alloc.allocate(dispatch_width / 8), BRW_REGISTER_TYPE_UW, dispatch_width * 2); - abld.exec_all() - .ADD(int_pixel_xy, - fs_reg(stride(suboffset(g1_uw, 4), 1, 4, 0)), - fs_reg(brw_imm_v(0x11001010))); + fs_inst *add = abld.exec_all() + .ADD(int_pixel_xy, + fs_reg(stride(suboffset(g1_uw, 4), 1, 4, 0)), + fs_reg(brw_imm_v(0x11001010))); + add-exec_size = dispatch_width * 2; this-pixel_x = vgrf(glsl_type::float_type); this-pixel_y = vgrf(glsl_type::float_type); ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] glapi: remap_helper.py: remove unused argument 'es'
I only did minor tweaks to these files, but the series LGTM.
Reviewed-by: Jose Fonseca jfons...@vmware.com
On 19/06/15 13:21, Emil Velikov wrote:
Identical to the previous commit - unused by neither the Autotools,
Android or SCons build.
XXX: There are no more users of gl_api.filter_functions_by_api(). Should
we just nuke it ?
Cc: Dylan Baker dylanx.c.ba...@intel.com
Cc: Jose Fonseca jfons...@vmware.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/mapi/glapi/gen/remap_helper.py | 8
1 file changed, 8 deletions(-)
diff --git a/src/mapi/glapi/gen/remap_helper.py
b/src/mapi/glapi/gen/remap_helper.py
index 94ae193..edc6c3e 100644
--- a/src/mapi/glapi/gen/remap_helper.py
+++ b/src/mapi/glapi/gen/remap_helper.py
@@ -174,12 +174,6 @@ def _parser():
metavar=input_file_name,
dest='file_name',
help=An xml description file.)
-parser.add_argument('-c', '--es-version',
-choices=[None, 'es1', 'es2'],
-default=None,
-metavar='ver',
-dest='es',
-help='A GLES version to support')
return parser.parse_args()
@@ -188,8 +182,6 @@ def main():
args = _parser()
api = gl_XML.parse_GL_API(args.file_name)
-if args.es is not None:
-api.filter_functions_by_api(args.es)
printer = PrintGlRemap()
printer.Print(api)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] egl: use unix defines on osx with clang
On 19 June 2015 at 00:23, Julien Isorce julien.iso...@gmail.com wrote: On 18 June 2015 at 19:33, Emil Velikov emil.l.veli...@gmail.com wrote: On 18 June 2015 at 19:29, Emil Velikov emil.l.veli...@gmail.com wrote: Sorry about that. Unintentionally hit send ;-\ On 18 June 2015 at 06:53, Julien Isorce julien.iso...@gmail.com wrote: CC egl_dri2.lo include/EGL/eglplatform.h:135:2: error: Platform not recognized include/EGL/eglplatform.h:140:9: error: unknown type name 'EGLNativeDisplayType' typedef EGLNativeDisplayType NativeDisplayType; You should not longer see this message. Did you try building things, with the updated eglplatform.h ? You are right I forgot to update the new error message with current eglplatform.h. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90249 Signed-off-by: Julien Isorce j.iso...@samsung.com --- include/EGL/eglplatform.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/EGL/eglplatform.h b/include/EGL/eglplatform.h index 7802542..b376e64 100644 --- a/include/EGL/eglplatform.h +++ b/include/EGL/eglplatform.h @@ -77,7 +77,7 @@ typedef HDC EGLNativeDisplayType; typedef HBITMAP EGLNativePixmapType; typedef HWNDEGLNativeWindowType; -#elif defined(__APPLE__) || defined(__WINSCW__) || defined(__SYMBIAN32__) /* Symbian */ +#elif defined(__WINSCW__) || defined(__SYMBIAN32__) /* Symbian */ The above defined(__APPLE__)) comes from Khronos, so if it's wrong perhaps it should be reported to them ? Afaict with current mesa this patch is not needed, and things will just work. I remember that with the latest eglplatform.h I had to manually include #include X11/Xlib.h / #include X11/Xutil.h where they are used (because not hitting their inclusion by eglplatform.h) But then build was complaining about converting int to Display*, and void* to Pixmap/Window. A naive cast could silenced the build error but then it was crashing at runtime. I'll have another try. So it seems that we need something like MESA_EGL_NO_X11_HEADERS for __APPLE__. If anyone has personal experience with upstreaming/discussing such changes to Khronos, some input would be appreciated :-) I think that updating the commit message (and of course getting in touch with the Khronos guys). With Samsung being a Promoter member there should be a few people from Samsung that can help sort/speed things up. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/5] applegl: Provide requirements of _SET_DrawBuffers
On 19 June 2015 at 00:05, Julien Isorce julien.iso...@gmail.com wrote: Sorry for removing the XXX line. Original message is here: https://bugs.freedesktop.org/attachment.cgi?id=115539 At the time src/glx/apple/apple_glapi.c has been developed this patch was not needed I guess so I wonder which change made the regression. That's one way to get to the bottom of it. Alternatively we can take a look at how other glx (indirect, xlib) handle it. As is, the patch gets a big fat NACK, sorry. Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] building mesa using gcc complier on windows
Hi All, I am trying to build the mesa using scons on windows using gcc compiler but I am getting the error The command line is too long. Can anyone help me in this? Regards Sreerama V [DISCLAIMER : This message is sent confidentially. It is for the use of the named recipient(s) only. If you have received by mistake, please do not copy, distribute, disclose or use its contents and kindly notify us. No confidentiality or privilege is waived or lost by any errors in transmission. All e-mail, sent to or from this address, may be accessed by someone other than the recipient, for maintenance and security reasons. Assystem Technologies India Private Ltd, 2A,Xylem,Plot No.4 4A, Dyavasandra Industrial Area, Mahadevapura, Bangalore - 560 048, India. Please consider your environmental responsibility before printing this e-mail.] ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/14] mesa: Fix conditions to test signed, unsigned integer format
On Thu, 2015-06-18 at 09:19 -0700, Anuj Phogat wrote:
On Thu, Jun 18, 2015 at 7:09 AM, Iago Toral ito...@igalia.com wrote:
On Tue, 2015-06-16 at 11:15 -0700, Anuj Phogat wrote:
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/main/readpix.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index caa2648..a9416ef 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -160,10 +160,12 @@ _mesa_readpixels_needs_slow_path(const struct
gl_context *ctx, GLenum format,
srcType = _mesa_get_format_datatype(rb-Format);
if ((srcType == GL_INT
+ _mesa_is_enum_format_integer(format)
(type == GL_UNSIGNED_INT ||
type == GL_UNSIGNED_SHORT ||
type == GL_UNSIGNED_BYTE)) ||
(srcType == GL_UNSIGNED_INT
+ _mesa_is_enum_format_integer(format)
(type == GL_INT ||
type == GL_SHORT ||
type == GL_BYTE))) {
As far as I understand this code we are trying to see if we can use
memcpy to directly copy the contents of the framebuffer to the
destination buffer. In that case, as long as the src/dst types have
different sign we can't just use memcpy, right? In fact it looks like we
might need to expand the checks to include the cases where srcType is
GL_(UNSIGNED_)SHORT and GL_(UNSIGNED_)BYTE as well.
srcType returned by _mesa_get_format_datatype() is one of:
GL_UNSIGNED_NORMALIZED
GL_SIGNED_NORMALIZED
GL_UNSIGNED_INT
GL_INT
GL_FLOAT
So, the suggested checks for srcType are not required.
Oh, right, although I think that does not invalidate my point: can we
memcpy from a GL_UNSIGNED_NORMALIZED to a format with type GL_FLOAT or
GL_SIGNED_NORMALIZED? It does not look like these checks here are
thorough.
In any case, that's beyond the point of your patch. Talking specifically
about your patch: can we memcpy, for example, from a _signed_ integer
format like MESA_FORMAT_R_SINT8 to an _unsigned_ format (integer or
not)? I don't think we can, in which case your patch would not look
correct to me.
Also, as I said in my previous e-mail, I feel like these checks here do
not add anything, at least when this function is called from
readpixels_can_use_memcpy, since even if we return true here, we will
later call _mesa_format_matches_format_and_type and that would check
that the formats match anyway before going through the memcpy path. Even
the other use of this function in Gallium would call
_mesa_format_matches_format_and_type before it calls this... That's why
I think we probably want to remove these checks from this function and
rely on _mesa_format_matches_format_and_type exclusively to check
allowed formats and types.
That said, I think this code is not necessary with the call to
_mesa_format_matches_format_and_type that we do immediately after this,
since that will check that the framebuffer format exactly matches the
destination format anyway, which is a much tighter check than this. In
fact, a quick piglit run without these checks does not seem to break any
tests on i965. Gallium uses these two functions in a slightly different
way in st_cb_readpixels.c though, so I wonder if their use case requires
these checks to exist in this function anyway.
Iago
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/17] i965/fs: Fix fs_inst::regs_read() for uniform pull constant loads
On Thu, 2015-06-18 at 17:50 -0700, Jason Ekstrand wrote: Previously, fs_inst::regs_read() fell back to depending on the register width for the second source. This isn't really correct since it isn't a SIMD8 value at all, but a SIMD4x2 value. This commit changes it to explicitly be always one register. Right, in fact we were incorrectly computing a size of 2 registers in SIMD16 executions because of this. Reviewed-by: Iago Toral Quiroga ito...@igalia.com --- src/mesa/drivers/dri/i965/brw_fs.cpp | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp index 37b6d0d..ce56657 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp @@ -763,6 +763,12 @@ fs_inst::regs_read(int arg) const return exec_size / 4; break; + case FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD_GEN7: + /* The second argument is a single SIMD4x2 register */ + if (arg == 1) + return 1; + break; + default: if (is_tex() arg == 0 src[0].file == GRF) return mlen; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/17] i965/fs: Use a switch statement in fs_inst::regs_read()
Reviewed-by: Iago Toral Quiroga ito...@igalia.com
On Thu, 2015-06-18 at 17:50 -0700, Jason Ekstrand wrote:
This makes things a little simpler, more efficient, and quite a bit more
readable.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 45
++--
1 file changed, 23 insertions(+), 22 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 5563c5a..37b6d0d 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -744,28 +744,29 @@ fs_inst::is_partial_write() const
int
fs_inst::regs_read(int arg) const
{
- if (is_tex() arg == 0 src[0].file == GRF) {
- return mlen;
- } else if (opcode == FS_OPCODE_FB_WRITE arg == 0) {
- return mlen;
- } else if (opcode == SHADER_OPCODE_URB_WRITE_SIMD8 arg == 0) {
- return mlen;
- } else if (opcode == SHADER_OPCODE_UNTYPED_ATOMIC arg == 0) {
- return mlen;
- } else if (opcode == SHADER_OPCODE_UNTYPED_SURFACE_READ arg == 0) {
- return mlen;
- } else if (opcode == SHADER_OPCODE_UNTYPED_SURFACE_WRITE arg == 0) {
- return mlen;
- } else if (opcode == SHADER_OPCODE_TYPED_ATOMIC arg == 0) {
- return mlen;
- } else if (opcode == SHADER_OPCODE_TYPED_SURFACE_READ arg == 0) {
- return mlen;
- } else if (opcode == SHADER_OPCODE_TYPED_SURFACE_WRITE arg == 0) {
- return mlen;
- } else if (opcode == FS_OPCODE_INTERPOLATE_AT_PER_SLOT_OFFSET arg ==
0) {
- return mlen;
- } else if (opcode == FS_OPCODE_LINTERP arg == 0) {
- return exec_size / 4;
+ switch (opcode) {
+ case FS_OPCODE_FB_WRITE:
+ case SHADER_OPCODE_URB_WRITE_SIMD8:
+ case SHADER_OPCODE_UNTYPED_ATOMIC:
+ case SHADER_OPCODE_UNTYPED_SURFACE_READ:
+ case SHADER_OPCODE_UNTYPED_SURFACE_WRITE:
+ case SHADER_OPCODE_TYPED_ATOMIC:
+ case SHADER_OPCODE_TYPED_SURFACE_READ:
+ case SHADER_OPCODE_TYPED_SURFACE_WRITE:
+ case FS_OPCODE_INTERPOLATE_AT_PER_SLOT_OFFSET:
+ if (arg == 0)
+ return mlen;
+ break;
+
+ case FS_OPCODE_LINTERP:
+ if (arg == 0)
+ return exec_size / 4;
+ break;
+
+ default:
+ if (is_tex() arg == 0 src[0].file == GRF)
+ return mlen;
+ break;
}
switch (src[arg].file) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] darwin: Suppress type conversion warnings for GLhandleARB
On 19/06/15 04:46, Ian Romanick wrote:
On 06/17/2015 10:53 PM, Julien Isorce wrote:
From: Jon TURNEY jon.tur...@dronecode.org.uk
On darwin, GLhandleARB is defined as a void *, not the unsigned int it is on
linux.
For the moment, apply a cast to supress the warning
Possibly this is safe, as for the mesa software renderer the shader program
handle is not a real pointer, but a integer handle
Probably this is not the right thing to do, and we should pay closer attention
to how the GLhandlerARB type is used.
In Mesa, glBindAttribLocation (which takes GLuint) and
glBindAttribLocationARB (which takes GLhandleARB) are *the same
function*. The same applies to pretty much all the other GLhandleARB
functions.
Properly fixing this is a nightmare, but I think that short term
workaround is feasible.
This is the generated glapitemp.h:
KEYWORD1 void KEYWORD2 NAME(BindAttribLocationARB)(GLhandleARB
program, GLuint index, const GLcharARB * name)
{
(void) program; (void) index; (void) name;
DISPATCH(BindAttribLocation, (program, index, name), (F,
glBindAttribLocationARB(%d, %d, %p);\n, program, index, (const void *)
name));
}
Provided that GLhandlerARB is defined as `unsigned long` during Mesa
build on MacOSX (to avoid these int-void *) conversions [1], the
compiler should implicitly cast the 64bits GLhandlerARB program to an
32-bits GLuint.
So, when an app calls glBindAttribLocationARB it will be dispatched to
_mesa_BindAttribLocation, and the program truncated. So it should all
just work.
Ditto for when GLhandleARB appears as return value.
The only problem is when GLhandleARB appears as a pointer, as there is
only one such instance:
GLAPI void APIENTRY glGetAttachedObjectsARB (GLhandleARB
containerObj, GLsizei maxCount, GLsizei *count, GLhandleARB *obj);
But we do have a separate entry-point for this
(_mesa_GetAttachedObjectsARB) so again, we're all good.
So, Jon/Julien's patch seems perfectly workable -- all really left to do
is to silence GLhandleARB - GLuint conversions.
Jose
[1] Apitrace also defines GLhandleARB as unsigned long internally to
avoid this
https://github.com/apitrace/apitrace/blob/master/thirdparty/khronos/GL/glext.patch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 19/46] mesa: don't allow drawing with tess ctrl shader and without tess eval shader
On Wednesday, June 17, 2015 01:01:15 AM Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
---
src/mesa/main/api_validate.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index 401120a..9a5ac69 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -69,6 +69,25 @@ check_valid_to_render(struct gl_context *ctx, const char
*function)
return false;
}
+ /* The spec argues that this is allowed because a tess ctrl shader
+ * without a tess eval shader can be used with transform feedback.
+ * However, glBeginTransformFeedback doesn't allow GL_PATCHES and
+ * therefore doesn't allow tessellation.
+ *
+ * Further investigation showed that this is indeed a spec bug and
+ * a tess ctrl shader without a tess eval shader shouldn't have been
+ * allowed, because there is no API in GL 4.0 that can make use this
+ * to produce something useful.
+ *
+ * Also, all vendors except one don't support a tess ctrl shader
without
+ * a tess eval shader anyway.
+ */
+ if (ctx-TessCtrlProgram._Current !ctx-TessEvalProgram._Current) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ %s(tess eval shader is missing), function);
+ return false;
+ }
+
/* Section 7.3 (Program Objects) of the OpenGL 4.5 Core Profile spec
* says:
*
This makes sense to me - the TCS always generates patches, and I don't
see any way to record those with transform feedback. And nothing else
can use patches. So...effectively you need a TES.
It sounds like they were leaving the door open for a vendor extension
that allowed transform feedback on patches, but nobody has written such
an extension yet.
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 0/2] nouveau: support for custom VRAM domains
New revision of this patchset that prevents VRAM objects from being allocated on VRAM-less systems like Tegra. This is required for Mesa to work on such systems. Changes since v2: - Use vram_size to detect systems without VRAM and set the correct domain instead of expecting each chip to set its domain explicitly. Alexandre Courbot (2): nouveau: support for custom VRAM domains nvc0: use NV_VRAM_DOMAIN() macro src/gallium/drivers/nouveau/nouveau_buffer.c | 6 ++ src/gallium/drivers/nouveau/nouveau_screen.c | 10 ++ src/gallium/drivers/nouveau/nouveau_screen.h | 4 src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_compute.c| 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_context.c| 4 ++-- src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_program.c| 8 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 17 +++-- src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_tex.c| 2 +- src/gallium/drivers/nouveau/nvc0/nve4_compute.c| 2 +- 13 files changed, 40 insertions(+), 23 deletions(-) -- 2.4.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 1/2] nouveau: support for custom VRAM domains
Some GPUs (e.g. GK20A, GM20B) do not embed VRAM of their own and use
the system memory as a backend instead. For such systems, allocating
objects in VRAM results in errors since the kernel will not allow
VRAM objects allocations.
This patch adds a vram_domain member to struct nouveau_screen that can
optionally be initialized to an alternative domain to use for VRAM
allocations. If left untouched, NOUVEAU_BO_VRAM will be used for
systems that embed VRAM, and NOUVEAU_BO_GART will be used for VRAM-less
systems.
Code that uses GPU objects is then expected to use the NV_VRAM_DOMAIN()
macro in place of NOUVEAU_BO_VRAM to ensure correct behavior on
VRAM-less chips.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
src/gallium/drivers/nouveau/nouveau_screen.c | 10 ++
src/gallium/drivers/nouveau/nouveau_screen.h | 4
2 files changed, 14 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c
b/src/gallium/drivers/nouveau/nouveau_screen.c
index b4f1413fd8ba..c6e5074db195 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.c
+++ b/src/gallium/drivers/nouveau/nouveau_screen.c
@@ -164,6 +164,16 @@ nouveau_screen_init(struct nouveau_screen *screen, struct
nouveau_device *dev)
size = sizeof(nvc0_data);
}
+ /*
+* Set default VRAM domain if not overridden
+*/
+ if (!screen-vram_domain) {
+ if (dev-vram_size 0)
+ screen-vram_domain = NOUVEAU_BO_VRAM;
+ else
+ screen-vram_domain = NOUVEAU_BO_GART;
+ }
+
ret = nouveau_object_new(dev-object, 0, NOUVEAU_FIFO_CHANNEL_CLASS,
data, size, screen-channel);
if (ret)
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.h
b/src/gallium/drivers/nouveau/nouveau_screen.h
index cf06f7e88aa0..30041b271c94 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.h
+++ b/src/gallium/drivers/nouveau/nouveau_screen.h
@@ -51,6 +51,8 @@ struct nouveau_screen {
boolean hint_buf_keep_sysmem_copy;
+ unsigned vram_domain;
+
struct {
unsigned profiles_checked;
unsigned profiles_present;
@@ -94,6 +96,8 @@ struct nouveau_screen {
#endif
};
+#define NV_VRAM_DOMAIN(screen) ((screen)-vram_domain)
+
#ifdef NOUVEAU_ENABLE_DRIVER_STATISTICS
# define NOUVEAU_DRV_STAT(s, n, v) do { \
(s)-stats.named.n += (v); \
--
2.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 2/2] nvc0: use NV_VRAM_DOMAIN() macro
Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
VRAM domains for chips that do not have dedicated video memory.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
src/gallium/drivers/nouveau/nouveau_buffer.c | 6 ++
src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_compute.c| 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_context.c| 4 ++--
src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_program.c| 8
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 17 +++--
src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_tex.c| 2 +-
src/gallium/drivers/nouveau/nvc0/nve4_compute.c| 2 +-
11 files changed, 26 insertions(+), 23 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c
b/src/gallium/drivers/nouveau/nouveau_buffer.c
index 32fa65c8a51c..bb7676cffbc0 100644
--- a/src/gallium/drivers/nouveau/nouveau_buffer.c
+++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
@@ -658,13 +658,11 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
switch (buffer-base.usage) {
case PIPE_USAGE_DEFAULT:
case PIPE_USAGE_IMMUTABLE:
- buffer-domain = NOUVEAU_BO_VRAM;
- break;
case PIPE_USAGE_DYNAMIC:
/* For most apps, we'd have to do staging transfers to avoid sync
* with this usage, and GART - GART copies would be suboptimal.
*/
- buffer-domain = NOUVEAU_BO_VRAM;
+ buffer-domain = NV_VRAM_DOMAIN(screen);
break;
case PIPE_USAGE_STAGING:
case PIPE_USAGE_STREAM:
@@ -676,7 +674,7 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
}
} else {
if (buffer-base.bind screen-vidmem_bindings)
- buffer-domain = NOUVEAU_BO_VRAM;
+ buffer-domain = NV_VRAM_DOMAIN(screen);
else
if (buffer-base.bind screen-sysmem_bindings)
buffer-domain = NOUVEAU_BO_GART;
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
index 10cebb17eee3..f15d8f3ecb69 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
@@ -377,7 +377,7 @@ nv50_miptree_create(struct pipe_screen *pscreen,
if (!bo_config.nv50.memtype (pt-bind PIPE_BIND_SHARED))
mt-base.domain = NOUVEAU_BO_GART;
else
- mt-base.domain = NOUVEAU_BO_VRAM;
+ mt-base.domain = NV_VRAM_DOMAIN(nouveau_screen(pscreen));
bo_flags = mt-base.domain | NOUVEAU_BO_NOSNOOP;
if (mt-base.base.bind (PIPE_BIND_CURSOR | PIPE_BIND_DISPLAY_TARGET))
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
index ad287a2af6b6..56fc83d3679f 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
@@ -57,7 +57,7 @@ nvc0_screen_compute_setup(struct nvc0_screen *screen,
return ret;
}
- ret = nouveau_bo_new(dev, NOUVEAU_BO_VRAM, 0, 1 12, NULL,
+ ret = nouveau_bo_new(dev, NV_VRAM_DOMAIN(screen-base), 0, 1 12, NULL,
screen-parm);
if (ret)
return ret;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
index 7904984f5037..a35c3f661423 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
@@ -329,7 +329,7 @@ nvc0_create(struct pipe_screen *pscreen, void *priv)
/* add permanently resident buffers to bufctxts */
- flags = NOUVEAU_BO_VRAM | NOUVEAU_BO_RD;
+ flags = NV_VRAM_DOMAIN(screen-base) | NOUVEAU_BO_RD;
BCTX_REFN_bo(nvc0-bufctx_3d, SCREEN, flags, screen-text);
BCTX_REFN_bo(nvc0-bufctx_3d, SCREEN, flags, screen-uniform_bo);
@@ -340,7 +340,7 @@ nvc0_create(struct pipe_screen *pscreen, void *priv)
BCTX_REFN_bo(nvc0-bufctx_cp, CP_SCREEN, flags, screen-parm);
}
- flags = NOUVEAU_BO_VRAM | NOUVEAU_BO_RDWR;
+ flags = NV_VRAM_DOMAIN(screen-base) | NOUVEAU_BO_RDWR;
if (screen-poly_cache)
BCTX_REFN_bo(nvc0-bufctx_3d, SCREEN, flags, screen-poly_cache);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
index fc75fc6a4a17..3875bbf4ca4d 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
@@ -302,7 +302,7 @@ nvc0_miptree_create(struct pipe_screen *pscreen,
if (!bo_config.nvc0.memtype (pt-usage == PIPE_USAGE_STAGING || pt-bind
PIPE_BIND_SHARED))
mt-base.domain = NOUVEAU_BO_GART;
else
- mt-base.domain = NOUVEAU_BO_VRAM;
+ mt-base.domain = NV_VRAM_DOMAIN(nouveau_screen(pscreen));
bo_flags
Re: [Mesa-dev] [PATCH 20/46] glsl: add tessellation shader parsing support.
On Wednesday, June 17, 2015 01:01:16 AM Marek Olšák wrote:
From: Fabian Bieler fabianbie...@fastmail.fm
---
src/glsl/ast.h | 54 +++-
src/glsl/ast_to_hir.cpp | 133
+++-
src/glsl/ast_type.cpp | 112 -
src/glsl/glsl_parser.yy | 118 +--
src/glsl/glsl_parser_extras.cpp | 39 +++-
src/glsl/glsl_parser_extras.h | 31 --
6 files changed, 471 insertions(+), 16 deletions(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index ef74e51..26ad3bf 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -514,6 +514,17 @@ struct ast_type_qualifier {
unsigned stream:1; /** Has stream value assigned */
unsigned explicit_stream:1; /** stream value assigned explicitly
by shader code */
/** \} */
+
+ /** \name Layout qualifiers for GL_ARB_tessellation_shader */
+ /** \{ */
+ /* tess eval input layout */
+ /* gs prim_type reused for primitive mode */
+ unsigned vertex_spacing:1;
+ unsigned ordering:1;
+ unsigned point_mode:1;
+ /* tess control output layout */
+ unsigned vertices:1;
+ /** \} */
}
/** \brief Set of flags, accessed by name. */
q;
@@ -549,7 +560,10 @@ struct ast_type_qualifier {
/** Stream in GLSL 1.50 geometry shaders. */
unsigned stream;
- /** Input or output primitive type in GLSL 1.50 geometry shaders */
+ /**
+* Input or output primitive type in GLSL 1.50 geometry shaders
+* and tessellation shaders.
+*/
GLenum prim_type;
/**
@@ -576,6 +590,18 @@ struct ast_type_qualifier {
*/
int local_size[3];
+ /** Tessellation evaluation shader: vertex spacing (equal, fractional
even/odd) */
+ GLenum vertex_spacing;
+
+ /** Tessellation evaluation shader: vertex ordering (CW or CCW) */
+ GLenum ordering;
+
+ /** Tessellation evaluation shader: point mode */
+ bool point_mode;
+
+ /** Tessellation control shader: number of output vertices */
+ int vertices;
+
/**
* Image format specified with an ARB_shader_image_load_store
* layout qualifier.
@@ -631,6 +657,11 @@ struct ast_type_qualifier {
_mesa_glsl_parse_state *state,
ast_type_qualifier q);
+ bool merge_out_qualifier(YYLTYPE *loc,
+ _mesa_glsl_parse_state *state,
+ ast_type_qualifier q,
+ ast_node* node);
+
bool merge_in_qualifier(YYLTYPE *loc,
_mesa_glsl_parse_state *state,
ast_type_qualifier q,
@@ -1031,6 +1062,27 @@ public:
/**
+ * AST node representing a declaration of the output layout for tessellation
+ * control shaders.
+ */
+class ast_tcs_output_layout : public ast_node
+{
+public:
+ ast_tcs_output_layout(const struct YYLTYPE locp, int vertices)
+ : vertices(vertices)
+ {
+ set_location(locp);
+ }
+
+ virtual ir_rvalue *hir(exec_list *instructions,
+ struct _mesa_glsl_parse_state *state);
+
+private:
+ const int vertices;
+};
+
+
+/**
* AST node representing a declaration of the input layout for geometry
* shaders.
*/
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 259e01e..53daf13 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -79,6 +79,7 @@ _mesa_ast_to_hir(exec_list *instructions, struct
_mesa_glsl_parse_state *state)
state-toplevel_ir = instructions;
state-gs_input_prim_type_specified = false;
+ state-tcs_output_vertices_specified = false;
state-cs_input_local_size_specified = false;
/* Section 4.2 of the GLSL 1.20 specification states:
@@ -2205,6 +2206,8 @@ validate_explicit_location(const struct
ast_type_qualifier *qual,
* inputoutput
* ---
* vertex explicit_loc sso
+* tess controlsso sso
+* tess eval sso sso
* geometrysso sso
* fragmentsso explicit_loc
*/
@@ -2227,6 +2230,8 @@ validate_explicit_location(const struct
ast_type_qualifier *qual,
fail = true;
break;
+ case MESA_SHADER_TESS_CTRL:
+ case MESA_SHADER_TESS_EVAL:
case MESA_SHADER_GEOMETRY:
if (var-data.mode == ir_var_shader_in || var-data.mode ==
ir_var_shader_out) {
if (!state-check_separate_shader_objects_allowed(loc, var))
@@ -2286,6 +2291,8 @@ validate_explicit_location(const struct
ast_type_qualifier *qual,
: (qual-location + VARYING_SLOT_VAR0);
break;
+ case MESA_SHADER_TESS_CTRL:
+
[Mesa-dev] [PATCH] u_vbuf: fix src_offset alignment in u_vbuf_create_vertex_elements()
If the driver says PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY=1,
the driver should never receive a pipe_vertex_element::src_offset value
that's not a multiple of four. But the vbuf code wasn't actually adjusting
the src_offset value when creating the vertex element state object.
We just need to align the src_offset values put in the driver_attribs[]
array.
See the piglit gl-1.5-vertex-buffer-offsets test.
---
src/gallium/auxiliary/util/u_vbuf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_vbuf.c
b/src/gallium/auxiliary/util/u_vbuf.c
index b1b89bf..02ae0b8 100644
--- a/src/gallium/auxiliary/util/u_vbuf.c
+++ b/src/gallium/auxiliary/util/u_vbuf.c
@@ -781,10 +781,11 @@ u_vbuf_create_vertex_elements(struct u_vbuf *mgr,
unsigned count,
ve-compatible_vb_mask_all = ~ve-incompatible_vb_mask_any used_buffers;
ve-incompatible_vb_mask_all = ~ve-compatible_vb_mask_any used_buffers;
- /* Align the formats to the size of DWORD if needed. */
+ /* Align the formats and offsets to the size of DWORD if needed. */
if (!mgr-caps.velem_src_offset_unaligned) {
for (i = 0; i count; i++) {
ve-native_format_size[i] = align(ve-native_format_size[i], 4);
+ driver_attribs[i].src_offset = align(ve-ve[i].src_offset, 4);
}
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] u_vbuf: fix src_offset alignment in u_vbuf_create_vertex_elements()
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Fri, Jun 19, 2015 at 4:39 PM, Brian Paul bri...@vmware.com wrote:
If the driver says PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY=1,
the driver should never receive a pipe_vertex_element::src_offset value
that's not a multiple of four. But the vbuf code wasn't actually adjusting
the src_offset value when creating the vertex element state object.
We just need to align the src_offset values put in the driver_attribs[]
array.
See the piglit gl-1.5-vertex-buffer-offsets test.
---
src/gallium/auxiliary/util/u_vbuf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_vbuf.c
b/src/gallium/auxiliary/util/u_vbuf.c
index b1b89bf..02ae0b8 100644
--- a/src/gallium/auxiliary/util/u_vbuf.c
+++ b/src/gallium/auxiliary/util/u_vbuf.c
@@ -781,10 +781,11 @@ u_vbuf_create_vertex_elements(struct u_vbuf *mgr,
unsigned count,
ve-compatible_vb_mask_all = ~ve-incompatible_vb_mask_any used_buffers;
ve-incompatible_vb_mask_all = ~ve-compatible_vb_mask_any used_buffers;
- /* Align the formats to the size of DWORD if needed. */
+ /* Align the formats and offsets to the size of DWORD if needed. */
if (!mgr-caps.velem_src_offset_unaligned) {
for (i = 0; i count; i++) {
ve-native_format_size[i] = align(ve-native_format_size[i], 4);
+ driver_attribs[i].src_offset = align(ve-ve[i].src_offset, 4);
}
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] nv50/ir: support different unordered_set implementations
If build with C++11 standard, use std::unordered_set.
Otherwise if build on old Android version with stlport,
use std::tr1::unordered_set with a wrapper class.
Otherwise use std::tr1::unordered_set.
Signed-off-by: Chih-Wei Huang cwhu...@linux.org.tw
---
Android.common.mk | 1 +
src/gallium/auxiliary/Android.mk | 2 --
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 15 +++--
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 4 +--
.../nouveau/codegen/nv50_ir_lowering_nvc0.h| 4 +--
src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 5 ++-
.../drivers/nouveau/codegen/unordered_set.h| 37 ++
7 files changed, 55 insertions(+), 13 deletions(-)
create mode 100644 src/gallium/drivers/nouveau/codegen/unordered_set.h
diff --git a/Android.common.mk b/Android.common.mk
index d662d60..de11e52 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -78,6 +78,7 @@ endif
LOCAL_CPPFLAGS += \
$(if $(filter true,$(MESA_LOLLIPOP_BUILD)),-D_USING_LIBCXX) \
+ -std=c++11 \
-Wno-error=non-virtual-dtor \
-Wno-non-virtual-dtor
diff --git a/src/gallium/auxiliary/Android.mk b/src/gallium/auxiliary/Android.mk
index 86430eb..dbaeef6 100644
--- a/src/gallium/auxiliary/Android.mk
+++ b/src/gallium/auxiliary/Android.mk
@@ -40,8 +40,6 @@ ifeq ($(MESA_ENABLE_LLVM),true)
LOCAL_SRC_FILES += \
$(GALLIVM_SOURCES) \
$(GALLIVM_CPP_SOURCES)
-
-LOCAL_CPPFLAGS := -std=c++11
endif
# We need libmesa_glsl to get NIR's generated include directories.
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
index 529dcb9..a060ba3 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
@@ -29,7 +29,16 @@
#include deque
#include list
#include vector
+#if __cplusplus = 201103L
+#include unordered_set
+using std::unordered_set;
+#elif defined(ANDROID) // Android release before lollipop
+#include codegen/unordered_set.h
+using std::isfinite;
+#else
#include tr1/unordered_set
+using std::tr1::unordered_set;
+#endif
#include codegen/nv50_ir_util.h
#include codegen/nv50_ir_graph.h
@@ -583,10 +592,10 @@ public:
static inline Value *get(Iterator);
- std::tr1::unordered_setValueRef * uses;
+ unordered_setValueRef * uses;
std::listValueDef * defs;
- typedef std::tr1::unordered_setValueRef *::iterator UseIterator;
- typedef std::tr1::unordered_setValueRef *::const_iterator UseCIterator;
+ typedef unordered_setValueRef *::iterator UseIterator;
+ typedef unordered_setValueRef *::const_iterator UseCIterator;
typedef std::listValueDef *::iterator DefIterator;
typedef std::listValueDef *::const_iterator DefCIterator;
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 7a5d1ce..eccb09c 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -224,7 +224,7 @@ NVC0LegalizePostRA::findFirstUses(
const Instruction *texi,
const Instruction *insn,
std::listTexUse uses,
- std::tr1::unordered_setconst Instruction * visited)
+ unordered_setconst Instruction * visited)
{
for (int d = 0; insn-defExists(d); ++d) {
Value *v = insn-getDef(d);
@@ -323,7 +323,7 @@ NVC0LegalizePostRA::insertTextureBarriers(Function *fn)
if (!uses)
return false;
for (size_t i = 0; i texes.size(); ++i) {
- std::tr1::unordered_setconst Instruction * visited;
+ unordered_setconst Instruction * visited;
findFirstUses(texes[i], texes[i], uses[i], visited);
}
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
index 260e101..8c3dcbc 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
@@ -20,8 +20,6 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
-#include tr1/unordered_set
-
#include codegen/nv50_ir.h
#include codegen/nv50_ir_build_util.h
@@ -73,7 +71,7 @@ private:
inline bool insnDominatedBy(const Instruction *, const Instruction *) const;
void findFirstUses(const Instruction *tex, const Instruction *def,
std::listTexUse,
- std::tr1::unordered_setconst Instruction *);
+ unordered_setconst Instruction *);
void findOverwritingDefs(const Instruction *tex, Instruction *insn,
const BasicBlock *term,
std::listTexUse);
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 898653c..219d5f1 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++
[Mesa-dev] [PATCH 2/3] android: avoid building errors with stlport
The gallium debugging helpers have defined the assert macro. It causes some errors when build with Android stlport. To workaround it, do not include assert.h if the assert macro has been defined. Signed-off-by: Chih-Wei Huang cwhu...@linux.org.tw --- src/gallium/auxiliary/util/u_math.h | 2 ++ src/util/list.h | 2 ++ 2 files changed, 4 insertions(+) diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h index 3b4040f..f075f1a 100644 --- a/src/gallium/auxiliary/util/u_math.h +++ b/src/gallium/auxiliary/util/u_math.h @@ -42,7 +42,9 @@ #include pipe/p_compiler.h #include c99_math.h +#ifndef assert #include assert.h +#endif #include float.h #include stdarg.h diff --git a/src/util/list.h b/src/util/list.h index 9460347..0ba883a 100644 --- a/src/util/list.h +++ b/src/util/list.h @@ -40,7 +40,9 @@ #include stdbool.h #include stddef.h +#ifndef assert #include assert.h +#endif struct list_head -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/3] Updated Android patches
Most of the Android patches I submitted last time were merged. The omitted patches are updated to address the review comments I got so far. Tested OK with Android-x86 lollipop-x86 and kitkat-x86 branches. Chih-Wei Huang (3): nv50/ir: support different unordered_set implementations android: avoid building errors with stlport egl/main: expose the EGL_RECORDABLE_ANDROID extension Android.common.mk | 1 + src/egl/main/eglconfig.c | 5 ++- src/egl/main/eglconfig.h | 2 ++ src/gallium/auxiliary/Android.mk | 2 -- src/gallium/auxiliary/util/u_math.h| 2 ++ src/gallium/drivers/nouveau/codegen/nv50_ir.h | 15 +++-- .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 4 +-- .../nouveau/codegen/nv50_ir_lowering_nvc0.h| 4 +-- src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 5 ++- .../drivers/nouveau/codegen/unordered_set.h| 37 ++ src/util/list.h| 2 ++ 11 files changed, 65 insertions(+), 14 deletions(-) create mode 100644 src/gallium/drivers/nouveau/codegen/unordered_set.h -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] egl/main: expose the EGL_RECORDABLE_ANDROID extension
Signed-off-by: Chih-Wei Huang cwhu...@linux.org.tw
---
src/egl/main/eglconfig.c | 5 -
src/egl/main/eglconfig.h | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/egl/main/eglconfig.c b/src/egl/main/eglconfig.c
index cf65c69..d9971ed 100644
--- a/src/egl/main/eglconfig.c
+++ b/src/egl/main/eglconfig.c
@@ -245,7 +245,10 @@ static const struct {
/* extensions */
{ EGL_Y_INVERTED_NOK,ATTRIB_TYPE_BOOLEAN,
ATTRIB_CRITERION_EXACT,
-EGL_DONT_CARE }
+EGL_DONT_CARE },
+ { EGL_RECORDABLE_ANDROID,ATTRIB_TYPE_BOOLEAN,
+ATTRIB_CRITERION_EXACT,
+EGL_DONT_CARE },
};
diff --git a/src/egl/main/eglconfig.h b/src/egl/main/eglconfig.h
index 84cb227..7121b3d 100644
--- a/src/egl/main/eglconfig.h
+++ b/src/egl/main/eglconfig.h
@@ -86,6 +86,7 @@ struct _egl_config
/* extensions */
EGLint YInvertedNOK;
+ EGLint RecordableAndroid;
};
@@ -133,6 +134,7 @@ _eglOffsetOfConfig(EGLint attr)
ATTRIB_MAP(EGL_CONFORMANT,Conformant);
/* extensions */
ATTRIB_MAP(EGL_Y_INVERTED_NOK,YInvertedNOK);
+ ATTRIB_MAP(EGL_RECORDABLE_ANDROID,RecordableAndroid);
#undef ATTRIB_MAP
default:
return -1;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 12/15] nv50/ir: optimize the use of std::tr1::unordered_set
2015-05-21 0:10 GMT+08:00 Ilia Mirkin imir...@alum.mit.edu: If this is required for compatibility reasons with old Android systems I suggest you wrap it under a preprocessor conditional like: #if __cplusplus = 201103L using std::unordered_set; #elif building-on-old-android-version-with-broken-stlport using my-funky-wrapper-for-std-unordered-set; #else using std::tr1::unordered_set; #endif Chih-Wei, I think this is the right way to go as well. Could you rework your nv50/ir patches into one that does it this way? Sounds like the #elif funky-wrapper bit isn't actually needed anymore either, as you're going with a C++11-only approach? Sorry for not update in time. I'm too busy recently. Just sent the updated patch as Ilia's suggestion. Thank you for all the comments. -- Chih-Wei Android-x86 project http://www.android-x86.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/gen8: Use HALIGN_16 for single sample mcs buffers
Tested-by: Mark Janes mark.a.ja...@intel.com
Ben Widawsky benjamin.widaw...@intel.com writes:
The original code meant to do this, but was only checking num_samples == 1 to
figure out if a surface was fast clear capable. However, we can allocate
single
sample miptrees with num_samples == 0 (when it's an internally created
buffer).
This fixes a bunch of the piglit tests on gen8. Other gens should have been
fine.
Here is the order of events that allowed this to slip through:
t0: I wrote halign patches and tested them. These alignment assertions are for
gen8 fast clear surfaces, basically.
t1: I pushed bogus perf patch which made fast clears never happen
t2: Reworked halign patches based on Chad's feedback and introduced the bug
this
patch fixes.
t2.5: I tested reworked patches, but assertion wasn't hit because of t1.
t3. Matt fixed issue in t1 which made fast clears happen here:
commit 22af95af8316f2888a3935cdf774ff0997b3dd42
Author: Matt Turner matts...@gmail.com
Date: Thu Jun 18 16:14:50 2015 -0700
i965: Add missing braces around if-statement.
This logic should match that of the v1 of my halign patch series.
Cc: Kenneth Graunke kenn...@whitecape.org
Cc: Matt Turner matts...@gmail.com
Reported-by: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 80c52f2..6aa969a 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -501,7 +501,7 @@ intel_miptree_create_layout(struct brw_context *brw,
* 6 | ? |?
*/
if (intel_miptree_is_fast_clear_capable(brw, mt)) {
- if (brw-gen = 9 || (brw-gen == 8 num_samples == 1))
+ if (brw-gen = 9 || (brw-gen == 8 num_samples = 1))
layout_flags |= MIPTREE_LAYOUT_FORCE_HALIGN16;
} else if (brw-gen = 9 num_samples 1) {
layout_flags |= MIPTREE_LAYOUT_FORCE_HALIGN16;
--
2.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: move ARB_gs5 enums to core, EXT_polygon_offset_clamp to desktop
When adding EXT_polygon_offset_clamp, I first made it core-only, and never moved the enum getter back to the GL/GL_CORE section. Similarly, ARB_gs5 is a core-only extension, so move its getters to the GL_CORE section. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- src/mesa/main/get_hash_params.py | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py index 84c5aa3..74ff3ba 100644 --- a/src/mesa/main/get_hash_params.py +++ b/src/mesa/main/get_hash_params.py @@ -799,17 +799,14 @@ descriptor=[ [ MAX_COMPUTE_UNIFORM_COMPONENTS, CONST(MAX_COMPUTE_UNIFORM_COMPONENTS), extra_ARB_compute_shader ], [ MAX_COMPUTE_IMAGE_UNIFORMS, CONST(MAX_COMPUTE_IMAGE_UNIFORMS), extra_ARB_compute_shader ], -# GL_ARB_gpu_shader5 - [ MAX_GEOMETRY_SHADER_INVOCATIONS, CONST(MAX_GEOMETRY_SHADER_INVOCATIONS), extra_ARB_gpu_shader5 ], - [ MIN_FRAGMENT_INTERPOLATION_OFFSET, CONTEXT_FLOAT(Const.MinFragmentInterpolationOffset), extra_ARB_gpu_shader5 ], - [ MAX_FRAGMENT_INTERPOLATION_OFFSET, CONTEXT_FLOAT(Const.MaxFragmentInterpolationOffset), extra_ARB_gpu_shader5 ], - [ FRAGMENT_INTERPOLATION_OFFSET_BITS, CONST(FRAGMENT_INTERPOLATION_OFFSET_BITS), extra_ARB_gpu_shader5 ], - # GL_ARB_framebuffer_no_attachments [MAX_FRAMEBUFFER_WIDTH, CONTEXT_INT(Const.MaxFramebufferWidth), extra_ARB_framebuffer_no_attachments], [MAX_FRAMEBUFFER_HEIGHT, CONTEXT_INT(Const.MaxFramebufferHeight), extra_ARB_framebuffer_no_attachments], [MAX_FRAMEBUFFER_LAYERS, CONTEXT_INT(Const.MaxFramebufferLayers), extra_ARB_framebuffer_no_attachments], [MAX_FRAMEBUFFER_SAMPLES, CONTEXT_INT(Const.MaxFramebufferSamples), extra_ARB_framebuffer_no_attachments], + +# GL_EXT_polygon_offset_clamp + [ POLYGON_OFFSET_CLAMP_EXT, CONTEXT_FLOAT(Polygon.OffsetClamp), extra_EXT_polygon_offset_clamp ], ]}, # Enums restricted to OpenGL Core profile @@ -824,8 +821,11 @@ descriptor=[ [ LAYER_PROVOKING_VERTEX, CONTEXT_ENUM(Light.ProvokingVertex), extra_ARB_viewport_array ], [ VIEWPORT_INDEX_PROVOKING_VERTEX, CONTEXT_ENUM(Light.ProvokingVertex), extra_ARB_viewport_array ], -# GL_EXT_polygon_offset_clamp - [ POLYGON_OFFSET_CLAMP_EXT, CONTEXT_FLOAT(Polygon.OffsetClamp), extra_EXT_polygon_offset_clamp ], +# GL_ARB_gpu_shader5 + [ MAX_GEOMETRY_SHADER_INVOCATIONS, CONST(MAX_GEOMETRY_SHADER_INVOCATIONS), extra_ARB_gpu_shader5 ], + [ MIN_FRAGMENT_INTERPOLATION_OFFSET, CONTEXT_FLOAT(Const.MinFragmentInterpolationOffset), extra_ARB_gpu_shader5 ], + [ MAX_FRAGMENT_INTERPOLATION_OFFSET, CONTEXT_FLOAT(Const.MaxFragmentInterpolationOffset), extra_ARB_gpu_shader5 ], + [ FRAGMENT_INTERPOLATION_OFFSET_BITS, CONST(FRAGMENT_INTERPOLATION_OFFSET_BITS), extra_ARB_gpu_shader5 ], ]} ] -- 2.3.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 08/15] egl/main: let EGL_RECORDABLE_ANDROID be a valid attrib
2015-06-09 4:17 GMT+08:00 Eric Anholt e...@anholt.net: Chih-Wei Huang cwhu...@android-x86.org writes: --- src/egl/main/eglconfig.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/egl/main/eglconfig.h b/src/egl/main/eglconfig.h index 84cb227..7121b3d 100644 --- a/src/egl/main/eglconfig.h +++ b/src/egl/main/eglconfig.h @@ -86,6 +86,7 @@ struct _egl_config /* extensions */ EGLint YInvertedNOK; + EGLint RecordableAndroid; }; @@ -133,6 +134,7 @@ _eglOffsetOfConfig(EGLint attr) ATTRIB_MAP(EGL_CONFORMANT,Conformant); /* extensions */ ATTRIB_MAP(EGL_Y_INVERTED_NOK,YInvertedNOK); + ATTRIB_MAP(EGL_RECORDABLE_ANDROID,RecordableAndroid); #undef ATTRIB_MAP default: return -1; This should be associated with exposing the EGL_ANDROID_recordable extension, right? Sorry for reply late. I just sent an update patch. But not sure if it's what you expect. -- Chih-Wei Android-x86 project http://www.android-x86.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] nv50/ir: support different unordered_set implementations
Wouldn't it be simpler to just have
codegen/unordered_set.h
which in turn has all the odd logic? I'm definitely a tad unhappy
about adding using in a header, but if the using goes inside the
nv50_ir namespace, I'm less weirded out by it. And then effectively
all 3 become nv50_ir::unordered_set, instead of the current situation
with 2 ::unordered_set and 1 nv50_ir::unordered_set.
By the way, I'm about to add some unordered_map usage. Is this going
to explode the world for android as well? Something like
https://github.com/imirkin/mesa/commit/c6dc6fd6ad19f152a53c58bac93c9aadd6958ae7
but I'm still making sure I have a full understanding of the
underlying issue, so might be a little while before I push.
-ilia
On Fri, Jun 19, 2015 at 12:50 PM, Chih-Wei Huang
cwhu...@android-x86.org wrote:
If build with C++11 standard, use std::unordered_set.
Otherwise if build on old Android version with stlport,
use std::tr1::unordered_set with a wrapper class.
Otherwise use std::tr1::unordered_set.
Signed-off-by: Chih-Wei Huang cwhu...@linux.org.tw
---
Android.common.mk | 1 +
src/gallium/auxiliary/Android.mk | 2 --
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 15 +++--
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 4 +--
.../nouveau/codegen/nv50_ir_lowering_nvc0.h| 4 +--
src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 5 ++-
.../drivers/nouveau/codegen/unordered_set.h| 37
++
7 files changed, 55 insertions(+), 13 deletions(-)
create mode 100644 src/gallium/drivers/nouveau/codegen/unordered_set.h
diff --git a/Android.common.mk b/Android.common.mk
index d662d60..de11e52 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -78,6 +78,7 @@ endif
LOCAL_CPPFLAGS += \
$(if $(filter true,$(MESA_LOLLIPOP_BUILD)),-D_USING_LIBCXX) \
+ -std=c++11 \
-Wno-error=non-virtual-dtor \
-Wno-non-virtual-dtor
diff --git a/src/gallium/auxiliary/Android.mk
b/src/gallium/auxiliary/Android.mk
index 86430eb..dbaeef6 100644
--- a/src/gallium/auxiliary/Android.mk
+++ b/src/gallium/auxiliary/Android.mk
@@ -40,8 +40,6 @@ ifeq ($(MESA_ENABLE_LLVM),true)
LOCAL_SRC_FILES += \
$(GALLIVM_SOURCES) \
$(GALLIVM_CPP_SOURCES)
-
-LOCAL_CPPFLAGS := -std=c++11
endif
# We need libmesa_glsl to get NIR's generated include directories.
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
index 529dcb9..a060ba3 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
@@ -29,7 +29,16 @@
#include deque
#include list
#include vector
+#if __cplusplus = 201103L
+#include unordered_set
+using std::unordered_set;
+#elif defined(ANDROID) // Android release before lollipop
+#include codegen/unordered_set.h
+using std::isfinite;
+#else
#include tr1/unordered_set
+using std::tr1::unordered_set;
+#endif
#include codegen/nv50_ir_util.h
#include codegen/nv50_ir_graph.h
@@ -583,10 +592,10 @@ public:
static inline Value *get(Iterator);
- std::tr1::unordered_setValueRef * uses;
+ unordered_setValueRef * uses;
std::listValueDef * defs;
- typedef std::tr1::unordered_setValueRef *::iterator UseIterator;
- typedef std::tr1::unordered_setValueRef *::const_iterator UseCIterator;
+ typedef unordered_setValueRef *::iterator UseIterator;
+ typedef unordered_setValueRef *::const_iterator UseCIterator;
typedef std::listValueDef *::iterator DefIterator;
typedef std::listValueDef *::const_iterator DefCIterator;
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 7a5d1ce..eccb09c 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -224,7 +224,7 @@ NVC0LegalizePostRA::findFirstUses(
const Instruction *texi,
const Instruction *insn,
std::listTexUse uses,
- std::tr1::unordered_setconst Instruction * visited)
+ unordered_setconst Instruction * visited)
{
for (int d = 0; insn-defExists(d); ++d) {
Value *v = insn-getDef(d);
@@ -323,7 +323,7 @@ NVC0LegalizePostRA::insertTextureBarriers(Function *fn)
if (!uses)
return false;
for (size_t i = 0; i texes.size(); ++i) {
- std::tr1::unordered_setconst Instruction * visited;
+ unordered_setconst Instruction * visited;
findFirstUses(texes[i], texes[i], uses[i], visited);
}
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
index 260e101..8c3dcbc 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
@@ -20,8
Re: [Mesa-dev] [PATCH 1/3] nv50/ir: support different unordered_set implementations
On Fri, Jun 19, 2015 at 1:19 PM, Chih-Wei Huang cwhu...@android-x86.org wrote:
2015-06-20 1:01 GMT+08:00 Ilia Mirkin imir...@alum.mit.edu:
Wouldn't it be simpler to just have
codegen/unordered_set.h
which in turn has all the odd logic? I'm definitely a tad unhappy
about adding using in a header, but if the using goes inside the
nv50_ir namespace, I'm less weirded out by it. And then effectively
all 3 become nv50_ir::unordered_set, instead of the current situation
with 2 ::unordered_set and 1 nv50_ir::unordered_set.
Well, I think the style is suggested by Francisco.
Let me make sure.
Do you hope me to move all #if ... #elif ... #else
logic into codegen/unordered_set.h,
and keep the using in nv50_ir namespace only?
That would be my preference. I haven't used C++ seriously in a while,
but I definitely remember that having a using in a global namespace is
a problem waiting to happen. So the codegen/unordered_set.h header
would go something like
#if foo
#include
#else if
#include
#endif
namespace nv50_ir {
#if foo
using a
#else if bar
using b
#else
crazy-class
#endif
}
Does that make sense to you?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/3] nv50/ir: support different unordered_set implementations
The nouveau bits are
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
If someone can say something non-negative-sounding about the
Android.mk change, happy to push this out. [I assume there's some
reason why it's part of this change.]
On Fri, Jun 19, 2015 at 2:00 PM, Chih-Wei Huang cwhu...@android-x86.org wrote:
If build with C++11 standard, use std::unordered_set.
Otherwise if build on old Android version with stlport,
use std::tr1::unordered_set with a wrapper class.
Otherwise use std::tr1::unordered_set.
Signed-off-by: Chih-Wei Huang cwhu...@linux.org.tw
---
Android.common.mk | 2 +-
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 8 ++--
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 4 +-
.../nouveau/codegen/nv50_ir_lowering_nvc0.h| 4 +-
src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 5 +--
.../drivers/nouveau/codegen/unordered_set.h| 48
++
6 files changed, 58 insertions(+), 13 deletions(-)
create mode 100644 src/gallium/drivers/nouveau/codegen/unordered_set.h
diff --git a/Android.common.mk b/Android.common.mk
index d662d60..35dcda2 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -77,7 +77,7 @@ LOCAL_CFLAGS += \
endif
LOCAL_CPPFLAGS += \
- $(if $(filter true,$(MESA_LOLLIPOP_BUILD)),-D_USING_LIBCXX) \
+ $(if $(filter true,$(MESA_LOLLIPOP_BUILD)),-std=c++11) \
-Wno-error=non-virtual-dtor \
-Wno-non-virtual-dtor
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
index 529dcb9..03cd569 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
@@ -29,8 +29,8 @@
#include deque
#include list
#include vector
-#include tr1/unordered_set
+#include codegen/unordered_set.h
#include codegen/nv50_ir_util.h
#include codegen/nv50_ir_graph.h
@@ -583,10 +583,10 @@ public:
static inline Value *get(Iterator);
- std::tr1::unordered_setValueRef * uses;
+ unordered_setValueRef * uses;
std::listValueDef * defs;
- typedef std::tr1::unordered_setValueRef *::iterator UseIterator;
- typedef std::tr1::unordered_setValueRef *::const_iterator UseCIterator;
+ typedef unordered_setValueRef *::iterator UseIterator;
+ typedef unordered_setValueRef *::const_iterator UseCIterator;
typedef std::listValueDef *::iterator DefIterator;
typedef std::listValueDef *::const_iterator DefCIterator;
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 7a5d1ce..eccb09c 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -224,7 +224,7 @@ NVC0LegalizePostRA::findFirstUses(
const Instruction *texi,
const Instruction *insn,
std::listTexUse uses,
- std::tr1::unordered_setconst Instruction * visited)
+ unordered_setconst Instruction * visited)
{
for (int d = 0; insn-defExists(d); ++d) {
Value *v = insn-getDef(d);
@@ -323,7 +323,7 @@ NVC0LegalizePostRA::insertTextureBarriers(Function *fn)
if (!uses)
return false;
for (size_t i = 0; i texes.size(); ++i) {
- std::tr1::unordered_setconst Instruction * visited;
+ unordered_setconst Instruction * visited;
findFirstUses(texes[i], texes[i], uses[i], visited);
}
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
index 260e101..8c3dcbc 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
@@ -20,8 +20,6 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
-#include tr1/unordered_set
-
#include codegen/nv50_ir.h
#include codegen/nv50_ir_build_util.h
@@ -73,7 +71,7 @@ private:
inline bool insnDominatedBy(const Instruction *, const Instruction *)
const;
void findFirstUses(const Instruction *tex, const Instruction *def,
std::listTexUse,
- std::tr1::unordered_setconst Instruction *);
+ unordered_setconst Instruction *);
void findOverwritingDefs(const Instruction *tex, Instruction *insn,
const BasicBlock *term,
std::listTexUse);
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 898653c..219d5f1 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
@@ -25,7 +25,6 @@
#include stack
#include limits
-#include tr1/unordered_set
namespace nv50_ir {
@@ -1551,7 +1550,7 @@ SpillCodeInserter::run(const std::listValuePair lst)
// Keep
Re: [Mesa-dev] [PATCH 1/2] glapi: gl_table.py: remove unused variable 'es'
I was planning to do this too.
Reviewed-by: Dylan Baker baker.dyla...@gmail.com
On Jun 19, 2015 5:17 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
None of the three build systems ever set it, as such we can clear things
up a bit.
Cc: Dylan Baker dylanx.c.ba...@intel.com
Cc: Jose Fonseca jfons...@vmware.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/mapi/glapi/gen/gl_table.py | 57
++
1 file changed, 8 insertions(+), 49 deletions(-)
diff --git a/src/mapi/glapi/gen/gl_table.py
b/src/mapi/glapi/gen/gl_table.py
index 3f02902..e25971a 100644
--- a/src/mapi/glapi/gen/gl_table.py
+++ b/src/mapi/glapi/gen/gl_table.py
@@ -33,10 +33,9 @@ import license
class PrintGlTable(gl_XML.gl_print_base):
-def __init__(self, es=False):
+def __init__(self):
gl_XML.gl_print_base.__init__(self)
-self.es = es
self.header_tag = '_GLAPI_TABLE_H_'
self.name = gl_table.py (from Mesa)
self.license = license.bsd_license_template % ( \
@@ -76,10 +75,9 @@ class PrintGlTable(gl_XML.gl_print_base):
class PrintRemapTable(gl_XML.gl_print_base):
-def __init__(self, es=False):
+def __init__(self):
gl_XML.gl_print_base.__init__(self)
-self.es = es
self.header_tag = '_DISPATCH_H_'
self.name = gl_table.py (from Mesa)
self.license = license.bsd_license_template % (
@@ -123,7 +121,6 @@ class PrintRemapTable(gl_XML.gl_print_base):
functions = []
abi_functions = []
-alias_functions = []
count = 0
for f in api.functionIterateByOffset():
if not f.is_abi():
@@ -132,11 +129,6 @@ class PrintRemapTable(gl_XML.gl_print_base):
else:
abi_functions.append([f, -1])
-if self.es:
-# remember functions with aliases
-if len(f.entry_points) 1:
-alias_functions.append(f)
-
print '/* total number of offsets below */'
print '#define _gloffset_COUNT %d' % (len(abi_functions +
functions))
print ''
@@ -144,18 +136,11 @@ class PrintRemapTable(gl_XML.gl_print_base):
for f, index in abi_functions:
print '#define _gloffset_%s %d' % (f.name, f.offset)
-if self.es:
-remap_table = esLocalRemapTable
-
-print '#define %s_size %u' % (remap_table, count)
-print 'static int %s[ %s_size ];' % (remap_table, remap_table)
-print ''
-else:
-remap_table = driDispatchRemapTable
+remap_table = driDispatchRemapTable
-print '#define %s_size %u' % (remap_table, count)
-print 'extern int %s[ %s_size ];' % (remap_table, remap_table)
-print ''
+print '#define %s_size %u' % (remap_table, count)
+print 'extern int %s[ %s_size ];' % (remap_table, remap_table)
+print ''
for f, index in functions:
print '#define %s_remap_index %u' % (f.name, index)
@@ -182,23 +167,6 @@ class PrintRemapTable(gl_XML.gl_print_base):
print '}'
print
-if alias_functions:
-print ''
-print '/* define aliases for compatibility */'
-for f in alias_functions:
-for name in f.entry_points:
-if name != f.name:
-print '#define CALL_%s(disp, parameters)
CALL_%s(disp, parameters)' % (name, f.name)
-print '#define GET_%s(disp) GET_%s(disp)' %
(name, f.name)
-print '#define SET_%s(disp, fn) SET_%s(disp, fn)'
% (name, f.name)
-print ''
-
-for f in alias_functions:
-for name in f.entry_points:
-if name != f.name:
-print '#define %s_remap_index %s_remap_index' %
(name, f.name)
-print ''
-
return
@@ -215,12 +183,6 @@ def _parser():
default='table',
metavar=mode,
help=Generate either a table or a remap_table)
-parser.add_argument('-c', '--es-version',
-choices=[None, 'es1', 'es2'],
-default=None,
-metavar=ver,
-dest='es',
-help=filter functions for es)
return parser.parse_args()
@@ -231,12 +193,9 @@ def main():
api = gl_XML.parse_GL_API(args.file_name)
if args.mode == table:
-printer = PrintGlTable(args.es)
+printer = PrintGlTable()
elif args.mode == remap_table:
-printer = PrintRemapTable(args.es)
-
-if args.es is not None:
-api.filter_functions_by_api(args.es)
+printer = PrintRemapTable()
printer.Print(api)
--
2.4.2
Re: [Mesa-dev] [PATCH 2/2] glsl: Fix counting of varyings.
Both look good to me, but perhaps Ian should check too.
Reviewed-by: Brian Paul bri...@vmware.com
On 06/19/2015 07:08 AM, Jose Fonseca wrote:
When input and output varyings started to be counted separately (commit
42305fb5) the is_varying_var function wasn't updated to return true for
output varyings or input varyings for stages other than the fragment
shader), effectively making the varying limit to never be checked.
With this change, color, texture coord, and generic varyings are not
counted, but others are ignored. It is assumed the hardware will handle
special varyings internally (ie, optimistic rather than pessimistic), to
avoid causing regressions where things were working somehow.
This fixes `glsl-max-varyings --exceed-limits` with softpipe/llvmpipe,
which was asserting because we were getting varyings beyond
VARYING_SLOT_MAX in st_glsl_to_tgsi.cpp.
It also prevents the assertion failure with
https://bugs.freedesktop.org/show_bug.cgi?id=90539 but the tests still
fails due to the link error.
This change also adds a few assertions to catch this sort of errors
earlier, and potentially prevent buffer overflows in the future (no
buffer overflow was detected here though).
However, this change causes several tests to regress:
spec/glsl-1.10/execution/varying-packing/simple ivec3 array
spec/glsl-1.10/execution/varying-packing/simple ivec3 separate
spec/glsl-1.10/execution/varying-packing/simple uvec3 array
spec/glsl-1.10/execution/varying-packing/simple uvec3 separate
spec/arb_gpu_shader_fp64/varying-packing/simple dmat3 array
spec/glsl-1.50/execution/geometry/max-input-components
spec/glsl-1.50/execution/variable-indexing/gs-input-array-vec4-index-rd
spec/glsl-1.50/execution/variable-indexing/vs-output-array-vec4-index-wr-before-gs
But this all seem to be issues either in the way we count varyings
(e.g., geometry inputs get counted multiple times) or in the tests
themselves, or limitations in the varying packer, and deserve attention
on their own right.
---
src/glsl/link_varyings.cpp | 70 --
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +
2 files changed, 58 insertions(+), 14 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 278a778..7649720 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -190,6 +190,8 @@ cross_validate_outputs_to_inputs(struct gl_shader_program
*prog,
*/
const unsigned idx = var-data.location - VARYING_SLOT_VAR0;
+ assert(idx MAX_VARYING);
+
if (explicit_locations[idx] != NULL) {
linker_error(prog,
%s shader has multiple outputs explicitly
@@ -1031,25 +1033,63 @@ varying_matches::match_comparator(const void
*x_generic, const void *y_generic)
/**
* Is the given variable a varying variable to be counted against the
* limit in ctx-Const.MaxVarying?
- * This includes variables such as texcoords, colors and generic
- * varyings, but excludes variables such as gl_FrontFacing and gl_FragCoord.
+ *
+ * OpenGL specification states:
+ *
+ * Each output variable component used as either a vertex shader output or
+ * fragment shader input counts against this limit, except for the components
+ * of gl_Position. A program containing only a vertex and fragment shader
+ * that accesses more than this limit's worth of components of outputs may
+ * fail to link, unless device-dependent optimizations are able to make the
+ * program fit within available hardware resources.
+ *
*/
static bool
var_counts_against_varying_limit(gl_shader_stage stage, const ir_variable
*var)
{
- /* Only fragment shaders will take a varying variable as an input */
- if (stage == MESA_SHADER_FRAGMENT
- var-data.mode == ir_var_shader_in) {
- switch (var-data.location) {
- case VARYING_SLOT_POS:
- case VARYING_SLOT_FACE:
- case VARYING_SLOT_PNTC:
- return false;
- default:
- return true;
- }
+ assert(var-data.mode == ir_var_shader_in || var-data.mode ==
ir_var_shader_out);
+
+ /* FIXME: It looks like we're currently counting each input multiple times
+* on geometry shaders. See piglit
+* spec/glsl-1.50/execution/geometry/max-input-components */
+ if (stage == MESA_SHADER_GEOMETRY) {
+ return false;
+ }
+
+ switch (var-data.location) {
+ case VARYING_SLOT_POS:
+ return false;
+ case VARYING_SLOT_COL0:
+ case VARYING_SLOT_COL1:
+ case VARYING_SLOT_FOGC:
+ case VARYING_SLOT_TEX0:
+ case VARYING_SLOT_TEX1:
+ case VARYING_SLOT_TEX2:
+ case VARYING_SLOT_TEX3:
+ case VARYING_SLOT_TEX4:
+ case VARYING_SLOT_TEX5:
+ case VARYING_SLOT_TEX6:
+ case VARYING_SLOT_TEX7:
+ return true;
+ case VARYING_SLOT_PSIZ:
+ case VARYING_SLOT_BFC0:
+ case VARYING_SLOT_BFC1:
+ case VARYING_SLOT_EDGE:
+ case VARYING_SLOT_CLIP_VERTEX:
+ case VARYING_SLOT_CLIP_DIST0:
[Mesa-dev] [PATCH v2 04/17] i965/fs: Explicitly set the exec_size on the add(32) in interpolation setup
Soon we will start using the builder to explicitly set all the execution sizes. We could make a 32-wide builder, but the builder asserts that we never grow it which is usually a reasonable assumption. Sinc this one instruction is a bit of an odd-ball, we just set the exec_size explicitly. v2: Explicitly new the fs_inst instead of using the builder and setting exec_size after the fact. --- src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp index 4770838..33464c5 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp @@ -1357,10 +1357,13 @@ fs_visitor::emit_interpolation_setup_gen6() */ fs_reg int_pixel_xy(GRF, alloc.allocate(dispatch_width / 8), BRW_REGISTER_TYPE_UW, dispatch_width * 2); - abld.exec_all() - .ADD(int_pixel_xy, - fs_reg(stride(suboffset(g1_uw, 4), 1, 4, 0)), - fs_reg(brw_imm_v(0x11001010))); + fs_inst *add = + new (mem_ctx) fs_inst(BRW_OPCODE_ADD, dispatch_width * 2, + int_pixel_xy, + fs_reg(stride(suboffset(g1_uw, 4), 1, 4, 0)), + fs_reg(brw_imm_v(0x11001010))); + add-force_writemask_all = true; + abld.emit(add); this-pixel_x = vgrf(glsl_type::float_type); this-pixel_y = vgrf(glsl_type::float_type); -- 2.4.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] nv50/ir: support different unordered_set implementations
2015-06-20 1:01 GMT+08:00 Ilia Mirkin imir...@alum.mit.edu: Wouldn't it be simpler to just have codegen/unordered_set.h which in turn has all the odd logic? I'm definitely a tad unhappy about adding using in a header, but if the using goes inside the nv50_ir namespace, I'm less weirded out by it. And then effectively all 3 become nv50_ir::unordered_set, instead of the current situation with 2 ::unordered_set and 1 nv50_ir::unordered_set. Well, I think the style is suggested by Francisco. Let me make sure. Do you hope me to move all #if ... #elif ... #else logic into codegen/unordered_set.h, and keep the using in nv50_ir namespace only? By the way, I'm about to add some unordered_map usage. Is this going to explode the world for android as well? Something like Probably... Will try it once it pushed. https://github.com/imirkin/mesa/commit/c6dc6fd6ad19f152a53c58bac93c9aadd6958ae7 but I'm still making sure I have a full understanding of the underlying issue, so might be a little while before I push. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/3] nv50/ir: support different unordered_set implementations
If build with C++11 standard, use std::unordered_set.
Otherwise if build on old Android version with stlport,
use std::tr1::unordered_set with a wrapper class.
Otherwise use std::tr1::unordered_set.
Signed-off-by: Chih-Wei Huang cwhu...@linux.org.tw
---
Android.common.mk | 2 +-
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 8 ++--
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 4 +-
.../nouveau/codegen/nv50_ir_lowering_nvc0.h| 4 +-
src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 5 +--
.../drivers/nouveau/codegen/unordered_set.h| 48 ++
6 files changed, 58 insertions(+), 13 deletions(-)
create mode 100644 src/gallium/drivers/nouveau/codegen/unordered_set.h
diff --git a/Android.common.mk b/Android.common.mk
index d662d60..35dcda2 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -77,7 +77,7 @@ LOCAL_CFLAGS += \
endif
LOCAL_CPPFLAGS += \
- $(if $(filter true,$(MESA_LOLLIPOP_BUILD)),-D_USING_LIBCXX) \
+ $(if $(filter true,$(MESA_LOLLIPOP_BUILD)),-std=c++11) \
-Wno-error=non-virtual-dtor \
-Wno-non-virtual-dtor
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
index 529dcb9..03cd569 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
@@ -29,8 +29,8 @@
#include deque
#include list
#include vector
-#include tr1/unordered_set
+#include codegen/unordered_set.h
#include codegen/nv50_ir_util.h
#include codegen/nv50_ir_graph.h
@@ -583,10 +583,10 @@ public:
static inline Value *get(Iterator);
- std::tr1::unordered_setValueRef * uses;
+ unordered_setValueRef * uses;
std::listValueDef * defs;
- typedef std::tr1::unordered_setValueRef *::iterator UseIterator;
- typedef std::tr1::unordered_setValueRef *::const_iterator UseCIterator;
+ typedef unordered_setValueRef *::iterator UseIterator;
+ typedef unordered_setValueRef *::const_iterator UseCIterator;
typedef std::listValueDef *::iterator DefIterator;
typedef std::listValueDef *::const_iterator DefCIterator;
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 7a5d1ce..eccb09c 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -224,7 +224,7 @@ NVC0LegalizePostRA::findFirstUses(
const Instruction *texi,
const Instruction *insn,
std::listTexUse uses,
- std::tr1::unordered_setconst Instruction * visited)
+ unordered_setconst Instruction * visited)
{
for (int d = 0; insn-defExists(d); ++d) {
Value *v = insn-getDef(d);
@@ -323,7 +323,7 @@ NVC0LegalizePostRA::insertTextureBarriers(Function *fn)
if (!uses)
return false;
for (size_t i = 0; i texes.size(); ++i) {
- std::tr1::unordered_setconst Instruction * visited;
+ unordered_setconst Instruction * visited;
findFirstUses(texes[i], texes[i], uses[i], visited);
}
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
index 260e101..8c3dcbc 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
@@ -20,8 +20,6 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
-#include tr1/unordered_set
-
#include codegen/nv50_ir.h
#include codegen/nv50_ir_build_util.h
@@ -73,7 +71,7 @@ private:
inline bool insnDominatedBy(const Instruction *, const Instruction *) const;
void findFirstUses(const Instruction *tex, const Instruction *def,
std::listTexUse,
- std::tr1::unordered_setconst Instruction *);
+ unordered_setconst Instruction *);
void findOverwritingDefs(const Instruction *tex, Instruction *insn,
const BasicBlock *term,
std::listTexUse);
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 898653c..219d5f1 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
@@ -25,7 +25,6 @@
#include stack
#include limits
-#include tr1/unordered_set
namespace nv50_ir {
@@ -1551,7 +1550,7 @@ SpillCodeInserter::run(const std::listValuePair lst)
// Keep track of which instructions to delete later. Deleting them
// inside the loop is unsafe since a single instruction may have
// multiple destinations that all need to be spilled (like OP_SPLIT).
- std::tr1::unordered_setInstruction * to_del;
+ unordered_setInstruction * to_del;
for (Value::DefIterator d = lval-defs.begin(); d != lval-defs.end();
++d) {
@@
Re: [Mesa-dev] [PATCH] mesa: move ARB_gs5 enums to core, EXT_polygon_offset_clamp to desktop
Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/3] nv50/ir: support different unordered_set implementations
2015-06-20 2:05 GMT+08:00 Ilia Mirkin imir...@alum.mit.edu: The nouveau bits are Reviewed-by: Ilia Mirkin imir...@alum.mit.edu If someone can say something non-negative-sounding about the Android.mk change, happy to push this out. [I assume there's some reason why it's part of this change.] About the Android.mk change, originally I hope to use _USING_LIBCXX to distinguish building with libcxx or stlport. But now I think it's unnecessary since stlport is not c++11 compliant. So just use c++11 to distinguish the two cases. Nobody else uses _USING_LIBCXX. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] egl/main: expose the EGL_RECORDABLE_ANDROID extension
Hi Chih-Wei,
On 19 June 2015 at 17:50, Chih-Wei Huang cwhu...@android-x86.org wrote:
Signed-off-by: Chih-Wei Huang cwhu...@linux.org.tw
---
src/egl/main/eglconfig.c | 5 -
src/egl/main/eglconfig.h | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/egl/main/eglconfig.c b/src/egl/main/eglconfig.c
index cf65c69..d9971ed 100644
--- a/src/egl/main/eglconfig.c
+++ b/src/egl/main/eglconfig.c
@@ -245,7 +245,10 @@ static const struct {
/* extensions */
{ EGL_Y_INVERTED_NOK,ATTRIB_TYPE_BOOLEAN,
ATTRIB_CRITERION_EXACT,
-EGL_DONT_CARE }
+EGL_DONT_CARE },
+ { EGL_RECORDABLE_ANDROID,ATTRIB_TYPE_BOOLEAN,
+ATTRIB_CRITERION_EXACT,
+EGL_DONT_CARE },
};
diff --git a/src/egl/main/eglconfig.h b/src/egl/main/eglconfig.h
index 84cb227..7121b3d 100644
--- a/src/egl/main/eglconfig.h
+++ b/src/egl/main/eglconfig.h
@@ -86,6 +86,7 @@ struct _egl_config
/* extensions */
EGLint YInvertedNOK;
+ EGLint RecordableAndroid;
};
@@ -133,6 +134,7 @@ _eglOffsetOfConfig(EGLint attr)
ATTRIB_MAP(EGL_CONFORMANT,Conformant);
/* extensions */
ATTRIB_MAP(EGL_Y_INVERTED_NOK,YInvertedNOK);
+ ATTRIB_MAP(EGL_RECORDABLE_ANDROID,RecordableAndroid);
I believe what Eric meant earlier was that - in order for the extra
token to be recognised one needs to implement(and advertise) the whole
EGL_ANDROID_recordable extension. From a quick look at the spec, this
means adding a _EGL_CHECK_EXTENSION() _eglCreateExtensionsString and
making use of the value, rather than just accepting the new token.
If you write a piglit test or two that would be amazing :-)
Cheers,
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] bugzilla_mesa.sh: sort the bugs list by number
Cc: 10.5 10.6 mesa-sta...@lists.freedesktop.org Suggested-by: Ilia Mirkin imir...@alum.mit.edu Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- bin/bugzilla_mesa.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bin/bugzilla_mesa.sh b/bin/bugzilla_mesa.sh index 491ca0e..9b0cbbc 100755 --- a/bin/bugzilla_mesa.sh +++ b/bin/bugzilla_mesa.sh @@ -25,7 +25,7 @@ trim_after='s/\(show_bug.cgi?id=[0-9]*\).*/\1/' use_https='s/http:/https:/' # extract fdo urls from commit log -urls=$(git log $* | grep 'bugs.freedesktop.org/show_bug' | sed -e $trim_before -e $trim_after -e $use_https | sort | uniq) +urls=$(git log $* | grep 'bugs.freedesktop.org/show_bug' | sed -e $trim_before -e $trim_after -e $use_https | sort-n | uniq) # if DRYRUN is set to yes, simply print the URLs and don't fetch the # details from fdo bugzilla. -- 2.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] bugzilla_mesa.sh: sort the bugs list by number
I don't suppose you tested this... you probably just want 'sort -n -u' instead of 'sort-n (which doesn't exist) | uniq'. Double-check that it works though, not sure if it'll work with the number at the end. But it might. On Fri, Jun 19, 2015 at 3:41 PM, Emil Velikov emil.l.veli...@gmail.com wrote: Cc: 10.5 10.6 mesa-sta...@lists.freedesktop.org Suggested-by: Ilia Mirkin imir...@alum.mit.edu Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- bin/bugzilla_mesa.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bin/bugzilla_mesa.sh b/bin/bugzilla_mesa.sh index 491ca0e..9b0cbbc 100755 --- a/bin/bugzilla_mesa.sh +++ b/bin/bugzilla_mesa.sh @@ -25,7 +25,7 @@ trim_after='s/\(show_bug.cgi?id=[0-9]*\).*/\1/' use_https='s/http:/https:/' # extract fdo urls from commit log -urls=$(git log $* | grep 'bugs.freedesktop.org/show_bug' | sed -e $trim_before -e $trim_after -e $use_https | sort | uniq) +urls=$(git log $* | grep 'bugs.freedesktop.org/show_bug' | sed -e $trim_before -e $trim_after -e $use_https | sort-n | uniq) # if DRYRUN is set to yes, simply print the URLs and don't fetch the # details from fdo bugzilla. -- 2.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/11] configure: error out when building libEGL without shared-glapi
The latter is a hard requirement and without it we'll error out later on in the build. Cc: 10.5 10.6 mesa-sta...@lists.freedesktop.org Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- configure.ac | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure.ac b/configure.ac index 8e62bd8..56095ba 100644 --- a/configure.ac +++ b/configure.ac @@ -1543,6 +1543,9 @@ if test x$enable_egl = xyes; then if test $enable_static != yes; then if test x$enable_dri = xyes; then HAVE_EGL_DRIVER_DRI2=1 +if test x$enable_shared_glapi = xno; then +AC_MSG_ERROR([egl_dri2 requires --enable-shared-glapi]) +fi else # Avoid building an empty libEGL. Drop/update this # when other backends (haiku?) come along. -- 2.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/11] android: egl: do not link against libglapi
The only reason we touch glapi is to dlopen it to: - make sure that the unresolved _glapi* symbols in the dri modules are provided. - fetch glFlush() and use it at various stages in the dri2 driver. XXX: If anyone has suggestions why the latter is required (or can recommend any reading material) I'm all ears. Cc: Chih-Wei Huang cwhu...@linux.org.tw Cc: Eric Anholt e...@anholt.net Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/egl/main/Android.mk | 1 - 1 file changed, 1 deletion(-) diff --git a/src/egl/main/Android.mk b/src/egl/main/Android.mk index 8f687e9..0ba7295 100644 --- a/src/egl/main/Android.mk +++ b/src/egl/main/Android.mk @@ -44,7 +44,6 @@ LOCAL_CFLAGS := \ -D_EGL_OS_UNIX=1 LOCAL_SHARED_LIBRARIES := \ - libglapi \ libdl \ libhardware \ liblog \ -- 2.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/11] gbm: do not (over)link against libglapi.so
The whole of GBM does not rely on even a single symbol from the GL dispatch library, unsuprisingly. The only need for it comes from the unresolved symbols in the DRI modules, which are now correctly handled with Frank's commit. Cc: 10.5 10.6 mesa-sta...@lists.freedesktop.org Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/gbm/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gbm/Makefile.am b/src/gbm/Makefile.am index dbd4f83..918fdf7 100644 --- a/src/gbm/Makefile.am +++ b/src/gbm/Makefile.am @@ -52,7 +52,8 @@ libgbm_dri_la_CFLAGS = \ $(LIBDRM_CFLAGS) libgbm_la_LIBADD += \ - libgbm_dri.la $(top_builddir)/src/mapi/shared-glapi/libglapi.la $(LIBDRM_LIBS) + libgbm_dri.la \ + $(LIBDRM_LIBS) endif TESTS = gbm-symbols-check -- 2.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/11] drivers/x11: fix the build against shared_glapi
Cc: Brian Paul bri...@vmware.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/mesa/drivers/x11/Makefile.am | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/mesa/drivers/x11/Makefile.am b/src/mesa/drivers/x11/Makefile.am index c0596f8..a8847e8 100644 --- a/src/mesa/drivers/x11/Makefile.am +++ b/src/mesa/drivers/x11/Makefile.am @@ -25,6 +25,11 @@ EXTRA_DIST = SConscript +if HAVE_SHARED_GLAPI +SHARED_GLAPI_CFLAGS = -DGLX_SHARED_GLAPI +SHARED_GLAPI_LIB = $(top_builddir)/src/mapi/shared-glapi/libglapi.la +endif + AM_CPPFLAGS = \ -I$(top_srcdir)/include \ -I$(top_srcdir)/src/mapi \ @@ -34,6 +39,7 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/src/gallium/auxiliary \ -I$(top_srcdir)/src/mesa/main \ $(X11_INCLUDES) \ + $(SHARED_GLAPI_CFLAGS) \ $(DEFINES) if HAVE_X11_DRIVER @@ -66,6 +72,7 @@ GL_PATCH = 0 lib@GL_LIB@_la_LIBADD = \ $(top_builddir)/src/mesa/libmesa.la \ $(top_builddir)/src/mapi/glapi/libglapi.la \ + $(SHARED_GLAPI_LIB) \ $(GL_LIB_DEPS) lib@GL_LIB@_la_LDFLAGS = \ -- 2.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/11] configure: allow building shared-glapi powered libgl-xlib
XXX: With this one done, we can finally transition with enforcing shared-glapi, and - link the dri modules against libglapi.so, add --no-undefined to the LDFLAGS - drop the dlopen(libglapi.so/libGL.so, RTLD_GLOBAL) workarounds in the loaders - libGL, libEGL and libgbm. - start killing off/cleaning up the dispatch ? The caveats: 1) up-to what stage do we care about static libraries - libgl (either dri or xlib based) - osmesa - libEGL 2) how about other platforms (scons) ? - currently the scons uses static glapi, - would we need the dlopen(...) on windows ? Cc: Brian Paul bri...@vmware.com Cc: Jose Fonseca jfons...@vmware.com Cc: Adam Jackson a...@redhat.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- configure.ac | 6 -- 1 file changed, 6 deletions(-) diff --git a/configure.ac b/configure.ac index 5161361..677fb5b 100644 --- a/configure.ac +++ b/configure.ac @@ -941,12 +941,6 @@ x*yes*yes*) ;; esac -# Building Xlib-GLX requires shared glapi to be disabled. -if test x$enable_shared_glapi$enable_xlib_glx = xyesyes; then -AC_MSG_NOTICE([Shared GLAPI should not used with Xlib-GLX, disabling]) -enable_shared_glapi=no -fi - AM_CONDITIONAL(HAVE_SHARED_GLAPI, test x$enable_shared_glapi = xyes) # Build the pipe-drivers as separate libraries/modules. -- 2.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/11] configure: error out when building backend-less libEGL
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- configure.ac | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 677fb5b..8e62bd8 100644 --- a/configure.ac +++ b/configure.ac @@ -1542,8 +1542,12 @@ if test x$enable_egl = xyes; then if test $enable_static != yes; then if test x$enable_dri = xyes; then - HAVE_EGL_DRIVER_DRI2=1 - fi +HAVE_EGL_DRIVER_DRI2=1 +else +# Avoid building an empty libEGL. Drop/update this +# when other backends (haiku?) come along. +AC_MSG_ERROR([egl requires --enable-dri]) +fi fi fi -- 2.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/11] glapi fixes - build whole of mesa with
Hi all, A lovely series inspired (more like 'was awaken to send these out') by Pal Rohár, who was having issues when building xlib-libgl (plus the now enabled gles*) So here, we teach the final two static glapi users about shared-glapi, plus some related fixes. After this is done we can finally start transitioning to shared-only glapi, with some more details as mentioned in one of the patches: XXX: With this one done, we can finally transition with enforcing shared-glapi, and - link the dri modules against libglapi.so, add --no-undefined to the LDFLAGS - drop the dlopen(libglapi.so/libGL.so, RTLD_GLOBAL) workarounds in the loaders - libGL, libEGL and libgbm. - start killing off/cleaning up the dispatch ? The caveats: 1) up to what stage do we care about static libraries - libgl (either dri or xlib based) - osmesa - libEGL 2) how about other platforms (scons) ? - currently the scons uses static glapi, - would we need the dlopen(...) on windows ? Hope everyone is excited about this one as I am :-) Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/11] gbm: dlopen libglapi so gbm_create_device works
From: Frank Henigman fjhenig...@chromium.org
Dri driver libs are not linked to pull in libglapi so gbm_create_device()
fails when it tries to dlopen them (unless the application is linked
with something that does pull in libglapi, like libGL).
Until dri drivers can be fixed properly, dlopen libglapi before trying
to dlopen them.
Cc: 10.5 10.6 mesa-sta...@lists.freedesktop.org
Signed-off-by: Frank Henigman fjhenig...@google.com
[Emil Velikov: Drop misleading bugzilla link, mention that libname differs]
Reviewed-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gbm/backends/dri/gbm_dri.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 62bdf89..ccc3cc6 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -311,6 +311,14 @@ dri_open_driver(struct gbm_dri_device *dri)
if (search_paths == NULL)
search_paths = DEFAULT_DRIVER_DIR;
+ /* Temporarily work around dri driver libs that need symbols in libglapi
+* but don't automatically link it in.
+*/
+ /* XXX: Library name differs on per platforms basis. Update this as
+* osx/cygwin/windows/bsd gets support for GBM..
+*/
+ dlopen(libglapi.so.0, RTLD_LAZY | RTLD_GLOBAL);
+
dri-driver = NULL;
end = search_paths + strlen(search_paths);
for (p = search_paths; p end dri-driver == NULL; p = next + 1) {
--
2.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/11] confiigure: drop unused variable GBM_BACKEND_DIRS
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- configure.ac | 1 - 1 file changed, 1 deletion(-) diff --git a/configure.ac b/configure.ac index 56095ba..ddc757e 100644 --- a/configure.ac +++ b/configure.ac @@ -1507,7 +1507,6 @@ if test x$enable_gbm = xyes; then fi if test x$enable_dri = xyes; then -GBM_BACKEND_DIRS=$GBM_BACKEND_DIRS dri if test x$enable_shared_glapi = xno; then AC_MSG_ERROR([gbm_dri requires --enable-shared-glapi]) fi -- 2.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/11] targets/libgl-xlib: fix the build against shared_glapi
Cc: Brian Paul bri...@vmware.com Cc: Jose Fonseca jfons...@vmware.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/gallium/targets/libgl-xlib/Makefile.am | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/gallium/targets/libgl-xlib/Makefile.am b/src/gallium/targets/libgl-xlib/Makefile.am index 33b0d13..d99caae 100644 --- a/src/gallium/targets/libgl-xlib/Makefile.am +++ b/src/gallium/targets/libgl-xlib/Makefile.am @@ -24,6 +24,11 @@ GL_MAJOR = 1 GL_MINOR = 5 GL_TINY = $(MESA_MAJOR)$(MESA_MINOR)0$(MESA_TINY) +if HAVE_SHARED_GLAPI +SHARED_GLAPI_CFLAGS = -DGLX_SHARED_GLAPI +SHARED_GLAPI_LIB = $(top_builddir)/src/mapi/shared-glapi/libglapi.la +endif + AM_CPPFLAGS = \ -I$(top_srcdir)/include \ -I$(top_srcdir)/src \ @@ -35,6 +40,7 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/src/gallium/state_trackers/glx/xlib \ -I$(top_srcdir)/src/gallium/auxiliary \ -I$(top_srcdir)/src/gallium/winsys \ + $(SHARED_GLAPI_CFLAGS) \ -DGALLIUM_SOFTPIPE \ -DGALLIUM_RBUG \ -DGALLIUM_TRACE @@ -65,6 +71,7 @@ lib@GL_LIB@_la_LIBADD = \ $(top_builddir)/src/mapi/glapi/libglapi.la \ $(top_builddir)/src/mesa/libmesagallium.la \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ + $(SHARED_GLAPI_LIB) \ $(GL_LIB_DEPS) \ $(CLOCK_LIB) -- 2.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/11] configure: warn about shared_glapi xlib-glx only when both are set
Printing out the message when shared_glapi is disabled only leads to confusion. Cc: 10.5 10.6 mesa-sta...@lists.freedesktop.org Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 3c763c2..5161361 100644 --- a/configure.ac +++ b/configure.ac @@ -942,7 +942,7 @@ x*yes*yes*) esac # Building Xlib-GLX requires shared glapi to be disabled. -if test x$enable_xlib_glx = xyes; then +if test x$enable_shared_glapi$enable_xlib_glx = xyesyes; then AC_MSG_NOTICE([Shared GLAPI should not used with Xlib-GLX, disabling]) enable_shared_glapi=no fi -- 2.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
