[Mesa-dev] [Bug 45571] fatal error: program/symbol_table.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=45571 --- Comment #8 from Jos van Wolput 2012-02-05 00:50:40 PST --- After a closer look I noticed that the error I get isn't exactly the same as the one mentioned by Alexandre Demers: --- In file included from glsl_parser_extras.h:35:0, from ast.h:30, from glsl_lexer.ll:27: glsl_symbol_table.h:29:15: fatal error: new: No such file or directory compilation terminated. make[2]: *** [glsl_lexer.o] Error 1 --- -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 45571] fatal error: program/symbol_table.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=45571 --- Comment #9 from Knut Petersen 2012-02-05 03:07:34 PST --- (In reply to comment #6) > (In reply to comment #4) > > If it is necessary to run "git clean -dfx" after every change > > to mesa that means nothing but that the build system is broken > > and should be fixed. > > How do you expect `make clean` (ie, the build system) to know to clean files > that have been removed from git? First of all: git clean -dfx helped in my case. What should a "make distclean/realclean" do? Up to now I expected a result according to http://www.gnu.org/software/automake/manual/html_node/Clean.html - iow delete anything generated by autogen.sh and make. Obviously that is not the case. After a mesa build with my configuration parameters (only i915) "make realclean" fails to delete 360 files generated during the build process, 20 of these are *.h, *.c or *.h files. I´d call that broken. Granted, a "make clean/realclean/distclean" might fail to delete a stale file that does not belong to the current version of the sources, but how could that cause any harm? Such a file should not be referenced in any Makefile and so it should be simply ignored. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 45622] incorrect constant used with pipe_resource field?
https://bugs.freedesktop.org/show_bug.cgi?id=45622 --- Comment #1 from Christoph Bumiller 2012-02-05 07:42:29 PST --- Yes that's wrong, it should be 'usage' (the function arg), not 'pr->flags'. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC]Varyings Packing
Hi, I implemented the GLES 2.0 packing algorithm with the following patches. It work, no regression (on top of 5be55ed426a5f20723a9fd6ca083235363dd6bd5) and it passes the glsl-max-varying-2 tests (I'm resending this piglit test with some fixes : I inverted some size there...). I'd like to customise the packing function with respect to drivers. Currently it packs none/smooth/flat/noperspective interpoled value in separate ranges of registers. This is the most conservative approach, because AFAIK r600g does not support mixed interpolation in a same register. However i965 can mix smooth and noperspective varying, yielding to more packing opportunity, and scalar hardware (nouveau or swrast) have no such constraint, so having some kind of "flag" to provide the linker with the register constraints would be better. I can implement the horizontal field support for glsl_to_tgsi but it is more difficult for me to do it for r200 and i915 (I don't own such hardware). I think that r200 does not support shaders at all, but i915 does. Regards, Vincent ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] glsl: Adds an horizontal_location fields to ir_variable.
This field allows to address output variables more precisely
(varyings won't have to "hold" a whole register if they are not vec4).
---
src/gallium/state_trackers/dri/drm/dri2.c |3 +++
src/glsl/ir.cpp |1 +
src/glsl/ir.h | 22 ++
src/glsl/ir_clone.cpp |1 +
src/mesa/drivers/dri/i965/brw_fs.cpp |4 ++--
5 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
b/src/gallium/state_trackers/dri/drm/dri2.c
index afd91ee..4c08a02 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -316,6 +316,9 @@ dri2_allocate_buffer(__DRIscreen *sPriv,
switch (format) {
case 32:
+ pf = PIPE_FORMAT_B8G8R8A8_UNORM;
+ break;
+ case 24:
pf = PIPE_FORMAT_B8G8R8X8_UNORM;
break;
case 16:
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index a5eca5a..a4c93ce 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -1335,6 +1335,7 @@ ir_variable::ir_variable(const struct glsl_type *type,
const char *name,
this->pixel_center_integer = false;
this->depth_layout = ir_depth_layout_none;
this->used = false;
+ this->horizontal_location = 0;
if (type && type->base_type == GLSL_TYPE_SAMPLER)
this->read_only = true;
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 1faae3c..cf0e444 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -396,6 +396,28 @@ public:
* slot has not been assigned, the value will be -1.
*/
int location;
+
+ /**
+* Storage starting component for this variable
+*
+* Variable storage can be 4-bytes aligned instead of 16-bytes aligned to
+* preserve space, for instance a vec2 can be stored in FILE[location].yz
+* and in this case, its starting_component is y (eq to 1).
+*
+* Register can be seen as a 2D array as follow :
+* - Locations are assigned to rows,
+* - Components are assigned to columns.
+*
+* 0: [ 0.x 0.y 0.z 0.w]
+* 1: [ 1.x 1.y 1.z 1.w]
+* 2: [ 2.x 2.y 2.z 2.w]
+* ...
+* n: [ n.x n.y n.z n.w]
+*
+* Thus we refers this as "horizontal_location" (vertical location is
+* the above "location" field).
+*/
+unsigned horizontal_location:2;
/**
* Built-in state that backs this uniform
diff --git a/src/glsl/ir_clone.cpp b/src/glsl/ir_clone.cpp
index c63615c..17e800a 100644
--- a/src/glsl/ir_clone.cpp
+++ b/src/glsl/ir_clone.cpp
@@ -46,6 +46,7 @@ ir_variable::clone(void *mem_ctx, struct hash_table *ht) const
var->invariant = this->invariant;
var->interpolation = this->interpolation;
var->location = this->location;
+ var->horizontal_location = this->horizontal_location;
var->warn_extension = this->warn_extension;
var->origin_upper_left = this->origin_upper_left;
var->pixel_center_integer = this->pixel_center_integer;
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 6ecaa6c..d095e86 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -462,7 +462,7 @@ fs_visitor::emit_general_interpolation(ir_variable *ir)
* field of the setup reg.
*/
for (unsigned int k = 0; k < type->vector_elements; k++) {
- struct brw_reg interp = interp_reg(location, k);
+ struct brw_reg interp = interp_reg(location, k +
ir->horizontal_location);
interp = suboffset(interp, 3);
interp.type = reg->type;
emit(FS_OPCODE_CINTERP, attr, fs_reg(interp));
@@ -482,7 +482,7 @@ fs_visitor::emit_general_interpolation(ir_variable *ir)
k == 3 && !(c->key.proj_attrib_mask & (1 << location))) {
emit(BRW_OPCODE_MOV, attr, fs_reg(1.0f));
} else {
- struct brw_reg interp = interp_reg(location, k);
+ struct brw_reg interp = interp_reg(location, k +
ir->horizontal_location);
brw_wm_barycentric_interp_mode barycoord_mode;
if (interpolation_mode == INTERP_QUALIFIER_SMOOTH)
barycoord_mode = BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC;
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] i965: Adds support for horizontal location
---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 39 +++-
1 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 13ba18b..88b8a9d 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -832,6 +832,7 @@ vec4_visitor::visit(ir_variable *ir)
{
dst_reg *reg = NULL;
+ unsigned components;
if (variable_storage(ir))
return;
@@ -854,15 +855,26 @@ vec4_visitor::visit(ir_variable *ir)
break;
case ir_var_out:
- reg = new(mem_ctx) dst_reg(this, ir->type);
+ components =
(ir->type->is_array())?ir->type->fields.array->vector_elements:ir->type->vector_elements;
+ if (!output_reg_annotation[ir->location]) {
+ // The reg has not been set
+ reg = new(mem_ctx) dst_reg(this, ir->type);
- for (int i = 0; i < type_size(ir->type); i++) {
-output_reg[ir->location + i] = *reg;
-output_reg[ir->location + i].reg_offset = i;
-output_reg[ir->location + i].type =
-brw_type_for_base_type(ir->type->get_scalar_type());
-output_reg_annotation[ir->location + i] = ir->name;
- }
+ for (int i = 0; i < type_size(ir->type); i++) {
+ output_reg[ir->location + i] = *reg;
+ output_reg[ir->location + i].reg_offset = i;
+ output_reg[ir->location + i].type =
+ brw_type_for_base_type(ir->type->get_scalar_type());
+ output_reg[ir->location + i].writemask = (((1 << components) - 1)
<< ir->horizontal_location);
+ output_reg_annotation[ir->location + i] = ir->name;
+ }
+ } else {
+ // The reg has already been set : this output is packed
+ reg = &(output_reg[ir->location]);
+ output_reg[ir->location].writemask |= (((1 << components) - 1) <<
ir->horizontal_location);
+ char * new_annotation = ralloc_asprintf(mem_ctx, "%s ; %s",
output_reg_annotation[ir->location], ir->name);
+ output_reg_annotation[ir->location] = new_annotation;
+ }
break;
case ir_var_auto:
@@ -1404,6 +1416,12 @@ vec4_visitor::visit(ir_dereference_variable *ir)
if (type->is_scalar() || type->is_vector() || type->is_matrix())
this->result.swizzle = swizzle_for_size(type->vector_elements);
+ unsigned swz = this->result.swizzle;
+ this->result.swizzle = BRW_SWIZZLE4(BRW_GET_SWZ(swz, 0) +
ir->var->horizontal_location % 4,
+ BRW_GET_SWZ(swz, 1) +
ir->var->horizontal_location % 4,
+ BRW_GET_SWZ(swz, 2) +
ir->var->horizontal_location % 4,
+ BRW_GET_SWZ(swz, 3) +
ir->var->horizontal_location % 4
+ );
}
void
@@ -1660,6 +1678,10 @@ vec4_visitor::visit(ir_assignment *ir)
assert(ir->lhs->type->is_vector() ||
ir->lhs->type->is_scalar());
dst.writemask = ir->write_mask;
+
+ if (ir_variable *inside_var = ir->lhs->variable_referenced()) {
+ dst.writemask = dst.writemask << inside_var->horizontal_location;
+ }
for (int i = 0; i < 4; i++) {
if (dst.writemask & (1 << i)) {
@@ -2616,6 +2638,7 @@ vec4_visitor::vec4_visitor(struct brw_vs_compile *c,
this->live_intervals_valid = false;
this->uniforms = 0;
+ memset(output_reg_annotation, 0, sizeof(output_reg_annotation));
}
vec4_visitor::~vec4_visitor()
--
1.7.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] glsl: Adds varying packing for single vector based varyings
---
src/glsl/linker.cpp | 659 ++-
1 files changed, 550 insertions(+), 109 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 5095751..66c1671 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1458,6 +1458,8 @@ private:
* variable. -1 if a location hasn't been assigned yet.
*/
int location;
+
+ unsigned horizontal_location;
/**
* If location != -1, the number of vector elements in this variable, or 1
@@ -1496,6 +1498,7 @@ tfeedback_decl::init(struct gl_context *ctx, struct
gl_shader_program *prog,
*/
this->location = -1;
+ this->horizontal_location = 0;
this->orig_name = input;
this->is_clip_distance_mesa = false;
@@ -1602,6 +1605,7 @@ tfeedback_decl::assign_location(struct gl_context *ctx,
this->vector_elements = output_var->type->vector_elements;
this->matrix_columns = output_var->type->matrix_columns;
this->type = output_var->type->gl_type;
+ this->horizontal_location = output_var->horizontal_location;
}
/* From GL_EXT_transform_feedback:
@@ -1687,7 +1691,7 @@ tfeedback_decl::store(struct gl_context *ctx, struct
gl_shader_program *prog,
for (unsigned v = 0; v < this->matrix_columns; ++v) {
unsigned num_components = this->vector_elements;
assert(info->NumOutputs < max_outputs);
- info->Outputs[info->NumOutputs].ComponentOffset = 0;
+ info->Outputs[info->NumOutputs].ComponentOffset =
this->horizontal_location;
if (this->is_clip_distance_mesa) {
if (this->is_subscripted) {
num_components = 1;
@@ -1809,6 +1813,456 @@ assign_varying_location(ir_variable *input_var,
ir_variable *output_var,
}
}
+namespace pack {
+
+/**
+ * Varyings packing can be seen as an instance of the bin packing problem.
+ * It is a NP hard problem in general.
+ *
+ * ES 2.0 specs gives (GLSL_ES_Specification_1.0.17-3.pdf, p111) an algorithm
+ * that specifies a minimum requirement for when a set of varyings must be
+ * supported.
+ * We almost follow the algorithm : the target architecture should be a
+ * 8x4 grid, we use a {number_of_available_reg}x4 grid.
+ */
+class buffer_representation
+{
+protected:
+ class delayed_location_assignment : public exec_node
+ {
+ public:
+ ir_variable *producer;
+ ir_variable *consumer;
+ unsigned location;
+ unsigned horizontal_location;
+ delayed_location_assignment(ir_variable *p, ir_variable *c)
+ : producer(p), consumer(c)
+ {
+ }
+
+ bool is_before(const delayed_location_assignment *comparee) const
+ {
+ unsigned local_size =
(producer->type->is_array())?producer->type->length:1;
+ unsigned comparee_size =
(comparee->producer->type->is_array())?comparee->producer->type->length:1;
+ return local_size >= comparee_size;
+ }
+
+ void set_location_to_vars(unsigned producer_offset, unsigned
consumer_offset, unsigned location, unsigned horizontal_location)
+ {
+ producer->location = producer_offset + location;
+ producer->horizontal_location = horizontal_location;
+ if (consumer) {
+ consumer->location = consumer_offset + location;
+ consumer->horizontal_location = horizontal_location;
+ }
+ }
+
+ };
+
+ void *ctx;
+ unsigned number_of_regs;
+ bool * is_occupied;
+ unsigned occupied_space_in_column[4];
+ unsigned producer_offset, consumer_offset;
+ exec_list *stored_vars[8];
+
+
+ #define ARGMAX(i, j) (occupied_space_in_column[(i)] >=
occupied_space_in_column[(j)])?(i):(j)
+ #define ARGMIN(i, j) (occupied_space_in_column[(i)] >=
occupied_space_in_column[(j)])?(j):(i)
+
+ /**
+* Order index from most occupied column index to least occupied column
index
+*/
+ void order(unsigned reordered[4]) const
+ {
+ unsigned mx1 = ARGMAX(0, 1), mx2 = ARGMAX(2, 3);
+ unsigned mn1 = ARGMIN(0, 1), mn2 = ARGMIN(2, 3);
+
+ reordered[0] = ARGMAX(mx1, mx2);
+ unsigned semi_max = ARGMIN(mx1, mx2);
+ reordered[3] = ARGMIN(mn1, mn2);
+ unsigned semi_min = ARGMAX(mn1, mn2);
+ reordered[1] = ARGMAX(semi_max, semi_min);
+ reordered[2] = ARGMIN(semi_min, semi_max);
+ }
+
+ #undef ARGMAX
+ #undef ARGMIN
+
+ INLINE
+ bool& is_occupied_ref(unsigned index, unsigned components)
+ {
+ assert (components < 4 && index < number_of_regs);
+ return is_occupied[4 * index + components];
+ }
+
+ bool is_range_free(unsigned reg, unsigned component_start, unsigned
row_occupied, unsigned components_occupied)
+ {
+
+ if (component_start + components_occupied - 1 > 3)
+ return false;
+ if (reg + row_occupied - 1 > number_of_regs - 1)
+ return false;
+ for (unsigned j = 0; j < row_occupied; j++) {
+
[Mesa-dev] [PATCH] glsl: Modify glsl-max-varyings to test varying packing
---
tests/shaders/CMakeLists.gl.txt |1 +
tests/shaders/glsl-max-varyings-2.c | 413 +++
2 files changed, 414 insertions(+), 0 deletions(-)
create mode 100644 tests/shaders/glsl-max-varyings-2.c
diff --git a/tests/shaders/CMakeLists.gl.txt b/tests/shaders/CMakeLists.gl.txt
index 9d72260..b00219e 100644
--- a/tests/shaders/CMakeLists.gl.txt
+++ b/tests/shaders/CMakeLists.gl.txt
@@ -143,6 +143,7 @@ add_executable (vp-ignore-input vp-ignore-input.c)
add_executable (glsl-empty-vs-no-fs glsl-empty-vs-no-fs.c)
add_executable (glsl-mat-attribute glsl-mat-attribute.c)
add_executable (glsl-max-varyings glsl-max-varyings.c)
+add_executable (glsl-max-varyings-2 glsl-max-varyings-2.c)
add_executable (glsl-useprogram-displaylist glsl-useprogram-displaylist.c)
add_executable (glsl-routing glsl-routing.c)
add_executable (shader_runner shader_runner.c)
diff --git a/tests/shaders/glsl-max-varyings-2.c
b/tests/shaders/glsl-max-varyings-2.c
new file mode 100644
index 000..ce2767a
--- /dev/null
+++ b/tests/shaders/glsl-max-varyings-2.c
@@ -0,0 +1,413 @@
+/*
+ * Copyright © 2010 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Eric Anholt
+ *
+ */
+
+/** @file glsl-max-varyings.c
+ *
+ * Tests whether GL_MAX_VARYING_FLOATS varying components can be used when
packed
+ * as vec4, vec3, vec2, or float. Drivers have to pack varyings to pass this
test.
+ */
+
+#include "piglit-util.h"
+
+#define MAX_VARYING 128
+
+/* 10x10 rectangles with 2 pixels of pad. Deal with up to 32 varyings. */
+int piglit_width = (2 + MAX_VARYING * 12), piglit_height = (2 + MAX_VARYING *
12);
+int piglit_window_mode = GLUT_RGB | GLUT_DOUBLE;
+
+
+enum varyings_type {
+ FLT = 0,
+ V2 = 1,
+ V3 = 2,
+ V4 = 3
+};
+
+const unsigned increments[] = { 4, 2, 2, 1 };
+
+/* Generate a VS that writes to num_varyings vec4s, and put
+ * interesting data in data_varying with 0.0 everywhere else.
+ */
+static GLint get_vs(int num_varyings, int data_varying, enum varyings_type
type)
+{
+
+ const char * varying_decl[] = {
+ "varying float v%d;\n",
+ "varying vec2 v%d;\n",
+ "varying vec3 v%d;\n",
+ "varying vec4 v%d;\n",
+ };
+
+ GLuint shader;
+ unsigned i;
+ char *code;
+ char temp[2048];
+
+ code = malloc(2048 * 4);
+ code[0] = 0;
+ for (i = 0; i < num_varyings; i++) {
+sprintf(temp, varying_decl[type], i);
+ strcat(code, temp);
+ }
+
+ sprintf(temp,
+ "attribute vec4 green;\n"
+ "attribute float v_zero;\n"
+ "void main()\n"
+ "{\n"
+ " gl_Position = (gl_ModelViewProjectionMatrix * \n"
+ " gl_Vertex);\n"
+ );
+ strcat(code, temp);
+ i = 0;
+ while (i + increments[type] < num_varyings) {
+ if (i == data_varying) {
+ switch (type) {
+ case FLT:
+ sprintf(temp,
+ "v%d = green.x;\n"
+ "v%d = green.y;\n"
+ "v%d = green.z;\n"
+ "v%d = green.w;\n",
+ i,
+ i + 1,
+ i + 2,
+ i + 3);
+ break;
+ case V2:
+ sprintf(temp,
+ "v%d = green.xy;\n"
+ "v%d = green.zw;\n",
+ i,
+ i + 1);
+ break;
+ case V3:
+ sprintf(temp,
+ "v%d = green.xyz;\n"
+ "v%d.x = green.w;\n",
+ i,
+ i + 1);
+
[Mesa-dev] [Bug 45571] fatal error: program/symbol_table.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=45571 --- Comment #10 from Kenneth Graunke 2012-02-05 14:19:44 PST --- (In reply to comment #8) > After a closer look I noticed that the error I get isn't exactly the same as > the one mentioned by Alexandre Demers: > --- > In file included from glsl_parser_extras.h:35:0, > from ast.h:30, > from glsl_lexer.ll:27: > glsl_symbol_table.h:29:15: fatal error: new: No such file or directory > compilation terminated. > make[2]: *** [glsl_lexer.o] Error 1 > --- Uh. Sounds like it's not using a C++ compiler... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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] vbo: Ignore invalid element ranges if fixing 'end' breaks 'start'.
FWIW, I think there are some more errors (wrt base index) in that function: http://lists.freedesktop.org/archives/mesa-dev/2012-January/018306.html (I agree though there's a difference if the bounds would point to vertices outside the array or the bounds are so bogus that no index can be in the specified range, which is all we can do for detecting indices outside the range without scanning the indices.) Roland Am 04.02.2012 14:03, schrieb Jose Fonseca: > Hi Kenneth, > > I agree with the behavior change for compatability sake, but I think there's > a distinction to be made here in the warnings passed to the user. > > > The spec says the app supplied [start, end] range are supposed to be > conservative hints of the ranges of index value in the index buffer, i.e, all > values in the index buffer should be inside [start, end]. In particular > http://www.opengl.org/sdk/docs/man/xhtml/glDrawRangeElements.xml says: "There > is no requirement that all vertices in the range start end be referenced." > > > Passing an end value bigger than the maximum representable index is perfectly > fine and conformant behavior as the above rule is preserved. For example, an > app developer may set the end to 0xfff when they don't have that value > readily available. Mesa will emit a warning but it is being pedantic, > because it really should handle glDrawRangeElements(..., 0, 0xfff) > _exactly_ the same way as glDrawElements(...). > > > Passing start value that is above the vertex arrays size is clearly _not_ > conformant behavior. > > > IMO, over-generous `end` index, and totally bogus `start` are in totally > different scales of bad. The former should be worded as a performance hint, > or even removed, while the latter should be clearly marked as an error. > > > Jose > > > - Original Message - >> Certain applications, such as Regnum Online, appear to pass invalid >> start/end values to glDrawRangeElements. In particular, the 'end' >> index >> sometimes exceeds the maximum array element. >> >> In this case, we issued a warning and attempted to "fix" the end >> value >> by clamping it to the last array element. Then we re-checked whether >> end < start (which would normally result in an API error), and if so, >> dropped the call on the floor. >> >> This seems foolish: if 'end' is invalid, why should we trust 'start'? >> The application has already proven that it can't track these things. >> >> This patch takes a more conservative approach: >> 1. Force 'end' to be the maximum array element. >> 2. If end < start, assume both bounds were rubbish and discard them, >>treating the call as an ordinary glDrawElements(). >> >> This should allow more broken applications to work, while preserving >> the >> useful "This should probably be fixed in the application" warning. >> >> NOTE: This is a candidate for release branches. >> >> Cc: Mateusz Kaduk >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45214 >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44701 >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41152 >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40361 >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28138 >> Signed-off-by: Kenneth Graunke >> --- >> src/mesa/vbo/vbo_exec_array.c |7 ++- >> 1 files changed, 6 insertions(+), 1 deletions(-) >> >> Originally, I thought we must be doing something wrong, as I saw this >> message in some Unigine demos, Regnum Online, and even an oglconform >> test case. >> >> It looks like the oglconform test case is indeed specifying an 'end' >> value way larger than the buffer size, which is wrong (though the GL >> isn't required to raise an error.) >> >> I've also gone through the _MaxElement calculations and convinced >> myself that they're correct. Regnum is also passing us a range >> that's _completely_ outside of the buffer---both start and end are >> past _MaxElement. A small miscalculation wouldn't account for this. >> >> I also did some googling and found a bunch of bug reports about this >> where application authors were told about this warning and did appear >> to find and fix bugs in their application. >> >> So, at the end of the day, I think these apps are broken, but since >> we're already working around them, we may as well make them work. >> >> I'd appreciate review since this is my first foray into VBO land. >> The ~0's match what vbo_exec_DrawElements uses, so I feel pretty >> safe. >> >> Tested on Sandybridge. No regressions in Piglit's >> quick-driver.tests, >> the Khronos ES 2.0 test suite, or the vao tests in Intel's >> oglconform. >> >> diff --git a/src/mesa/vbo/vbo_exec_array.c >> b/src/mesa/vbo/vbo_exec_array.c >> index d6b4d61..8a3be1b 100644 >> --- a/src/mesa/vbo/vbo_exec_array.c >> +++ b/src/mesa/vbo/vbo_exec_array.c >> @@ -937,7 +937,12 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum >> mode, >>end = ctx->Array.ArrayObj->_MaxElement - 1; >> >>if
Re: [Mesa-dev] [PATCH] mesa: fixes for DrawRangeElements[BaseVertex] index validation
Sorry didn't see this response previously, threading didn't seem to work.
Am 04.02.2012 12:40, schrieb Kenneth Graunke:
> On 01/27/2012 06:00 PM, Roland Scheidegger wrote:
>> in check_index_bounds the comparison needs to be "greater equal" since
>> contrary to the name _MaxElement is the count of the array.
>> In vbo_exec_DrawRangeElementsBaseVertex, take into account the
>> basevertex.
>> As far as I can tell it is completely ok (though maybe stupid) to have
>> start/end of 100/199, with _MaxElement being 100, if the basevertex
>> is -100 (since the start/end are prior to adding basevertex). The
>> opposite
>> is also true (0/99 is not ok if _MaxElement is 100 and and basevertex
>> is 100).
>> Previously we would have issued a warning in such cases and worse
>> probably
>> "fixed" end to a bogus value.
>> Totally untested, found by code inspection when looking at bug 40361
>> (which
>> seems unrelated after all).
>> ---
>> src/mesa/main/api_validate.c |2 +-
>> src/mesa/vbo/vbo_exec_array.c | 30 +++---
>> 2 files changed, 20 insertions(+), 12 deletions(-)
>>
>> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
>> index b6871d0..1ae491f 100644
>> --- a/src/mesa/main/api_validate.c
>> +++ b/src/mesa/main/api_validate.c
>> @@ -187,7 +187,7 @@ check_index_bounds(struct gl_context *ctx, GLsizei
>> count, GLenum type,
>> vbo_get_minmax_indices(ctx,&prim,&ib,&min,&max, 1);
>>
>> if ((int)(min + basevertex)< 0 ||
>> - max + basevertex> ctx->Array.ArrayObj->_MaxElement) {
>> + max + basevertex>= ctx->Array.ArrayObj->_MaxElement) {
>> /* the max element is out of bounds of one or more enabled
>> arrays */
>> _mesa_warning(ctx, "glDrawElements() index=%u is out of bounds
>> (max=%u)",
>> max, ctx->Array.ArrayObj->_MaxElement);
>
> I might split this hunk out into a separate patch. This hunk is:
> Reviewed-by: Kenneth Graunke
>
> And yeah, _MaxElement does make me think "index of the last element"
> (N-1), not "the total number of elements" (N). I'm not a fan of the name.
Ok I'll commit this.
>
>> diff --git a/src/mesa/vbo/vbo_exec_array.c
>> b/src/mesa/vbo/vbo_exec_array.c
>> index 9861b21..3e0fe20 100644
>> --- a/src/mesa/vbo/vbo_exec_array.c
>> +++ b/src/mesa/vbo/vbo_exec_array.c
>> @@ -885,17 +885,18 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
>> end = MIN2(end, 0x);
>> }
>>
>> - if (end>= ctx->Array.ArrayObj->_MaxElement) {
>> + if ((int)(start + basevertex)< 0 ||
>> + end + basevertex>= ctx->Array.ArrayObj->_MaxElement) {
>> /* the max element is out of bounds of one or more enabled
>> arrays */
>> warnCount++;
>>
>> if (warnCount< 10) {
>> - _mesa_warning(ctx, "glDraw[Range]Elements(start %u, end %u,
>> count %d, "
>> - "type 0x%x, indices=%p)\n"
>> + _mesa_warning(ctx, "glDrawRangeElements[BaseVertex](start
>> %u, end %u, count %d, "
>> + "type 0x%x, indices=%p, base %d)\n"
>> "\tend is out of bounds (max=%u) "
>> "Element Buffer %u (size %d)\n"
>> "\tThis should probably be fixed in the
>> application.",
>> - start, end, count, type, indices,
>> + start, end, count, type, indices, basevertex,
>> ctx->Array.ArrayObj->_MaxElement - 1,
>>
>> ctx->Array.ArrayObj->ElementArrayBufferObj->Name,
>> (int)
>> ctx->Array.ArrayObj->ElementArrayBufferObj->Size);
>> @@ -913,14 +914,14 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
>> if (0) {
>>GLuint max = _mesa_max_buffer_index(ctx, count, type, indices,
>>
>> ctx->Array.ArrayObj->ElementArrayBufferObj);
>> - if (max>= ctx->Array.ArrayObj->_MaxElement) {
>> + if (max + basevertex>= ctx->Array.ArrayObj->_MaxElement) {
>> if (warnCount< 10) {
>> - _mesa_warning(ctx, "glDraw[Range]Elements(start %u,
>> end %u, "
>> - "count %d, type 0x%x, indices=%p)\n"
>> + _mesa_warning(ctx,
>> "glDrawRangeElements[BaseVertex](start %u, end %u, "
>> + "count %d, type 0x%x, indices=%p, base
>> %d)\n"
>>"\tindex=%u is out of bounds (max=%u) "
>>"Element Buffer %u (size %d)\n"
>>"\tSkipping the glDrawRangeElements()
>> call",
>> - start, end, count, type, indices, max,
>> + start, end, count, type, indices,
>> basevertex, max,
>>ctx->Array.ArrayObj->_MaxElement - 1,
>>
>> ctx->Array.ArrayObj->ElementArrayBufferObj->Name,
>>
[Mesa-dev] [Bug 45660] New: shared-glapi breaks glapi dispatch table
https://bugs.freedesktop.org/show_bug.cgi?id=45660 Bug #: 45660 Summary: shared-glapi breaks glapi dispatch table Classification: Unclassified Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: olva...@gmail.com ReportedBy: matts...@gmail.com CC: jon.tur...@dronecode.org.uk, mesa-dev@lists.freedesktop.org http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg18155.html Building with --enable-shared-glapi breaks the dispatch table, see Jon's email above. To test, configure with ./autogen.sh --enable-xlib-glx --disable-egl --disable-glu --disable-dri --with-gallium-drivers= and run fbotexture from mesa demos. Next, configure with ./autogen.sh --enable-xlib-glx --disable-egl --disable-glu --disable-dri --with-gallium-drivers= --enable-shared-glapi and run fbotexture. It will fail with GL_RENDERER = Mesa X11 Unable to create/attach depth and stencil renderbuffers to FBO! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: fixes for DrawRangeElements[BaseVertex] index validation
In vbo_exec_DrawRangeElementsBaseVertex, take into account the basevertex.
As far as I can tell it is completely ok (though maybe stupid) to have
start/end of 100/199, with _MaxElement being 100, if the basevertex
is -100 (since the start/end are prior to adding basevertex). The opposite
is also true (0/99 is not ok if _MaxElement is 100 and and basevertex is 100).
Previously we would have issued a warning in such cases and worse probably
"fixed" end to a bogus value.
Untested, found by code inspection when looking at bug 40361 (which
seems unrelated after all).
v2: As per mailing list discussion and the suggestion by Kenneth Graunke just
drop
the questionable effort to fix up the range and revert to have no range instead.
Rearrange some (disabled) debug bits a bit for slightly less complex code.
---
src/mesa/vbo/vbo_exec_array.c | 63 +++-
1 files changed, 30 insertions(+), 33 deletions(-)
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index d6b4d61..1f62e3a 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -885,17 +885,33 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
end = MIN2(end, 0x);
}
- if (end >= ctx->Array.ArrayObj->_MaxElement) {
- /* the max element is out of bounds of one or more enabled arrays */
+ if (0) {
+ printf("glDrawRangeElements{,BaseVertex}"
+"(start %u, end %u, type 0x%x, count %d) ElemBuf %u, "
+"base %d\n",
+start, end, type, count,
+ctx->Array.ArrayObj->ElementArrayBufferObj->Name,
+basevertex);
+ }
+
+#if 0
+ check_draw_elements_data(ctx, count, type, indices);
+#else
+ (void) check_draw_elements_data;
+#endif
+
+ if ((int)(start + basevertex) < 0 ||
+ end + basevertex >= ctx->Array.ArrayObj->_MaxElement) {
+ /* the max (or min) element is out of bounds of one or more enabled
arrays */
warnCount++;
if (warnCount < 10) {
- _mesa_warning(ctx, "glDraw[Range]Elements(start %u, end %u, count %d,
"
- "type 0x%x, indices=%p)\n"
+ _mesa_warning(ctx, "glDrawRangeElements[BaseVertex](start %u, end %u,
count %d, "
+ "type 0x%x, indices=%p, base %d)\n"
"\tend is out of bounds (max=%u) "
"Element Buffer %u (size %d)\n"
"\tThis should probably be fixed in the application.",
- start, end, count, type, indices,
+ start, end, count, type, indices, basevertex,
ctx->Array.ArrayObj->_MaxElement - 1,
ctx->Array.ArrayObj->ElementArrayBufferObj->Name,
(int) ctx->Array.ArrayObj->ElementArrayBufferObj->Size);
@@ -913,14 +929,14 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
if (0) {
GLuint max = _mesa_max_buffer_index(ctx, count, type, indices,
ctx->Array.ArrayObj->ElementArrayBufferObj);
- if (max >= ctx->Array.ArrayObj->_MaxElement) {
+ if (max + basevertex >= ctx->Array.ArrayObj->_MaxElement) {
if (warnCount < 10) {
- _mesa_warning(ctx, "glDraw[Range]Elements(start %u, end %u, "
- "count %d, type 0x%x, indices=%p)\n"
+ _mesa_warning(ctx, "glDrawRangeElements[BaseVertex](start %u,
end %u, "
+ "count %d, type 0x%x, indices=%p, base %d)\n"
"\tindex=%u is out of bounds (max=%u) "
"Element Buffer %u (size %d)\n"
"\tSkipping the glDrawRangeElements() call",
- start, end, count, type, indices, max,
+ start, end, count, type, indices, basevertex, max,
ctx->Array.ArrayObj->_MaxElement - 1,
ctx->Array.ArrayObj->ElementArrayBufferObj->Name,
(int)
ctx->Array.ArrayObj->ElementArrayBufferObj->Size);
@@ -928,34 +944,15 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode,
}
/* XXX we could also find the min index and compare to 'start'
* to see if start is correct. But it's more likely to get the
- * upper bound wrong.
+ * upper bound wrong, at least for the non-BaseVertex variant...
*/
}
-
- /* Set 'end' to the max possible legal value */
- assert(ctx->Array.ArrayObj->_MaxElement >= 1);
- end = ctx->Array.ArrayObj->_MaxElement - 1;
-
- if (end < start) {
- return;
- }
- }
-
- if (0) {
- printf("glDraw[Range]Elements{,BaseVertex}"
-"(start %u, end %u, type 0x%x, count %d) ElemBuf %u, "
-"base %d\n",
-start, end, type, count,
-ctx->Array.ArrayObj->ElementArrayBufferObj->N
[Mesa-dev] [Bug 45571] fatal error: program/symbol_table.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=45571 --- Comment #11 from Jos van Wolput 2012-02-05 20:56:16 PST --- (In reply to comment #10) > Uh. Sounds like it's not using a C++ compiler... I was using gcc-4.7 version 4.7-20120205-1:amd64 from Debian Experimental. Reverting to gcc-4.6 (4.6.2-12) solves this issue. The issue started some days ago presumably after the latest upgrade of gcc-4.7. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 45571] fatal error: program/symbol_table.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=45571 --- Comment #12 from Jos van Wolput 2012-02-05 23:57:18 PST --- Correction: I mentioned a wrong gcc-4.7 version. I was using gcc-4.7 version 4.7-20120129-1 which caused the issue, after upgrading to 4.7-20120205-1 (debian experimental) [trunk revision 183903] no more compilation problems. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
