[Mesa-dev] mesa/st: how to force glLinkProgram to create/translate the program?
Hi, My goal is to extend shader-db to be able to be used with nouveau, as I'm about to attempt a few compiler optimizations. But I'm having trouble with the very first step -- getting the driver to spit out the generated code. I've added logic to nouveau to translate the program as soon as it's available rather than on first use. However it seems that mesa/st has similar delaying logic, which makes it so that none of this is called when merely calling glLinkProgram. I'm having trouble figuring out how to bypass this and make it call update_vp/fp/gp which appear like they'll actually call pipe->create_fs_state/etc. I see st_link_shader getting called, as expected, which creates the TGSI... but what to do from there? Thanks, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 70591] glxext.h:275: error: redefinition of typedef ‘GLXContextID’
https://bugs.freedesktop.org/show_bug.cgi?id=70591 Vinson Lee changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Vinson Lee --- commit f8432832a7f3d3cc01f8bab8358069029d575ef0 Author: Vinson Lee Date: Mon Jan 6 12:09:29 2014 -0800 mesa: Remove GLXContextID typedef from glxext.h. This patch fixes this build error with gcc <= 4.5 and clang <= 3.1. CC clientattrib.lo In file included from ../../include/GL/glx.h:333:0, from glxclient.h:45, from clientattrib.c:32: ../../include/GL/glxext.h:275:13: error: redefinition of typedef 'GLXContextID' ../../include/GL/glx.h:171:13: note: previous declaration of 'GLXContextID' was here Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70591 Signed-off-by: Vinson Lee Reviewed-by: Kenneth Graunke -- 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 2/9] glsl: add dimension_count to glsl_types
On Thu, 2014-01-16 at 16:29 -0800, Matt Turner wrote:
> On Wed, Jan 15, 2014 at 10:27 PM, Timothy Arceri
> wrote:
> > Signed-off-by: Timothy Arceri
> > ---
> > src/glsl/glsl_types.cpp | 15 +++
> > src/glsl/glsl_types.h | 17 -
> > 2 files changed, 27 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
> > index 12d4ac0..1c9add7 100644
> > --- a/src/glsl/glsl_types.cpp
> > +++ b/src/glsl/glsl_types.cpp
> > @@ -277,12 +277,13 @@ _mesa_glsl_release_types(void)
> > }
> >
> >
> > -glsl_type::glsl_type(const glsl_type *array, unsigned length) :
> > +glsl_type::glsl_type(const glsl_type *array, unsigned length,
> > + unsigned dimension_count) :
> > base_type(GLSL_TYPE_ARRAY),
> > sampler_dimensionality(0), sampler_shadow(0), sampler_array(0),
> > sampler_type(0), interface_packing(0),
> > vector_elements(0), matrix_columns(0),
> > - name(NULL), length(length)
> > + name(NULL), length(length), dimension_count(dimension_count)
> > {
> > this->fields.array = array;
> > /* Inherit the gl type of the base. The GL type is used for
> > @@ -416,10 +417,16 @@ glsl_type::get_instance(unsigned base_type, unsigned
> > rows, unsigned columns)
> > return error_type;
> > }
> >
> > -
>
> Unrelated whitespace change.
>
> > const glsl_type *
> > glsl_type::get_array_instance(const glsl_type *base, unsigned array_size)
> > {
> > + return get_array_instance(base, array_size, 1);
> > +}
> > +
> > +const glsl_type *
> > +glsl_type::get_array_instance(const glsl_type *base, unsigned array_size,
> > + unsigned dimension_count)
> > +{
>
> Just add dimension_count=1 as a default parameter to the existing
> get_array_instance() method.
The new method is used also in later patches. Maybe I should add this to
the commit message?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH V2 6/9] glsl: Implement ARB_arrays_of_arrays support for constructors
V2: Fix up whitespaces
Signed-off-by: Timothy Arceri
---
src/glsl/ast_function.cpp | 43 ---
1 file changed, 40 insertions(+), 3 deletions(-)
diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index 2d05d07..0d2cac0 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -752,8 +752,10 @@ process_array_constructor(exec_list *instructions,
if (is_unsized_array) {
constructor_type =
-glsl_type::get_array_instance(constructor_type->element_type(),
- parameter_count);
+ glsl_type::get_array_instance(constructor_type->element_type(),
+ parameter_count,
+ constructor_type->dimension_count);
+
assert(constructor_type != NULL);
assert(constructor_type->length == parameter_count);
}
@@ -782,7 +784,8 @@ process_array_constructor(exec_list *instructions,
}
}
- if (result->type != constructor_type->element_type()) {
+ if (constructor_type->dimension_count == 1 &&
+ result->type != constructor_type->element_type()) {
_mesa_glsl_error(loc, state, "type error in array constructor: "
"expected: %s, found %s",
constructor_type->element_type()->name,
@@ -790,6 +793,40 @@ process_array_constructor(exec_list *instructions,
return ir_rvalue::error_value(ctx);
}
+ /* compare arrays of arrays dimensions, element type, and sizes*/
+ if (result->type->is_array()) {
+
+ if (result->type->dimension_count !=
(constructor_type->dimension_count-1)) {
+ _mesa_glsl_error(loc, state, "type error in array constructor: "
+ "expected array with: %u dimension(s),"
+ " found %u dimension(s)",
+ constructor_type->dimension_count-1,
+ result->type->dimension_count);
+ return ir_rvalue::error_value(ctx);
+ }
+
+ const glsl_type *expected_type = constructor_type->element_type();
+ const glsl_type *result_type = result->type;
+ for (unsigned i=0; itype->dimension_count; i++) {
+if (result_type->length != expected_type->length) {
+ _mesa_glsl_error(loc, state, "type error in array constructor: "
+"expected array with size: %u,"
+" found size %u",
+expected_type->length,
+result_type->length);
+ return ir_rvalue::error_value(ctx);
+}
+expected_type = expected_type->element_type();
+result_type = result_type->element_type();
+ }
+
+ if (expected_type != result_type) {
+_mesa_glsl_error(loc, state, "type error in array constructor: "
+ "expected: %s",
+ expected_type->name);
+ }
+ }
+
/* Attempt to convert the parameter to a constant valued expression.
* After doing so, track whether or not all the parameters to the
* constructor are trivially constant valued expressions.
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73776] NameError: name 'libloader' is not defined:
https://bugs.freedesktop.org/show_bug.cgi?id=73776 Fabio Pedretti changed: What|Removed |Added CC||fabio@libero.it -- 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 73776] NameError: name 'libloader' is not defined:
https://bugs.freedesktop.org/show_bug.cgi?id=73776
--- Comment #3 from Fabio Pedretti ---
> make[3]: Entering directory
> `/home/jos/src/xorg/git/mesa/src/gallium/auxiliary/pipe-loader'
> CC pipe_loader_drm.lo
> pipe_loader_drm.c: In function 'pipe_loader_drm_probe_fd':
> pipe_loader_drm.c:120:4: error: implicit declaration of function
> 'loader_get_pci_id_for_fd' [-Werror=implicit-function-declaration]
> if (loader_get_pci_id_for_fd(fd, &vendor_id, &chip_id)) {
> ^
Same error here on current git.
--
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 73672] Half Life 2 in Wine is broken since 4e549ddb
https://bugs.freedesktop.org/show_bug.cgi?id=73672 Benjamin Bellec changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Mesa core --- Comment #10 from Benjamin Bellec --- I just tested with nouveau on a GeForce 210 (NVA8) card (nv50 driver) and there is the same problem. But instead of a red weird screen (in Left 4 Dead 2) there is a completely black screen instead (the HUD is still visible like on r600g). I also performed other test (on r600g) within Left 4 Dead 2: with MSAA disabled => no problem with MSAAx2 enabled => textures are visible but game lags, screen is blinking and shaking, teamplayer models are disappearing sometimes and there is some other weird graphical bug with MSAAx4 enabled => red weird screen with HUD visible with MSAAx6 enabled => ditto with MSAAx8 enabled => ditto @Alexandre I'm using a RV770 (Radeon HD4850) @Marek Without LLVM. My compil conf is: ./autogen.sh --with-gallium-drivers=r600,nouveau --with-dri-drivers= --enable-texture-float --disable-dri3 --disable-r600-llvm-compiler --disable-gallium-llvm --enable-32-bit CFLAGS="-O2 -m32" CXXFLAGS="-O2 -m32" --libdir=/usr/lib -- 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 73672] Half Life 2 in Wine is broken since 4e549ddb
https://bugs.freedesktop.org/show_bug.cgi?id=73672 Benjamin Bellec changed: What|Removed |Added CC||b.bel...@gmail.com -- 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 73672] Half Life 2 in Wine is broken since 4e549ddb
https://bugs.freedesktop.org/show_bug.cgi?id=73672 --- Comment #11 from Ilia Mirkin --- (In reply to comment #10) > I just tested with nouveau on a GeForce 210 (NVA8) card (nv50 driver) and > there is the same problem. But instead of a red weird screen (in Left 4 Dead > 2) there is a completely black screen instead (the HUD is still visible like > on r600g). Was the mesa that you tested nouveau with between commits 95bf222603b and dd687fb8d09? If so, that could explain the black screen. If not, the bug may be helped with an apitrace demonstrating the issue. -- 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] Cleaning compute_memory_pool from gallium/drivers/r600
Hope I got everything right this time. Thanks a lot to Marek Olšák for all the help! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] r600g/compute: Fixing a typo and some indentation
---
src/gallium/drivers/r600/compute_memory_pool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index fd3a04c..7a7b057 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -264,7 +264,7 @@ void compute_memory_finalize_pending(struct
compute_memory_pool* pool,
unallocated += item->size_in_dw+1024;
}
else {
- /* The item is not pendng, so update the amount of space
+ /* The item is not pending, so update the amount of
space
* that has already been allocated. */
allocated += item->size_in_dw;
}
@@ -452,7 +452,7 @@ void compute_memory_transfer(
map = pipe->transfer_map(pipe, gart, 0, PIPE_TRANSFER_READ,
&(struct pipe_box) { .width = aligned_size,
.height = 1, .depth = 1 }, &xfer);
-assert(xfer);
+ assert(xfer);
assert(map);
memcpy(data, map + internal_offset, size);
pipe->transfer_unmap(pipe, xfer);
--
1.8.5.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] r600g/compute: Adding checks for NULL after CALLOC
---
src/gallium/drivers/r600/compute_memory_pool.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 7a7b057..da351d8 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -50,6 +50,8 @@ struct compute_memory_pool* compute_memory_pool_new(
{
struct compute_memory_pool* pool = (struct compute_memory_pool*)
CALLOC(sizeof(struct compute_memory_pool), 1);
+ if (pool == NULL)
+ return NULL;
COMPUTE_DBG(rscreen, "* compute_memory_pool_new()\n");
@@ -65,6 +67,9 @@ static void compute_memory_pool_init(struct
compute_memory_pool * pool,
initial_size_in_dw);
pool->shadow = (uint32_t*)CALLOC(initial_size_in_dw, 4);
+ if (pool->shadow == NULL)
+ return;
+
pool->next_id = 1;
pool->size_in_dw = initial_size_in_dw;
pool->bo = (struct
r600_resource*)r600_compute_buffer_alloc_vram(pool->screen,
@@ -401,6 +406,9 @@ struct compute_memory_item* compute_memory_alloc(
new_item = (struct compute_memory_item *)
CALLOC(sizeof(struct compute_memory_item), 1);
+ if (new_item == NULL)
+ return NULL;
+
new_item->size_in_dw = size_in_dw;
new_item->start_in_dw = -1; /* mark pending */
new_item->id = pool->next_id++;
--
1.8.5.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] r600g/compute: Add more NULL checks
In this case, NULL checks are added to compute_memory_grow_pool,
so it returns -1 when it fails. This makes necesary
to handle such cases in compute_memory_finalize_pending
when it is needed to grow the pool
---
src/gallium/drivers/r600/compute_memory_pool.c | 30 --
src/gallium/drivers/r600/compute_memory_pool.h | 6 --
2 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index da351d8..1e04639 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -161,9 +161,10 @@ struct compute_memory_item* compute_memory_postalloc_chunk(
}
/**
- * Reallocates pool, conserves data
+ * Reallocates pool, conserves data.
+ * @returns -1 if it fails, 0 otherwise
*/
-void compute_memory_grow_pool(struct compute_memory_pool* pool,
+int compute_memory_grow_pool(struct compute_memory_pool* pool,
struct pipe_context * pipe, int new_size_in_dw)
{
COMPUTE_DBG(pool->screen, "* compute_memory_grow_pool() "
@@ -174,6 +175,8 @@ void compute_memory_grow_pool(struct compute_memory_pool*
pool,
if (!pool->bo) {
compute_memory_pool_init(pool, MAX2(new_size_in_dw, 1024 * 16));
+ if (pool->shadow == NULL)
+ return -1;
} else {
new_size_in_dw += 1024 - (new_size_in_dw % 1024);
@@ -182,6 +185,9 @@ void compute_memory_grow_pool(struct compute_memory_pool*
pool,
compute_memory_shadow(pool, pipe, 1);
pool->shadow = realloc(pool->shadow, new_size_in_dw*4);
+ if (pool->shadow == NULL)
+ return -1;
+
pool->size_in_dw = new_size_in_dw;
pool->screen->b.b.resource_destroy(
(struct pipe_screen *)pool->screen,
@@ -191,6 +197,8 @@ void compute_memory_grow_pool(struct compute_memory_pool*
pool,
pool->size_in_dw * 4);
compute_memory_shadow(pool, pipe, 0);
}
+
+ return 0;
}
/**
@@ -214,8 +222,9 @@ void compute_memory_shadow(struct compute_memory_pool* pool,
/**
* Allocates pending allocations in the pool
+ * @returns -1 if it fails, 0 otherwise
*/
-void compute_memory_finalize_pending(struct compute_memory_pool* pool,
+int compute_memory_finalize_pending(struct compute_memory_pool* pool,
struct pipe_context * pipe)
{
struct compute_memory_item *pending_list = NULL, *end_p = NULL;
@@ -226,6 +235,8 @@ void compute_memory_finalize_pending(struct
compute_memory_pool* pool,
int64_t start_in_dw = 0;
+ int err = 0;
+
COMPUTE_DBG(pool->screen, "* compute_memory_finalize_pending()\n");
for (item = pool->item_list; item; item = item->next) {
@@ -293,7 +304,9 @@ void compute_memory_finalize_pending(struct
compute_memory_pool* pool,
* they aren't contiguous, so it will be impossible to allocate Item D.
*/
if (pool->size_in_dw < allocated+unallocated) {
- compute_memory_grow_pool(pool, pipe, allocated+unallocated);
+ err = compute_memory_grow_pool(pool, pipe,
allocated+unallocated);
+ if (err == -1)
+ return -1;
}
/* Loop through all the pending items, allocate space for them and
@@ -310,17 +323,20 @@ void compute_memory_finalize_pending(struct
compute_memory_pool* pool,
need += 1024 - (need % 1024);
if (need > 0) {
- compute_memory_grow_pool(pool,
+ err = compute_memory_grow_pool(pool,
pipe,
pool->size_in_dw + need);
}
else {
need = pool->size_in_dw / 10;
need += 1024 - (need % 1024);
- compute_memory_grow_pool(pool,
+ err = compute_memory_grow_pool(pool,
pipe,
pool->size_in_dw + need);
}
+
+ if (err == -1)
+ return -1;
}
COMPUTE_DBG(pool->screen, " + Found space for Item %p id = %u "
"start_in_dw = %u (%u bytes) size_in_dw = %u (%u
bytes)\n",
@@ -356,6 +372,8 @@ void compute_memory_finalize_pending(struct
compute_memory_pool* pool,
allocated += item->size_in_dw;
}
+
+ return 0;
}
diff --git a/src/gallium/drivers/r600/compute_memory_pool.h
b/src/gallium/drivers/r600/compute_memory_pool.h
index 3777e3f..e61c003 100644
--- a/src/gallium/drivers/r600
[Mesa-dev] [Bug 73672] Half Life 2 in Wine is broken since 4e549ddb
https://bugs.freedesktop.org/show_bug.cgi?id=73672 --- Comment #12 from Benjamin Bellec --- I compiled mesa 2 or 3 hours ago, this is mesa master. -- 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 4/5] r600g/compute: Tidy a bit compute_memory_finalize_pending
Explanation of the changes, as requested by Tom Stellard:
Let's take need after is calculated as
item->size_in_dw+2048 - (pool->size_in_dw - allocated)
BEFORE:
If need is positive or 0:
we calculate need += 1024 - (need % 1024), which is like
cealing to the nearest multiple of 1024, for example
0 goes to 1024, 512 goes to 1024 as well, 1025 goes
to 2048 and so on. So now need is always possitive,
we do compute_memory_grow_pool, check its output
and continue.
If need is negative:
we calculate need += 1024 - (need % 1024), in this case
we will have negative numbers, and if need is
[-1024:-1] 0, so now we take the else, recalculate
need as need = pool->size_in_dw / 10 and
need += 1024 - (need % 1024), we do
compute_memory_grow_pool, check its output and continue.
AFTER:
If need is positive or 0:
we jump the if, calculate need += 1024 - (need % 1024)
compute_memory_grow_pool, check its output and continue.
If need is negative:
we enter the if, and need is now pool->size_in_dw / 10.
Now we calculate need += 1024 - (need % 1024)
compute_memory_grow_pool, check its output and continue.
---
src/gallium/drivers/r600/compute_memory_pool.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 1e04639..7a3b92c 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/gallium/drivers/r600/compute_memory_pool.c
@@ -320,21 +320,16 @@ int compute_memory_finalize_pending(struct
compute_memory_pool* pool,
int64_t need = item->size_in_dw+2048 -
(pool->size_in_dw - allocated);
- need += 1024 - (need % 1024);
-
- if (need > 0) {
- err = compute_memory_grow_pool(pool,
- pipe,
- pool->size_in_dw + need);
- }
- else {
+ if (need < 0) {
need = pool->size_in_dw / 10;
- need += 1024 - (need % 1024);
- err = compute_memory_grow_pool(pool,
- pipe,
- pool->size_in_dw + need);
}
+ need += 1024 - (need % 1024);
+
+ err = compute_memory_grow_pool(pool,
+ pipe,
+ pool->size_in_dw + need);
+
if (err == -1)
return -1;
}
--
1.8.5.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] r600g/compute: Cleanup of compute_memory_pool.h
Removed compute_memory_defrag declaration because it seems to be unimplemented. I think that this function would have been the one that solves the problem with fragmentation that compute_memory_finalize_pending has. Also removed comments that are already at compute_memory_pool.c --- src/gallium/drivers/r600/compute_memory_pool.h | 15 --- 1 file changed, 15 deletions(-) diff --git a/src/gallium/drivers/r600/compute_memory_pool.h b/src/gallium/drivers/r600/compute_memory_pool.h index e61c003..c711c59 100644 --- a/src/gallium/drivers/r600/compute_memory_pool.h +++ b/src/gallium/drivers/r600/compute_memory_pool.h @@ -64,32 +64,17 @@ int64_t compute_memory_prealloc_chunk(struct compute_memory_pool* pool, int64_t struct compute_memory_item* compute_memory_postalloc_chunk(struct compute_memory_pool* pool, int64_t start_in_dw); ///search for the chunk where we can link our new chunk after it -/** - * reallocates pool, conserves data - * @returns -1 if it fails, 0 otherwise - */ int compute_memory_grow_pool(struct compute_memory_pool* pool, struct pipe_context * pipe, int new_size_in_dw); -/** - * Copy pool from device to host, or host to device - */ void compute_memory_shadow(struct compute_memory_pool* pool, struct pipe_context * pipe, int device_to_host); -/** - * Allocates pending allocations in the pool - * @returns -1 if it fails, 0 otherwise - */ int compute_memory_finalize_pending(struct compute_memory_pool* pool, struct pipe_context * pipe); -void compute_memory_defrag(struct compute_memory_pool* pool); ///Defragment the memory pool, always heavy memory usage void compute_memory_free(struct compute_memory_pool* pool, int64_t id); struct compute_memory_item* compute_memory_alloc(struct compute_memory_pool* pool, int64_t size_in_dw); ///Creates pending allocations -/** - * Transfer data host<->device, offset and size is in bytes - */ void compute_memory_transfer(struct compute_memory_pool* pool, struct pipe_context * pipe, int device_to_host, struct compute_memory_item* chunk, void* data, -- 1.8.5.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73776] NameError: name 'libloader' is not defined:
https://bugs.freedesktop.org/show_bug.cgi?id=73776 --- Comment #4 from Emil Velikov --- Interesting... where you guys when I've asked people to test the patches :) Jos van Wolput, Fabio Pedretti Rather than throwing random fragments of the build log, I would appreciate if you guys give us at least the configure options that you're using. Did you guys checked the attached patch ? Might be worth attaching the build log before/after applying it. -- 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 73776] NameError: name 'libloader' is not defined:
https://bugs.freedesktop.org/show_bug.cgi?id=73776
--- Comment #5 from Iaroslav ---
./configure --host=i586-suse-linux-gnu --build=i586-suse-linux-gnu
--program-prefix= --disable-dependency-tracking --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com
--mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking
--prefix=/usr --with-gallium-drivers=r600,r300,swrast,nouveau,radeonsi,svga,ilo
--with-dri-drivers=i965,i915,r200,radeon --disable-debug --enable-gallium-egl
--enable-shared-glapi --enable-glx-tls --enable-texture-float --enable-gles1
--enable-gles2 --with-egl-platforms=x11,drm --enable-opencl
--with-llvm-shared-libs --with-egl-platforms=x11,wayland,drm --enable-openvg
--enable-xa --enable-vdpau --enable-xvmc --enable-gbm --enable-gallium-gbm
--enable-gles1 --enable-gles2
[ 413s] gmake[3]: Entering directory
`/home/abuild/rpmbuild/BUILD/mesa/src/egl/main'
[ 413s] CC eglapi.lo
[ 413s] CC eglarray.lo
[ 413s] CC eglconfig.lo
[ 413s] CC eglcontext.lo
[ 414s] CC eglcurrent.lo
[ 414s] CC egldisplay.lo
[ 414s] CC egldriver.lo
[ 414s] CC eglfallbacks.lo
[ 414s] CC eglglobals.lo
[ 414s] CC eglimage.lo
[ 414s] CC egllog.lo
[ 414s] CC eglmisc.lo
[ 415s] CC eglmode.lo
[ 415s] CC eglscreen.lo
[ 415s] CC eglstring.lo
[ 415s] CC eglsurface.lo
[ 415s] CC eglsync.lo
[ 415s] CCLD libEGL.la
[ 416s] /usr/bin/mkdir -p ../../../lib;
[ 416s] ln -f .libs/libEGL.so.1.0.0 ../../../lib/libEGL.so.1
[ 416s] ln -sf libEGL.so.1 ../../../lib/libEGL.so
[ 416s] gmake[3]: Leaving directory
`/home/abuild/rpmbuild/BUILD/mesa/src/egl/main'
[ 416s] gmake[3]: Entering directory
`/home/abuild/rpmbuild/BUILD/mesa/src/egl'
[ 416s] gmake[3]: Nothing to be done for `all-am'.
[ 416s] gmake[3]: Leaving directory `/home/abuild/rpmbuild/BUILD/mesa/src/egl'
[ 416s] gmake[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/mesa/src/egl'
[ 416s] Making all in gallium/auxiliary
[ 416s] gmake[2]: Entering directory
`/home/abuild/rpmbuild/BUILD/mesa/src/gallium/auxiliary'
[ 416s] Making all in pipe-loader
[ 416s] gmake[3]: Entering directory
`/home/abuild/rpmbuild/BUILD/mesa/src/gallium/auxiliary/pipe-loader'
[ 416s] CC pipe_loader.lo
[ 416s] CC pipe_loader_sw.lo
[ 416s] CC pipe_loader_drm.lo
[ 416s] pipe_loader_drm.c: In function 'pipe_loader_drm_probe_fd':
[ 416s] pipe_loader_drm.c:120:4: error: implicit declaration of function
'loader_get_pci_id_for_fd' [-Werror=implicit-function-declaration]
[ 416s] if (loader_get_pci_id_for_fd(fd, &vendor_id, &chip_id)) {
[ 416s] ^
[ 416s] pipe_loader_drm.c:132:4: error: implicit declaration of function
'loader_get_driver_for_fd' [-Werror=implicit-function-declaration]
[ 416s] ddev->base.driver_name = loader_get_driver_for_fd(fd,
_LOADER_GALLIUM);
[ 416s] ^
[ 416s] pipe_loader_drm.c:132:58: error: '_LOADER_GALLIUM' undeclared (first
use in this function)
[ 416s] ddev->base.driver_name = loader_get_driver_for_fd(fd,
_LOADER_GALLIUM);
[ 416s] ^
[ 416s] pipe_loader_drm.c:132:58: note: each undeclared identifier is reported
only once for each function it appears in
[ 416s] cc1: some warnings being treated as errors
[ 416s] gmake[3]: *** [pipe_loader_drm.lo] Error 1
[ 416s] gmake[3]: *** Waiting for unfinished jobs
[ 416s] gmake[3]: Leaving directory
`/home/abuild/rpmbuild/BUILD/mesa/src/gallium/auxiliary/pipe-loader'
[ 416s] gmake[2]: *** [all-recursive] Error 1
[ 416s] gmake[2]: Leaving directory
`/home/abuild/rpmbuild/BUILD/mesa/src/gallium/auxiliary'
[ 416s] gmake[1]: *** [all-recursive] Error 1
[ 416s] gmake[1]: Leaving directory `/home/abuild/rpmbuild/BUILD/mesa/src'
[ 416s] make: *** [all-recursive] Error 1
[ 416s] error: Bad exit status from /var/tmp/rpm-tmp.H3SoeV (%build)
--
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] pipe-loader: Fix build
pipe_loader_drm.c: In function 'pipe_loader_drm_probe_fd': pipe_loader_drm.c:120:4: error: implicit declaration of function 'loader_get_pci_id_for_fd' [-Werror=implicit-function-declaration] --- src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c index d70a428..d6869fd 100644 --- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c @@ -41,6 +41,7 @@ #endif +#include "loader.h" #include "state_tracker/drm_driver.h" #include "pipe_loader_priv.h" -- 1.8.5.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73776] NameError: name 'libloader' is not defined:
https://bugs.freedesktop.org/show_bug.cgi?id=73776 --- Comment #6 from Armin K --- I've sent a patch for this not 5 minutes ago. -- 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 73672] Half Life 2 in Wine is broken since 4e549ddb
https://bugs.freedesktop.org/show_bug.cgi?id=73672 Marek Olšák changed: What|Removed |Added Component|Mesa core |Drivers/Gallium/r600 --- Comment #13 from Marek Olšák --- Is there any free wine test or game that I can use to reproduce this bug? -- 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 73672] Half Life 2 in Wine is broken since 4e549ddb
https://bugs.freedesktop.org/show_bug.cgi?id=73672 Marek Olšák changed: What|Removed |Added Component|Drivers/Gallium/r600|Mesa core -- 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] pipe-loader: Fix build
On 19/01/14 14:09, Armin K wrote: > pipe_loader_drm.c: In function 'pipe_loader_drm_probe_fd': > pipe_loader_drm.c:120:4: error: implicit declaration of function > 'loader_get_pci_id_for_fd' [-Werror=implicit-function-declaration] > --- Reviewed-by: Emil Velikov Seems like I failed at git rebase, thanks for the fix Armin. I'll push this shortly, alongside the other build fix. -Emil > src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c > b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c > index d70a428..d6869fd 100644 > --- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c > +++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c > @@ -41,6 +41,7 @@ > > #endif > > +#include "loader.h" > #include "state_tracker/drm_driver.h" > #include "pipe_loader_priv.h" > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73776] NameError: name 'libloader' is not defined:
https://bugs.freedesktop.org/show_bug.cgi?id=73776 Emil Velikov changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=73777 --- Comment #7 from Emil Velikov --- Just pushed a couple of fixes that should address all the reported issues. Namely - bug 73776, bug 73777 and the pipe-loader issue reported via irc and here. Vinson, please update the bugs when you have the chance to check the fix. -- 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 73777] xf86drm.h:40:17: error: drm.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=73777 Emil Velikov changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=73776 -- 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 demos] opengles2/es2tri: add precision qualifier to the fragment shader
The missing qualifier causes failure during the compilation stage.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73631
Signed-off-by: Emil Velikov
---
src/egl/opengles2/es2tri.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/egl/opengles2/es2tri.c b/src/egl/opengles2/es2tri.c
index 6dcc1b8..349a576 100644
--- a/src/egl/opengles2/es2tri.c
+++ b/src/egl/opengles2/es2tri.c
@@ -139,6 +139,7 @@ static void
create_shaders(void)
{
static const char *fragShaderText =
+ "precision mediump float;\n"
"varying vec4 v_color;\n"
"void main() {\n"
" gl_FragColor = v_color;\n"
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73631] es2tri fragment shader did not compile AMD ARUBA
https://bugs.freedesktop.org/show_bug.cgi?id=73631 --- Comment #4 from Emil Velikov --- Patch send to the ML http://lists.freedesktop.org/archives/mesa-dev/2014-January/051916.html -- 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 73672] Half Life 2 in Wine is broken since 4e549ddb
https://bugs.freedesktop.org/show_bug.cgi?id=73672 --- Comment #14 from Benjamin Bellec --- (In reply to comment #13) > Is there any free wine test or game that I can use to reproduce this bug? I tested several free or open-source games but none of them are impacted (Xonotic, 0AD, Ryzom, Yo Frankie!, TA Spring). So it looks like this mostly hits the games using the Valve's Source engine. I'm currently downloading Team Fortress 2 (which is free to play) given that it is based on the Source engine. -- 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 73776] NameError: name 'libloader' is not defined:
https://bugs.freedesktop.org/show_bug.cgi?id=73776 Vinson Lee changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Vinson Lee --- commit 26d380da69d3fc3a4ced291028c105c0ac0f1a92 Author: Emil Velikov Date: Sun Jan 19 03:09:03 2014 + loader: ifdef libdrm specific code and include Mesa provides the flexibility of building without the need to have libdrm present on the system. The situation has regressed with the recent commit commit 8c2e7fd8460750543367053b1be9368cc38e1d6a Author: Emil Velikov Date: Fri Jan 10 23:36:16 2014 + loader: introduce the loader util lib By isolating libdrm code by #ifndef __NOT_HAVE_DRM_H we can have libdrm-less builds on across all build systems. This patch converts Android's _EGL_NO_DRM to __NOT_HAVE_DRM_H to provide consistency with the other cases within mesa, allows compilation of libloader on libdrm-less scons and conditionally links against libdrm if present under automake. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73776 BUgzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73777 Signed-off-by: Emil Velikov Reviewed-by: Kenneth Graunke -- 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 73777] xf86drm.h:40:17: error: drm.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=73777 Vinson Lee changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Vinson Lee --- commit 26d380da69d3fc3a4ced291028c105c0ac0f1a92 Author: Emil Velikov Date: Sun Jan 19 03:09:03 2014 + loader: ifdef libdrm specific code and include Mesa provides the flexibility of building without the need to have libdrm present on the system. The situation has regressed with the recent commit commit 8c2e7fd8460750543367053b1be9368cc38e1d6a Author: Emil Velikov Date: Fri Jan 10 23:36:16 2014 + loader: introduce the loader util lib By isolating libdrm code by #ifndef __NOT_HAVE_DRM_H we can have libdrm-less builds on across all build systems. This patch converts Android's _EGL_NO_DRM to __NOT_HAVE_DRM_H to provide consistency with the other cases within mesa, allows compilation of libloader on libdrm-less scons and conditionally links against libdrm if present under automake. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73776 BUgzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73777 Signed-off-by: Emil Velikov Reviewed-by: Kenneth Graunke -- 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 73808] New: loader.c(90) : error C2365: 'log' : redefinition; previous definition was 'function'
https://bugs.freedesktop.org/show_bug.cgi?id=73808 Priority: medium Bug ID: 73808 Keywords: regression CC: emil.l.veli...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: loader.c(90) : error C2365: 'log' : redefinition; previous definition was 'function' Severity: blocker Classification: Unclassified OS: Windows (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa mesa: ad3c99e22a688b7c3f15894aabbedcc5cd89230b (master) MSVC build regression Compiling src\loader\loader.c ... loader.c src\loader\loader.c(90) : error C2365: 'log' : redefinition; previous definition was 'function' src\loader\loader.c(313) : error C2167: 'log' : too many actual parameters for intrinsic function src\loader\loader.c(320) : warning C4133: '=' : incompatible types - from 'void (__cdecl *)(int,const char *,...)' to 'double (__cdecl *)()' src\loader\loader.c(320) : error C2106: '=' : left operand must be l-value src\loader\loader.c(320) : warning C4550: expression evaluates to a function which is missing an argument list -- 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 73672] Half Life 2 in Wine is broken since 4e549ddb
https://bugs.freedesktop.org/show_bug.cgi?id=73672 --- Comment #15 from Alexandre Demers --- (In reply to comment #13) > Is there any free wine test or game that I can use to reproduce this bug? Confirmed with Team Forteress 2. -- 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 00/37] GL_ARB_viewport_array v2
On 01/17/2014 05:03 PM, Ian Romanick wrote: > This is the overall v2 of the GL_ARB_viewport_array series. It is > mostly the same as the previous series, but there are some differences > worth noting. > > Patch "i965: Consider all scissor rectangles in noop_scissor" in the > original series was replaced by "i965: Consider only the scissor > rectangle for viewport 0" in this series. As I mentioned on the > previous e-mail thread, the original patch was incorrect. > > In addition, per Ken's suggestion, "mesa: Update viewport state for > viewport_array" in the previous series has been split into several > patches (05 through 08) in the new series. There were a couple > non-cosmetic changes in the process (e.g., changing the Viewport[XYHW] > storage in meta to float). > > I believe this series is good to go, and I'd like to land it Monday or > Tuesday. The rest of the series is also: Reviewed-by: Kenneth Graunke Landing it Monday seems reasonable to me. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Add GS support to INTEL_DEBUG=shader_time.
On 01/17/2014 02:51 PM, Paul Berry wrote: > Previously, time spent in geometry shaders would be counted as part of > the vertex shader time. Oof. Nice catch. Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73672] Half Life 2 in Wine is broken since 4e549ddb
https://bugs.freedesktop.org/show_bug.cgi?id=73672 --- Comment #16 from Marek Olšák --- (In reply to comment #15) > (In reply to comment #13) > > Is there any free wine test or game that I can use to reproduce this bug? > > Confirmed with Team Forteress 2. TF2 for Windows or TF2 for Linux? -- 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] mesa: use _mesa_shader_stage_to_string() to generate file extension
ping ?
On 10/01/14 18:44, Emil Velikov wrote:
> Signed-off-by: Emil Velikov
> ---
>
> Hi Paul,
>
> Here is another small cleanup inspired by your work. Not
> entirely sure that the last hunk is correct though.
>
> Cheers,
> Emil
>
> ---
> src/mesa/program/prog_print.c | 26 +-
> 1 file changed, 5 insertions(+), 21 deletions(-)
>
> diff --git a/src/mesa/program/prog_print.c b/src/mesa/program/prog_print.c
> index 9391e99..4962401 100644
> --- a/src/mesa/program/prog_print.c
> +++ b/src/mesa/program/prog_print.c
> @@ -31,6 +31,7 @@
>
> #include /* for PRIx64 macro */
>
> +#include "glsl_parser_extras.h"
> #include "main/glheader.h"
> #include "main/context.h"
> #include "main/imports.h"
> @@ -1005,23 +1006,11 @@ _mesa_print_parameter_list(const struct
> gl_program_parameter_list *list)
> void
> _mesa_write_shader_to_file(const struct gl_shader *shader)
> {
> - const char *type = "";
> char filename[100];
> FILE *f;
>
> - switch (shader->Stage) {
> - case MESA_SHADER_FRAGMENT:
> - type = "frag";
> - break;
> - case MESA_SHADER_VERTEX:
> - type = "vert";
> - break;
> - case MESA_SHADER_GEOMETRY:
> - type = "geom";
> - break;
> - }
> -
> - _mesa_snprintf(filename, sizeof(filename), "shader_%u.%s", shader->Name,
> type);
> + _mesa_snprintf(filename, sizeof(filename), "shader_%u.%.4s", shader->Name,
> + _mesa_shader_stage_to_string(shader->Stage));
> f = fopen(filename, "w");
> if (!f) {
>fprintf(stderr, "Unable to open %s for writing\n", filename);
> @@ -1062,16 +1051,11 @@ void
> _mesa_append_uniforms_to_file(const struct gl_shader *shader)
> {
> const struct gl_program *const prog = shader->Program;
> - const char *type;
> char filename[100];
> FILE *f;
>
> - if (shader->Stage == MESA_SHADER_FRAGMENT)
> - type = "frag";
> - else
> - type = "vert";
> -
> - _mesa_snprintf(filename, sizeof(filename), "shader_%u.%s", shader->Name,
> type);
> + _mesa_snprintf(filename, sizeof(filename), "shader_%u.%.4s", shader->Name,
> + _mesa_shader_stage_to_string(shader->Stage));
> f = fopen(filename, "a"); /* append */
> if (!f) {
>fprintf(stderr, "Unable to open %s for appending\n", filename);
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Modify some error messages to refer to "vec4" instead of "vs".
On 01/17/2014 02:14 PM, Paul Berry wrote:
> These messages are in code that is shared between the VS and GS
> back-ends, so use the terminology "vec4" to avoid confusion.
> ---
> src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 8
> src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
> index c1ef81d..51e88d2 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
> @@ -327,7 +327,7 @@ vec4_generator::generate_tex(vec4_instruction *inst,
> }
> break;
>default:
> - assert(!"should not get here: invalid VS texture opcode");
> + assert(!"should not get here: invalid vec4 texture opcode");
>break;
>}
> } else {
> @@ -356,7 +356,7 @@ vec4_generator::generate_tex(vec4_instruction *inst,
>assert(inst->mlen == 2);
>break;
>default:
> - assert(!"should not get here: invalid VS texture opcode");
> + assert(!"should not get here: invalid vec4 texture opcode");
>break;
>}
> }
> @@ -1218,10 +1218,10 @@
> vec4_generator::generate_vec4_instruction(vec4_instruction *instruction,
>
> default:
>if (inst->opcode < (int) ARRAY_SIZE(opcode_descs)) {
> - _mesa_problem(&brw->ctx, "Unsupported opcode in `%s' in VS\n",
> + _mesa_problem(&brw->ctx, "Unsupported opcode in `%s' in vec4\n",
> opcode_descs[inst->opcode].name);
>} else {
> - _mesa_problem(&brw->ctx, "Unsupported opcode %d in VS",
> inst->opcode);
> + _mesa_problem(&brw->ctx, "Unsupported opcode %d in vec4",
> inst->opcode);
>}
>abort();
> }
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> index 3b8cef6..81906e8 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> @@ -3343,7 +3343,7 @@ vec4_visitor::fail(const char *format, ...)
> va_start(va, format);
> msg = ralloc_vasprintf(mem_ctx, format, va);
> va_end(va);
> - msg = ralloc_asprintf(mem_ctx, "VS compile failed: %s\n", msg);
> + msg = ralloc_asprintf(mem_ctx, "vec4 compile failed: %s\n", msg);
>
> this->fail_msg = msg;
>
>
Reviewed-by: Kenneth Graunke
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/rtasm: handle mmap failures appropriately
For a variety of reasons mmap (selinux and pax to name
a few) and can fail and with current code. This will
result in a crash in the driver, if not worse.
This has been the case since the inception of the
gallium copy of rtasm.
Cc: 9.1 9.2 10.0
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73473
Signed-off-by: Emil Velikov
---
v2: droped the selinux part, leaving only the crucial mmap check
Gents can someone take a look at this trivial patch.
Cheers,
Emil
---
src/gallium/auxiliary/rtasm/rtasm_execmem.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
index edc1b66..8c3dbef 100644
--- a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
+++ b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
@@ -69,7 +69,7 @@ static struct mem_block *exec_heap = NULL;
static unsigned char *exec_mem = NULL;
-static void
+static int
init_heap(void)
{
if (!exec_heap)
@@ -79,6 +79,8 @@ init_heap(void)
exec_mem = (unsigned char *) mmap(0, EXEC_HEAP_SIZE,
PROT_EXEC | PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+
+ return (exec_mem != MAP_FAILED);
}
@@ -90,7 +92,8 @@ rtasm_exec_malloc(size_t size)
pipe_mutex_lock(exec_mutex);
- init_heap();
+ if (!init_heap())
+ goto bail;
if (exec_heap) {
size = (size + 31) & ~31; /* next multiple of 32 bytes */
@@ -101,7 +104,8 @@ rtasm_exec_malloc(size_t size)
addr = exec_mem + block->ofs;
else
debug_printf("rtasm_exec_malloc failed\n");
-
+
+bail:
pipe_mutex_unlock(exec_mutex);
return addr;
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Move binding table update packets to binding table setup time.
On 01/15/2014 09:43 PM, Eric Anholt wrote:
> This keeps us from needing to reemit all the other stage state just
> because a surface changed.
>
> Improves unoptimized glamor x11perf -f8text by 1.10201% +/- 0.489869%
> (n=296).
> ---
> src/mesa/drivers/dri/i965/brw_binding_tables.c | 51
> --
> src/mesa/drivers/dri/i965/gen7_gs_state.c | 7
> src/mesa/drivers/dri/i965/gen7_vs_state.c | 7
> src/mesa/drivers/dri/i965/gen7_wm_state.c | 7
> 4 files changed, 39 insertions(+), 33 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_binding_tables.c
> b/src/mesa/drivers/dri/i965/brw_binding_tables.c
> index b39bd10..ca42472 100644
> --- a/src/mesa/drivers/dri/i965/brw_binding_tables.c
> +++ b/src/mesa/drivers/dri/i965/brw_binding_tables.c
> @@ -50,7 +50,7 @@
> * This copies brw_stage_state::surf_offset[] into the indirect state section
> * of the batchbuffer (allocated by brw_state_batch()).
> */
> -static void
> +static bool
> brw_upload_binding_table(struct brw_context *brw,
> GLbitfield brw_new_binding_table,
> struct brw_stage_state *stage_state)
> @@ -63,8 +63,9 @@ brw_upload_binding_table(struct brw_context *brw,
>if (stage_state->bind_bo_offset != 0) {
> brw->state.dirty.brw |= brw_new_binding_table;
> stage_state->bind_bo_offset = 0;
> + return true;
>}
> - return;
> + return false;
> }
>
> if (INTEL_DEBUG & DEBUG_SHADER_TIME) {
> @@ -81,6 +82,7 @@ brw_upload_binding_table(struct brw_context *brw,
> memcpy(bind, stage_state->surf_offset,
> prog_data->binding_table.size_bytes);
>
> brw->state.dirty.brw |= brw_new_binding_table;
> + return true;
> }
>
> /**
> @@ -92,15 +94,23 @@ brw_upload_binding_table(struct brw_context *brw,
> static void
> brw_vs_upload_binding_table(struct brw_context *brw)
> {
> - brw_upload_binding_table(brw, BRW_NEW_VS_BINDING_TABLE, &brw->vs.base);
> + if (brw_upload_binding_table(brw, BRW_NEW_VS_BINDING_TABLE,
> &brw->vs.base)) {
> + if (brw->gen >= 7) {
> + BEGIN_BATCH(2);
> + OUT_BATCH(_3DSTATE_BINDING_TABLE_POINTERS_VS << 16 | (2 - 2));
> + OUT_BATCH(brw->vs.base.bind_bo_offset);
> + ADVANCE_BATCH();
> + }
> + }
As is, this patch is
Reviewed-by: Kenneth Graunke
That said, I wonder if you couldn't pass the
_3DSTATE_BINDING_TABLE_POINTERS_[VHGDP]S enum to
brw_upload_binding_table and do this small BEGIN_BATCH there.
Would save some code...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73672] Half Life 2 in Wine is broken since 4e549ddb
https://bugs.freedesktop.org/show_bug.cgi?id=73672 --- Comment #17 from Alexandre Demers --- (In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #13) > > > Is there any free wine test or game that I can use to reproduce this bug? > > > > Confirmed with Team Forteress 2. > > TF2 for Windows or TF2 for Linux? Linux. -- 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] mesa: use _mesa_shader_stage_to_string() to generate file extension
What do you plan on using for `tesselation control` and `tesselation
evaluation` shaders?
On Mon, Jan 20, 2014 at 12:56 PM, Emil Velikov wrote:
> ping ?
>
> On 10/01/14 18:44, Emil Velikov wrote:
>> Signed-off-by: Emil Velikov
>> ---
>>
>> Hi Paul,
>>
>> Here is another small cleanup inspired by your work. Not
>> entirely sure that the last hunk is correct though.
>>
>> Cheers,
>> Emil
>>
>> ---
>> src/mesa/program/prog_print.c | 26 +-
>> 1 file changed, 5 insertions(+), 21 deletions(-)
>>
>> diff --git a/src/mesa/program/prog_print.c b/src/mesa/program/prog_print.c
>> index 9391e99..4962401 100644
>> --- a/src/mesa/program/prog_print.c
>> +++ b/src/mesa/program/prog_print.c
>> @@ -31,6 +31,7 @@
>>
>> #include /* for PRIx64 macro */
>>
>> +#include "glsl_parser_extras.h"
>> #include "main/glheader.h"
>> #include "main/context.h"
>> #include "main/imports.h"
>> @@ -1005,23 +1006,11 @@ _mesa_print_parameter_list(const struct
>> gl_program_parameter_list *list)
>> void
>> _mesa_write_shader_to_file(const struct gl_shader *shader)
>> {
>> - const char *type = "";
>> char filename[100];
>> FILE *f;
>>
>> - switch (shader->Stage) {
>> - case MESA_SHADER_FRAGMENT:
>> - type = "frag";
>> - break;
>> - case MESA_SHADER_VERTEX:
>> - type = "vert";
>> - break;
>> - case MESA_SHADER_GEOMETRY:
>> - type = "geom";
>> - break;
>> - }
>> -
>> - _mesa_snprintf(filename, sizeof(filename), "shader_%u.%s", shader->Name,
>> type);
>> + _mesa_snprintf(filename, sizeof(filename), "shader_%u.%.4s",
>> shader->Name,
>> + _mesa_shader_stage_to_string(shader->Stage));
>> f = fopen(filename, "w");
>> if (!f) {
>>fprintf(stderr, "Unable to open %s for writing\n", filename);
>> @@ -1062,16 +1051,11 @@ void
>> _mesa_append_uniforms_to_file(const struct gl_shader *shader)
>> {
>> const struct gl_program *const prog = shader->Program;
>> - const char *type;
>> char filename[100];
>> FILE *f;
>>
>> - if (shader->Stage == MESA_SHADER_FRAGMENT)
>> - type = "frag";
>> - else
>> - type = "vert";
>> -
>> - _mesa_snprintf(filename, sizeof(filename), "shader_%u.%s", shader->Name,
>> type);
>> + _mesa_snprintf(filename, sizeof(filename), "shader_%u.%.4s",
>> shader->Name,
>> + _mesa_shader_stage_to_string(shader->Stage));
>> f = fopen(filename, "a"); /* append */
>> if (!f) {
>>fprintf(stderr, "Unable to open %s for appending\n", filename);
>>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: use _mesa_shader_stage_to_string() to generate file extension
On 20/01/14 00:27, Chris Forbes wrote:
> What do you plan on using for `tesselation control` and `tesselation
> evaluation` shaders?
>
Ouch very nice argument. I only had vertex, fragment and compute shaders
in mind.
Please ignore my rumbling.
-Emil
> On Mon, Jan 20, 2014 at 12:56 PM, Emil Velikov
> wrote:
>> ping ?
>>
>> On 10/01/14 18:44, Emil Velikov wrote:
>>> Signed-off-by: Emil Velikov
>>> ---
>>>
>>> Hi Paul,
>>>
>>> Here is another small cleanup inspired by your work. Not
>>> entirely sure that the last hunk is correct though.
>>>
>>> Cheers,
>>> Emil
>>>
>>> ---
>>> src/mesa/program/prog_print.c | 26 +-
>>> 1 file changed, 5 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/src/mesa/program/prog_print.c b/src/mesa/program/prog_print.c
>>> index 9391e99..4962401 100644
>>> --- a/src/mesa/program/prog_print.c
>>> +++ b/src/mesa/program/prog_print.c
>>> @@ -31,6 +31,7 @@
>>>
>>> #include /* for PRIx64 macro */
>>>
>>> +#include "glsl_parser_extras.h"
>>> #include "main/glheader.h"
>>> #include "main/context.h"
>>> #include "main/imports.h"
>>> @@ -1005,23 +1006,11 @@ _mesa_print_parameter_list(const struct
>>> gl_program_parameter_list *list)
>>> void
>>> _mesa_write_shader_to_file(const struct gl_shader *shader)
>>> {
>>> - const char *type = "";
>>> char filename[100];
>>> FILE *f;
>>>
>>> - switch (shader->Stage) {
>>> - case MESA_SHADER_FRAGMENT:
>>> - type = "frag";
>>> - break;
>>> - case MESA_SHADER_VERTEX:
>>> - type = "vert";
>>> - break;
>>> - case MESA_SHADER_GEOMETRY:
>>> - type = "geom";
>>> - break;
>>> - }
>>> -
>>> - _mesa_snprintf(filename, sizeof(filename), "shader_%u.%s",
>>> shader->Name, type);
>>> + _mesa_snprintf(filename, sizeof(filename), "shader_%u.%.4s",
>>> shader->Name,
>>> + _mesa_shader_stage_to_string(shader->Stage));
>>> f = fopen(filename, "w");
>>> if (!f) {
>>>fprintf(stderr, "Unable to open %s for writing\n", filename);
>>> @@ -1062,16 +1051,11 @@ void
>>> _mesa_append_uniforms_to_file(const struct gl_shader *shader)
>>> {
>>> const struct gl_program *const prog = shader->Program;
>>> - const char *type;
>>> char filename[100];
>>> FILE *f;
>>>
>>> - if (shader->Stage == MESA_SHADER_FRAGMENT)
>>> - type = "frag";
>>> - else
>>> - type = "vert";
>>> -
>>> - _mesa_snprintf(filename, sizeof(filename), "shader_%u.%s",
>>> shader->Name, type);
>>> + _mesa_snprintf(filename, sizeof(filename), "shader_%u.%.4s",
>>> shader->Name,
>>> + _mesa_shader_stage_to_string(shader->Stage));
>>> f = fopen(filename, "a"); /* append */
>>> if (!f) {
>>>fprintf(stderr, "Unable to open %s for appending\n", filename);
>>>
>>
>> ___
>> 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] GalliumCompute / OpenCL on Radeon HD7790
This page:
http://dri.freedesktop.org/wiki/GalliumCompute/
says "Evergreen through Southern Islands GPU families are currently
supported."
It's unclear (at least to me) whether HD7790 ("Sea Islands") cards are
supposed to be included in this; apparently the GPUs are similar to the
rest of the 7000 series.
This article:
http://www.phoronix.com/scan.php?page=news_item&px=MTM5ODU
suggests that the answer might be "yes", but it doesn't specifically
mention GalliumCompute or OpenCL.
Could anybody clarify whether the information on the wiki page should
apply to a Radeon HD7790 card? Could the wiki be updated to be more
specific about which GPUs it is relevant to?
Also, could the build instructions comment on whether packages from the
Linux distribution (Debian?) might do as well? Or would those not have
been built with options like "--enable-experimental-targets=R600",
"--with-gallium-drivers=r600", and "--enable-opencl"?
Please CC me on any replies, as I'm not subscribed to these lists.
Thanks.
-- Ian Bruce
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] cl: Add support for OpenCV unit tests v2
I think you meant to ping the piglit list not mesa dev :)
In general this looks a lot better, I've got a few little things for you
On Friday, January 17, 2014 02:30:13 PM Tom Stellard wrote:
> From: Tom Stellard
>
> This enables piglit to run and interpret the results from OpenCV's
> gtest based opencv_test_ocl program.
>
> This patch adds two new CMake configuration variables:
>
> OPENCL_OpenCVTestOCL_BINDIR: You can use this variable to enable
> the OpenCV tests by setting it to the full path of the
> bin directory in your opencv build tree (e.g. /home/user/opencv/build/bin).
>
> OPENCL_OpenCVTestOCL_WORKDIR: (Optional)If you don't want to use
> OpenCV's default work directory, you can use this variable to specify
> a different one.
>
> v2:
> - Python code cleanups
>
> XXX: opencv
> ---
> CMakeLists.txt| 9 ++-
> tests/all_cl.py | 4 ++
> tests/cl/program/execute/opencv-merge-hist.cl | 98
> --- tests/ocl_config.py.in|
> 31 +
> tests/opencv.py | 76 +
> 5 files changed, 119 insertions(+), 99 deletions(-)
> delete mode 100644 tests/cl/program/execute/opencv-merge-hist.cl
> create mode 100644 tests/ocl_config.py.in
> create mode 100644 tests/opencv.py
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 1befffb..37eac65 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -92,7 +92,10 @@ if(PIGLIT_BUILD_GLES3_TESTS AND NOT PIGLIT_USE_WAFFLE)
> endif(PIGLIT_BUILD_GLES3_TESTS AND NOT PIGLIT_USE_WAFFLE)
>
> if(PIGLIT_BUILD_CL_TESTS)
> - find_package(OpenCL REQUIRED)
> +find_package(OpenCL REQUIRED)
> +set(OPENCL_OpenCVTestOCL_BINDIR "" CACHE STRING "Directory with the
> opencv_ocl_test program" ) +set(OPENCL_OpenCVTestOCL_WORKDIR ""
> CACHE STRING
> +"Directory with the opencv test resources (This is not needed
> if your OpenCV build directory was $(opencv_src_dir)/build )" )
> endif(PIGLIT_BUILD_CL_TESTS)
>
> IF(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
> @@ -356,6 +359,10 @@ configure_file(
> "${piglit_SOURCE_DIR}/tests/util/config.h.in"
> "${piglit_BINARY_DIR}/tests/util/config.h"
> )
> +configure_file(
> + "${piglit_SOURCE_DIR}/tests/ocl_config.py.in"
> + "${piglit_BINARY_DIR}/tests/ocl_config.py"
> +)
>
> include(cmake/piglit_util.cmake)
> include(cmake/piglit_glapi.cmake)
> diff --git a/tests/all_cl.py b/tests/all_cl.py
> index a7d7106..b9c112a 100644
> --- a/tests/all_cl.py
> +++ b/tests/all_cl.py
> @@ -7,6 +7,8 @@ __all__ = ['profile']
> import os
> import os.path as path
>
> +from tests.opencv import add_opencv_tests
> +
> from framework.core import Group, TestProfile
> from framework.exectest import PlainExecTest
>
> @@ -122,3 +124,5 @@ add_program_test_dir(program_execute_builtin,
> 'generated_tests/cl/builtin/relati program_execute_store = Group()
> program["Execute"]["Store"] = program_execute_store
> add_program_test_dir(program_execute_store, 'generated_tests/cl/store')
> +
> +add_opencv_tests(profile)
> diff --git a/tests/cl/program/execute/opencv-merge-hist.cl
> b/tests/cl/program/execute/opencv-merge-hist.cl deleted file mode 100644
> index 8dccf24..000
> --- a/tests/cl/program/execute/opencv-merge-hist.cl
> +++ /dev/null
> @@ -1,98 +0,0 @@
> -/*!
> -[config]
> -name: OpenCV merge-hist
> -kernel_name: merge_hist
> -dimensions: 1
> -global_size: 65536 1 1
> -local_size: 256 1 1
> -
> -# This test checks that the loop:
> -# for(int stride = HISTOGRAM256_WORK_GROUP_SIZE /2; stride > 0; stride >>=
> 1) -# in this kernel is unrolled correctly or not unrolled at all. The
> Clang -# OpenCL frontend was unrolling this in way that created illegal
> uses of the -# barrier() builtin which resulted in GPU hangs on r600g.
> -[test]
> -arg_in: 0 buffer int[65536] repeat 0
> -arg_out: 1 buffer int[256] repeat 0
> -arg_in: 2 int 256
> -
> -!*/
> -
> -// The kernel in this test is taken from the opencv library (opencv.org)
> -// File: modules/ocl/src/opencl/imgproc_histogram.cl
> -//
> -// License Agreement
> -//For Open Source Computer Vision Library
> -//
> -// Copyright (C) 2010-2012, Institute Of Software Chinese Academy Of
> Science, all rights reserved. -// Copyright (C) 2010-2012, Advanced Micro
> Devices, Inc., all rights reserved. -// Copyright (C) 2010-2012,
> Multicoreware, Inc., all rights reserved. -// Third party copyrights are
> property of their respective owners. -//
> -// @Authors
> -//Niko Li, newlife20080...@gmail.com
> -//Jia Haipeng, jiahaipen...@gmail.com
> -//Xu Pang, pangxu...@163.com
> -//Wenju He, we...@multicorewareinc.com
> -// Redistribution and use in source and binary forms, with or without
> modification, -// are permitted provided that the following conditions are
> met:
> -//
> -// * Redistribution's of source code must retain the above copyri
Re: [Mesa-dev] GalliumCompute / OpenCL on Radeon HD7790
On Son, 2014-01-19 at 09:20 -0800, ian_br...@fastmail.net wrote:
> This page:
>
> http://dri.freedesktop.org/wiki/GalliumCompute/
>
> says "Evergreen through Southern Islands GPU families are currently
> supported."
>
> It's unclear (at least to me) whether HD7790 ("Sea Islands") cards are
> supposed to be included in this; apparently the GPUs are similar to the
> rest of the 7000 series.
>
> This article:
>
> http://www.phoronix.com/scan.php?page=news_item&px=MTM5ODU
>
> suggests that the answer might be "yes", but it doesn't specifically
> mention GalliumCompute or OpenCL.
>
> Could anybody clarify whether the information on the wiki page should
> apply to a Radeon HD7790 card?
AFAIK it should.
> Also, could the build instructions comment on whether packages from the
> Linux distribution (Debian?) might do as well? Or would those not have
> been built with options like "--enable-experimental-targets=R600",
> "--with-gallium-drivers=r600", and "--enable-opencl"?
The Debian Mesa packages aren't built with --enable-opencl yet, there
are Debian bug reports requesting that.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [V3 PATCH 4/8] mesa: MESA_FORMAT Type P Conversion
On Fre, 2014-01-17 at 03:47 -0800, Mark Mueller wrote: > > diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h > index 348d2f4..fb43c83 100644 > --- a/src/mesa/main/formats.h > +++ b/src/mesa/main/formats.h > @@ -182,14 +182,14 @@ typedef enum > MESA_FORMAT_RGB_UNORM8, > > /* Type P formats */ > - MESA_FORMAT_RGB565, /* RGGG GGGB > */ > - MESA_FORMAT_RGB565_REV, /* GGGB RGGG */ > - MESA_FORMAT_ARGB, /* */ > - MESA_FORMAT_ARGB_REV, /* */ > - MESA_FORMAT_RGBA5551,/* RGGG GGBB BBBA */ > - MESA_FORMAT_ARGB1555, /* ARRR RRGG GGGB */ > - MESA_FORMAT_ARGB1555_REV, /* GGGB ARRR RRGG */ > - MESA_FORMAT_AL44, /* */ > + MESA_FORMAT_B5G6R5_UNORM, /* BGGG GGGR */ > + MESA_FORMAT_R5G6B5_UNORM, /* RGGG GGGB */ > + MESA_FORMAT_B4G4R4A4_UNORM, /* */ > + MESA_FORMAT_A4R4G4B4_UNORM, /* */ > + MESA_FORMAT_A1B5G5R5_UNORM, /* ARRR RRGG GGGB */ > + MESA_FORMAT_B5G5R5A1_UNORM, /* BGGG GGRR RRRA */ > + MESA_FORMAT_A1R5G5B5_UNORM, /* ARRR RRGG GGGB */ > + MESA_FORMAT_L4A4_UNORM, /* */ Please keep these comments aligned with the other comments describing packed format layouts. (Please also don't remove the header comments explaining the format of these comments) Also, why are you changing the component order in the comments for these, but not for some other packed formats in the series? Last but not least, there are a few cases in the series where you're defining a format as 'type A', when these comments clearly show that they're packed formats. Please be careful. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73631] es2tri fragment shader did not compile AMD ARUBA
https://bugs.freedesktop.org/show_bug.cgi?id=73631 Tapani Pälli changed: What|Removed |Added CC||lem...@gmail.com --- Comment #5 from Tapani Pälli --- In this case it should not be needed though as there are no float variables declared in the shader, isn't this a bug in the compiler instead? -- 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 V2 1/3] i965: Add an option to ignore sample qualifier
For the series,
Reviewed-by: Chris Forbes
On Sat, Jan 18, 2014 at 9:52 AM, Anuj Phogat wrote:
> This will be useful in my next patch which depends on a functionality
> of _mesa_get_min_invocations_per_fragment() to ignore the sample
> qualifier (prog->IsSample) based on a flag passed to it.
>
> Signed-off-by: Anuj Phogat
> Cc: Chris Forbes
> Cc: mesa-sta...@lists.freedesktop.org
> ---
> src/mesa/drivers/dri/i965/brw_wm.c| 2 +-
> src/mesa/drivers/dri/i965/gen6_wm_state.c | 2 +-
> src/mesa/drivers/dri/i965/gen7_wm_state.c | 4 ++--
> src/mesa/program/program.c| 5 +++--
> src/mesa/program/program.h| 3 ++-
> 5 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
> b/src/mesa/drivers/dri/i965/brw_wm.c
> index 6739a91..dee73c0 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm.c
> @@ -504,7 +504,7 @@ static void brw_wm_populate_key( struct brw_context *brw,
>
> /* _NEW_BUFFERS _NEW_MULTISAMPLE */
> key->compute_pos_offset =
> - _mesa_get_min_invocations_per_fragment(ctx, &fp->program) > 1 &&
> + _mesa_get_min_invocations_per_fragment(ctx, &fp->program, false) > 1 &&
>fp->program.Base.SystemValuesRead & SYSTEM_BIT_SAMPLE_POS;
>
> key->compute_sample_id =
> diff --git a/src/mesa/drivers/dri/i965/gen6_wm_state.c
> b/src/mesa/drivers/dri/i965/gen6_wm_state.c
> index 83a1708..0bb5ef3 100644
> --- a/src/mesa/drivers/dri/i965/gen6_wm_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_wm_state.c
> @@ -161,7 +161,7 @@ upload_wm_state(struct brw_context *brw)
> * better performance than 'SIMD8 only' dispatch.
> */
> int min_inv_per_frag =
> - _mesa_get_min_invocations_per_fragment(ctx, brw->fragment_program);
> + _mesa_get_min_invocations_per_fragment(ctx, brw->fragment_program,
> false);
> assert(min_inv_per_frag >= 1);
>
> if (brw->wm.prog_data->prog_offset_16) {
> diff --git a/src/mesa/drivers/dri/i965/gen7_wm_state.c
> b/src/mesa/drivers/dri/i965/gen7_wm_state.c
> index b6561bb..8dcefc2 100644
> --- a/src/mesa/drivers/dri/i965/gen7_wm_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_wm_state.c
> @@ -103,7 +103,7 @@ upload_wm_state(struct brw_context *brw)
>else
> dw1 |= GEN7_WM_MSRAST_OFF_PIXEL;
>
> - if (_mesa_get_min_invocations_per_fragment(ctx, brw->fragment_program)
> > 1)
> + if (_mesa_get_min_invocations_per_fragment(ctx, brw->fragment_program,
> false) > 1)
> dw2 |= GEN7_WM_MSDISPMODE_PERSAMPLE;
>else
> dw2 |= GEN7_WM_MSDISPMODE_PERPIXEL;
> @@ -236,7 +236,7 @@ upload_ps_state(struct brw_context *brw)
> * better performance than 'SIMD8 only' dispatch.
> */
> int min_inv_per_frag =
> - _mesa_get_min_invocations_per_fragment(ctx, brw->fragment_program);
> + _mesa_get_min_invocations_per_fragment(ctx, brw->fragment_program,
> false);
> assert(min_inv_per_frag >= 1);
>
> if (brw->wm.prog_data->prog_offset_16) {
> diff --git a/src/mesa/program/program.c b/src/mesa/program/program.c
> index 3c19e8c..ea8eb0d 100644
> --- a/src/mesa/program/program.c
> +++ b/src/mesa/program/program.c
> @@ -1023,7 +1023,8 @@ _mesa_postprocess_program(struct gl_context *ctx,
> struct gl_program *prog)
> */
> GLint
> _mesa_get_min_invocations_per_fragment(struct gl_context *ctx,
> - const struct gl_fragment_program
> *prog)
> + const struct gl_fragment_program
> *prog,
> + bool ignore_sample_qualifier)
> {
> /* From ARB_sample_shading specification:
> * "Using gl_SampleID in a fragment shader causes the entire shader
> @@ -1041,7 +1042,7 @@ _mesa_get_min_invocations_per_fragment(struct
> gl_context *ctx,
> * "Use of the "sample" qualifier on a fragment shader input
> * forces per-sample shading"
> */
> - if (prog->IsSample)
> + if (prog->IsSample && !ignore_sample_qualifier)
> return MAX2(ctx->DrawBuffer->Visual.samples, 1);
>
>if (prog->Base.SystemValuesRead & (SYSTEM_BIT_SAMPLE_ID |
> diff --git a/src/mesa/program/program.h b/src/mesa/program/program.h
> index 0e350cd..c47ac1c 100644
> --- a/src/mesa/program/program.h
> +++ b/src/mesa/program/program.h
> @@ -189,7 +189,8 @@ _mesa_postprocess_program(struct gl_context *ctx, struct
> gl_program *prog);
>
> extern GLint
> _mesa_get_min_invocations_per_fragment(struct gl_context *ctx,
> - const struct gl_fragment_program
> *prog);
> + const struct gl_fragment_program
> *prog,
> + bool ignore_sample_qualifier);
>
> static inline GLuint
> _mesa_program_enum_to_shader_stage(GLenum v)
> --
> 1.8.3.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://li
[Mesa-dev] [Bug 73631] es2tri fragment shader did not compile AMD ARUBA
https://bugs.freedesktop.org/show_bug.cgi?id=73631 --- Comment #6 from Tapani Pälli --- (In reply to comment #5) > In this case it should not be needed though as there are no float variables > declared in the shader, isn't this a bug in the compiler instead? oops, I missed the varying vec4 and precision qualifier makes it to work, it is correct fix. -- 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 demos] opengles2/es2tri: add precision qualifier to the fragment shader
On 01/19/2014 06:34 PM, Emil Velikov wrote:
The missing qualifier causes failure during the compilation stage.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73631
Signed-off-by: Emil Velikov
---
src/egl/opengles2/es2tri.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/egl/opengles2/es2tri.c b/src/egl/opengles2/es2tri.c
index 6dcc1b8..349a576 100644
--- a/src/egl/opengles2/es2tri.c
+++ b/src/egl/opengles2/es2tri.c
@@ -139,6 +139,7 @@ static void
create_shaders(void)
{
static const char *fragShaderText =
+ "precision mediump float;\n"
"varying vec4 v_color;\n"
"void main() {\n"
" gl_FragColor = v_color;\n"
yep, varying declaration was missing precision qualifier.
Reviewed-by: Tapani Pälli
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] glsl: Optimize log(exp(x)) and exp(log(x)) into x.
---
src/glsl/opt_algebraic.cpp | 36
1 file changed, 36 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 6b0d992..4aa49e5 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -252,6 +252,42 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
}
break;
+ case ir_unop_exp:
+ if (op_expr[0] == NULL)
+break;
+
+ if (op_expr[0]->operation == ir_unop_log) {
+ return op_expr[0]->operands[0];
+ }
+ break;
+
+ case ir_unop_log:
+ if (op_expr[0] == NULL)
+break;
+
+ if (op_expr[0]->operation == ir_unop_exp) {
+ return op_expr[0]->operands[0];
+ }
+ break;
+
+ case ir_unop_exp2:
+ if (op_expr[0] == NULL)
+break;
+
+ if (op_expr[0]->operation == ir_unop_log2) {
+ return op_expr[0]->operands[0];
+ }
+ break;
+
+ case ir_unop_log2:
+ if (op_expr[0] == NULL)
+break;
+
+ if (op_expr[0]->operation == ir_unop_exp2) {
+ return op_expr[0]->operands[0];
+ }
+ break;
+
case ir_unop_logic_not: {
enum ir_expression_operation new_op = ir_unop_logic_not;
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/6] glsl: Optimize lrp(x, x, coefficient) --> x.
total instructions in shared programs: 1627754 -> 1624534 (-0.20%)
instructions in affected programs: 45748 -> 42528 (-7.04%)
GAINED:3
LOST: 0
(serious sam, humus domino demo)
---
Note, Matt has a similar patch specific to i965/fs. This makes the
change global, though apparently less effectively than i965's did.
src/glsl/opt_algebraic.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 918982a..4a96a55 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -508,6 +508,8 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
return ir->operands[0];
} else if (is_vec_one(op_const[2])) {
return ir->operands[1];
+ } else if (ir->operands[0]->equals(ir->operands[1])) {
+ return ir->operands[0];
}
break;
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/6] glsl: Optimize triop_csel with all-true or all-false.
--- src/glsl/opt_algebraic.cpp | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp index 7fbc32e..cc9c928 100644 --- a/src/glsl/opt_algebraic.cpp +++ b/src/glsl/opt_algebraic.cpp @@ -526,6 +526,13 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir) } break; + case ir_triop_csel: + if (is_vec_one(op_const[0])) +return ir->operands[1]; + if (is_vec_zero(op_const[0])) +return ir->operands[2]; + break; + default: break; } -- 1.8.5.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] glsl: Optimize ~~x into x.
---
src/glsl/opt_algebraic.cpp | 12
1 file changed, 12 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 332f0b7..6b0d992 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -218,6 +218,18 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
this->mem_ctx = ralloc_parent(ir);
switch (ir->operation) {
+ case ir_unop_bit_not:
+ if (op_expr[0] == NULL)
+break;
+
+ switch (op_expr[0]->operation) {
+ case ir_unop_bit_not:
+ return abs(op_expr[0]->operands[0]);
+ default:
+ break;
+ }
+ break;
+
case ir_unop_abs:
if (op_expr[0] == NULL)
break;
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] glsl: Optimize various cases of fma (aka MAD).
---
src/glsl/opt_algebraic.cpp | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 4a96a55..7fbc32e 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -502,6 +502,19 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
break;
+ case ir_triop_fma:
+ /* Operands are op0 * op1 + op2. */
+ if (is_vec_zero(op_const[0]) || is_vec_zero(op_const[1])) {
+ return ir->operands[2];
+ } else if (is_vec_zero(op_const[2])) {
+ return mul(ir->operands[0], ir->operands[1]);
+ } else if (is_vec_one(op_const[0])) {
+ return add(ir->operands[1], ir->operands[2]);
+ } else if (is_vec_one(op_const[1])) {
+ return add(ir->operands[0], ir->operands[2]);
+ }
+ break;
+
case ir_triop_lrp:
/* Operands are (x, y, a). */
if (is_vec_zero(op_const[2])) {
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] glsl: Optimize pow(x, 1) -> x.
total instructions in shared programs: 1627826 -> 1627754 (-0.00%) instructions in affected programs: 6640 -> 6568 (-1.08%) GAINED:0 LOST: 0 (HoN and savage2) --- src/glsl/opt_algebraic.cpp | 4 1 file changed, 4 insertions(+) diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp index 4aa49e5..918982a 100644 --- a/src/glsl/opt_algebraic.cpp +++ b/src/glsl/opt_algebraic.cpp @@ -475,6 +475,10 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir) if (is_vec_one(op_const[0])) return op_const[0]; + /* x^1 == x */ + if (is_vec_one(op_const[1])) + return ir->operands[0]; + /* pow(2,x) == exp2(x) */ if (is_vec_two(op_const[0])) return expr(ir_unop_exp2, ir->operands[1]); -- 1.8.5.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
