[Mesa-dev] [PATCH] mesa: remove _mesa_symbol_table_iterator structure
Nothing uses this structure, removal fixes Klocwork error about
the possible oom condition in _mesa_symbol_table_iterator_ctor.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/program/symbol_table.c | 86 -
src/mesa/program/symbol_table.h | 13 ---
2 files changed, 99 deletions(-)
diff --git a/src/mesa/program/symbol_table.c b/src/mesa/program/symbol_table.c
index 4f6f31f..2f41322 100644
--- a/src/mesa/program/symbol_table.c
+++ b/src/mesa/program/symbol_table.c
@@ -112,24 +112,6 @@ struct _mesa_symbol_table {
};
-struct _mesa_symbol_table_iterator {
-/**
- * Name space of symbols returned by this iterator.
- */
-int name_space;
-
-
-/**
- * Currently iterated symbol
- *
- * The next call to \c _mesa_symbol_table_iterator_get will return this
- * value. It will also update this value to the value that should be
- * returned by the next call.
- */
-struct symbol *curr;
-};
-
-
static void
check_symbol_table(struct _mesa_symbol_table *table)
{
@@ -201,74 +183,6 @@ find_symbol(struct _mesa_symbol_table *table, const char
*name)
}
-struct _mesa_symbol_table_iterator *
-_mesa_symbol_table_iterator_ctor(struct _mesa_symbol_table *table,
- int name_space, const char *name)
-{
-struct _mesa_symbol_table_iterator *iter = calloc(1, sizeof(*iter));
-struct symbol_header *const hdr = find_symbol(table, name);
-
-iter-name_space = name_space;
-
-if (hdr != NULL) {
-struct symbol *sym;
-
-for (sym = hdr-symbols; sym != NULL; sym = sym-next_with_same_name) {
-assert(sym-hdr == hdr);
-
-if ((name_space == -1) || (sym-name_space == name_space)) {
-iter-curr = sym;
-break;
-}
-}
-}
-
-return iter;
-}
-
-
-void
-_mesa_symbol_table_iterator_dtor(struct _mesa_symbol_table_iterator *iter)
-{
-free(iter);
-}
-
-
-void *
-_mesa_symbol_table_iterator_get(struct _mesa_symbol_table_iterator *iter)
-{
-return (iter-curr == NULL) ? NULL : iter-curr-data;
-}
-
-
-int
-_mesa_symbol_table_iterator_next(struct _mesa_symbol_table_iterator *iter)
-{
-struct symbol_header *hdr;
-
-if (iter-curr == NULL) {
-return 0;
-}
-
-hdr = iter-curr-hdr;
-iter-curr = iter-curr-next_with_same_name;
-
-while (iter-curr != NULL) {
-assert(iter-curr-hdr == hdr);
-(void)hdr;
-
-if ((iter-name_space == -1)
-|| (iter-curr-name_space == iter-name_space)) {
-return 1;
-}
-
-iter-curr = iter-curr-next_with_same_name;
-}
-
-return 0;
-}
-
-
/**
* Determine the scope distance of a symbol from the current scope
*
diff --git a/src/mesa/program/symbol_table.h b/src/mesa/program/symbol_table.h
index f9d9164..1027f47 100644
--- a/src/mesa/program/symbol_table.h
+++ b/src/mesa/program/symbol_table.h
@@ -24,7 +24,6 @@
#define MESA_SYMBOL_TABLE_H
struct _mesa_symbol_table;
-struct _mesa_symbol_table_iterator;
extern void _mesa_symbol_table_push_scope(struct _mesa_symbol_table *table);
@@ -47,16 +46,4 @@ extern struct _mesa_symbol_table
*_mesa_symbol_table_ctor(void);
extern void _mesa_symbol_table_dtor(struct _mesa_symbol_table *);
-extern struct _mesa_symbol_table_iterator *_mesa_symbol_table_iterator_ctor(
-struct _mesa_symbol_table *table, int name_space, const char *name);
-
-extern void _mesa_symbol_table_iterator_dtor(
-struct _mesa_symbol_table_iterator *);
-
-extern void *_mesa_symbol_table_iterator_get(
-struct _mesa_symbol_table_iterator *iter);
-
-extern int _mesa_symbol_table_iterator_next(
-struct _mesa_symbol_table_iterator *iter);
-
#endif /* MESA_SYMBOL_TABLE_H */
--
1.8.5.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gbm: export gbm_device_is_format_supported
Probably depending on compiler settings, the definition can be hidden,
so undefined reference error can be encountred during linking
https://bugs.freedesktop.org/show_bug.cgi?id=75528
---
src/gbm/main/gbm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 7a4e406..b057386 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -81,7 +81,7 @@ gbm_device_get_backend_name(struct gbm_device *gbm)
*
* \sa enum gbm_bo_format for the list of formats
*/
-int
+GBM_EXPORT int
gbm_device_is_format_supported(struct gbm_device *gbm,
uint32_t format, uint32_t usage)
{
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Assert array index on access to vec4_visitor's arrays.
On 02/27/2014 12:30 AM, Ian Romanick wrote: Did you piglit run this? I applied it on current master, and about 2,700 piglit tests assert. Yes, at the time there were no piglit errors. Confirmed, the patch series breaks current master. Not to mention it doesn't apply cleanly anymore anyway, new series required. diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp b/src/mesa/drivers/dri/i965/brw_vec4.cpp index fb57707..4dc0482 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp @@ -411,6 +411,7 @@ vec4_visitor::pack_uniform_registers() /* Now, figure out a packing of the live uniform vectors into our * push constants. */ + assert(uniforms uniform_array_size); All of the tests that I looked at (about a dozen) hit this assertion. From tests/quick, with some grepping and processing on piglit result json directly, all those assert failures are this one. *quick debugging build later* And all those asserts hit because uniforms == uniform_array_size. Fix is on the way. -- Petri Latvala ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 63717] Poor performance in games with Intel 965GM
https://bugs.freedesktop.org/show_bug.cgi?id=63717 --- Comment #3 from Kenneth Graunke kenn...@whitecape.org --- I suspect that upgrading to Mesa 10.1 (due to be released in a few days) should help quite a bit, though I haven't measured it. In particular, Matt's vectorizer work reduces sequences of 4 extended math operations down to 1. On 965GM, extended math is done on a single mathbox shared across all EUs (IIRC), so reducing math usage should have a significant impact on performance. -- 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] [PATCHv4 2/3] glx_pbuffer: Refactor GetDrawableAttribute
Am 27.02.2014 03:14, schrieb Jason Wood:
On 02/26/2014 06:55 PM, Ian Romanick wrote:
On 02/26/2014 05:22 PM, Jason Wood wrote:
On 02/26/2014 04:27 PM, Adel Gadllah wrote:
Move the pdraw != NULL check out so that they don't
have to be duplicated.
Signed-off-by: Adel Gadllah adel.gadl...@gmail.com
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/glx/glx_pbuffer.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index 411d6e5..978730c 100644
--- a/src/glx/glx_pbuffer.c
+++ b/src/glx/glx_pbuffer.c
@@ -350,6 +350,9 @@ GetDrawableAttribute(Display * dpy, GLXDrawable
drawable,
_XEatData(dpy, length);
}
else {
+#if defined(GLX_DIRECT_RENDERING) !defined(GLX_USE_APPLEGL)
+ __GLXDRIdrawable *pdraw = GetGLXDRIDrawable(dpy, drawable);
+#endif
What is the point of moving the declaration of pdraw into a separate
ifdef from the only one it is used in? It seems to me that this change
only serves to make the code less readable.
This was my recommendation. It eliminates needing to add yet another
level of indentation below... especially with patch 3/3 on top of it.
That is fair. I should have taken a closer look at 3/3 before commenting.
However, patch 3/3 again moves the declaration for pdraw -- to the top
of the function. Why move the declaration twice? No need for the extra
code churn...
Well I could move it to the top in the second patch as well but the thing is it does not make much sense to move it to
the top while being only used in the else branch ...
Patch 3/3 moves it to the top because it does not have to do the round trip
(everything can be done at the client side).
So its not really extra code churn but changes that more or less make sense
in isolation.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 74010] mesa-10.0.2: z-buffer issue with opengl 3.3 context on intel
https://bugs.freedesktop.org/show_bug.cgi?id=74010 Evgeny Bobkin evgen.i...@gmail.com changed: What|Removed |Added Attachment #92718|text/plain |video/webm mime type|| -- 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 74010] mesa-10.0.2: z-buffer issue with opengl 3.3 context on intel
https://bugs.freedesktop.org/show_bug.cgi?id=74010 --- Comment #7 from Evgeny Bobkin evgen.i...@gmail.com --- Thank you for the explanation, maybe your are correct. From my point of view it should definitely not end up with a segmentation fault. (In reply to comment #6) I've encountered this segfault before, and i think i can give some useful informations. ... For the overlapping triangles problem, i've never seen that before... so maybe it is a problem in your code. maybe, therefore I have attached a simple test case demonstrating the issue. Moreover, this simple test case works fine as expected within the opengl 3.0 context and with other proprietary drivers (ati, nvidia) as well -- 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] [PATCH 1/2] i965: Allocate vec4_visitor's uniform_size and uniform_vector_size arrays dynamically.
v2: Don't add function parameters, pass the required size in
prog_data-nr_params.
v3:
- Use the name uniform_array_size instead of uniform_param_count.
- Round up when dividing param_count by 4.
- Use MAX2() instead of taking the maximum by hand.
- Don't crash if prog_data passed to vec4_visitor constructor is NULL
v4: Rebase for current master
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71254
Signed-off-by: Petri Latvala petri.latv...@intel.com
---
src/mesa/drivers/dri/i965/brw_vec4.h | 5 +++--
src/mesa/drivers/dri/i965/brw_vec4_gs.c| 5 +
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 11 +++
src/mesa/drivers/dri/i965/brw_vs.c | 8
4 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/i965/brw_vec4.h
index fb5c0a6..d97c103 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -387,8 +387,9 @@ public:
*/
dst_reg output_reg[BRW_VARYING_SLOT_COUNT];
const char *output_reg_annotation[BRW_VARYING_SLOT_COUNT];
- int uniform_size[MAX_UNIFORMS];
- int uniform_vector_size[MAX_UNIFORMS];
+ int *uniform_size;
+ int *uniform_vector_size;
+ int uniform_array_size; /* Size of uniform_[vector_]size arrays */
int uniforms;
src_reg shader_start_time;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs.c
b/src/mesa/drivers/dri/i965/brw_vec4_gs.c
index 85fb979..8a9625b 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs.c
@@ -68,6 +68,11 @@ do_gs_prog(struct brw_context *brw,
rzalloc_array(NULL, const float *, param_count);
c.prog_data.base.base.pull_param =
rzalloc_array(NULL, const float *, param_count);
+ /* Setting nr_params here NOT to the size of the param and pull_param
+* arrays, but to the number of uniform components vec4_visitor
+* needs. vec4_visitor::setup_uniforms() will set it back to a proper value.
+*/
+ c.prog_data.base.base.nr_params = ALIGN(param_count, 4) / 4 +
gs-num_samplers;
if (gp-program.OutputType == GL_POINTS) {
/* When the output type is points, the geometry shader may output data
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index aedab93..cc92a8a 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -3401,6 +3401,17 @@ vec4_visitor::vec4_visitor(struct brw_context *brw,
this-max_grf = brw-gen = 7 ? GEN7_MRF_HACK_START : BRW_MAX_GRF;
this-uniforms = 0;
+
+ /* Initialize uniform_array_size to at least 1 because pre-gen6 VS requires
+* at least one. See setup_uniforms() in brw_vec4.cpp.
+*/
+ this-uniform_array_size = 1;
+ if (prog_data) {
+ this-uniform_array_size = MAX2(stage_prog_data-nr_params, 1);
+ }
+
+ this-uniform_size = rzalloc_array(mem_ctx, int, this-uniform_array_size);
+ this-uniform_vector_size = rzalloc_array(mem_ctx, int,
this-uniform_array_size);
}
vec4_visitor::~vec4_visitor()
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c
b/src/mesa/drivers/dri/i965/brw_vs.c
index d3dbc8e..ef8dcf1 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -235,6 +235,14 @@ do_vs_prog(struct brw_context *brw,
stage_prog_data-param = rzalloc_array(NULL, const float *, param_count);
stage_prog_data-pull_param = rzalloc_array(NULL, const float *,
param_count);
+ /* Setting nr_params here NOT to the size of the param and pull_param
+* arrays, but to the number of uniform components vec4_visitor
+* needs. vec4_visitor::setup_uniforms() will set it back to a proper value.
+*/
+ stage_prog_data-nr_params = ALIGN(param_count, 4) / 4;
+ if (vs) {
+ stage_prog_data-nr_params += vs-num_samplers;
+ }
GLbitfield64 outputs_written = vp-program.Base.OutputsWritten;
prog_data.inputs_read = vp-program.Base.InputsRead;
--
1.8.4.rc3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/2] v5: Fix array overrun with too many uniforms
Fixing https://bugs.freedesktop.org/show_bug.cgi?id=71254 once again. Rebased for current master, plumbing-class changes to patch 1/2. Fixed one of the asserts in patch 2/2. Full piglit run shows no regressions. Petri Latvala (2): i965: Allocate vec4_visitor's uniform_size and uniform_vector_size arrays dynamically. i965: Assert array index on access to vec4_visitor's arrays. src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 ++ src/mesa/drivers/dri/i965/brw_vec4.h | 5 +++-- src/mesa/drivers/dri/i965/brw_vec4_gs.c| 5 + src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 17 + src/mesa/drivers/dri/i965/brw_vs.c | 8 5 files changed, 35 insertions(+), 2 deletions(-) -- 1.8.4.rc3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965: Assert array index on access to vec4_visitor's arrays.
v2: vec4_visitor::pack_uniform_registers(): Use correct comparison in the
assert, this-uniforms is already adjusted. Compare the actual value used to
index uniform_size and uniform_vector_size instead.
Signed-off-by: Petri Latvala petri.latv...@intel.com
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 ++
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 6 ++
2 files changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index fcb7365..c30afae 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -422,6 +422,7 @@ vec4_visitor::pack_uniform_registers()
* push constants.
*/
for (int src = 0; src uniforms; src++) {
+ assert(src uniform_array_size);
int size = this-uniform_vector_size[src];
if (!uniform_used[src]) {
@@ -1404,6 +1405,7 @@ vec4_visitor::setup_uniforms(int reg)
* matter what, or the GPU would hang.
*/
if (brw-gen 6 this-uniforms == 0) {
+ assert(this-uniforms this-uniform_array_size);
this-uniform_vector_size[this-uniforms] = 1;
stage_prog_data-param =
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index cc92a8a..88ee929 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -664,6 +664,7 @@ vec4_visitor::setup_uniform_values(ir_variable *ir)
storage-type-matrix_columns);
for (unsigned s = 0; s vector_count; s++) {
+ assert(uniforms uniform_array_size);
uniform_vector_size[uniforms] = storage-type-vector_elements;
int i;
@@ -687,6 +688,7 @@ vec4_visitor::setup_uniform_clipplane_values()
gl_clip_plane *clip_planes = brw_select_clip_planes(ctx);
for (int i = 0; i key-nr_userclip_plane_consts; ++i) {
+ assert(this-uniforms uniform_array_size);
this-uniform_vector_size[this-uniforms] = 4;
this-userplane[i] = dst_reg(UNIFORM, this-uniforms);
this-userplane[i].type = BRW_REGISTER_TYPE_F;
@@ -717,6 +719,7 @@ vec4_visitor::setup_builtin_uniform_values(ir_variable *ir)
(gl_state_index *)slots[i].tokens);
float *values = this-prog-Parameters-ParameterValues[index][0].f;
+ assert(this-uniforms uniform_array_size);
this-uniform_vector_size[this-uniforms] = 0;
/* Add each of the unique swizzled channels of the element.
* This will end up matching the size of the glsl_type of this field.
@@ -727,6 +730,7 @@ vec4_visitor::setup_builtin_uniform_values(ir_variable *ir)
last_swiz = swiz;
stage_prog_data-param[this-uniforms * 4 + j] = values[swiz];
+assert(this-uniforms uniform_array_size);
if (swiz = last_swiz)
this-uniform_vector_size[this-uniforms]++;
}
@@ -976,6 +980,7 @@ vec4_visitor::visit(ir_variable *ir)
/* Track how big the whole uniform variable is, in case we need to put a
* copy of its data into pull constants for array access.
*/
+ assert(this-uniforms uniform_array_size);
this-uniform_size[this-uniforms] = type_size(ir-type);
if (!strncmp(ir-name, gl_, 3)) {
@@ -3302,6 +3307,7 @@
vec4_visitor::move_uniform_array_access_to_pull_constants()
pull_constant_loc[uniform] = stage_prog_data-nr_pull_params / 4;
+ assert(uniform uniform_array_size);
for (int j = 0; j uniform_size[uniform] * 4; j++) {
stage_prog_data-pull_param[stage_prog_data-nr_pull_params++]
= values[j];
--
1.8.4.rc3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gbm: export gbm_device_is_format_supported
On 27/02/14 08:23, Marek Chalupa wrote:
Probably depending on compiler settings, the definition can be hidden,
so undefined reference error can be encountred during linking
When building with automake, the definition will be hidden if the
compiler supports visibility flags. This was done with an earlier patch
that adds them for the gbm target. The patch is only present in master
so the stable branches are safe on that regard.
This symbol fell short when I was going through the gbm api, thanks for
catching that.
Reviewed-by: Emil Velikov emil.l.veli...@gmail.com
https://bugs.freedesktop.org/show_bug.cgi?id=75528
---
src/gbm/main/gbm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 7a4e406..b057386 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -81,7 +81,7 @@ gbm_device_get_backend_name(struct gbm_device *gbm)
*
* \sa enum gbm_bo_format for the list of formats
*/
-int
+GBM_EXPORT int
gbm_device_is_format_supported(struct gbm_device *gbm,
uint32_t format, uint32_t usage)
{
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] meta: Drop ctx-API checks.
Kenneth Graunke kenn...@whitecape.org writes: API is always API_OPENGL_COMPAT (since commit 4e4a537ad55f61a25, meta: Push into desktop GL mode when doing meta operations.), so most of these checks do nothing. We could instead check save-API to only bother setting/restoring relevant GL state, but I'm not sure saving a few _mesa_set_enable calls is worth the complexity. My understanding is the point of the ctx-API guards was to avoid raising GL errors. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/drivers/common/meta.c | 139 +--- src/mesa/drivers/common/meta_blit.c | 3 +- 2 files changed, 50 insertions(+), 92 deletions(-) We either ought to do this, or move _mesa_meta_begin's ctx-API override to /after/ the state saving. I'm not sure which we ought to do. This simplifies a lot of the core/compat/ES insanity quite a bit, but doing the save state/restore state in the real API might be more sensible... I think I like it this way more. If we're concerned about state save/restore overhead, then I think some day we'd want to just avoid all the FF state save/restore in the GLSL-based paths. These two are: Reviewed-by: Eric Anholt e...@anholt.net pgpkRSD24SsKs.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure: disable shared glapi when building xlib powered glx
With commit 0432aa064b(configure: use shared-glapi when more than one gl* API is used) we removed disable shared-glapi when building without dri hunk. In the good old days of classic mesa, dri and xlib-glx were mutually exclusive thus the hunk made sense. Currently enable-dri is used as a synonym for a range of things thus it's more appropriate to handle xlib-glx explicitly. Fixes a missing symbol '_glapi_Dispatch' in a xlib powered libGL, build using the following ./autogen.sh --enable-xlib-glx --disable-dri --with-gallium-drivers=swrast Cc: Brian Paul bri...@vmware.com Reported-by: Brian Paul bri...@vmware.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- Hi Brian, Can you give this patch a try, it fixes the problem on my system. FWIW I will follow up with a cleanup patch that creates a local enable-dri-glx, that should prevent issues like that from happening again. -Emil configure.ac | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configure.ac b/configure.ac index 0e0fd18..5e1ac65 100644 --- a/configure.ac +++ b/configure.ac @@ -743,6 +743,12 @@ x*yes*yes*) ;; esac +# Building Xlib-GLX requires shared glapi to be disabled. +if test x$enable_xlib_glx = xyes; 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) dnl -- 1.9.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: disable shared glapi when building xlib powered glx
On Thu, Feb 27, 2014 at 11:03 AM, Emil Velikov emil.l.veli...@gmail.comwrote: With commit 0432aa064b(configure: use shared-glapi when more than one gl* API is used) we removed disable shared-glapi when building without dri hunk. In the good old days of classic mesa, dri and xlib-glx were mutually exclusive thus the hunk made sense. Currently enable-dri is used as a synonym for a range of things thus it's more appropriate to handle xlib-glx explicitly. Fixes a missing symbol '_glapi_Dispatch' in a xlib powered libGL, build using the following ./autogen.sh --enable-xlib-glx --disable-dri --with-gallium-drivers=swrast Cc: Brian Paul bri...@vmware.com Reported-by: Brian Paul bri...@vmware.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- Hi Brian, Can you give this patch a try, it fixes the problem on my system. Works for me here. Thanks! -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: do depth/stencil format conversion in glGetTexImage
glGetTexImage(GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8) was just
using memcpy() instead of _mesa_unpack_uint_24_8_depth_stencil_row()
to convert texels from the hardware format to the GL format.
Fixes issue reported by David Meng at Intel. The new piglit
ext_packed_depth_stencil-getteximage test checks for this bug.
Also, add some format/type assertions. We don't yet handle the
GL_FLOAT_32_UNSIGNED_INT_24_8_REV type. That should be fixed in
a follow-on patch.
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/main/texgetimage.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index fedd814..daabf2e 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -130,6 +130,10 @@ get_tex_depth_stencil(struct gl_context *ctx, GLuint
dimensions,
const GLint depth = texImage-Depth;
GLint img, row;
+ assert(format == GL_DEPTH_STENCIL);
+ assert(type == GL_UNSIGNED_INT_24_8);
+ /* XXX type == GL_FLOAT_32_UNSIGNED_INT_24_8_REV is not handled yet */
+
for (img = 0; img depth; img++) {
GLubyte *srcMap;
GLint rowstride;
@@ -145,8 +149,11 @@ get_tex_depth_stencil(struct gl_context *ctx, GLuint
dimensions,
void *dest = _mesa_image_address(dimensions, ctx-Pack, pixels,
width, height, format, type,
img, row, 0);
-/* XXX Z24_S8 vs. S8_Z24??? */
-memcpy(dest, src, width * sizeof(GLuint));
+/* Unpack from texture's format to GL's z24_s8 layout */
+_mesa_unpack_uint_24_8_depth_stencil_row(texImage-TexFormat,
+ width,
+ (const GLuint *) src,
+ dest);
if (ctx-Pack.SwapBytes) {
_mesa_swap4((GLuint *) dest, width);
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure: use enable_dri_glx local variable
GLX can be either dri or xlib based, while enable_dri is used in a variety of contexts. With enable_dri_glx the context is clearly visible. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- configure.ac | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/configure.ac b/configure.ac index 5e1ac65..903d5ff 100644 --- a/configure.ac +++ b/configure.ac @@ -696,13 +696,16 @@ AM_CONDITIONAL(NEED_OPENGL_COMMON, test x$enable_opengl = xyes -o \ x$enable_gles1 = xyes -o \ x$enable_gles2 = xyes) +enable_dri_glx=$enable_dri + if test x$enable_glx = xno; then AC_MSG_WARN([GLX disabled, disabling Xlib-GLX]) enable_xlib_glx=no +enable_dri_glx=no fi -if test x$enable_dri$enable_xlib_glx = xyesyes; then -AC_MSG_ERROR([DRI and Xlib-GLX cannot be built together]) +if test x$enable_dri_glx$enable_xlib_glx = xyesyes; then +AC_MSG_ERROR([DRI-GLX and Xlib-GLX cannot be built together]) fi if test x$enable_opengl$enable_xlib_glx = xnoyes; then @@ -715,16 +718,16 @@ if test x$enable_glx$enable_opengl = xyesno; then enable_glx=no fi -# Disable GLX if DRI and Xlib-GLX are not enabled +# Disable GLX if DRI-GLX and Xlib-GLX are not enabled if test x$enable_glx = xyes -a \ -x$enable_dri = xno -a \ +x$enable_dri_glx = xno -a \ x$enable_xlib_glx = xno; then -AC_MSG_WARN([Neither DRI nor Xlib-GLX enabled, disabling GLX]) +AC_MSG_WARN([Neither DRI-GLX nor Xlib-GLX enabled, disabling GLX]) enable_glx=no fi AM_CONDITIONAL(HAVE_DRI_GLX, test x$enable_glx = xyes -a \ - x$enable_dri = xyes) + x$enable_dri_glx = xyes) AM_CONDITIONAL(HAVE_DRI, test x$enable_dri = xyes) AM_CONDITIONAL(HAVE_DRI3, test x$enable_dri3 = xyes) -- 1.9.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glx: load dri driver with RTLD_LOCAL so dlclose never fails to unload
From: Jerome Glisse jgli...@redhat.com
There is no reason anymore to load with RTLD_GLOBAL and for some driver
this even result in dlclose failing to unload leading to catastrophic
failure with swrast fallback.
Signed-off-by: Jérôme Glisse jgli...@redhat.com
---
src/glx/dri_common.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index 8bf4705..e5a3f70 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -45,8 +45,8 @@
#ifndef RTLD_NOW
#define RTLD_NOW 0
#endif
-#ifndef RTLD_GLOBAL
-#define RTLD_GLOBAL 0
+#ifndef RTLD_LOCAL
+#define RTLD_LOCAL 0
#endif
_X_HIDDEN void
@@ -99,7 +99,7 @@ driOpenDriver(const char *driverName)
int len;
/* Attempt to make sure libGL symbols will be visible to the driver */
- glhandle = dlopen(libGL.so.1, RTLD_NOW | RTLD_GLOBAL);
+ glhandle = dlopen(libGL.so.1, RTLD_NOW | RTLD_LOCAL);
libPaths = NULL;
if (geteuid() == getuid()) {
@@ -127,14 +127,14 @@ driOpenDriver(const char *driverName)
snprintf(realDriverName, sizeof realDriverName,
%.*s/tls/%s_dri.so, len, p, driverName);
InfoMessageF(OpenDriver: trying %s\n, realDriverName);
- handle = dlopen(realDriverName, RTLD_NOW | RTLD_GLOBAL);
+ handle = dlopen(realDriverName, RTLD_NOW | RTLD_LOCAL);
#endif
if (handle == NULL) {
snprintf(realDriverName, sizeof realDriverName,
%.*s/%s_dri.so, len, p, driverName);
InfoMessageF(OpenDriver: trying %s\n, realDriverName);
- handle = dlopen(realDriverName, RTLD_NOW | RTLD_GLOBAL);
+ handle = dlopen(realDriverName, RTLD_NOW | RTLD_LOCAL);
}
if (handle != NULL)
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: use enable_dri_glx local variable
On Thu, Feb 27, 2014 at 10:32 AM, Emil Velikov emil.l.veli...@gmail.com wrote: GLX can be either dri or xlib based, while enable_dri is used in a variety of contexts. With enable_dri_glx the context is clearly visible. I think this makes it more confusing... We're just adding an extra variable and not simplifying any checks. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: use enable_dri_glx local variable
On 27/02/14 19:04, Matt Turner wrote: On Thu, Feb 27, 2014 at 10:32 AM, Emil Velikov emil.l.veli...@gmail.com wrote: GLX can be either dri or xlib based, while enable_dri is used in a variety of contexts. With enable_dri_glx the context is clearly visible. I think this makes it more confusing... We're just adding an extra variable and not simplifying any checks. Not sure how it would make things more confusing than what they already are. I'm fine with or without this patch just thought it will provide some clarity. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 75584] New: Request write access to mesa repository
https://bugs.freedesktop.org/show_bug.cgi?id=75584 Priority: medium Bug ID: 75584 Assignee: mesa-dev@lists.freedesktop.org Summary: Request write access to mesa repository Severity: normal Classification: Unclassified OS: All Reporter: court...@lunarg.com Hardware: Other Status: NEW Version: unspecified Component: Other Product: Mesa Created attachment 94848 -- https://bugs.freedesktop.org/attachment.cgi?id=94848action=edit SSH key Would like write access to post patches to the mesa repository. Hope I don't need it often, but having access would reduce burden on Intel and Mesa developers a little that push my patches today. Public GPG and SSH keys attached. -- 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 75584] Request write access to mesa repository
https://bugs.freedesktop.org/show_bug.cgi?id=75584 --- Comment #1 from Courtney Goeltzenleuchter court...@lunarg.com --- Created attachment 94849 -- https://bugs.freedesktop.org/attachment.cgi?id=94849action=edit GPG public key -- 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 3/4] configure: error out when building xa only with swrast
On 25/02/14 08:24, Matt Turner wrote: On Mon, Feb 24, 2014 at 3:05 PM, Emil Velikov emil.l.veli...@gmail.com wrote: Building to provide accelration using swrast does not make sense. Note: update your build script to explicitly mention svga in the gallium drivers list, if you are building the vmwgfx xa library. 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 6db3c1d..d98dca9 100644 --- a/configure.ac +++ b/configure.ac @@ -1234,6 +1234,9 @@ dnl dnl XA configuration dnl if test x$enable_xa = xyes; then +if test x$gallium_drivers = xswrast; then + AC_MSG_ERROR([Building xa requires at least one non swrast gallium driver]) +fi GALLIUM_STATE_TRACKERS_DIRS=xa $GALLIUM_STATE_TRACKERS_DIRS enable_gallium_loader=yes enable_gallium_drm_loader=yes -- 1.9.0 It's a never ending battle if we try to catch all kinds of nonsensical build configurations. I don't think it's worth it, except in a few cases. In fact, doesn't xf86-video-vmware just link against libxatracker? I don't think preventing xatracker from building without a vmwgfx target is even correct. [ Pardon for the rant ] Currently gallium gbm and opencl use the so called pipe-drivers. They can be considered as raw drivers that different state-trackers (ST) can load at runtime. Recently Rob, added pipe-loader support to the xatracker so that one could use different hardware drivers with it. Atm if one builds swrast only, the xatracker.so library is build but one could not actually use it, as it does not load pipe-swrast.so. True one can link against it, but they will have bigger problems as it would fail to find/load a hw driver at runtime. Thus causing bigger problems to unaware packagers/users. IMHO it's better to error at configure than dying at runtime. This patch will only affect people that explicitly set --enable-xa --with-gallium-drivers=swrast and prevents them from doing a silly thing. Perhaps changing the message to the following would make more sense Building xa requires at least one non swrast gallium driver. If you are looking to use libxatracker.so with vmware's virtual gpu, make sure to include svga in the gallium drivers list. eg. --with-gallium-drivers=svga -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 10.1 release candidate 2
Since RC2 there have been 37 commits to the 10.1 branch. There are at least 4 patches on the mailing list for review that are tagged for inclusion in the branch. The plan of record is to release 10.1 tomorrow. I don't think that's a good idea. How do people feel about having an RC3 tomorrow and a final 10.1, say, Tuesday? On 02/21/2014 06:07 PM, Ian Romanick wrote: Mesa 10.1 release candidate 2 is now available for testing. The current plan of record is to have the 10.2 release one week from today on Friday, February 28th. The tag in the GIT repository for Mesa 10.1-rc2 is 'mesa-10.1-rc2'. Mesa 10.1 release candidate 1 is available for download at ftp://freedesktop.org/pub/mesa/10.1/ md5sums: 7a4f991783bea17f9d07f3147553c7e9 MesaLib-10.1.0-rc2.tar.gz 4c63d3958f345f0818e2090843893bfd MesaLib-10.1.0-rc2.tar.bz2 94744da5d2ff5f4724465af64a65d48f MesaLib-10.1.0-rc2.zip I have verified building from the .tar.bz2 file by doing the following on a Fedora 18 system: tar -xjf Mesa-10.1.0-rc2.tar.bz2 cd Mesa-10.1.0-rc2 ./configure --enable-gallium-llvm --with-llvm-shared-libs make -j6 make install ___ 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 2/4] i965: Drop the system-memory temporary allocations for flush explicit.
While in expected usage patterns nobody will ever hit this path, doubling
our bandwidth usedd used seems like a waste, and it cost us extra code too.
---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 103 ---
src/mesa/drivers/dri/i965/intel_buffer_objects.h | 7 +-
2 files changed, 58 insertions(+), 52 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
index 5bf4533..e496836 100644
--- a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
+++ b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
@@ -409,27 +409,21 @@ intel_bufferobj_map_range(struct gl_context * ctx,
* guarantees the driver has advertised to the application.
*/
const unsigned alignment = ctx-Const.MinMapBufferAlignment;
- const unsigned extra = (uintptr_t) offset % alignment;
- if (access GL_MAP_FLUSH_EXPLICIT_BIT) {
- intel_obj-range_map_buffer[index] = _mesa_align_malloc(length +
extra,
- alignment);
- obj-Mappings[index].Pointer =
-intel_obj-range_map_buffer[index] + extra;
+ intel_obj-map_extra[index] = (uintptr_t) offset % alignment;
+ intel_obj-range_map_bo[index] = drm_intel_bo_alloc(brw-bufmgr,
+ BO blit temp,
+ length +
+
intel_obj-map_extra[index],
+ alignment);
+ if (brw-has_llc) {
+ drm_intel_bo_map(intel_obj-range_map_bo[index],
+ (access GL_MAP_WRITE_BIT) != 0);
} else {
-intel_obj-range_map_bo[index] = drm_intel_bo_alloc(brw-bufmgr,
- range map,
- length + extra,
- alignment);
-if (brw-has_llc) {
- drm_intel_bo_map(intel_obj-range_map_bo[index],
-(access GL_MAP_WRITE_BIT) != 0);
-} else {
- drm_intel_gem_bo_map_gtt(intel_obj-range_map_bo[index]);
-}
-obj-Mappings[index].Pointer =
-intel_obj-range_map_bo[index]-virtual + extra;
+ drm_intel_gem_bo_map_gtt(intel_obj-range_map_bo[index]);
}
+ obj-Mappings[index].Pointer =
+ intel_obj-range_map_bo[index]-virtual + intel_obj-map_extra[index];
return obj-Mappings[index].Pointer;
}
@@ -468,35 +462,51 @@ intel_bufferobj_flush_mapped_range(struct gl_context *ctx,
{
struct brw_context *brw = brw_context(ctx);
struct intel_buffer_object *intel_obj = intel_buffer_object(obj);
- drm_intel_bo *temp_bo;
+ GLbitfield access = obj-Mappings[index].AccessFlags;
+
+ assert(access GL_MAP_FLUSH_EXPLICIT_BIT);
- /* Unless we're in the range map using a temporary system buffer,
-* there's no work to do.
+ /* If we gave a direct mapping of the buffer instead of using a temporary,
+* then there's nothing to do.
*/
- if (intel_obj-range_map_buffer[index] == NULL)
+ if (intel_obj-range_map_bo[index] == NULL)
return;
if (length == 0)
return;
- temp_bo = drm_intel_bo_alloc(brw-bufmgr, range map flush, length, 64);
-
- /* Use obj-Pointer instead of intel_obj-range_map_buffer because the
-* former points to the actual mapping while the latter may be offset to
-* meet alignment guarantees.
+ /* Note that we're not unmapping our buffer while executing the blit. We
+* need to have a mapping still at the end of this call, since the user
+* gets to make further modifications and glFlushMappedBufferRange() calls.
+* This is safe, because:
+*
+* - On LLC platforms, we're using a CPU mapping that's coherent with the
+* GPU (except for the render caches), so the kernel doesn't need to do
+* any flushing work for us except for what happens at batch exec time
+* anyway.
+*
+* - On non-LLC platforms, we're using a GTT mapping that writes directly
+* to system memory (except for the chipset cache that gets flushed at
+* batch exec time).
+*
+* In both cases we don't need to stall for the previous blit to complete
+* so we can re-map (and we definitely don't want to, since that would be
+* slow): If the user edits a part of their buffer that's previously been
+* blitted, then our lack of synchoronization is fine, because either
+* they'll get some too-new data in the first blit and not do another blit
+* of that area (but in that case the results are undefined), or they'll do
+* another blit of that area and the complete newer data will land the
+* second time.
*/
- drm_intel_bo_subdata(temp_bo, 0, length,
[Mesa-dev] [PATCH 1/4] i965: Switch mapping modes for non-explicit-flush blit-temporary maps.
On LLC, it should always be better to use a cached mapping than the GTT.
On non-LLC, it seems pretty silly to try to optimize read performance for
the INVALIDATE_RANGE_BIT case. This will make the buffer_storage logic
easier.
---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
index e6124dc..5bf4533 100644
--- a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
+++ b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
@@ -421,11 +421,11 @@ intel_bufferobj_map_range(struct gl_context * ctx,
range map,
length + extra,
alignment);
-if (!(access GL_MAP_READ_BIT)) {
- drm_intel_gem_bo_map_gtt(intel_obj-range_map_bo[index]);
-} else {
+if (brw-has_llc) {
drm_intel_bo_map(intel_obj-range_map_bo[index],
(access GL_MAP_WRITE_BIT) != 0);
+} else {
+ drm_intel_gem_bo_map_gtt(intel_obj-range_map_bo[index]);
}
obj-Mappings[index].Pointer =
intel_obj-range_map_bo[index]-virtual + extra;
--
1.9.rc1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] i965 GL_ARB_buffer_storage
One thing I noticed while working on this was that we only reallocate buffer storage for INVALIDATE_BUFFER_BIT when UNSYNCHRONIZED_BIT is unset. The ARB_mbr spec says that the contents may be discarded, not must be discarded. However, while writing the glamor code I happened to type this for the wraparound case: glamor_priv-vb = glMapBufferRange(GL_ARRAY_BUFFER, 0, size, GL_MAP_WRITE_BIT | GL_MAP_INVALIDATE_BUFFER_BIT | GL_MAP_UNSYNCHRONIZED_BIT | GL_MAP_PERSISTENT_BIT | GL_MAP_COHERENT_BIT); intending that the buffer storage get reallocated, and that we not worry about any synchronization after that. My code would have been broken on the i965 driver. I'm wondering if this is the intended behavior of the spec, or if we want to treat the may as a must. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] i965: Always use CPU mappings for BOs on LLC platforms.
It looks like there's no big difference for write-only workloads, but
using a CPU map means that if they happen to read without having set the
MAP_READ_BIT, they get 100x the performance for those reads.
---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
index e496836..260308a 100644
--- a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
+++ b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
@@ -429,7 +429,7 @@ intel_bufferobj_map_range(struct gl_context * ctx,
if (access GL_MAP_UNSYNCHRONIZED_BIT)
drm_intel_gem_bo_map_unsynchronized(intel_obj-buffer);
- else if (!(access GL_MAP_READ_BIT)) {
+ else if (!brw-has_llc !(access GL_MAP_READ_BIT)) {
drm_intel_gem_bo_map_gtt(intel_obj-buffer);
intel_bufferobj_mark_inactive(intel_obj);
} else {
--
1.9.rc1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] i965: Add support for GL_ARB_buffer_storage.
It turns out we can allow COHERENT storage/mappings all the time,
regardless of LLC vs non-LLC. It just means never using temporary
mappings to avoid GPU stalls, and on non-LLC we have to use the GTT intead
of CPU mappings. If we were to use CPU maps on non-LLC (which might be
useful if apps end up using buffer_storage on PBO reads, to avoid WC read
slowness), those would be PERSISTENT but not COHERENT, but doing that
would require us driving the clflushes from userspace somehow.
Using this in glamor, I got a 29.5361% +/- 2.74092% improvement in x11perf
-aa10text (n=489).
---
docs/GL3.txt | 2 +-
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 9 +++--
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 5261eda..45db98f 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -170,7 +170,7 @@ GL 4.4:
GLSL 4.4 not started
GL_MAX_VERTEX_ATTRIB_STRIDE not started
- GL_ARB_buffer_storageDONE (r300, r600,
radeonsi)
+ GL_ARB_buffer_storageDONE (i965, r300, r600,
radeonsi)
GL_ARB_clear_texture not started
GL_ARB_enhanced_layouts not started
GL_ARB_multi_bindstarted (Fredrik
Höglund)
diff --git a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
index 260308a..96dacde 100644
--- a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
+++ b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
@@ -401,8 +401,12 @@ intel_bufferobj_map_range(struct gl_context * ctx,
* doesn't require the current contents of that range, make a new
* BO, and we'll copy what they put in there out at unmap or
* FlushRange time.
+*
+* That is, unless they're looking for a persistent mapping -- we would
+* need to do blits in the MemoryBarrier call, and it's easier to just do a
+* GPU stall and do a mapping.
*/
- if (!(access GL_MAP_UNSYNCHRONIZED_BIT)
+ if (!(access (GL_MAP_UNSYNCHRONIZED_BIT | GL_MAP_PERSISTENT_BIT))
(access GL_MAP_INVALIDATE_RANGE_BIT)
drm_intel_bo_busy(intel_obj-buffer)) {
/* Ensure that the base alignment of the allocation meets the alignment
@@ -429,7 +433,8 @@ intel_bufferobj_map_range(struct gl_context * ctx,
if (access GL_MAP_UNSYNCHRONIZED_BIT)
drm_intel_gem_bo_map_unsynchronized(intel_obj-buffer);
- else if (!brw-has_llc !(access GL_MAP_READ_BIT)) {
+ else if (!brw-has_llc (!(access GL_MAP_READ_BIT) ||
+ (access GL_MAP_PERSISTENT_BIT))) {
drm_intel_gem_bo_map_gtt(intel_obj-buffer);
intel_bufferobj_mark_inactive(intel_obj);
} else {
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index ef9aa55..860896a 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -162,6 +162,7 @@ intelInitExtensions(struct gl_context *ctx)
assert(brw-gen = 4);
+ ctx-Extensions.ARB_buffer_storage = true;
ctx-Extensions.ARB_depth_buffer_float = true;
ctx-Extensions.ARB_depth_clamp = true;
ctx-Extensions.ARB_depth_texture = true;
--
1.9.rc1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Don't use derived vertex state in api_arrayelt.c
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/main/api_arrayelt.c | 111 ++-
1 file changed, 57 insertions(+), 54 deletions(-)
It's possible that this patch fixes a segfault in FlightGear (see bug 73504),
so I think it's a candidate for the 10.1 branch, but maybe not for 10.1.0.
diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index 05cbc0f..ebeba88 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -43,18 +43,21 @@
#include macros.h
#include mtypes.h
#include main/dispatch.h
+#include varray.h
typedef void (GLAPIENTRY *array_func)( const void * );
typedef struct {
- const struct gl_client_array *array;
+ const struct gl_vertex_attrib_array *array;
+ const struct gl_vertex_buffer_binding *binding;
int offset;
} AEarray;
typedef void (GLAPIENTRY *attrib_func)( GLuint indx, const void *data );
typedef struct {
- const struct gl_client_array *array;
+ const struct gl_vertex_attrib_array *array;
+ const struct gl_vertex_buffer_binding *binding;
attrib_func func;
GLuint index;
} AEattrib;
@@ -1470,18 +1473,6 @@ check_vbo(AEcontext *actx, struct gl_buffer_object *vbo)
}
-static inline void
-update_derived_client_arrays(struct gl_context *ctx)
-{
- struct gl_vertex_array_object *vao = ctx-Array.VAO;
-
- if (vao-NewArrays) {
- _mesa_update_vao_client_arrays(ctx, vao);
- vao-NewArrays = 0;
- }
-}
-
-
/**
* Make a list of per-vertex functions to call for each glArrayElement call.
* These functions access the array data (i.e. glVertex, glColor, glNormal,
@@ -1500,67 +1491,81 @@ _ae_update_state(struct gl_context *ctx)
actx-nr_vbos = 0;
/* conventional vertex arrays */
- if (vao-_VertexAttrib[VERT_ATTRIB_COLOR_INDEX].Enabled) {
- aa-array = vao-_VertexAttrib[VERT_ATTRIB_COLOR_INDEX];
+ if (vao-VertexAttrib[VERT_ATTRIB_COLOR_INDEX].Enabled) {
+ aa-array = vao-VertexAttrib[VERT_ATTRIB_COLOR_INDEX];
+ aa-binding = vao-VertexBinding[aa-array-VertexBinding];
aa-offset = IndexFuncs[TYPE_IDX(aa-array-Type)];
- check_vbo(actx, aa-array-BufferObj);
+ check_vbo(actx, aa-binding-BufferObj);
aa++;
}
- if (vao-_VertexAttrib[VERT_ATTRIB_EDGEFLAG].Enabled) {
- aa-array = vao-_VertexAttrib[VERT_ATTRIB_EDGEFLAG];
+
+ if (vao-VertexAttrib[VERT_ATTRIB_EDGEFLAG].Enabled) {
+ aa-array = vao-VertexAttrib[VERT_ATTRIB_EDGEFLAG];
+ aa-binding = vao-VertexBinding[aa-array-VertexBinding];
aa-offset = _gloffset_EdgeFlagv;
- check_vbo(actx, aa-array-BufferObj);
+ check_vbo(actx, aa-binding-BufferObj);
aa++;
}
- if (vao-_VertexAttrib[VERT_ATTRIB_NORMAL].Enabled) {
- aa-array = vao-_VertexAttrib[VERT_ATTRIB_NORMAL];
+
+ if (vao-VertexAttrib[VERT_ATTRIB_NORMAL].Enabled) {
+ aa-array = vao-VertexAttrib[VERT_ATTRIB_NORMAL];
+ aa-binding = vao-VertexBinding[aa-array-VertexBinding];
aa-offset = NormalFuncs[TYPE_IDX(aa-array-Type)];
- check_vbo(actx, aa-array-BufferObj);
+ check_vbo(actx, aa-binding-BufferObj);
aa++;
}
- if (vao-_VertexAttrib[VERT_ATTRIB_COLOR0].Enabled) {
- aa-array = vao-_VertexAttrib[VERT_ATTRIB_COLOR0];
+
+ if (vao-VertexAttrib[VERT_ATTRIB_COLOR0].Enabled) {
+ aa-array = vao-VertexAttrib[VERT_ATTRIB_COLOR0];
+ aa-binding = vao-VertexBinding[aa-array-VertexBinding];
aa-offset = ColorFuncs[aa-array-Size-3][TYPE_IDX(aa-array-Type)];
- check_vbo(actx, aa-array-BufferObj);
+ check_vbo(actx, aa-binding-BufferObj);
aa++;
}
- if (vao-_VertexAttrib[VERT_ATTRIB_COLOR1].Enabled) {
- aa-array = vao-_VertexAttrib[VERT_ATTRIB_COLOR1];
+
+ if (vao-VertexAttrib[VERT_ATTRIB_COLOR1].Enabled) {
+ aa-array = vao-VertexAttrib[VERT_ATTRIB_COLOR1];
+ aa-binding = vao-VertexBinding[aa-array-VertexBinding];
aa-offset = SecondaryColorFuncs[TYPE_IDX(aa-array-Type)];
- check_vbo(actx, aa-array-BufferObj);
+ check_vbo(actx, aa-binding-BufferObj);
aa++;
}
- if (vao-_VertexAttrib[VERT_ATTRIB_FOG].Enabled) {
- aa-array = vao-_VertexAttrib[VERT_ATTRIB_FOG];
+
+ if (vao-VertexAttrib[VERT_ATTRIB_FOG].Enabled) {
+ aa-array = vao-VertexAttrib[VERT_ATTRIB_FOG];
+ aa-binding = vao-VertexBinding[aa-array-VertexBinding];
aa-offset = FogCoordFuncs[TYPE_IDX(aa-array-Type)];
- check_vbo(actx, aa-array-BufferObj);
+ check_vbo(actx, aa-binding-BufferObj);
aa++;
}
+
for (i = 0; i ctx-Const.MaxTextureCoordUnits; i++) {
- struct gl_client_array *attribArray =
- vao-_VertexAttrib[VERT_ATTRIB_TEX(i)];
+ struct gl_vertex_attrib_array *attribArray =
+ vao-VertexAttrib[VERT_ATTRIB_TEX(i)];
if (attribArray-Enabled) {
/* NOTE: we use generic glVertexAttribNV functions here.
* If we ever remove GL_NV_vertex_program this will have to change.
*/
at-array =
Re: [Mesa-dev] Mesa 10.1 release candidate 2
Sounds fine to me. -Brian On 02/27/2014 02:08 PM, Ian Romanick wrote: Since RC2 there have been 37 commits to the 10.1 branch. There are at least 4 patches on the mailing list for review that are tagged for inclusion in the branch. The plan of record is to release 10.1 tomorrow. I don't think that's a good idea. How do people feel about having an RC3 tomorrow and a final 10.1, say, Tuesday? On 02/21/2014 06:07 PM, Ian Romanick wrote: Mesa 10.1 release candidate 2 is now available for testing. The current plan of record is to have the 10.2 release one week from today on Friday, February 28th. The tag in the GIT repository for Mesa 10.1-rc2 is 'mesa-10.1-rc2'. Mesa 10.1 release candidate 1 is available for download at https://urldefense.proofpoint.com/v1/url?u=ftp://freedesktop.org/pub/mesa/10.1/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=FvYj8lfo951paTnx9TCFYaEvHwZVZTTMvhpgPUCQ%2F7A%3D%0As=46d845ffc03df490333ac1a98d7bfa6da89c897f1500f45bc560767e031f5f11 md5sums: 7a4f991783bea17f9d07f3147553c7e9 MesaLib-10.1.0-rc2.tar.gz 4c63d3958f345f0818e2090843893bfd MesaLib-10.1.0-rc2.tar.bz2 94744da5d2ff5f4724465af64a65d48f MesaLib-10.1.0-rc2.zip I have verified building from the .tar.bz2 file by doing the following on a Fedora 18 system: tar -xjf Mesa-10.1.0-rc2.tar.bz2 cd Mesa-10.1.0-rc2 ./configure --enable-gallium-llvm --with-llvm-shared-libs make -j6 make install ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=FvYj8lfo951paTnx9TCFYaEvHwZVZTTMvhpgPUCQ%2F7A%3D%0As=3aa39855ba2cc330e4f5f1863d971e27d36329a11495fa95797f16ab58dbe5d6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=FvYj8lfo951paTnx9TCFYaEvHwZVZTTMvhpgPUCQ%2F7A%3D%0As=3aa39855ba2cc330e4f5f1863d971e27d36329a11495fa95797f16ab58dbe5d6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Piglit - GL/GLSL tests - GSoC 2014
Hey! I thank you for the information! Dragomir has also provided me with some helpful links and jljusten solved a lot of my queries on IRC. I am trying to understand how things are working and will start working on a proposal! Thanks! Chirag Agrawal Department of Computer Science BITS Pilani, Goa Campus On Thu, Feb 27, 2014 at 7:07 AM, Anuj Phogat anuj.pho...@gmail.com wrote: On Tue, Feb 25, 2014 at 9:47 AM, Chirag Agrawal a.chira...@gmail.comwrote: Hey! I am Chirag. I am currently part of a dual degree program (5yr) at Birla Institute of Technology Science, Pilani - Goa Campus, India. I am in my 4th year as a candidate for a master's degree in Mathematics and a bachelor's degree in Computer Science. My programming expertise includes proficiency in C and Python and some experience with C++ and JAVA. My recent programming experience includes my internship at DreamWorks, Bangalore, where I worked with NUKE's API in C++. I have also worked on multiple projects that made an extensive use of OpenGL, as part of my course in Computer Graphics. I was wondering if someone could help me understand a little more about the project - *GL/GLSL tests for GL 4.0 and newer* What kind of tests are we looking for? Is there some code that I could look at? Chirag, You can look at existing piglit tests to get some idea. Get it via git: git clone git://anongit.freedesktop.org/git/piglit git web interface for piglit: http://cgit.freedesktop.org/piglit Public mailing list: http://lists.freedesktop.org/mailman/listinfo/piglit Refer to OpenGL/GLSL specifications at Khronos website: http://www.opengl.org/registry/ http://www.opengl.org/registry/ Anuj Thanks!! Sincerely, Chirag Agrawal Department of Computer Science BITS Pilani, Goa Campus ___ 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] Introductory projects in r600/radeonsi
I've been following mesa development for a while and am hoping to find a good project in either the r600 or radeonsi drivers that would give me a place to start learning about the general structure of mesa dev. I have a solid understanding of C and a reasonable familiarity with OpenGL. Suggestions as to a good place to start working would be much appreciated. Sean Burke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nv50: enable texture query lod
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Note: this applies on top of airlied's r600g-texture-gather branch.
Appears to pass all 4 piglit tests. The conversion from what the instruction
outputs is the same as what the blob does.
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 +
.../drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 4
.../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 3 +++
.../nouveau/codegen/nv50_ir_lowering_nv50.cpp | 23 ++
.../drivers/nouveau/codegen/nv50_ir_print.cpp | 1 +
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +-
6 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
index 857980d..286ac83 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
@@ -117,6 +117,7 @@ enum operation
OP_TXQ, // texture size query
OP_TXD, // texture derivatives
OP_TXG, // texture gather
+ OP_TXLQ, // texture query lod
OP_TEXCSAA, // texture op for coverage sampling
OP_TEXPREP, // turn cube map array into 2d array coordinates
OP_SULDB, // surface load (raw)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
index bef103f..0b0d480 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
@@ -1450,6 +1450,9 @@ CodeEmitterNV50::emitTEX(const TexInstruction *i)
code[0] = 0x0100;
code[1] = 0x8000;
break;
+ case OP_TXLQ:
+ code[1] = 0x6002;
+ break;
default:
assert(i-op == OP_TEX);
break;
@@ -1790,6 +1793,7 @@ CodeEmitterNV50::emitInstruction(Instruction *insn)
case OP_TXB:
case OP_TXL:
case OP_TXF:
+ case OP_TXLQ:
emitTEX(insn-asTex());
break;
case OP_TXQ:
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index d226d0c..10ec8c6 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -255,6 +255,7 @@ unsigned int Instruction::srcMask(unsigned int s) const
case TGSI_OPCODE_TXD:
case TGSI_OPCODE_TXL:
case TGSI_OPCODE_TXP:
+ case TGSI_OPCODE_LODQ:
{
const struct tgsi_instruction_texture *tex = insn-Texture;
@@ -558,6 +559,7 @@ static nv50_ir::operation translateOpcode(uint opcode)
NV50_IR_OPCODE_CASE(SAD, SAD);
NV50_IR_OPCODE_CASE(TXF, TXF);
NV50_IR_OPCODE_CASE(TXQ, TXQ);
+ NV50_IR_OPCODE_CASE(LODQ, TXLQ);
NV50_IR_OPCODE_CASE(EMIT, EMIT);
NV50_IR_OPCODE_CASE(ENDPRIM, RESTART);
@@ -2428,6 +2430,7 @@ Converter::handleInstruction(const struct
tgsi_full_instruction *insn)
case TGSI_OPCODE_TXB:
case TGSI_OPCODE_TXL:
case TGSI_OPCODE_TXP:
+ case TGSI_OPCODE_LODQ:
// R S L CDxDy
handleTEX(dst0, 1, 1, 0x03, 0x0f, 0x00, 0x00);
break;
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
index 984a8ca..91cae53 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
@@ -543,6 +543,7 @@ private:
bool handleTXB(TexInstruction *); // I really
bool handleTXL(TexInstruction *); // hate
bool handleTXD(TexInstruction *); // these 3
+ bool handleTXLQ(TexInstruction *);
bool handleCALL(Instruction *);
bool handlePRECONT(Instruction *);
@@ -856,6 +857,26 @@ NV50LoweringPreSSA::handleTXD(TexInstruction *i)
}
bool
+NV50LoweringPreSSA::handleTXLQ(TexInstruction *i)
+{
+ handleTEX(i);
+ bld.setPosition(i, true);
+
+ /* The returned values are not quite what we want:
+* (a) convert from s32 to f32
+* (b) multiply by 1/256
+*/
+ for (int def = 0; def 2; ++def) {
+ if (!i-defExists(def))
+ continue;
+ bld.mkCvt(OP_CVT, TYPE_F32, i-getDef(def), TYPE_S32, i-getDef(def));
+ bld.mkOp2(OP_MUL, TYPE_F32, i-getDef(def),
+i-getDef(def), bld.loadImm(NULL, 1.0f / 256));
+ }
+ return true;
+}
+
+bool
NV50LoweringPreSSA::handleSET(Instruction *i)
{
if (i-dType == TYPE_F32) {
@@ -1196,6 +1217,8 @@ NV50LoweringPreSSA::visit(Instruction *i)
return handleTXL(i-asTex());
case OP_TXD:
return handleTXD(i-asTex());
+ case OP_TXLQ:
+ return handleTXLQ(i-asTex());
case OP_EX2:
bld.mkOp1(OP_PREEX2, TYPE_F32, i-getDef(0), i-getSrc(0));
i-setSrc(0, i-getDef(0));
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
index ae42d03..4093bc0 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
[Mesa-dev] [PATCH] gallium/util: add missing u_math include
This is needed for MIN2/MAX2
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/auxiliary/util/u_range.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_range.h
b/src/gallium/auxiliary/util/u_range.h
index 4b1d0d1..efe25ef 100644
--- a/src/gallium/auxiliary/util/u_range.h
+++ b/src/gallium/auxiliary/util/u_range.h
@@ -36,6 +36,8 @@
#include os/os_thread.h
+#include util/u_math.h
+
struct util_range {
unsigned start; /* inclusive */
unsigned end; /* exclusive */
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx: load dri driver with RTLD_LOCAL so dlclose never fails to unload
j.gli...@gmail.com writes: From: Jerome Glisse jgli...@redhat.com There is no reason anymore to load with RTLD_GLOBAL and for some driver this even result in dlclose failing to unload leading to catastrophic failure with swrast fallback. I don't remember the last time drivers relied on GL symbols being present -- we've been using _mesa_ prefixed stuff in meta for many years, for example. I think this should be plenty safe. Reviewed-by: Eric Anholt e...@anholt.net pgpF7OSOfnexi.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: do depth/stencil format conversion in glGetTexImage
Brian Paul bri...@vmware.com writes: glGetTexImage(GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8) was just using memcpy() instead of _mesa_unpack_uint_24_8_depth_stencil_row() to convert texels from the hardware format to the GL format. Fixes issue reported by David Meng at Intel. The new piglit ext_packed_depth_stencil-getteximage test checks for this bug. Also, add some format/type assertions. We don't yet handle the GL_FLOAT_32_UNSIGNED_INT_24_8_REV type. That should be fixed in a follow-on patch. Reviewed-by: Eric Anholt e...@anholt.net pgp7E5swJ_8lG.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
