[Mesa-dev] [Bug 91468] LLVM 3.8(svn): llvm changes llvm-config output again?

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91468

Krzysztof A. Sobiecki sob...@gmail.com changed:

   What|Removed |Added

URL||https://llvm.org/bugs/show_
   ||bug.cgi?id=24333

--- Comment #9 from Krzysztof A. Sobiecki sob...@gmail.com ---
So I have filled a bug with LLVM: https://llvm.org/bugs/show_bug.cgi?id=24333

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] r600g: fix the CB_SHADER_MASK setup

[Marek Olšák]

From: Marek Olšák marek.ol...@amd.com

This fixes the single-sample fast clear hang.

Cc: 10.6 mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/r600/evergreen_state.c | 8 
 src/gallium/drivers/r600/r600_shader.c | 1 +
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/r600/evergreen_state.c 
b/src/gallium/drivers/r600/evergreen_state.c
index 5c8fd0d..13ecc46 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1736,10 +1736,10 @@ static void evergreen_emit_cb_misc_state(struct 
r600_context *rctx, struct r600_
 
r600_write_context_reg_seq(cs, R_028238_CB_TARGET_MASK, 2);
radeon_emit(cs, a-blend_colormask  fb_colormask); /* 
R_028238_CB_TARGET_MASK */
-   /* Always enable the first colorbuffer in CB_SHADER_MASK. This
-* will assure that the alpha-test will work even if there is
-* no colorbuffer bound. */
-   radeon_emit(cs, 0xf | (a-dual_src_blend ? ps_colormask : 0) | 
fb_colormask); /* R_02823C_CB_SHADER_MASK */
+   /* This must match the used export instructions exactly.
+* Other values may lead to undefined behavior and hangs.
+*/
+   radeon_emit(cs, ps_colormask); /* R_02823C_CB_SHADER_MASK */
 }
 
 static void evergreen_emit_db_state(struct r600_context *rctx, struct 
r600_atom *atom)
diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 09f50f5..8d1f95a 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -2490,6 +2490,7 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
output[j].array_base = 0;
output[j].op = CF_OP_EXPORT;
j++;
+   shader-nr_ps_color_exports++;
}
 
noutput = j;
-- 
2.1.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] r600g: re-enable single-sample fast clear

[Marek Olšák]

From: Marek Olšák marek.ol...@amd.com

Fixed by the CB_SHADER_MASK fix.
---
 src/gallium/drivers/r600/r600_blit.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_blit.c 
b/src/gallium/drivers/r600/r600_blit.c
index 1c59230..8664e03 100644
--- a/src/gallium/drivers/r600/r600_blit.c
+++ b/src/gallium/drivers/r600/r600_blit.c
@@ -393,12 +393,7 @@ static void r600_clear(struct pipe_context *ctx, unsigned 
buffers,
struct r600_context *rctx = (struct r600_context *)ctx;
struct pipe_framebuffer_state *fb = rctx-framebuffer.state;
 
-   /* Single-sample fast color clear is broken on r600g:
-*   https://bugs.freedesktop.org/show_bug.cgi?id=73528
-*   https://bugs.freedesktop.org/show_bug.cgi?id=82186
-*/
-   if (buffers  PIPE_CLEAR_COLOR  rctx-b.chip_class = EVERGREEN 
-   rctx-framebuffer.nr_samples  1) {
+   if (buffers  PIPE_CLEAR_COLOR  rctx-b.chip_class = EVERGREEN) {
evergreen_do_fast_color_clear(rctx-b, fb, 
rctx-framebuffer.atom,
  buffers, color);
if (!buffers)
-- 
2.1.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 88780, which changed state.

Bug 88780 Summary: Several Unity3D-based games render with foggy blueish 
overlay
https://bugs.freedesktop.org/show_bug.cgi?id=88780

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
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/3] r600g: fix the single-sample fast clear setup

[Marek Olšák]

From: Marek Olšák marek.ol...@amd.com

No effect, but this is what we should be doing.
---
 src/gallium/drivers/r600/evergreen_state.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/r600/evergreen_state.c 
b/src/gallium/drivers/r600/evergreen_state.c
index 7065af9..5c8fd0d 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1028,7 +1028,10 @@ void evergreen_init_color_surface(struct r600_context 
*rctx,
macro_aspect = rtex-surface.mtilea;
bankw = rtex-surface.bankw;
bankh = rtex-surface.bankh;
-   fmask_bankh = rtex-fmask.bank_height;
+   if (rtex-fmask.size)
+   fmask_bankh = rtex-fmask.bank_height;
+   else
+   fmask_bankh = rtex-surface.bankh;
tile_split = eg_tile_split(tile_split);
macro_aspect = eg_macro_tile_aspect(macro_aspect);
bankw = eg_bank_wh(bankw);
@@ -1149,10 +1152,11 @@ void evergreen_init_color_surface(struct r600_context 
*rctx,
surf-cb_color_attrib = color_attrib;
if (rtex-fmask.size) {
surf-cb_color_fmask = (base_offset + rtex-fmask.offset)  8;
+   surf-cb_color_fmask_slice = 
S_028C88_TILE_MAX(rtex-fmask.slice_tile_max);
} else {
surf-cb_color_fmask = surf-cb_color_base;
+   surf-cb_color_fmask_slice = S_028C88_TILE_MAX(slice);
}
-   surf-cb_color_fmask_slice = 
S_028C88_TILE_MAX(rtex-fmask.slice_tile_max);
 
surf-color_initialized = true;
 }
-- 
2.1.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] mesa: _mesa_format_convert should be endian agnostic

[Oded Gabbay]

This patch fixes a bug that is manifested in the read path of mesa when
running on big-endian machines. The effects can be seen when running
piglit sanity test and/or taking a screen capture.

The bug is caused when _mesa_format_convert receives src_format as
mesa_format, which it thens changes to mesa_array_format. During this
change, it checks for endianness and swaps the bytes accordingly.
However, because the bytes are _already_ swapped in the memory itself
(being written there by llvmpipe), and src_format value matches the
_actual_ contents of the memory, the result of the read is wrong.

Therefore, because other layers/functions, such as llvm or
read_rgba_pixels() takes care whether we are dealing with big-endian or
little-endian, _mesa_format_convert should be endian agnostic to avoid
duplicate swapping of bytes.

btw, it is also mentioned in the comment of the function that it doesn't
handle byte-swapping, so the original code contradicts the documentation.

Signed-off-by: Oded Gabbay oded.gab...@gmail.com
CC: 10.5 10.6 mesa-sta...@lists.freedesktop.org
---
 src/mesa/main/formats.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index baeb1bf..7a41cb0 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -372,10 +372,8 @@ uint32_t
 _mesa_format_to_array_format(mesa_format format)
 {
const struct gl_format_info *info = _mesa_get_format_info(format);
-   if (_mesa_little_endian())
-  return info-ArrayFormat;
-   else
-  return _mesa_array_format_flip_channels(info-ArrayFormat);
+
+   return info-ArrayFormat;
 }
 
 static struct hash_table *format_array_format_table;
-- 
2.4.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] mesa: clear existing swizzle info before bitwise-OR

[Oded Gabbay]

This patch fixes a bug in big-endian handling, where the previous
swizzle info wasn't cleared before a new swizzle info was inserted into
the format field using a bitwise-OR operation.

Signed-off-by: Oded Gabbay oded.gab...@gmail.com
CC: 10.5 10.6 mesa-sta...@lists.freedesktop.org
---
 src/mesa/main/formats.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
index 7e451ca..eacd8b7 100644
--- a/src/mesa/main/formats.h
+++ b/src/mesa/main/formats.h
@@ -191,6 +191,9 @@ static inline void
 _mesa_array_format_set_swizzle(mesa_array_format *f,
int32_t x, int32_t y, int32_t z, int32_t w)
 {
+   /* clear old swizzle info */
+   *f = ~((0x7  8) | (0x7  11) | (0x7  14) | (0x7  17));
+
*f |= ((x  8 )  MESA_ARRAY_FORMAT_SWIZZLE_X_MASK) |
  ((y  11)  MESA_ARRAY_FORMAT_SWIZZLE_Y_MASK) |
  ((z  14)  MESA_ARRAY_FORMAT_SWIZZLE_Z_MASK) |
-- 
2.4.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Fix missing BRW_NEW_FS_PROG_DATA in gen6_renderbuffer_surfaces.

[Kenneth Graunke]

On Saturday, August 01, 2015 05:43:26 PM Emil Velikov wrote:
 On 6 July 2015 at 21:40, Kenneth Graunke kenn...@whitecape.org wrote:
  On Monday, July 06, 2015 12:18:18 PM Matt Turner wrote:
  On Mon, Jul 6, 2015 at 9:55 AM, Kenneth Graunke kenn...@whitecape.org 
  wrote:
   It looks like this was forgotten in commit 3c9dc2d31b80fc73bffa1f40a
   (i965: Make a brw_stage_prog_data for storing the SURF_INDEX
   information.)   In other words, it's been missing since we moved to
   dynamic binding table slot assignments.
 
  Author: Eric Anholt e...@anholt.net
  AuthorDate: Wed Oct 2 14:07:40 2013 -0700
  CommitDate: Tue Oct 15 10:18:42 2013 -0700
 
  Dang.
 
  How did you find this?
 
  After reading Eero's latest performance analysis observations, I decided
  to try marking render targets uncached (MOCS = UC) when blending and
  logic ops (i.e. things that cause render target reads) are disabled.
 
  This necessitated adding _NEW_COLOR.  Then I realized
  BRW_NEW_FS_PROG_DATA was just plain missing.
 
 Seems like this patch has fallen between the cracks. Can anyone take a
 look or let me know if it's no longer applicable.
 
 Thanks
 Emil

Chris and I informally NAK'd it on IRC, sorry.  It turns out that
render_target_start is always 0, so omitting the bit should be harmless.

We thought about sending a patch to delete the field and hardcode 0
instead...


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] r600g: fix the single-sample fast clear setup

[Dieter Nützel]

Am 02.08.2015 15:36, schrieb Marek Olšák:

From: Marek Olšák marek.ol...@amd.com

No effect, but this is what we should be doing.


Hello Marek,

who should test this on which stuff?
BTW Do you think, we see GL 4.1 on r600g (Turks ;-) with 11.0.1?

Great work!

-Dieter


---
 src/gallium/drivers/r600/evergreen_state.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 7065af9..5c8fd0d 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1028,7 +1028,10 @@ void evergreen_init_color_surface(struct
r600_context *rctx,
macro_aspect = rtex-surface.mtilea;
bankw = rtex-surface.bankw;
bankh = rtex-surface.bankh;
-   fmask_bankh = rtex-fmask.bank_height;
+   if (rtex-fmask.size)
+   fmask_bankh = rtex-fmask.bank_height;
+   else
+   fmask_bankh = rtex-surface.bankh;
tile_split = eg_tile_split(tile_split);
macro_aspect = eg_macro_tile_aspect(macro_aspect);
bankw = eg_bank_wh(bankw);
@@ -1149,10 +1152,11 @@ void evergreen_init_color_surface(struct
r600_context *rctx,
surf-cb_color_attrib = color_attrib;
if (rtex-fmask.size) {
surf-cb_color_fmask = (base_offset + rtex-fmask.offset)  8;
+		surf-cb_color_fmask_slice = 
S_028C88_TILE_MAX(rtex-fmask.slice_tile_max);

} else {
surf-cb_color_fmask = surf-cb_color_base;
+   surf-cb_color_fmask_slice = S_028C88_TILE_MAX(slice);
}
-	surf-cb_color_fmask_slice = 
S_028C88_TILE_MAX(rtex-fmask.slice_tile_max);


surf-color_initialized = true;
 }


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] clover: clEnqueue* should block when asked for

[EdB]

As a side effect, this fix clRetain/ReleaseEvent Piglit test
---
 src/gallium/state_trackers/clover/api/transfer.cpp | 29 --
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/clover/api/transfer.cpp 
b/src/gallium/state_trackers/clover/api/transfer.cpp
index fdb9405..c2f4f13 100644
--- a/src/gallium/state_trackers/clover/api/transfer.cpp
+++ b/src/gallium/state_trackers/clover/api/transfer.cpp
@@ -295,6 +295,9 @@ clEnqueueReadBuffer(cl_command_queue d_q, cl_mem d_mem, 
cl_bool blocking,
mem, obj_origin, obj_pitch,
region));
 
+   if (blocking)
+  hev().wait();
+
ret_object(rd_ev, hev);
return CL_SUCCESS;
 
@@ -325,6 +328,9 @@ clEnqueueWriteBuffer(cl_command_queue d_q, cl_mem d_mem, 
cl_bool blocking,
ptr, {}, obj_pitch,
region));
 
+   if (blocking)
+  hev().wait();
+
ret_object(rd_ev, hev);
return CL_SUCCESS;
 
@@ -362,6 +368,9 @@ clEnqueueReadBufferRect(cl_command_queue d_q, cl_mem d_mem, 
cl_bool blocking,
mem, obj_origin, obj_pitch,
region));
 
+   if (blocking)
+  hev().wait();
+
ret_object(rd_ev, hev);
return CL_SUCCESS;
 
@@ -398,6 +407,8 @@ clEnqueueWriteBufferRect(cl_command_queue d_q, cl_mem 
d_mem, cl_bool blocking,
   soft_copy_op(q, mem, obj_origin, obj_pitch,
ptr, host_origin, host_pitch,
region));
+   if (blocking)
+  hev().wait();
 
ret_object(rd_ev, hev);
return CL_SUCCESS;
@@ -504,6 +515,9 @@ clEnqueueReadImage(cl_command_queue d_q, cl_mem d_mem, 
cl_bool blocking,
img, src_origin, src_pitch,
region));
 
+   if (blocking)
+  hev().wait();
+
ret_object(rd_ev, hev);
return CL_SUCCESS;
 
@@ -537,6 +551,8 @@ clEnqueueWriteImage(cl_command_queue d_q, cl_mem d_mem, 
cl_bool blocking,
   soft_copy_op(q, img, dst_origin, dst_pitch,
ptr, {}, src_pitch,
region));
+   if (blocking)
+  hev().wait();
 
ret_object(rd_ev, hev);
return CL_SUCCESS;
@@ -666,8 +682,12 @@ clEnqueueMapBuffer(cl_command_queue d_q, cl_mem d_mem, 
cl_bool blocking,
validate_map_flags(mem, flags);
 
void *map = mem.resource(q).add_map(q, flags, blocking, obj_origin, region);
+   auto hev = createhard_event(q, CL_COMMAND_MAP_BUFFER, deps);
+
+   if (blocking)
+  hev().wait();
 
-   ret_object(rd_ev, createhard_event(q, CL_COMMAND_MAP_BUFFER, deps));
+   ret_object(rd_ev, hev);
ret_error(r_errcode, CL_SUCCESS);
return map;
 
@@ -695,7 +715,12 @@ clEnqueueMapImage(cl_command_queue d_q, cl_mem d_mem, 
cl_bool blocking,
 
void *map = img.resource(q).add_map(q, flags, blocking, origin, region);
 
-   ret_object(rd_ev, createhard_event(q, CL_COMMAND_MAP_IMAGE, deps));
+   auto hev = createhard_event(q, CL_COMMAND_MAP_IMAGE, deps);
+
+   if (blocking)
+  hev().wait();
+
+   ret_object(rd_ev, hev);
ret_error(r_errcode, CL_SUCCESS);
return map;
 
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] r600g: re-enable single-sample fast clear

[Dieter Nützel]

Am 02.08.2015 15:36, schrieb Marek Olšák:

From: Marek Olšák marek.ol...@amd.com

Fixed by the CB_SHADER_MASK fix.


Hurray,

r600g (Turks) ~10% performance drop for Mesa's 'objview' is _mostly_ 
fixed.

Mostly 'cause it is NOT on par as before (the 'broken') version.
E.g. 'buddha' was stable at 600 FPS (see below).

Thanks,
  Dieter

Without fast clear: with new fixed version:
./objview bobcat.obj 
1130.967407 FPS1299.925171 FPS
1171.957153 FPS1328.50 FPS
1170.75 FPS1328.50 FPS

./objview buddha.obj 
533.25 FPS   560.609985 FPS
543.364258 FPS   574.463013 FPS
542.864380 FPS   574.00 FPS

./objview bunny.obj 
743.25 FPS   811.25 FPS
768.00 FPS   825.50 FPS
765.50 FPS   826.75 FPS

./objview GreatLakesBiplaneHP.obj 
604.848938 FPS   644.00 FPS
617.691406 FPS   658.50 FPS
618.25 FPS   658.50 FPS

Taken from former posts with Michel (about enabling DRI3/glamor):
Mesa-demo's 'objview' show this:

bobcat.obj:~790 = ~1048 fps | ~25%  with glamor ~1388 fps
buddha.obj:~370 =  ~527 fps | 33%  with glamor  ~600 fps
bunny.obj:~530 =  ~720 fps | 25%  with glamor  ~863 fps
GreatLakesBiplaneHP.obj:~435 =  ~593 fps | 33%  with glamor  ~687 
fps



---
 src/gallium/drivers/r600/r600_blit.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index 1c59230..8664e03 100644
--- a/src/gallium/drivers/r600/r600_blit.c
+++ b/src/gallium/drivers/r600/r600_blit.c
@@ -393,12 +393,7 @@ static void r600_clear(struct pipe_context *ctx,
unsigned buffers,
struct r600_context *rctx = (struct r600_context *)ctx;
struct pipe_framebuffer_state *fb = rctx-framebuffer.state;

-   /* Single-sample fast color clear is broken on r600g:
-*   https://bugs.freedesktop.org/show_bug.cgi?id=73528
-*   https://bugs.freedesktop.org/show_bug.cgi?id=82186
-*/
-   if (buffers  PIPE_CLEAR_COLOR  rctx-b.chip_class = EVERGREEN 
-   rctx-framebuffer.nr_samples  1) {
+   if (buffers  PIPE_CLEAR_COLOR  rctx-b.chip_class = EVERGREEN) {
evergreen_do_fast_color_clear(rctx-b, fb, 
rctx-framebuffer.atom,
  buffers, color);
if (!buffers)

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] r600g: re-enable single-sample fast clear

[Marek Olšák]

On Sun, Aug 2, 2015 at 9:03 PM, Dieter Nützel die...@nuetzel-hh.de wrote:
 Am 02.08.2015 19:54, schrieb Dieter Nützel:

 Am 02.08.2015 15:36, schrieb Marek Olšák:

 From: Marek Olšák marek.ol...@amd.com

 Fixed by the CB_SHADER_MASK fix.


 Hurray,

 r600g (Turks) ~10% performance drop for Mesa's 'objview' is _mostly_
 fixed.
 Mostly 'cause it is NOT on par as before (the 'broken') version.
 E.g. 'buddha' was stable at 600 FPS (see below).

 Thanks,
   Dieter


 Tested-by: Dieter Nützel die...@nuetzel-hh.de

 OK,
 I retested with
 git revert 97ec2c6 (r600g: disable single-sample fast color clear due to
 hangs)
 Speed is back (I put all three results together in the below table)

 BTW I hadn't any hangs on Evergreen (Turks) with old version.
 Any specific test I should try?

This test case hangs on my Redwood without the patches and fast clear enabled:
https://bugs.freedesktop.org/attachment.cgi?id=117466

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl: replace old hash table with new and faster one

[Alejandro Seguí]

---
 src/glsl/ir_print_visitor.cpp | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/src/glsl/ir_print_visitor.cpp b/src/glsl/ir_print_visitor.cpp
index 78475f3..641a996 100644
--- a/src/glsl/ir_print_visitor.cpp
+++ b/src/glsl/ir_print_visitor.cpp
@@ -25,7 +25,7 @@
 #include glsl_types.h
 #include glsl_parser_extras.h
 #include main/macros.h
-#include program/hash_table.h
+#include util/hash_table.h
 
 static void print_type(FILE *f, const glsl_type *t);
 
@@ -89,14 +89,14 @@ ir_print_visitor::ir_print_visitor(FILE *f)
 {
indentation = 0;
printable_names =
-  hash_table_ctor(32, hash_table_pointer_hash, hash_table_pointer_compare);
+  _mesa_hash_table_create(NULL, _mesa_hash_pointer, 
_mesa_key_pointer_equal);
symbols = _mesa_symbol_table_ctor();
mem_ctx = ralloc_context(NULL);
 }
 
 ir_print_visitor::~ir_print_visitor()
 {
-   hash_table_dtor(printable_names);
+   _mesa_hash_table_destroy(printable_names, NULL);
_mesa_symbol_table_dtor(symbols);
ralloc_free(mem_ctx);
 }
@@ -121,9 +121,14 @@ ir_print_visitor::unique_name(ir_variable *var)
}
 
/* Do we already have a name for this variable? */
-   const char *name = (const char *) hash_table_find(this-printable_names, 
var);
-   if (name != NULL)
-  return name;
+   struct hash_entry * entry =
+  _mesa_hash_table_search(this-printable_names, var);
+
+   if (entry != NULL) {
+  return (const char *) entry-data;
+   }
+
+   const char* name = NULL;
 
/* If there's no conflict, just use the original name */
if (_mesa_symbol_table_find_symbol(this-symbols, -1, var-name) == NULL) {
@@ -132,7 +137,7 @@ ir_print_visitor::unique_name(ir_variable *var)
   static unsigned i = 1;
   name = ralloc_asprintf(this-mem_ctx, %s@%u, var-name, ++i);
}
-   hash_table_insert(this-printable_names, (void *) name, var);
+   _mesa_hash_table_insert(this-printable_names, var, (void *) name);
_mesa_symbol_table_add_symbol(this-symbols, -1, name, var);
return name;
 }
-- 
2.5.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] r600g: fix the single-sample fast clear setup

[Marek Olšák]

On Sun, Aug 2, 2015 at 7:05 PM, Dieter Nützel die...@nuetzel-hh.de wrote:
 Am 02.08.2015 15:36, schrieb Marek Olšák:

 From: Marek Olšák marek.ol...@amd.com

 No effect, but this is what we should be doing.


 Hello Marek,

 who should test this on which stuff?

I've tested it.

 BTW Do you think, we see GL 4.1 on r600g (Turks ;-) with 11.0.1?

I hope so, but I don't know.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] r600g: re-enable single-sample fast clear

[Dieter Nützel]

Am 02.08.2015 19:54, schrieb Dieter Nützel:

Am 02.08.2015 15:36, schrieb Marek Olšák:

From: Marek Olšák marek.ol...@amd.com

Fixed by the CB_SHADER_MASK fix.


Hurray,

r600g (Turks) ~10% performance drop for Mesa's 'objview' is _mostly_ 
fixed.

Mostly 'cause it is NOT on par as before (the 'broken') version.
E.g. 'buddha' was stable at 600 FPS (see below).

Thanks,
  Dieter


Tested-by: Dieter Nützel die...@nuetzel-hh.de

OK,
I retested with
git revert 97ec2c6 (r600g: disable single-sample fast color clear due to 
hangs)

Speed is back (I put all three results together in the below table)

BTW I hadn't any hangs on Evergreen (Turks) with old version.
Any specific test I should try?

-Dieter

Without fast clear: with new fixed version:
git revert 97ec2c6

./objview bobcat.obj 
1130.967407 FPS1299.925171 FPS
1393.75 FPS
1171.957153 FPS1328.50 FPS
1391.75 FPS
1170.75 FPS1328.50 FPS
1392.25 FPS


./objview buddha.obj 
533.25 FPS   560.609985 FPS  
602.599487 FPS
543.364258 FPS   574.463013 FPS  
601.849670 FPS
542.864380 FPS   574.00 FPS  
601.50 FPS


./objview bunny.obj 
743.25 FPS   811.25 FPS 
867.283325 FPS
768.00 FPS   825.50 FPS 
865.00 FPS
765.50 FPS   826.75 FPS 
865.00 FPS


./objview GreatLakesBiplaneHP.obj 
604.848938 FPS   644.00 FPS 
688.75 FPS
617.691406 FPS   658.50 FPS 
689.50 FPS
618.25 FPS   658.50 FPS 
690.00 FPS


Taken from former posts with Michel (about enabling DRI3/glamor):
Mesa-demo's 'objview' show this:

bobcat.obj:~790 = ~1048 fps | ~25%  with glamor ~1388 fps
buddha.obj:~370 =  ~527 fps | 33%  with glamor  ~600 fps
bunny.obj:~530 =  ~720 fps | 25%  with glamor  ~863 fps
GreatLakesBiplaneHP.obj:~435 =  ~593 fps | 33%  with glamor  ~687 
fps



---
 src/gallium/drivers/r600/r600_blit.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index 1c59230..8664e03 100644
--- a/src/gallium/drivers/r600/r600_blit.c
+++ b/src/gallium/drivers/r600/r600_blit.c
@@ -393,12 +393,7 @@ static void r600_clear(struct pipe_context *ctx,
unsigned buffers,
struct r600_context *rctx = (struct r600_context *)ctx;
struct pipe_framebuffer_state *fb = rctx-framebuffer.state;

-   /* Single-sample fast color clear is broken on r600g:
-*   https://bugs.freedesktop.org/show_bug.cgi?id=73528
-*   https://bugs.freedesktop.org/show_bug.cgi?id=82186
-*/
-   if (buffers  PIPE_CLEAR_COLOR  rctx-b.chip_class = EVERGREEN 
-   rctx-framebuffer.nr_samples  1) {
+   if (buffers  PIPE_CLEAR_COLOR  rctx-b.chip_class = EVERGREEN) {
 		evergreen_do_fast_color_clear(rctx-b, fb, 
rctx-framebuffer.atom,

  buffers, color);
if (!buffers)

___
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] [Bug 91468] LLVM 3.8(svn): llvm changes llvm-config output again?

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91468

--- Comment #8 from Krzysztof A. Sobiecki sob...@gmail.com ---
I was trying to contact maintainer of http://llvm.org/apt/unstable/, now I will
fill a bug on llvms bugzilla.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: replace old hash table with new and faster one

[Timothy Arceri]

On Sun, 2015-08-02 at 19:50 +0200, Alejandro Seguí wrote:

Maybe just for completeness you could add this to the commit message

The util/hash_table was intended to be a fast hash table
replacement for the program/hash_table see 35fd61bd99c1 and 72e55bb6888ff.

 ---
  src/glsl/ir_print_visitor.cpp | 19 ---
  1 file changed, 12 insertions(+), 7 deletions(-)
 
 diff --git a/src/glsl/ir_print_visitor.cpp b/src/glsl/ir_print_visitor.cpp
 index 78475f3..641a996 100644
 --- a/src/glsl/ir_print_visitor.cpp
 +++ b/src/glsl/ir_print_visitor.cpp
 @@ -25,7 +25,7 @@
  #include glsl_types.h
  #include glsl_parser_extras.h
  #include main/macros.h
 -#include program/hash_table.h
 +#include util/hash_table.h
  
  static void print_type(FILE *f, const glsl_type *t);
  
 @@ -89,14 +89,14 @@ ir_print_visitor::ir_print_visitor(FILE *f)
  {
 indentation = 0;
 printable_names =
 -  hash_table_ctor(32, hash_table_pointer_hash, 
 hash_table_pointer_compare);
 +  _mesa_hash_table_create(NULL, _mesa_hash_pointer, 
 _mesa_key_pointer_equal);
 symbols = _mesa_symbol_table_ctor();
 mem_ctx = ralloc_context(NULL);
  }
  
  ir_print_visitor::~ir_print_visitor()
  {
 -   hash_table_dtor(printable_names);
 +   _mesa_hash_table_destroy(printable_names, NULL);
 _mesa_symbol_table_dtor(symbols);
 ralloc_free(mem_ctx);
  }
 @@ -121,9 +121,14 @@ ir_print_visitor::unique_name(ir_variable *var)
 }
  
 /* Do we already have a name for this variable? */
 -   const char *name = (const char *) hash_table_find(this-printable_names, 
 var);
 -   if (name != NULL)
 -  return name;
 +   struct hash_entry * entry =
 +_mesa_hash_table_search(this-printable_names, var);
 +
 +   if (entry != NULL) {
 +  return (const char *) entry-data;
 +   }
 +
 +   const char* name = NULL;

The above looks a bit funny just floating here maybe move it

  
 /* If there's no conflict, just use the original name */
Here.
 if (_mesa_symbol_table_find_symbol(this-symbols, -1, var-name) == 
 NULL) {
 @@ -132,7 +137,7 @@ ir_print_visitor::unique_name(ir_variable *var)
static unsigned i = 1;
name = ralloc_asprintf(this-mem_ctx, %s@%u, var-name, ++i);
 }
 -   hash_table_insert(this-printable_names, (void *) name, var);
 +   _mesa_hash_table_insert(this-printable_names, var, (void *) name);
 _mesa_symbol_table_add_symbol(this-symbols, -1, name, var);
 return name;
  }

With those couple of small changes you can add to the commit message
Reviewed-by: Timothy Arceri t_arc...@yahoo.com.au

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] r600g: re-enable single-sample fast clear

[Dieter Nützel]

Am 02.08.2015 21:11, schrieb Marek Olšák:
On Sun, Aug 2, 2015 at 9:03 PM, Dieter Nützel die...@nuetzel-hh.de 
wrote:

Am 02.08.2015 19:54, schrieb Dieter Nützel:


Am 02.08.2015 15:36, schrieb Marek Olšák:


From: Marek Olšák marek.ol...@amd.com

Fixed by the CB_SHADER_MASK fix.



Hurray,

r600g (Turks) ~10% performance drop for Mesa's 'objview' is _mostly_
fixed.
Mostly 'cause it is NOT on par as before (the 'broken') version.
E.g. 'buddha' was stable at 600 FPS (see below).

Thanks,
  Dieter



Tested-by: Dieter Nützel die...@nuetzel-hh.de

OK,
I retested with
git revert 97ec2c6 (r600g: disable single-sample fast color clear due 
to

hangs)
Speed is back (I put all three results together in the below table)

BTW I hadn't any hangs on Evergreen (Turks) with old version.
Any specific test I should try?


This test case hangs on my Redwood without the patches and fast clear 
enabled:

https://bugs.freedesktop.org/attachment.cgi?id=117466

Marek


OK,

all acked, now.
Your test case hangs on Evergreen (Turks) here, too.

[14644.548816] radeon :01:00.0: ring 0 stalled for more than 
10248msec
[14644.548824] radeon :01:00.0: GPU lockup (current fence id 
0x0026e33d last fence id 0x0026e33f on ring 0)
[14644.569069] [drm:r600_ib_test [radeon]] *ERROR* radeon: fence wait 
failed (-35).
[14644.569086] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: 
failed testing IB on GFX ring (-35).


But I could get logs and reboot...

With these patches and fast clear enabled _everything_ is GOOD.
Even SPEED! --- Only thing I had to do was a REBOOT.
Maybe one of the registers hold the OLD falue?

Commit, please.
Acked-by: Dieter Nützel die...@nuetzel-hh.de

Dieter

PS We all repeat loud:
A reboot now and then could make gfk development go...

bobcat.obj
1392.50 FPS
1393.75 FPS
1394.00 FPS

buddha.obj
603.698425 FPS
600.25 FPS
600.100098 FPS

bunny.obj
867.00 FPS
863.534241 FPS
864.284058 FPS

GreatLakesBiplaneHP.obj
691.25 FPS
688.827942 FPS
689.577759 FPS
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] r600g: fix the single-sample fast clear setup

[Dave Airlie]

For the series,

Reviewed-by: Dave Airlie airl...@redhat.com

On 2 August 2015 at 23:36, Marek Olšák mar...@gmail.com wrote:
 From: Marek Olšák marek.ol...@amd.com

 No effect, but this is what we should be doing.
 ---
  src/gallium/drivers/r600/evergreen_state.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

 diff --git a/src/gallium/drivers/r600/evergreen_state.c 
 b/src/gallium/drivers/r600/evergreen_state.c
 index 7065af9..5c8fd0d 100644
 --- a/src/gallium/drivers/r600/evergreen_state.c
 +++ b/src/gallium/drivers/r600/evergreen_state.c
 @@ -1028,7 +1028,10 @@ void evergreen_init_color_surface(struct r600_context 
 *rctx,
 macro_aspect = rtex-surface.mtilea;
 bankw = rtex-surface.bankw;
 bankh = rtex-surface.bankh;
 -   fmask_bankh = rtex-fmask.bank_height;
 +   if (rtex-fmask.size)
 +   fmask_bankh = rtex-fmask.bank_height;
 +   else
 +   fmask_bankh = rtex-surface.bankh;
 tile_split = eg_tile_split(tile_split);
 macro_aspect = eg_macro_tile_aspect(macro_aspect);
 bankw = eg_bank_wh(bankw);
 @@ -1149,10 +1152,11 @@ void evergreen_init_color_surface(struct r600_context 
 *rctx,
 surf-cb_color_attrib = color_attrib;
 if (rtex-fmask.size) {
 surf-cb_color_fmask = (base_offset + rtex-fmask.offset)  
 8;
 +   surf-cb_color_fmask_slice = 
 S_028C88_TILE_MAX(rtex-fmask.slice_tile_max);
 } else {
 surf-cb_color_fmask = surf-cb_color_base;
 +   surf-cb_color_fmask_slice = S_028C88_TILE_MAX(slice);
 }
 -   surf-cb_color_fmask_slice = 
 S_028C88_TILE_MAX(rtex-fmask.slice_tile_max);

 surf-color_initialized = true;
  }
 --
 2.1.4

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: replace old hash table with new and faster one

[Chris Forbes]

Some perf numbers would be nice. How much is this winning?

- Chris

On Mon, Aug 3, 2015 at 11:18 AM, Timothy Arceri t_arc...@yahoo.com.au wrote:
 On Sun, 2015-08-02 at 19:50 +0200, Alejandro Seguí wrote:

 Maybe just for completeness you could add this to the commit message

 The util/hash_table was intended to be a fast hash table
 replacement for the program/hash_table see 35fd61bd99c1 and 72e55bb6888ff.

 ---
  src/glsl/ir_print_visitor.cpp | 19 ---
  1 file changed, 12 insertions(+), 7 deletions(-)

 diff --git a/src/glsl/ir_print_visitor.cpp b/src/glsl/ir_print_visitor.cpp
 index 78475f3..641a996 100644
 --- a/src/glsl/ir_print_visitor.cpp
 +++ b/src/glsl/ir_print_visitor.cpp
 @@ -25,7 +25,7 @@
  #include glsl_types.h
  #include glsl_parser_extras.h
  #include main/macros.h
 -#include program/hash_table.h
 +#include util/hash_table.h

  static void print_type(FILE *f, const glsl_type *t);

 @@ -89,14 +89,14 @@ ir_print_visitor::ir_print_visitor(FILE *f)
  {
 indentation = 0;
 printable_names =
 -  hash_table_ctor(32, hash_table_pointer_hash,
 hash_table_pointer_compare);
 +  _mesa_hash_table_create(NULL, _mesa_hash_pointer,
 _mesa_key_pointer_equal);
 symbols = _mesa_symbol_table_ctor();
 mem_ctx = ralloc_context(NULL);
  }

  ir_print_visitor::~ir_print_visitor()
  {
 -   hash_table_dtor(printable_names);
 +   _mesa_hash_table_destroy(printable_names, NULL);
 _mesa_symbol_table_dtor(symbols);
 ralloc_free(mem_ctx);
  }
 @@ -121,9 +121,14 @@ ir_print_visitor::unique_name(ir_variable *var)
 }

 /* Do we already have a name for this variable? */
 -   const char *name = (const char *) hash_table_find(this-printable_names,
 var);
 -   if (name != NULL)
 -  return name;
 +   struct hash_entry * entry =
 +_mesa_hash_table_search(this-printable_names, var);
 +
 +   if (entry != NULL) {
 +  return (const char *) entry-data;
 +   }
 +
 +   const char* name = NULL;

 The above looks a bit funny just floating here maybe move it


 /* If there's no conflict, just use the original name */
 Here.
 if (_mesa_symbol_table_find_symbol(this-symbols, -1, var-name) ==
 NULL) {
 @@ -132,7 +137,7 @@ ir_print_visitor::unique_name(ir_variable *var)
static unsigned i = 1;
name = ralloc_asprintf(this-mem_ctx, %s@%u, var-name, ++i);
 }
 -   hash_table_insert(this-printable_names, (void *) name, var);
 +   _mesa_hash_table_insert(this-printable_names, var, (void *) name);
 _mesa_symbol_table_add_symbol(this-symbols, -1, name, var);
 return name;
  }

 With those couple of small changes you can add to the commit message
 Reviewed-by: Timothy Arceri t_arc...@yahoo.com.au

 ___
 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] glsl: replace old hash table with new and faster one

[Chris Forbes]

Oh, fair enough then.
On Aug 3, 2015 12:39 PM, Ilia Mirkin imir...@alum.mit.edu wrote:

 Given that this is a debug-only thing, I doubt perf numbers are that
 interesting.

 I have no clue what the diff is between the two hash tables, but if
 one is allegedly faster than the other, that should be determined, and
 we should just mass-migrate...

   -ilia

 On Sun, Aug 2, 2015 at 8:05 PM, Chris Forbes chr...@ijw.co.nz wrote:
  Some perf numbers would be nice. How much is this winning?
 
  - Chris
 
  On Mon, Aug 3, 2015 at 11:18 AM, Timothy Arceri t_arc...@yahoo.com.au
 wrote:
  On Sun, 2015-08-02 at 19:50 +0200, Alejandro Seguí wrote:
 
  Maybe just for completeness you could add this to the commit message
 
  The util/hash_table was intended to be a fast hash table
  replacement for the program/hash_table see 35fd61bd99c1 and
 72e55bb6888ff.
 
  ---
   src/glsl/ir_print_visitor.cpp | 19 ---
   1 file changed, 12 insertions(+), 7 deletions(-)
 
  diff --git a/src/glsl/ir_print_visitor.cpp
 b/src/glsl/ir_print_visitor.cpp
  index 78475f3..641a996 100644
  --- a/src/glsl/ir_print_visitor.cpp
  +++ b/src/glsl/ir_print_visitor.cpp
  @@ -25,7 +25,7 @@
   #include glsl_types.h
   #include glsl_parser_extras.h
   #include main/macros.h
  -#include program/hash_table.h
  +#include util/hash_table.h
 
   static void print_type(FILE *f, const glsl_type *t);
 
  @@ -89,14 +89,14 @@ ir_print_visitor::ir_print_visitor(FILE *f)
   {
  indentation = 0;
  printable_names =
  -  hash_table_ctor(32, hash_table_pointer_hash,
  hash_table_pointer_compare);
  +  _mesa_hash_table_create(NULL, _mesa_hash_pointer,
  _mesa_key_pointer_equal);
  symbols = _mesa_symbol_table_ctor();
  mem_ctx = ralloc_context(NULL);
   }
 
   ir_print_visitor::~ir_print_visitor()
   {
  -   hash_table_dtor(printable_names);
  +   _mesa_hash_table_destroy(printable_names, NULL);
  _mesa_symbol_table_dtor(symbols);
  ralloc_free(mem_ctx);
   }
  @@ -121,9 +121,14 @@ ir_print_visitor::unique_name(ir_variable *var)
  }
 
  /* Do we already have a name for this variable? */
  -   const char *name = (const char *)
 hash_table_find(this-printable_names,
  var);
  -   if (name != NULL)
  -  return name;
  +   struct hash_entry * entry =
  +_mesa_hash_table_search(this-printable_names, var);
  +
  +   if (entry != NULL) {
  +  return (const char *) entry-data;
  +   }
  +
  +   const char* name = NULL;
 
  The above looks a bit funny just floating here maybe move it
 
 
  /* If there's no conflict, just use the original name */
  Here.
  if (_mesa_symbol_table_find_symbol(this-symbols, -1, var-name) ==
  NULL) {
  @@ -132,7 +137,7 @@ ir_print_visitor::unique_name(ir_variable *var)
 static unsigned i = 1;
 name = ralloc_asprintf(this-mem_ctx, %s@%u, var-name, ++i);
  }
  -   hash_table_insert(this-printable_names, (void *) name, var);
  +   _mesa_hash_table_insert(this-printable_names, var, (void *) name);
  _mesa_symbol_table_add_symbol(this-symbols, -1, name, var);
  return name;
   }
 
  With those couple of small changes you can add to the commit message
  Reviewed-by: Timothy Arceri t_arc...@yahoo.com.au
 
  ___
  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 mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: replace old hash table with new and faster one

[Ilia Mirkin]

Given that this is a debug-only thing, I doubt perf numbers are that
interesting.

I have no clue what the diff is between the two hash tables, but if
one is allegedly faster than the other, that should be determined, and
we should just mass-migrate...

  -ilia

On Sun, Aug 2, 2015 at 8:05 PM, Chris Forbes chr...@ijw.co.nz wrote:
 Some perf numbers would be nice. How much is this winning?

 - Chris

 On Mon, Aug 3, 2015 at 11:18 AM, Timothy Arceri t_arc...@yahoo.com.au wrote:
 On Sun, 2015-08-02 at 19:50 +0200, Alejandro Seguí wrote:

 Maybe just for completeness you could add this to the commit message

 The util/hash_table was intended to be a fast hash table
 replacement for the program/hash_table see 35fd61bd99c1 and 72e55bb6888ff.

 ---
  src/glsl/ir_print_visitor.cpp | 19 ---
  1 file changed, 12 insertions(+), 7 deletions(-)

 diff --git a/src/glsl/ir_print_visitor.cpp b/src/glsl/ir_print_visitor.cpp
 index 78475f3..641a996 100644
 --- a/src/glsl/ir_print_visitor.cpp
 +++ b/src/glsl/ir_print_visitor.cpp
 @@ -25,7 +25,7 @@
  #include glsl_types.h
  #include glsl_parser_extras.h
  #include main/macros.h
 -#include program/hash_table.h
 +#include util/hash_table.h

  static void print_type(FILE *f, const glsl_type *t);

 @@ -89,14 +89,14 @@ ir_print_visitor::ir_print_visitor(FILE *f)
  {
 indentation = 0;
 printable_names =
 -  hash_table_ctor(32, hash_table_pointer_hash,
 hash_table_pointer_compare);
 +  _mesa_hash_table_create(NULL, _mesa_hash_pointer,
 _mesa_key_pointer_equal);
 symbols = _mesa_symbol_table_ctor();
 mem_ctx = ralloc_context(NULL);
  }

  ir_print_visitor::~ir_print_visitor()
  {
 -   hash_table_dtor(printable_names);
 +   _mesa_hash_table_destroy(printable_names, NULL);
 _mesa_symbol_table_dtor(symbols);
 ralloc_free(mem_ctx);
  }
 @@ -121,9 +121,14 @@ ir_print_visitor::unique_name(ir_variable *var)
 }

 /* Do we already have a name for this variable? */
 -   const char *name = (const char *) hash_table_find(this-printable_names,
 var);
 -   if (name != NULL)
 -  return name;
 +   struct hash_entry * entry =
 +_mesa_hash_table_search(this-printable_names, var);
 +
 +   if (entry != NULL) {
 +  return (const char *) entry-data;
 +   }
 +
 +   const char* name = NULL;

 The above looks a bit funny just floating here maybe move it


 /* If there's no conflict, just use the original name */
 Here.
 if (_mesa_symbol_table_find_symbol(this-symbols, -1, var-name) ==
 NULL) {
 @@ -132,7 +137,7 @@ ir_print_visitor::unique_name(ir_variable *var)
static unsigned i = 1;
name = ralloc_asprintf(this-mem_ctx, %s@%u, var-name, ++i);
 }
 -   hash_table_insert(this-printable_names, (void *) name, var);
 +   _mesa_hash_table_insert(this-printable_names, var, (void *) name);
 _mesa_symbol_table_add_symbol(this-symbols, -1, name, var);
 return name;
  }

 With those couple of small changes you can add to the commit message
 Reviewed-by: Timothy Arceri t_arc...@yahoo.com.au

 ___
 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 mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: replace old hash table with new and faster one

[Alejandro Seguí Díaz]

I'm starting to contribute and Timothy Arceri told me about this
task. The change was made at that sole file because we talked
about no need to migrate all tables at once, but we discuss this
and I take note to migrate all hash tables at once if everyone
agrees.

PS.: I forgot to add Reviewed-by Timothy Arceri at the commit
message. If we are ok with migrating in steps, I'll edit it and send
the patch again.

2015-08-03 2:40 GMT+02:00 Chris Forbes chr...@ijw.co.nz:

 Oh, fair enough then.
 On Aug 3, 2015 12:39 PM, Ilia Mirkin imir...@alum.mit.edu wrote:

 Given that this is a debug-only thing, I doubt perf numbers are that
 interesting.

 I have no clue what the diff is between the two hash tables, but if
 one is allegedly faster than the other, that should be determined, and
 we should just mass-migrate...

   -ilia

 On Sun, Aug 2, 2015 at 8:05 PM, Chris Forbes chr...@ijw.co.nz wrote:
  Some perf numbers would be nice. How much is this winning?
 
  - Chris
 
  On Mon, Aug 3, 2015 at 11:18 AM, Timothy Arceri t_arc...@yahoo.com.au
 wrote:
  On Sun, 2015-08-02 at 19:50 +0200, Alejandro Seguí wrote:
 
  Maybe just for completeness you could add this to the commit message
 
  The util/hash_table was intended to be a fast hash table
  replacement for the program/hash_table see 35fd61bd99c1 and
 72e55bb6888ff.
 
  ---
   src/glsl/ir_print_visitor.cpp | 19 ---
   1 file changed, 12 insertions(+), 7 deletions(-)
 
  diff --git a/src/glsl/ir_print_visitor.cpp
 b/src/glsl/ir_print_visitor.cpp
  index 78475f3..641a996 100644
  --- a/src/glsl/ir_print_visitor.cpp
  +++ b/src/glsl/ir_print_visitor.cpp
  @@ -25,7 +25,7 @@
   #include glsl_types.h
   #include glsl_parser_extras.h
   #include main/macros.h
  -#include program/hash_table.h
  +#include util/hash_table.h
 
   static void print_type(FILE *f, const glsl_type *t);
 
  @@ -89,14 +89,14 @@ ir_print_visitor::ir_print_visitor(FILE *f)
   {
  indentation = 0;
  printable_names =
  -  hash_table_ctor(32, hash_table_pointer_hash,
  hash_table_pointer_compare);
  +  _mesa_hash_table_create(NULL, _mesa_hash_pointer,
  _mesa_key_pointer_equal);
  symbols = _mesa_symbol_table_ctor();
  mem_ctx = ralloc_context(NULL);
   }
 
   ir_print_visitor::~ir_print_visitor()
   {
  -   hash_table_dtor(printable_names);
  +   _mesa_hash_table_destroy(printable_names, NULL);
  _mesa_symbol_table_dtor(symbols);
  ralloc_free(mem_ctx);
   }
  @@ -121,9 +121,14 @@ ir_print_visitor::unique_name(ir_variable *var)
  }
 
  /* Do we already have a name for this variable? */
  -   const char *name = (const char *)
 hash_table_find(this-printable_names,
  var);
  -   if (name != NULL)
  -  return name;
  +   struct hash_entry * entry =
  +_mesa_hash_table_search(this-printable_names, var);
  +
  +   if (entry != NULL) {
  +  return (const char *) entry-data;
  +   }
  +
  +   const char* name = NULL;
 
  The above looks a bit funny just floating here maybe move it
 
 
  /* If there's no conflict, just use the original name */
  Here.
  if (_mesa_symbol_table_find_symbol(this-symbols, -1, var-name)
 ==
  NULL) {
  @@ -132,7 +137,7 @@ ir_print_visitor::unique_name(ir_variable *var)
 static unsigned i = 1;
 name = ralloc_asprintf(this-mem_ctx, %s@%u, var-name,
 ++i);
  }
  -   hash_table_insert(this-printable_names, (void *) name, var);
  +   _mesa_hash_table_insert(this-printable_names, var, (void *)
 name);
  _mesa_symbol_table_add_symbol(this-symbols, -1, name, var);
  return name;
   }
 
  With those couple of small changes you can add to the commit message
  Reviewed-by: Timothy Arceri t_arc...@yahoo.com.au
 
  ___
  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 mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl: replace old hash table with new and faster one

[Alejandro Seguí]

The util/hash_table was intended to be a fast hash table
replacement for the program/hash_table see 35fd61bd99c1 and
72e55bb6888ff.
---
 src/glsl/ir_print_visitor.cpp | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/src/glsl/ir_print_visitor.cpp b/src/glsl/ir_print_visitor.cpp
index 78475f3..f9adc56 100644
--- a/src/glsl/ir_print_visitor.cpp
+++ b/src/glsl/ir_print_visitor.cpp
@@ -25,7 +25,7 @@
 #include glsl_types.h
 #include glsl_parser_extras.h
 #include main/macros.h
-#include program/hash_table.h
+#include util/hash_table.h
 
 static void print_type(FILE *f, const glsl_type *t);
 
@@ -89,14 +89,14 @@ ir_print_visitor::ir_print_visitor(FILE *f)
 {
indentation = 0;
printable_names =
-  hash_table_ctor(32, hash_table_pointer_hash, hash_table_pointer_compare);
+  _mesa_hash_table_create(NULL, _mesa_hash_pointer, 
_mesa_key_pointer_equal);
symbols = _mesa_symbol_table_ctor();
mem_ctx = ralloc_context(NULL);
 }
 
 ir_print_visitor::~ir_print_visitor()
 {
-   hash_table_dtor(printable_names);
+   _mesa_hash_table_destroy(printable_names, NULL);
_mesa_symbol_table_dtor(symbols);
ralloc_free(mem_ctx);
 }
@@ -121,18 +121,22 @@ ir_print_visitor::unique_name(ir_variable *var)
}
 
/* Do we already have a name for this variable? */
-   const char *name = (const char *) hash_table_find(this-printable_names, 
var);
-   if (name != NULL)
-  return name;
+   struct hash_entry * entry =
+  _mesa_hash_table_search(this-printable_names, var);
+
+   if (entry != NULL) {
+  return (const char *) entry-data;
+   }
 
/* If there's no conflict, just use the original name */
+   const char* name = NULL;
if (_mesa_symbol_table_find_symbol(this-symbols, -1, var-name) == NULL) {
   name = var-name;
} else {
   static unsigned i = 1;
   name = ralloc_asprintf(this-mem_ctx, %s@%u, var-name, ++i);
}
-   hash_table_insert(this-printable_names, (void *) name, var);
+   _mesa_hash_table_insert(this-printable_names, var, (void *) name);
_mesa_symbol_table_add_symbol(this-symbols, -1, name, var);
return name;
 }
-- 
2.5.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] help: mesa GL_OES_mapbuffer

[????????]

it did not work. 


off screen rendering might be a walkaround, but would it work for pixel buffer 
surface?




thanks.
hilbert___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] help:eglCopyBuffers

[????????]

background:
1)ubuntu
2)libgles1-mesa-dev libgles2-mesa-dev installed


problem
 surface=eglCreatePbufferSurface
 Pixmap = XCreatePixmap(d,w,width,height,32); 
eglCopyBuffers(dpy,sur, EGLNativePixmap)pixmap) returns EGL_FALSE;
eglGetError()= 0x3000


Question:
1) was what I did right?
2)I got X Error 9 bad pixmap or window parameters
3) but rglGetError() returns ox3000 , it meant  NO_ERROR.


how could I Get the pixels from a pixel buffer surface?


thanks
hilbert___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] help: mesa GL_OES_mapbuffer

[Ilia Mirkin]

https://www.khronos.org/registry/gles/extensions/OES/OES_mapbuffer.txt

This extension adds to the vertex buffer object functionality supported
by OpenGL ES 1.1 or ES 2.0 by allowing the entire data storage of a
buffer object to be mapped into the client's address space.

So this only applies to buffer objects (i.e. things created with
glGenBuffers). It should thus work with a buffer later (or earlier)
bound as a PBO (i.e. GL_PIXEL_PACK_BUFFER/GL_PIXEL_UNPACK_BUFFER), but
not with a texture or renderbuffer.

You might be interested in http://docs.gl/es3/glBindBuffer

Hope this helps,

  -ilia

On Sat, Aug 1, 2015 at 9:02 PM, 凶恶的狼 731116...@qq.com wrote:
 it did not work.

 off screen rendering might be a walkaround, but would it work for pixel
 buffer surface?


 thanks.
 hilbert

 ___
 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