Re: [Mesa-dev] [PATCH 1/7] mesa: implement glBindBuffersBase() and gl BindBuffersRange()
Maxence, while I think it's great that you're interested in working on this extension, I'm afraid I have another implementation in a branch in my mesa tree: http://cgit.freedesktop.org/~fredrik/mesa/log/?h=arb-multi-bind I've looked at your patches, and noticed you've implemented the functions by calling the _mesa_Bind*() functions in a loop. I know that the specification uses examples that look very much like this to illustrate the intended effect of calling each function. But when actually implemented in this this way you don't get the performance benefit you would get by writing a specialized implementation of each function. For example you can avoid locking the mutex that protects the hash table more than once when you look up the pointers to the objects. There is also some state validation that doesn't need to be repeated for each object. Another downside is that when an error occurs, the _mesa_Bind*() functions will report the wrong entry point in the error message. The quality of those messages is important now that we support KHR_debug, because they are reported to the client. While your implementation is simpler than mine, I think my approach is better in the long term. But I think others should chime in on this. Fredrik ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] FOSDEM14: Graphics DevRoom: Deadline approaching fast.
Hi, There are still 5 slots open for the FOSDEM graphics DevRoom, and the deadline is this friday, the 10th. Get a move on. If you have requested an account reset with me before, but if you then haven't bothered filing a talk, you do NOT have a slot. Please file a talk ASAP to still secure a place. For more information on how to file for a devroom, read the email sent back in october: http://lists.x.org/archives/xorg-devel/2013-October/038185.html Luc Verhaegen. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6][RFC] Gallium/dri2: implement blitImage
On Mon, 2014-01-06 at 12:50 +0100, Marek Olšák wrote: > > Fences might not be implemented by some drivers. I recommend setting > the fence pointer to NULL, then calling flush and then checking if > it's not NULL. That's not necessary, Gallium drivers have to implement the fence interfaces. -- 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] [PATCH 3/4] winsys/radeon: Keep bo statistics
On Mon, Jan 6, 2014 at 12:17 PM, Lauri Kasanen wrote:
> These will be used later on for optimizing the VRAM placement.
>
> No measurable overhead (glxgears).
I recommend testing torcs (the Forza track) next time. glxgears is not
useful here.
>
> Signed-off-by: Lauri Kasanen
> ---
> src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 3 +++
> src/gallium/winsys/radeon/drm/radeon_drm_bo.h | 16
> src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 8
> 3 files changed, 27 insertions(+)
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> index 7543840..9aa1a0f 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> @@ -529,6 +529,9 @@ static void *radeon_bo_map(struct radeon_winsys_cs_handle
> *buf,
> fprintf(ws->bo_stats_file, "%p cpu mapped @%llu\n", bo,
> stats_time_get(ws));
> }
>
> +bo->stats.num_cpu_ops++;
> +bo->stats.last_cpu_time = stats_time_get(ws);
> +
> return radeon_bo_do_map(bo);
> }
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
> b/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
> index 5536bc1..651694b 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
> @@ -44,6 +44,20 @@ struct radeon_bo_desc {
> unsigned initial_domains;
> };
>
> +struct radeon_bo_stats {
> +uint64_t num_reads;
> +uint64_t num_writes;
> +uint64_t num_cpu_ops;
> +
> +/* Milliseconds in a monotonic clock */
> +uint64_t last_read_time;
> +uint64_t last_write_time;
> +uint64_t last_cpu_time;
> +
> +/* Depth, MSAA, etc. */
> +bool high_prio;
> +};
> +
> struct radeon_bo {
> struct pb_buffer base;
>
> @@ -67,6 +81,8 @@ struct radeon_bo {
>
> boolean flinked;
> uint32_t flink;
> +
> +struct radeon_bo_stats stats;
> };
>
> struct pb_manager *radeon_bomgr_create(struct radeon_drm_winsys *rws);
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> index 4d46e85..f78b6cc 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
> @@ -361,6 +361,14 @@ static unsigned radeon_drm_cs_add_reloc(struct
> radeon_winsys_cs *rcs,
> }
> }
>
> +if (usage & RADEON_USAGE_WRITE) {
> +bo->stats.num_writes++;
> +bo->stats.last_write_time = stats_time_get(ws);
> +} else {
> +bo->stats.num_reads++;
> +bo->stats.last_read_time = stats_time_get(ws);
> +}
You do know that this is mostly useless, don't you? You sure won't
know which resources are used for reading only, because
glBufferSubData or glTexSubImage may generate a write, and an app
which uploads data every frame or every couple of draw calls can cause
the resource to appear as being used for writing all the time, while
in reality it's only used for reading during rendering. You also won't
know how many draw calls the resource is used in, because the function
is called only once per state change and there can be many draw calls
per state change. In my opinion, the only useful information would be
"last_use_time" and you can record it just once in radeon_cs_flush (or
radeon_drm_cs_emit_ioctl_oneshot if you want to do it in the CS
thread) instead of doing it in add_reloc, which may be called many
times for the same buffer.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: rename min(), max() functions to fix MSVC build
On Tue, Jan 7, 2014 at 12:12 AM, Brian Paul wrote: > Evidently, there's some other definition of "min" and "max" that > causes MSVC to choke on these function names. Renaming to min2() > and max2() fixes things. Wouldn't it be easier to just make sure NOMINMAX is defined before including any system-headers? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] radeon: Determine the bo priority (MSAA, depth, UVD are high)
On Mon, Jan 6, 2014 at 12:18 PM, Lauri Kasanen wrote:
> Signed-off-by: Lauri Kasanen
> ---
> src/gallium/drivers/radeon/r600_buffer_common.c | 8
> src/gallium/drivers/radeon/radeon_uvd.c | 4 ++--
> src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 4
> src/gallium/winsys/radeon/drm/radeon_drm_bo.h | 1 +
> src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 2 +-
> src/gallium/winsys/radeon/drm/radeon_winsys.h | 2 ++
> 6 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
> b/src/gallium/drivers/radeon/r600_buffer_common.c
> index ac5fbcc..fb8005a 100644
> --- a/src/gallium/drivers/radeon/r600_buffer_common.c
> +++ b/src/gallium/drivers/radeon/r600_buffer_common.c
> @@ -25,6 +25,7 @@
> */
>
> #include "r600_cs.h"
> +#include "util/u_format.h"
> #include "util/u_memory.h"
> #include "util/u_upload_mgr.h"
> #include
> @@ -101,6 +102,12 @@ bool r600_init_resource(struct r600_common_screen
> *rscreen,
> bool use_reusable_pool, unsigned usage)
> {
> uint32_t initial_domain, domains;
> + bool high_prio = false;
> +
> + /* If it's depth or MSAA, consider it high priority */
> + if (util_format_has_depth(util_format_description(res->b.b.format)) ||
> + res->b.b.nr_samples > 1)
> + high_prio = true;
I think this is a wrong place to check for texture properties. It
should be in r600_texture_create_object.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73337] ir_builder.h(187) : error C2226: syntax error : unexpected type 'ir_builder::operand'
https://bugs.freedesktop.org/show_bug.cgi?id=73337 Brian Paul changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Brian Paul --- Should be fixed by commit 8d1400fe123dc229e87a3a6316b0697f864695a3. -- 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] glsl: rename min(), max() functions to fix MSVC build
On 01/06/2014 03:12 PM, Brian Paul wrote:
> Evidently, there's some other definition of "min" and "max" that
> causes MSVC to choke on these function names. Renaming to min2()
> and max2() fixes things.
That's really strange...but I'm fine with renaming them. Sorry for the
trouble.
Reviewed-by: Kenneth Graunke
> ---
> src/glsl/builtin_functions.cpp |6 +++---
> src/glsl/ir_builder.cpp|4 ++--
> src/glsl/ir_builder.h |4 ++--
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
> index f56be0c..10127f3 100644
> --- a/src/glsl/builtin_functions.cpp
> +++ b/src/glsl/builtin_functions.cpp
> @@ -4073,7 +4073,7 @@ builtin_builder::_min3(builtin_available_predicate
> avail,
> ir_variable *z = in_var(z_type, "z");
> MAKE_SIG(x_type, avail, 3, x, y, z);
>
> - ir_expression *min3 = min(x, min(y,z));
> + ir_expression *min3 = min2(x, min2(y,z));
> body.emit(ret(min3));
>
> return sig;
> @@ -4089,7 +4089,7 @@ builtin_builder::_max3(builtin_available_predicate
> avail,
> ir_variable *z = in_var(z_type, "z");
> MAKE_SIG(x_type, avail, 3, x, y, z);
>
> - ir_expression *max3 = max(x, max(y,z));
> + ir_expression *max3 = max2(x, max2(y,z));
> body.emit(ret(max3));
>
> return sig;
> @@ -4105,7 +4105,7 @@ builtin_builder::_mid3(builtin_available_predicate
> avail,
> ir_variable *z = in_var(z_type, "z");
> MAKE_SIG(x_type, avail, 3, x, y, z);
>
> - ir_expression *mid3 = max(min(x, y), max(min(x, z), min(y, z)));
> + ir_expression *mid3 = max2(min2(x, y), max2(min2(x, z), min2(y, z)));
> body.emit(ret(mid3));
>
> return sig;
> diff --git a/src/glsl/ir_builder.cpp b/src/glsl/ir_builder.cpp
> index 31ed191..7f41ed6 100644
> --- a/src/glsl/ir_builder.cpp
> +++ b/src/glsl/ir_builder.cpp
> @@ -211,12 +211,12 @@ ir_expression *sub(operand a, operand b)
> return expr(ir_binop_sub, a, b);
> }
>
> -ir_expression *min(operand a, operand b)
> +ir_expression *min2(operand a, operand b)
> {
> return expr(ir_binop_min, a, b);
> }
>
> -ir_expression *max(operand a, operand b)
> +ir_expression *max2(operand a, operand b)
> {
> return expr(ir_binop_max, a, b);
> }
> diff --git a/src/glsl/ir_builder.h b/src/glsl/ir_builder.h
> index 4b85ea1..f00e6f3 100644
> --- a/src/glsl/ir_builder.h
> +++ b/src/glsl/ir_builder.h
> @@ -184,8 +184,8 @@ ir_expression *i2b(operand a);
> ir_expression *f2b(operand a);
> ir_expression *b2f(operand a);
>
> -ir_expression *min(operand a, operand b);
> -ir_expression *max(operand a, operand b);
> +ir_expression *min2(operand a, operand b);
> +ir_expression *max2(operand a, operand b);
>
> ir_expression *fma(operand a, operand b, operand c);
> ir_expression *lrp(operand x, operand y, operand a);
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/7] i965: Don't call the blitter on addresses it can't handle.
On Mon, Jan 6, 2014 at 11:00 AM, Kenneth Graunke wrote:
> On 01/05/2014 02:28 PM, Eric Anholt wrote:
>> Anuj Phogat writes:
>>
>>> On Mon, Dec 23, 2013 at 4:08 PM, Eric Anholt wrote:
Noticed by tex3d-maxsize on my next commit to check that our addresses
don't overflow.
---
src/mesa/drivers/dri/i965/intel_blit.c| 20
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 23 ---
2 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_blit.c
b/src/mesa/drivers/dri/i965/intel_blit.c
index 7bc289f..13cc777 100644
--- a/src/mesa/drivers/dri/i965/intel_blit.c
+++ b/src/mesa/drivers/dri/i965/intel_blit.c
@@ -229,12 +229,32 @@ intel_miptree_blit(struct brw_context *brw,
src_x += src_image_x;
src_y += src_image_y;
+ /* The blitter interprets the 16-bit src x/y as a signed 16-bit value,
+* where negative values are invalid. The values we're working with
are
+* unsigned, so make sure we don't overflow.
+*/
+ if (src_x >= 32768 || src_y >= 32768) {
+ perf_debug("Falling back due to >=32k src offset (%d, %d)\n",
+ src_x, src_y);
+ return false;
+ }
+
uint32_t dst_image_x, dst_image_y;
intel_miptree_get_image_offset(dst_mt, dst_level, dst_slice,
&dst_image_x, &dst_image_y);
dst_x += dst_image_x;
dst_y += dst_image_y;
+ /* The blitter interprets the 16-bit destination x/y as a signed 16-bit
+* value. The values we're working with are unsigned, so make sure we
+* don't overflow.
+*/
+ if (dst_x >= 32768 || dst_y >= 32768) {
+ perf_debug("Falling back due to >=32k dst offset (%d, %d)\n",
+ dst_x, dst_y);
+ return false;
+ }
+
if (!intelEmitCopyBlit(brw,
src_mt->cpp,
src_pitch,
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index de47143..0818226 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -443,7 +443,8 @@ intel_miptree_choose_tiling(struct brw_context *brw,
if (minimum_pitch < 64)
return I915_TILING_NONE;
- if (ALIGN(minimum_pitch, 512) >= 32768) {
+ if (ALIGN(minimum_pitch, 512) >= 32768 ||
+ mt->total_width >= 32768 || mt->total_height >= 32768) {
perf_debug("%dx%d miptree too large to blit, falling back to
untiled",
mt->total_width, mt->total_height);
return I915_TILING_NONE;
@@ -2233,6 +2234,22 @@ intel_miptree_release_map(struct intel_mipmap_tree
*mt,
*map = NULL;
}
+static bool
+can_blit_slice(struct intel_mipmap_tree *mt,
+ unsigned int level, unsigned int slice)
+{
+ uint32_t image_x;
+ uint32_t image_y;
+ intel_miptree_get_image_offset(mt, level, slice, &image_x, &image_y);
+ if (image_x >= 32768 || image_y >= 32768)
+ return false;
+
+ if (mt->region->pitch >= 32768)
+ return false;
+
+ return true;
+}
+
static void
intel_miptree_map_singlesample(struct brw_context *brw,
struct intel_mipmap_tree *mt,
@@ -2276,11 +2293,11 @@ intel_miptree_map_singlesample(struct brw_context
*brw,
!mt->compressed &&
(mt->region->tiling == I915_TILING_X ||
(brw->gen >= 6 && mt->region->tiling == I915_TILING_Y)) &&
-mt->region->pitch < 32768) {
+can_blit_slice(mt, level, slice)) {
intel_miptree_map_blit(brw, mt, map, level, slice);
} else if (mt->region->tiling != I915_TILING_NONE &&
mt->region->bo->size >= brw->max_gtt_map_object_size) {
- assert(mt->region->pitch < 32768);
+ assert(can_blit_slice(mt, level, slice));
>>> I think the right thing to do here is:
>>> - mt->region->bo->size >= brw->max_gtt_map_object_size) {
>>> - assert(mt->region->pitch < 32768);
>>> + mt->region->bo->size >= brw->max_gtt_map_object_size &&
>>> + can_blit_slice(mt, level, slice)) {
>>>
>>> This allow us falling back to intel_miptree_map_gtt(). I suggested this
>>> change
>>> as a part of '[PATCH] i965: Fix the region's pitch condition to use
>>> blitter'.
>>
>> If region->bo->size >= max_gtt_map_object_size, you can't fall back to
>> GTT mapping, though. Since you can't do that, previous code needs to
>> have made sure you can't reach this point.
>
> I agree with Eric - we can't fal
Re: [Mesa-dev] [PATCH 2/4] radeon: Add bo statistics dumping support
Is the logging really needed apart from initial debugging and
validation of the code? I don't see a reason to have this in master.
Also, pipe_screen functions must not change the contents of
radeon_winsys. They are different objects. The two can only
communicate using the functions declared in the radeon_winsys
structure.
Marek
On Mon, Jan 6, 2014 at 12:17 PM, Lauri Kasanen wrote:
> No measurable overhead when off (glxgears within 0.5%).
>
> v2: Cosmetic changes.
>
> Signed-off-by: Lauri Kasanen
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 32
> +++
> src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
> src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 17 ++
> src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 9
> src/gallium/winsys/radeon/drm/radeon_winsys.h | 6 +
> 5 files changed, 65 insertions(+)
>
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
> b/src/gallium/drivers/radeon/r600_pipe_common.c
> index 28921be..f649b9f 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
> @@ -26,11 +26,18 @@
>
> #include "r600_pipe_common.h"
> #include "r600_cs.h"
> +#include "../../winsys/radeon/drm/radeon_drm_winsys.h"
> +#include "os/os_time.h"
> #include "tgsi/tgsi_parse.h"
> #include "util/u_format_s3tc.h"
> #include "util/u_upload_mgr.h"
> #include
>
> +#ifdef __GLIBC__
> +#define _GNU_SOURCE
> +#include
> +#endif
> +
> static const struct debug_named_value common_debug_options[] = {
> /* logging */
> { "tex", DBG_TEX, "Print texture info" },
> @@ -38,6 +45,7 @@ static const struct debug_named_value
> common_debug_options[] = {
> { "compute", DBG_COMPUTE, "Print compute info" },
> { "vm", DBG_VM, "Print virtual addresses when creating resources" },
> { "trace_cs", DBG_TRACE_CS, "Trace cs and write rlockup_.c file
> with faulty cs" },
> + { "bostats", DBG_BO_STATS, "Write bo statistics to
> /tmp/bostats.[.name]" },
>
> /* shaders */
> { "fs", DBG_FS, "Print fetch shaders" },
> @@ -209,6 +217,24 @@ bool r600_common_screen_init(struct r600_common_screen
> *rscreen,
> return false;
> }
>
> + if (rscreen->debug_flags & DBG_BO_STATS) {
> + char statsfile[80];
> + const pid_t pid = getpid();
> +
> +#ifdef __GLIBC__
> + snprintf(statsfile, 80, "/tmp/bostats.%u.%s", pid,
> program_invocation_short_name);
> +#else
> + snprintf(statsfile, 80, "/tmp/bostats.%u", pid);
> +#endif
> +
> + rscreen->ws->bo_stats_file = fopen(statsfile, "w");
> + if (!rscreen->ws->bo_stats_file)
> + fprintf(stderr, "Failed to open bo stats file %s\n",
> statsfile);
> + else
> + fprintf(rscreen->ws->bo_stats_file, "started @%llu\n",
> + stats_time_get(ws));
> + }
> +
> util_format_s3tc_init();
>
> pipe_mutex_init(rscreen->aux_context_lock);
> @@ -217,6 +243,12 @@ bool r600_common_screen_init(struct r600_common_screen
> *rscreen,
>
> void r600_common_screen_cleanup(struct r600_common_screen *rscreen)
> {
> + if ((rscreen->debug_flags & DBG_BO_STATS) &&
> rscreen->ws->bo_stats_file) {
> + fflush(rscreen->ws->bo_stats_file);
> + fclose(rscreen->ws->bo_stats_file);
> + rscreen->ws->bo_stats_file = NULL;
> + }
> +
> pipe_mutex_destroy(rscreen->aux_context_lock);
> rscreen->aux_context->destroy(rscreen->aux_context);
> }
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
> b/src/gallium/drivers/radeon/r600_pipe_common.h
> index bf0b968..4c35e66 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.h
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.h
> @@ -67,6 +67,7 @@
> #define DBG_COMPUTE(1 << 2)
> #define DBG_VM (1 << 3)
> #define DBG_TRACE_CS (1 << 4)
> +#define DBG_BO_STATS (1 << 5)
> /* shaders */
> #define DBG_FS (1 << 8)
> #define DBG_VS (1 << 9)
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> index ca569a1..7543840 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> @@ -370,6 +370,7 @@ static void radeon_bo_destroy(struct pb_buffer *_buf)
> {
> struct radeon_bo *bo = radeon_bo(_buf);
> struct radeon_bomgr *mgr = bo->mgr;
> +struct radeon_winsys *ws = (struct radeon_winsys *) mgr->rws;
> struct drm_gem_close args;
>
> memset(&args, 0, sizeof(args));
> @@ -399,6 +400,11 @@ static void radeon_bo_destroy(struct pb_buffer *_buf)
> bo->rws->allocated_vram -= align(bo->base.size, 4096);
> else if (bo->initial_domain & RADEON_DOMAIN_GTT)
> bo->rws->allocated_gtt
[Mesa-dev] [PATCH] glsl: rename min(), max() functions to fix MSVC build
Evidently, there's some other definition of "min" and "max" that
causes MSVC to choke on these function names. Renaming to min2()
and max2() fixes things.
---
src/glsl/builtin_functions.cpp |6 +++---
src/glsl/ir_builder.cpp|4 ++--
src/glsl/ir_builder.h |4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index f56be0c..10127f3 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -4073,7 +4073,7 @@ builtin_builder::_min3(builtin_available_predicate avail,
ir_variable *z = in_var(z_type, "z");
MAKE_SIG(x_type, avail, 3, x, y, z);
- ir_expression *min3 = min(x, min(y,z));
+ ir_expression *min3 = min2(x, min2(y,z));
body.emit(ret(min3));
return sig;
@@ -4089,7 +4089,7 @@ builtin_builder::_max3(builtin_available_predicate avail,
ir_variable *z = in_var(z_type, "z");
MAKE_SIG(x_type, avail, 3, x, y, z);
- ir_expression *max3 = max(x, max(y,z));
+ ir_expression *max3 = max2(x, max2(y,z));
body.emit(ret(max3));
return sig;
@@ -4105,7 +4105,7 @@ builtin_builder::_mid3(builtin_available_predicate avail,
ir_variable *z = in_var(z_type, "z");
MAKE_SIG(x_type, avail, 3, x, y, z);
- ir_expression *mid3 = max(min(x, y), max(min(x, z), min(y, z)));
+ ir_expression *mid3 = max2(min2(x, y), max2(min2(x, z), min2(y, z)));
body.emit(ret(mid3));
return sig;
diff --git a/src/glsl/ir_builder.cpp b/src/glsl/ir_builder.cpp
index 31ed191..7f41ed6 100644
--- a/src/glsl/ir_builder.cpp
+++ b/src/glsl/ir_builder.cpp
@@ -211,12 +211,12 @@ ir_expression *sub(operand a, operand b)
return expr(ir_binop_sub, a, b);
}
-ir_expression *min(operand a, operand b)
+ir_expression *min2(operand a, operand b)
{
return expr(ir_binop_min, a, b);
}
-ir_expression *max(operand a, operand b)
+ir_expression *max2(operand a, operand b)
{
return expr(ir_binop_max, a, b);
}
diff --git a/src/glsl/ir_builder.h b/src/glsl/ir_builder.h
index 4b85ea1..f00e6f3 100644
--- a/src/glsl/ir_builder.h
+++ b/src/glsl/ir_builder.h
@@ -184,8 +184,8 @@ ir_expression *i2b(operand a);
ir_expression *f2b(operand a);
ir_expression *b2f(operand a);
-ir_expression *min(operand a, operand b);
-ir_expression *max(operand a, operand b);
+ir_expression *min2(operand a, operand b);
+ir_expression *max2(operand a, operand b);
ir_expression *fma(operand a, operand b, operand c);
ir_expression *lrp(operand x, operand y, operand a);
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [v3][r600g] Cleaning compute_memory_pool from gallium/drivers/r600
The r600g prefix is wrong. Your commit messages should follow the same
conventions the other Mesa developers use (see the git log for examples).
Since you're changing compute, you should use the prefix
"r600g/compute:" ("r600g:" is okay too), but never "[r600g]". The
subjects of your emails don't have any prefix, which is wrong too and
it's why I ignored your emails until now.
Marek
On Mon, Jan 6, 2014 at 10:47 PM, Bruno Jiménez wrote:
> Hi,
>
> Third version of the patches.
>
> Now with r600g in the commit messages.
> Patches 2 and 3 have spaces between 'if' and '('.
> Patches 1,4 and 5 are the same.
>
> Thanks!
>
> [PATCH 1/5] [r600g] Fixing a typo and some indentation
> [PATCH 2/5] [r600g] Adding checks for NULL after CALLOC
> [PATCH 3/5] [r600g] Add more NULL checks
> [PATCH 4/5] [r600g] Tidy a bit compute_memory_finalize_pending
> [PATCH 5/5] [r600g] Cleanup of compute_memory_pool.h
> ___
> 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 73337] New: ir_builder.h(187) : error C2226: syntax error : unexpected type 'ir_builder::operand'
https://bugs.freedesktop.org/show_bug.cgi?id=73337 Priority: medium Bug ID: 73337 Keywords: regression CC: kenn...@whitecape.org Assignee: mesa-dev@lists.freedesktop.org Summary: ir_builder.h(187) : error C2226: syntax error : unexpected type 'ir_builder::operand' 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: f8432832a7f3d3cc01f8bab8358069029d575ef0 (master) Compiling src\mesa\main\ff_fragment_shader.cpp ... ff_fragment_shader.cpp src\mapi\../glsl/ir_builder.h(187) : error C2226: syntax error : unexpected type 'ir_builder::operand' src\mapi\../glsl/ir_builder.h(187) : error C2059: syntax error : ')' src\mapi\../glsl/ir_builder.h(188) : error C2226: syntax error : unexpected type 'ir_builder::operand' src\mapi\../glsl/ir_builder.h(188) : error C2059: syntax error : ')' commit 61c450fc81900131621e57fdd78a40e82239daf3 Author: Maxence Le Doré Date: Fri Jan 3 00:09:50 2014 +0100 glsl: add min() and max() functions to builder.cpp 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] configure: Disable xvmc by default
On Sun, Jan 5, 2014 at 7:00 PM, Tom Stellard wrote: > On Sun, Jan 05, 2014 at 09:49:53PM -0500, Ilia Mirkin wrote: >> On Sun, Jan 5, 2014 at 9:49 PM, Tom Stellard wrote: >> > From: Tom Stellard >> > >> > The xvmc unit tests are failing on r300g and r600g. >> >> FWIW it works fine on nv40-nv96. (Haven't checked the actual >> unit-tests, but the functionality is fine.) >> > > I'm more concerned with the unit tests, since I would like to get make > check working. It would be great if someone could fix the unit tests, > but until that happens, I think xvmc should be disabled. > > -Tom > >> > --- >> > configure.ac | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/configure.ac b/configure.ac >> > index f75325d..d41455b 100644 >> > --- a/configure.ac >> > +++ b/configure.ac >> > @@ -583,7 +583,7 @@ AC_ARG_ENABLE([xvmc], >> > [AS_HELP_STRING([--enable-xvmc], >> > [enable xvmc library @<:@default=auto@:>@])], >> > [enable_xvmc="$enableval"], >> > - [enable_xvmc=auto]) >> > + [enable_xvmc=no]) >> > AC_ARG_ENABLE([vdpau], >> > [AS_HELP_STRING([--enable-vdpau], >> > [enable vdpau library @<:@default=auto@:>@])], >> > -- >> > 1.8.1.5 >> > >> > ___ >> > 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 The XvMC unit tests are failing on swrast, softpipe, and llvmpipe too. Reviewed-by: Vinson Lee ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Simplify built-in generator functions for min3/max3/mid3.
The type of all three parameters are identical, so we don't need to
specify it three times. The predicate is always identical too, so we
don't need to make it a parameter, either.
Signed-off-by: Kenneth Graunke
Cc: Maxence Le Doré
---
src/glsl/builtin_functions.cpp | 137 ++---
1 file changed, 60 insertions(+), 77 deletions(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index f56be0c..5a7a975 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -576,20 +576,9 @@ private:
ir_function_signature *_atomic_op(const char *intrinsic,
builtin_available_predicate avail);
- ir_function_signature *_min3(builtin_available_predicate avail,
-const glsl_type *x_type,
-const glsl_type *y_type,
-const glsl_type *z_type);
-
- ir_function_signature *_max3(builtin_available_predicate avail,
-const glsl_type *x_type,
-const glsl_type *y_type,
-const glsl_type *z_type);
-
- ir_function_signature *_mid3(builtin_available_predicate avail,
-const glsl_type *x_type,
-const glsl_type *y_type,
-const glsl_type *z_type);
+ B1(min3)
+ B1(max3)
+ B1(mid3)
#undef B0
#undef B1
@@ -2128,54 +2117,54 @@ builtin_builder::create_builtins()
NULL);
add_function("min3",
-_min3(shader_trinary_minmax, glsl_type::float_type,
glsl_type::float_type, glsl_type::float_type),
-_min3(shader_trinary_minmax, glsl_type::vec2_type,
glsl_type::vec2_type, glsl_type::vec2_type),
-_min3(shader_trinary_minmax, glsl_type::vec3_type,
glsl_type::vec3_type, glsl_type::vec3_type),
-_min3(shader_trinary_minmax, glsl_type::vec4_type,
glsl_type::vec4_type, glsl_type::vec4_type),
-
-_min3(shader_trinary_minmax, glsl_type::int_type,
glsl_type::int_type, glsl_type::int_type),
-_min3(shader_trinary_minmax, glsl_type::ivec2_type,
glsl_type::ivec2_type, glsl_type::ivec2_type),
-_min3(shader_trinary_minmax, glsl_type::ivec3_type,
glsl_type::ivec3_type, glsl_type::ivec3_type),
-_min3(shader_trinary_minmax, glsl_type::ivec4_type,
glsl_type::ivec4_type, glsl_type::ivec4_type),
-
-_min3(shader_trinary_minmax, glsl_type::uint_type,
glsl_type::uint_type, glsl_type::uint_type),
-_min3(shader_trinary_minmax, glsl_type::uvec2_type,
glsl_type::uvec2_type, glsl_type::uvec2_type),
-_min3(shader_trinary_minmax, glsl_type::uvec3_type,
glsl_type::uvec3_type, glsl_type::uvec3_type),
-_min3(shader_trinary_minmax, glsl_type::uvec4_type,
glsl_type::uvec4_type, glsl_type::uvec4_type),
+_min3(glsl_type::float_type),
+_min3(glsl_type::vec2_type),
+_min3(glsl_type::vec3_type),
+_min3(glsl_type::vec4_type),
+
+_min3(glsl_type::int_type),
+_min3(glsl_type::ivec2_type),
+_min3(glsl_type::ivec3_type),
+_min3(glsl_type::ivec4_type),
+
+_min3(glsl_type::uint_type),
+_min3(glsl_type::uvec2_type),
+_min3(glsl_type::uvec3_type),
+_min3(glsl_type::uvec4_type),
NULL);
add_function("max3",
-_max3(shader_trinary_minmax, glsl_type::float_type,
glsl_type::float_type, glsl_type::float_type),
-_max3(shader_trinary_minmax, glsl_type::vec2_type,
glsl_type::vec2_type, glsl_type::vec2_type),
-_max3(shader_trinary_minmax, glsl_type::vec3_type,
glsl_type::vec3_type, glsl_type::vec3_type),
-_max3(shader_trinary_minmax, glsl_type::vec4_type,
glsl_type::vec4_type, glsl_type::vec4_type),
-
-_max3(shader_trinary_minmax, glsl_type::int_type,
glsl_type::int_type, glsl_type::int_type),
-_max3(shader_trinary_minmax, glsl_type::ivec2_type,
glsl_type::ivec2_type, glsl_type::ivec2_type),
-_max3(shader_trinary_minmax, glsl_type::ivec3_type,
glsl_type::ivec3_type, glsl_type::ivec3_type),
-_max3(shader_trinary_minmax, glsl_type::ivec4_type,
glsl_type::ivec4_type, glsl_type::ivec4_type),
-
-_max3(shader_trinary_minmax, glsl_type::uint_type,
glsl_type::uint_type, glsl_type::uint_type),
-_max3(shader_trinary_minmax, glsl_type::uvec2_type,
glsl_type::uvec2_type, glsl_type::uvec2_type),
-_max3(shader_trinary_minmax, glsl_type::uvec3_type,
glsl_type::uvec3_type, glsl_type::uvec3_type),
-_max3(shader_trinary_minmax, glsl_type::uvec4_type,
glsl_type::uvec4_type, glsl_
[Mesa-dev] [Bug 72877] Wrong colors with Mesa 9.2 and Mesa 10.0 on PPC Linux systems
https://bugs.freedesktop.org/show_bug.cgi?id=72877 --- Comment #7 from Christian Zigotzky --- Created attachment 91566 --> https://bugs.freedesktop.org/attachment.cgi?id=91566&action=edit glxgears has wrong colors with Mesa 10.0.1 -- 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] AMD_shader_trinary_minmax V2 changes
On 01/02/2014 03:22 PM, Maxence Le Doré wrote: > - Correct typo in predicate function > - Split the patch that introduces ir_builder changes > - Drop trivial min3_expr(), max3_expr(), mid3_expr() > - Thanks to Roland Scheidegger and Mario Rugiero, catch all cases for > evaluation of mid3 > - Squash trivial patches. > > > Tried something to fix my weird mail address with git sendmail. Hope > this will work next time. Looks great, Maxence! Thanks! Pushed to master. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glsl: Refactor is_zero/one/negative_one into an is_value() method.
This patch creates a new generic is_value() method, which checks if an
ir_constant has a particular value. (For vectors, it must have the
single value repeated across all components.)
It then rewrites the is_zero/is_one/is_negative_one methods to use this
generic helper. All three were basically identical except for the value
they checked for. The other difference is that is_negative_one rejects
boolean types. The new is_value function maintains this behavior, only
allowing boolean types when checking for 0 or 1.
Signed-off-by: Kenneth Graunke
---
src/glsl/ir.cpp | 85 -
src/glsl/ir.h | 6
2 files changed, 23 insertions(+), 68 deletions(-)
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index 04a7b87..ba6903d 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -1122,27 +1122,31 @@ ir_constant::has_value(const ir_constant *c) const
}
bool
-ir_constant::is_zero() const
+ir_constant::is_value(float f, int i) const
{
if (!this->type->is_scalar() && !this->type->is_vector())
return false;
+ /* Only accept boolean values for 0/1. */
+ if (int(bool(i)) != i && this->type->is_boolean())
+ return false;
+
for (unsigned c = 0; c < this->type->vector_elements; c++) {
switch (this->type->base_type) {
case GLSL_TYPE_FLOAT:
-if (this->value.f[c] != 0.0)
+if (this->value.f[c] != f)
return false;
break;
case GLSL_TYPE_INT:
-if (this->value.i[c] != 0)
+if (this->value.i[c] != i)
return false;
break;
case GLSL_TYPE_UINT:
-if (this->value.u[c] != 0)
+if (this->value.u[c] != unsigned(i))
return false;
break;
case GLSL_TYPE_BOOL:
-if (this->value.b[c] != false)
+if (this->value.b[c] != bool(i))
return false;
break;
default:
@@ -1159,76 +1163,21 @@ ir_constant::is_zero() const
}
bool
-ir_constant::is_one() const
+ir_constant::is_zero() const
{
- if (!this->type->is_scalar() && !this->type->is_vector())
- return false;
-
- for (unsigned c = 0; c < this->type->vector_elements; c++) {
- switch (this->type->base_type) {
- case GLSL_TYPE_FLOAT:
-if (this->value.f[c] != 1.0)
- return false;
-break;
- case GLSL_TYPE_INT:
-if (this->value.i[c] != 1)
- return false;
-break;
- case GLSL_TYPE_UINT:
-if (this->value.u[c] != 1)
- return false;
-break;
- case GLSL_TYPE_BOOL:
-if (this->value.b[c] != true)
- return false;
-break;
- default:
-/* The only other base types are structures, arrays, and samplers.
- * Samplers cannot be constants, and the others should have been
- * filtered out above.
- */
-assert(!"Should not get here.");
-return false;
- }
- }
+ return is_value(0.0, 0);
+}
- return true;
+bool
+ir_constant::is_one() const
+{
+ return is_value(1.0, 1);
}
bool
ir_constant::is_negative_one() const
{
- if (!this->type->is_scalar() && !this->type->is_vector())
- return false;
-
- if (this->type->is_boolean())
- return false;
-
- for (unsigned c = 0; c < this->type->vector_elements; c++) {
- switch (this->type->base_type) {
- case GLSL_TYPE_FLOAT:
-if (this->value.f[c] != -1.0)
- return false;
-break;
- case GLSL_TYPE_INT:
-if (this->value.i[c] != -1)
- return false;
-break;
- case GLSL_TYPE_UINT:
-if (int(this->value.u[c]) != -1)
- return false;
-break;
- default:
-/* The only other base types are structures, arrays, samplers, and
- * booleans. Samplers cannot be constants, and the others should
- * have been filtered out above.
- */
-assert(!"Should not get here.");
-return false;
- }
- }
-
- return true;
+ return is_value(-1.0, -1);
}
bool
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 780959b..4d86385 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -2186,6 +2186,12 @@ public:
*/
bool has_value(const ir_constant *) const;
+ /**
+* Return true if this ir_constant represents the given value.
+*
+* For vectors, this checks that each component is the given value.
+*/
+ virtual bool is_value(float f, int i) const;
virtual bool is_zero() const;
virtual bool is_one() const;
virtual bool is_negative_one() const;
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glsl: Optimize pow(2, x) --> exp2(x).
On Haswell, POW takes 24 cycles, while EXP2 only takes 14. Plus, using
POW requires putting 2.0 in a register, while EXP2 doesn't.
I believe that EXP2 will be faster than POW on basically all GPUs, so
it makes sense to optimize it.
Looking at the savage2 subset of shader-db:
total instructions in shared programs: 113225 -> 113179 (-0.04%)
instructions in affected programs: 2139 -> 2093 (-2.15%)
instances of 'math pow': 795 -> 749 (-6.14%)
instances of 'math exp': 389 -> 435 (11.8%)
Signed-off-by: Kenneth Graunke
---
src/glsl/opt_algebraic.cpp | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 5e885f7..332f0b7 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -88,6 +88,12 @@ is_vec_one(ir_constant *ir)
}
static inline bool
+is_vec_two(ir_constant *ir)
+{
+ return (ir == NULL) ? false : ir->is_value(2.0, 2);
+}
+
+static inline bool
is_vec_negative_one(ir_constant *ir)
{
return (ir == NULL) ? false : ir->is_negative_one();
@@ -420,6 +426,11 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
/* 1^x == 1 */
if (is_vec_one(op_const[0]))
return op_const[0];
+
+ /* pow(2,x) == exp2(x) */
+ if (is_vec_two(op_const[0]))
+ return expr(ir_unop_exp2, ir->operands[1]);
+
break;
case ir_unop_rcp:
--
1.8.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] [r600g] 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.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] [r600g] 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.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] [r600g] 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] [PATCH 5/5] [r600g] 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.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [v3][r600g] Cleaning compute_memory_pool from gallium/drivers/r600
Hi,
Third version of the patches.
Now with r600g in the commit messages.
Patches 2 and 3 have spaces between 'if' and '('.
Patches 1,4 and 5 are the same.
Thanks!
[PATCH 1/5] [r600g] Fixing a typo and some indentation
[PATCH 2/5] [r600g] Adding checks for NULL after CALLOC
[PATCH 3/5] [r600g] Add more NULL checks
[PATCH 4/5] [r600g] Tidy a bit compute_memory_finalize_pending
[PATCH 5/5] [r600g] Cleanup of compute_memory_pool.h
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] [r600g] 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.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 72877] Wrong colors with Mesa 9.2 and Mesa 10.0 on PPC Linux systems
https://bugs.freedesktop.org/show_bug.cgi?id=72877 Christian Zigotzky changed: What|Removed |Added Attachment #91561|text/plain |image/jpeg mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 72877] Wrong colors with Mesa 9.2 and Mesa 10.0 on PPC Linux systems
https://bugs.freedesktop.org/show_bug.cgi?id=72877 --- Comment #6 from Christian Zigotzky --- Created attachment 91561 --> https://bugs.freedesktop.org/attachment.cgi?id=91561&action=edit Lubuntu 13.10 PowerPC (Kernel 3.13-rc7) with the old Mesa 8.0.2 Lubuntu 13.10 PowerPC (Kernel 3.13-rc7) with the old Mesa 8.0.2. 3D acceleration works well in the fullscreen mode. -- 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] [Mesa-stable] [PATCH] mesa: implement missing glGet(GL_RGBA_SIGNED_COMPONENTS_EXT) query
On 01/06/2014 01:21 PM, Chris Forbes wrote: + const GLboolean signd = +rb ? _mesa_is_format_signed(rb-> Format) : GL_FALSE; + v->value_int_4[0] = + v->value_int_4[1] = + v->value_int_4[2] = + v->value_int_4[3] = signd; Might have gone with something like is_signed rather than dropping a letter to avoid the keyword. Done. I like that better too. Either way, Reviewed-by: Chris Forbes Thanks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: implement missing glGet(GL_RGBA_SIGNED_COMPONENTS_EXT) query
On 01/06/2014 11:57 AM, Brian Paul wrote: > This is part of the GL_EXT_packed_float extension. > > Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=73096 > Cc: 10.0 Thanks, Brian! Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/7] i965: Add an assert for when SET_FIELD's value exceeds the field size.
On 12/23/2013 04:08 PM, Eric Anholt wrote:
> This was one of the things we always wanted to do to this, to make it more
> useful than just (value << FIELD_MASK).
> ---
> src/mesa/drivers/dri/i965/brw_defines.h | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
> b/src/mesa/drivers/dri/i965/brw_defines.h
> index dc38ace..21a97a9 100644
> --- a/src/mesa/drivers/dri/i965/brw_defines.h
> +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> @@ -30,7 +30,13 @@
>*/
>
> #define INTEL_MASK(high, low) (((1<<((high)-(low)+1))-1)<<(low))
> -#define SET_FIELD(value, field) (((value) << field ## _SHIFT) & field ##
> _MASK)
> +#define SET_FIELD(value, field) \
> + ({ \
> + uint32_t fieldval = (value) << field ## _SHIFT; \
> + assert((fieldval & ~ field ## _MASK) == 0); \
> + fieldval & field ## _MASK;\
> + })
> +
> #define GET_FIELD(word, field) (((word) & field ## _MASK) >> field ##
> _SHIFT)
>
> #ifndef BRW_DEFINES_H
Whoa. This is some crazy language extension.
However, it appears to be supported by GCC, Clang, and (according to
Google) Sun Studio 12.
I might add a comment:
/* Using the GNU statement expression extension */
Otherwise, this series is:
Reviewed-by: Kenneth Graunke
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Remove GLXContextID typedef from glxext.h.
On 01/06/2014 12:17 PM, Vinson Lee wrote: > 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 > --- > include/GL/glxext.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/include/GL/glxext.h b/include/GL/glxext.h > index cfabe8c..7132385 100644 > --- a/include/GL/glxext.h > +++ b/include/GL/glxext.h > @@ -272,7 +272,6 @@ __GLXextFuncPtr glXGetProcAddressARB (const GLubyte > *procName); > > #ifndef GLX_EXT_import_context > #define GLX_EXT_import_context 1 > -typedef XID GLXContextID; > #define GLX_SHARE_CONTEXT_EXT 0x800A > #define GLX_VISUAL_ID_EXT 0x800B > #define GLX_SCREEN_EXT0x800C > Seems worth applying for now - hopefully the Khronos bug Eric filed will result in it being removed from the upstream version too. Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] mesa: implement missing glGet(GL_RGBA_SIGNED_COMPONENTS_EXT) query
+ const GLboolean signd = +rb ? _mesa_is_format_signed(rb-> Format) : GL_FALSE; + v->value_int_4[0] = + v->value_int_4[1] = + v->value_int_4[2] = + v->value_int_4[3] = signd; Might have gone with something like is_signed rather than dropping a letter to avoid the keyword. Either way, Reviewed-by: Chris Forbes ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] 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 --- include/GL/glxext.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/GL/glxext.h b/include/GL/glxext.h index cfabe8c..7132385 100644 --- a/include/GL/glxext.h +++ b/include/GL/glxext.h @@ -272,7 +272,6 @@ __GLXextFuncPtr glXGetProcAddressARB (const GLubyte *procName); #ifndef GLX_EXT_import_context #define GLX_EXT_import_context 1 -typedef XID GLXContextID; #define GLX_SHARE_CONTEXT_EXT 0x800A #define GLX_VISUAL_ID_EXT 0x800B #define GLX_SCREEN_EXT0x800C -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] mesa: implement missing glGet(GL_RGBA_SIGNED_COMPONENTS_EXT) query
On 01/06/2014 01:01 PM, Chris Forbes wrote: On Tue, Jan 7, 2014 at 8:57 AM, Brian Paul wrote: --- a/src/mesa/main/get_hash_params.py +++ b/src/mesa/main/get_hash_params.py @@ -611,6 +611,9 @@ descriptor=[ # GL_ARB_fragment_program [ "FRAGMENT_PROGRAM_ARB", "CONTEXT_BOOL(FragmentProgram.Enabled), extra_ARB_fragment_program" ], +# GL_EXT_packed_depth_stencil GL_EXT_packed_float? Yes, I'll fix that before pushing. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] mesa: implement missing glGet(GL_RGBA_SIGNED_COMPONENTS_EXT) query
On Tue, Jan 7, 2014 at 8:57 AM, Brian Paul wrote: > --- a/src/mesa/main/get_hash_params.py > +++ b/src/mesa/main/get_hash_params.py > @@ -611,6 +611,9 @@ descriptor=[ > # GL_ARB_fragment_program >[ "FRAGMENT_PROGRAM_ARB", "CONTEXT_BOOL(FragmentProgram.Enabled), > extra_ARB_fragment_program" ], > > +# GL_EXT_packed_depth_stencil GL_EXT_packed_float? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: implement missing glGet(GL_RGBA_SIGNED_COMPONENTS_EXT) query
This is part of the GL_EXT_packed_float extension.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=73096
Cc: 10.0
---
src/mesa/main/formats.c | 19 +++
src/mesa/main/formats.h |3 +++
src/mesa/main/get.c | 21 +
src/mesa/main/get_hash_params.py |3 +++
4 files changed, 46 insertions(+)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index 07d2a72..eb2a07e 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -1967,6 +1967,25 @@ _mesa_is_format_unsigned(gl_format format)
/**
+ * Does the given format store signed values?
+ */
+GLboolean
+_mesa_is_format_signed(gl_format format)
+{
+ if (format == MESA_FORMAT_R11_G11_B10_FLOAT) {
+ /* this packed float format only stores unsigned values */
+ return GL_FALSE;
+ }
+ else {
+ const struct gl_format_info *info = _mesa_get_format_info(format);
+ return (info->DataType == GL_SIGNED_NORMALIZED ||
+ info->DataType == GL_INT ||
+ info->DataType == GL_FLOAT);
+ }
+}
+
+
+/**
* Return color encoding for given format.
* \return GL_LINEAR or GL_SRGB
*/
diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
index 64b4b9a..0c91aea 100644
--- a/src/mesa/main/formats.h
+++ b/src/mesa/main/formats.h
@@ -341,6 +341,9 @@ _mesa_is_format_integer_color(gl_format format);
extern GLboolean
_mesa_is_format_unsigned(gl_format format);
+extern GLboolean
+_mesa_is_format_signed(gl_format format);
+
extern GLenum
_mesa_get_format_color_encoding(gl_format format);
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 6913808..596942c 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -327,6 +327,12 @@ static const int
extra_EXT_framebuffer_sRGB_and_new_buffers[] = {
EXTRA_END
};
+static const int extra_EXT_packed_float[] = {
+ EXT(EXT_packed_float),
+ EXTRA_NEW_BUFFERS,
+ EXTRA_END
+};
+
static const int extra_EXT_texture_array_es3[] = {
EXT(EXT_texture_array),
EXTRA_API_ES3,
@@ -757,6 +763,21 @@ find_custom_value(struct gl_context *ctx, const struct
value_desc *d, union valu
ctx->Texture.Unit[unit].CurrentTex[d->offset]->Name;
break;
+ /* GL_EXT_packed_float */
+ case GL_RGBA_SIGNED_COMPONENTS_EXT:
+ {
+ /* Note: we only check the 0th color attachment. */
+ const struct gl_renderbuffer *rb =
+ctx->DrawBuffer->_ColorDrawBuffers[0];
+ const GLboolean signd =
+rb ? _mesa_is_format_signed(rb->Format) : GL_FALSE;
+ v->value_int_4[0] =
+ v->value_int_4[1] =
+ v->value_int_4[2] =
+ v->value_int_4[3] = signd;
+ }
+ break;
+
/* GL_ARB_vertex_buffer_object */
case GL_VERTEX_ARRAY_BUFFER_BINDING_ARB:
case GL_NORMAL_ARRAY_BUFFER_BINDING_ARB:
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 653bf62..f763e09 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -611,6 +611,9 @@ descriptor=[
# GL_ARB_fragment_program
[ "FRAGMENT_PROGRAM_ARB", "CONTEXT_BOOL(FragmentProgram.Enabled),
extra_ARB_fragment_program" ],
+# GL_EXT_packed_depth_stencil
+ [ "RGBA_SIGNED_COMPONENTS_EXT", "LOC_CUSTOM, TYPE_INT_4, 0,
extra_EXT_packed_float" ],
+
# GL_EXT_depth_bounds_test
[ "DEPTH_BOUNDS_TEST_EXT", "CONTEXT_BOOL(Depth.BoundsTest),
extra_EXT_depth_bounds_test" ],
[ "DEPTH_BOUNDS_EXT", "CONTEXT_FLOAT2(Depth.BoundsMin),
extra_EXT_depth_bounds_test" ],
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] mesa: implement glBindBuffersBase() and gl BindBuffersRange()
On 01/02/2014 04:27 PM, Maxence Le Doré wrote:
> ---
> src/mesa/main/bufferobj.c | 158
> ++
> src/mesa/main/bufferobj.h | 9 ++-
> 2 files changed, 165 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
> index a3d8f24..bad8f90 100644
> --- a/src/mesa/main/bufferobj.c
> +++ b/src/mesa/main/bufferobj.c
> @@ -2706,3 +2706,161 @@ _mesa_InvalidateBufferData(GLuint buffer)
> */
> return;
> }
> +
> +void GLAPIENTRY
> +_mesa_BindBuffersBase(GLenum target, GLuint first, GLsizei count,
> + const GLuint *buffers)
> +{
> + GET_CURRENT_CONTEXT(ctx);
> + int i = 0;
> + GLboolean exceedMaxBindings = GL_FALSE;
In addition to all of Brian's formatting comments, for things that are
not visible to the GL API, use standard C types instead of GL types.
Use 'bool' here (and some other places) instead of GLboolean.
> +
> + switch(target) {
> + case GL_TRANSFORM_FEEDBACK_BUFFER:
> + first + count > ctx->Const.MaxTransformFeedbackBuffers ?
> + exceedMaxBindings = GL_TRUE : exceedMaxBindings = GL_FALSE;
> + break;
> + case GL_UNIFORM_BUFFER:
> + first + count > ctx->Const.MaxUniformBufferBindings ?
> + exceedMaxBindings = GL_TRUE : exceedMaxBindings = GL_FALSE;
> + break;
> + case GL_ATOMIC_COUNTER_BUFFER:
> + first + count > ctx->Const.MaxAtomicBufferBindings ?
> + exceedMaxBindings = GL_TRUE : exceedMaxBindings = GL_FALSE;
> + break;
> + default:
> + _mesa_error(ctx, GL_INVALID_ENUM,
> + "glBindBuffersBase(invalid target)");
> + return;
> + }
> +
> + if(exceedMaxBindings) {
> + _mesa_error(ctx, GL_INVALID_OPERATION,
> + "glBindBuffersBase(first+count)");
> + return;
> + }
> +
> + for(i = 0 ; i < count ; i++) {
> + GLuint buffer;
> + struct gl_buffer_object *bufferObj;
> +
> + if(buffers == NULL)
> +buffer = 0;
> + else
> +buffer = buffers[i];
> +
> + if(buffer != 0) {
> +bufferObj = _mesa_lookup_bufferobj(ctx, buffer);
> +if(bufferObj) {
> + _mesa_BindBufferBase(target, first+i, buffer);
> +}
> +else
> + _mesa_error(ctx, GL_INVALID_OPERATION,
> + "glBindBufferBase(buffer[%i] is invalid)", i);
> + }
> + else
> +_mesa_BindBufferBase(target, first + i, 0);
> + }
> +}
> +
> +void GLAPIENTRY
> +_mesa_BindBuffersRange(GLenum target, GLuint first, GLsizei count,
> + const GLuint *buffers, const GLintptr *offsets,
> + const GLsizeiptr *sizes)
> +{
> + GET_CURRENT_CONTEXT(ctx);
> + int i = 0;
> + GLboolean exceedMaxBindings = GL_FALSE;
> +
> + switch(target) {
> + case GL_TRANSFORM_FEEDBACK_BUFFER:
> + first + count > ctx->Const.MaxTransformFeedbackBuffers ?
> + exceedMaxBindings = GL_TRUE : exceedMaxBindings = GL_FALSE;
> + break;
> + case GL_UNIFORM_BUFFER:
> + first + count > ctx->Const.MaxUniformBufferBindings ?
> + exceedMaxBindings = GL_TRUE : exceedMaxBindings = GL_FALSE;
> + break;
> + case GL_ATOMIC_COUNTER_BUFFER:
> + first + count > ctx->Const.MaxAtomicBufferBindings ?
> + exceedMaxBindings = GL_TRUE : exceedMaxBindings = GL_FALSE;
> + break;
> + default:
> + _mesa_error(ctx, GL_INVALID_ENUM,
> + "glBindBuffersRange(invalid target)");
> + return;
> + }
> +
> + if(exceedMaxBindings) {
> + _mesa_error(ctx, GL_INVALID_OPERATION,
> + "glBindBuffersRange(first+count)");
> + return;
> + }
> +
> + for(i = 0 ; i < count ; i++) {
> + GLuint buffer;
> + GLintptr offset;
> + GLsizeiptr size;
> + struct gl_buffer_object *bufferObj;
> +
> + if(buffers == NULL)
> +buffer = 0;
> + else {
> +buffer = buffers[i];
> +offset = offsets[i];
> +size = sizes[i];
> + }
> +
> + if(buffer != 0) {
> +bufferObj = _mesa_lookup_bufferobj(ctx, buffer);
> +if(bufferObj) {
> + GLboolean validOffet, validSize;
> +
> + switch(target) {
> +case GL_TRANSFORM_FEEDBACK_BUFFER:
> + (offset >= 0) ?
> + validOffset = GL_TRUE : validOffet = GL_FALSE;
> + (size >= 0) ?
> + validSize = GL_TRUE : validSize = GL_FALSE;
> + /* TODO : add target specific checks */
> + break;
> +case GL_UNIFORM_BUFFER:
> + (offset >= 0) ?
> + validOffset = GL_TRUE : validOffet = GL_FALSE;
> + (size >= 0) ?
> + validSize = GL_TRUE : validSize = GL_FALSE;
> + /* TODO : add target specific checks */
> + break;
> +case GL_ATOMIC_COUNTER_BUFFER:
> + (offset >= 0) ?
> + validOffset = G
[Mesa-dev] [Bug 73096] Query GL_RGBA_SIGNED_COMPONENTS_EXT missing
https://bugs.freedesktop.org/show_bug.cgi?id=73096 Brian Paul changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |bri...@vmware.com |org | --- Comment #1 from Brian Paul --- Created attachment 91557 --> https://bugs.freedesktop.org/attachment.cgi?id=91557&action=edit patch to implement GL_RGBA_SIGNED_COMPONENTS_EXT query Hi Bruce, Thanks for catching that. I'm attaching a patch to add the missing query code. I'll post to mesa-dev for review too. Regarding your piglit test: it should probably be moved to the tests/spec/ext_packed_float/ directory. We're trying to move away from tests/bugs/ It looks good otherwise. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] r200: Free glCtx in radeonDestroyContext
On Mon, Jan 6, 2014 at 1:26 PM, Ian Romanick wrote: > On 01/02/2014 10:38 AM, Aaron Watry wrote: >> Note: I don't have hardware to test this, but I believe it to be correct. >> >> Found while tracking down a related leak in evergreen context management. >> --- >> src/mesa/drivers/dri/radeon/radeon_common_context.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/src/mesa/drivers/dri/radeon/radeon_common_context.c >> b/src/mesa/drivers/dri/radeon/radeon_common_context.c >> index 6dec137..161a0b7 100644 >> --- a/src/mesa/drivers/dri/radeon/radeon_common_context.c >> +++ b/src/mesa/drivers/dri/radeon/radeon_common_context.c >> @@ -245,8 +245,8 @@ void radeonDestroyContext(__DRIcontext *driContextPriv ) >> _swrast_DestroyContext( &radeon->glCtx ); >> >> /* free atom list */ >> - /* free the Mesa context data */ >> - _mesa_free_context_data(&radeon->glCtx); >> + /* free the Mesa context and its data */ >> + _mesa_destroy_context(&radeon->glCtx); > > This will free(radeon), and... > >> /* free the option cache */ >> driDestroyOptionCache(&radeon->optionCache); > > ...this will dereference it. > > The context is already freed at the bottom of this function, so I don't > think this patch is necessary at all. > Fair enough. Given that I don't have hardware to test with, I'll drop this patch in v2 of the series (to address Michel's comments). --Aaron ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] intel: support factors for min/max blending
On 01/02/2014 05:18 PM, Maxence Le Doré wrote:
> ---
> src/mesa/drivers/dri/i915/i830_state.c | 12
> src/mesa/drivers/dri/i965/brw_util.c | 24 +---
> 2 files changed, 25 insertions(+), 11 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i915/i830_state.c
> b/src/mesa/drivers/dri/i915/i830_state.c
> index bbf0cef..6a5db43 100644
> --- a/src/mesa/drivers/dri/i915/i830_state.c
> +++ b/src/mesa/drivers/dri/i915/i830_state.c
i915_state.c should get the same treatment.
> @@ -303,10 +303,16 @@ i830_set_blend_state(struct gl_context * ctx)
>eqnRGB = BLENDFUNC_MIN;
>funcRGB = SRC_BLND_FACT(BLENDFACT_ONE) | DST_BLND_FACT(BLENDFACT_ONE);
>break;
> + case GL_FACTOR_MIN_AMD:
> + eqnRGB = BLENDFUNC_MIN;
> + break;
> case GL_MAX:
>eqnRGB = BLENDFUNC_MAX;
>funcRGB = SRC_BLND_FACT(BLENDFACT_ONE) | DST_BLND_FACT(BLENDFACT_ONE);
>break;
> + case GL_FACTOR_MAX_AMD:
> + eqnRGB = BLENDFUNC_MAX;
> + break;
> case GL_FUNC_SUBTRACT:
>eqnRGB = BLENDFUNC_SUB;
>break;
> @@ -331,10 +337,16 @@ i830_set_blend_state(struct gl_context * ctx)
>eqnA = BLENDFUNC_MIN;
>funcA = SRC_BLND_FACT(BLENDFACT_ONE) | DST_BLND_FACT(BLENDFACT_ONE);
>break;
> + case GL_FACTOR_MIN_AMD:
> + eqnA = BLENDFUNC_MIN;
> + break;
> case GL_MAX:
>eqnA = BLENDFUNC_MAX;
>funcA = SRC_BLND_FACT(BLENDFACT_ONE) | DST_BLND_FACT(BLENDFACT_ONE);
>break;
> + case GL_FACTOR_MAX_AMD:
> + eqnA = BLENDFUNC_MAX;
> + break;
> case GL_FUNC_SUBTRACT:
>eqnA = BLENDFUNC_SUB;
>break;
> diff --git a/src/mesa/drivers/dri/i965/brw_util.c
> b/src/mesa/drivers/dri/i965/brw_util.c
> index 4a303cd..292b7e5 100644
> --- a/src/mesa/drivers/dri/i965/brw_util.c
> +++ b/src/mesa/drivers/dri/i965/brw_util.c
> @@ -40,17 +40,19 @@
> GLuint brw_translate_blend_equation( GLenum mode )
> {
> switch (mode) {
> - case GL_FUNC_ADD:
> - return BRW_BLENDFUNCTION_ADD;
> - case GL_MIN:
> - return BRW_BLENDFUNCTION_MIN;
> - case GL_MAX:
> - return BRW_BLENDFUNCTION_MAX;
> - case GL_FUNC_SUBTRACT:
> - return BRW_BLENDFUNCTION_SUBTRACT;
> - case GL_FUNC_REVERSE_SUBTRACT:
> - return BRW_BLENDFUNCTION_REVERSE_SUBTRACT;
> - default:
> + case GL_FUNC_ADD:
> + return BRW_BLENDFUNCTION_ADD;
> + case GL_MIN:
> + case GL_FACTOR_MIN_AMD:
> + return BRW_BLENDFUNCTION_MIN;
> + case GL_MAX:
> + case GL_FACTOR_MAX_AMD:
> + return BRW_BLENDFUNCTION_MAX;
> + case GL_FUNC_SUBTRACT:
> + return BRW_BLENDFUNCTION_SUBTRACT;
> + case GL_FUNC_REVERSE_SUBTRACT:
> + return BRW_BLENDFUNCTION_REVERSE_SUBTRACT;
> + default:
>assert(0);
>return BRW_BLENDFUNCTION_ADD;
> }
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6][RFC] drirc: Add string support
On 01/05/2014 01:26 PM, Axel Davy wrote:
> This may require changes to the driconf gui.
>
> Signed-off-by: Axel Davy
> ---
> src/mesa/drivers/dri/common/xmlconfig.c | 24
> src/mesa/drivers/dri/common/xmlconfig.h | 7 ++-
> 2 files changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/common/xmlconfig.c
> b/src/mesa/drivers/dri/common/xmlconfig.c
> index b95e452..c1dae20 100644
> --- a/src/mesa/drivers/dri/common/xmlconfig.c
> +++ b/src/mesa/drivers/dri/common/xmlconfig.c
> @@ -311,6 +311,9 @@ static GLboolean parseValue (driOptionValue *v,
> driOptionType type,
>case DRI_FLOAT:
> v->_float = strToF (string, &tail);
> break;
> + case DRI_STRING:
> + v->_string = strndup(string, STRING_CONF_MAXLEN);
> + return GL_TRUE;
No tabs.
> }
>
> if (tail == string)
> @@ -404,6 +407,8 @@ static GLboolean checkValue (const driOptionValue *v,
> const driOptionInfo *info)
> v->_float <= info->ranges[i].end._float)
> return GL_TRUE;
> break;
> + case DRI_STRING:
> + break;
>default:
> assert (0); /* should never happen */
> }
> @@ -567,6 +572,8 @@ static void parseOptInfoAttr (struct OptInfoData *data,
> const XML_Char **attr) {
> cache->info[opt].type = DRI_INT;
> else if (!strcmp (attrVal[OA_TYPE], "float"))
> cache->info[opt].type = DRI_FLOAT;
> +else if (!strcmp (attrVal[OA_TYPE], "string"))
> + cache->info[opt].type = DRI_STRING;
> else
> XML_FATAL ("illegal type in option: %s.", attrVal[OA_TYPE]);
>
> @@ -981,6 +988,15 @@ void driDestroyOptionInfo (driOptionCache *info) {
> }
>
> void driDestroyOptionCache (driOptionCache *cache) {
This { should be on its own line.
> +if (cache->info) {
> + GLuint i, size = 1 << cache->tableSize;
For things that the application cannot see, just use unsigned.
> + for (i = 0; i < size; ++i) {
> + if (cache->info[i].type == DRI_STRING) {
> + char *str = cache->values[i]._string;
> + free (str);
> + }
> + }
> +}
> free(cache->values);
> }
>
> @@ -1013,3 +1029,11 @@ GLfloat driQueryOptionf (const driOptionCache *cache,
> const char *name) {
> assert (cache->info[i].type == DRI_FLOAT);
> return cache->values[i]._float;
> }
> +
> +char * driQueryOptionstr (const driOptionCache *cache, const char *name) {
{
> +GLuint i = findOption (cache, name);
unsigned
> + /* make sure the option is defined and has the correct type */
> +assert (cache->info[i].name != NULL);
> +assert (cache->info[i].type == DRI_STRING);
> +return cache->values[i]._string;
> +}
> diff --git a/src/mesa/drivers/dri/common/xmlconfig.h
> b/src/mesa/drivers/dri/common/xmlconfig.h
> index d0ad42c..93fd3f3 100644
> --- a/src/mesa/drivers/dri/common/xmlconfig.h
> +++ b/src/mesa/drivers/dri/common/xmlconfig.h
> @@ -30,9 +30,11 @@
> #ifndef __XMLCONFIG_H
> #define __XMLCONFIG_H
>
> +#define STRING_CONF_MAXLEN 25
> +
> /** \brief Option data types */
> typedef enum driOptionType {
> -DRI_BOOL, DRI_ENUM, DRI_INT, DRI_FLOAT
> +DRI_BOOL, DRI_ENUM, DRI_INT, DRI_FLOAT, DRI_STRING
> } driOptionType;
>
> /** \brief Option value */
> @@ -40,6 +42,7 @@ typedef union driOptionValue {
> GLboolean _bool; /**< \brief Boolean */
> GLint _int; /**< \brief Integer or Enum */
> GLfloat _float; /**< \brief Floating-point */
> +char* _string; /**< \brief String */
> } driOptionValue;
>
> /** \brief Single range of valid values
> @@ -118,5 +121,7 @@ GLboolean driQueryOptionb (const driOptionCache *cache,
> const char *name);
> GLint driQueryOptioni (const driOptionCache *cache, const char *name);
> /** \brief Query a floating-point option value */
> GLfloat driQueryOptionf (const driOptionCache *cache, const char *name);
> +/** \brief Query a string option value */
> +char* driQueryOptionstr (const driOptionCache *cache, const char *name);
>
> #endif
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] r200: Free glCtx in radeonDestroyContext
On 01/02/2014 10:38 AM, Aaron Watry wrote: > Note: I don't have hardware to test this, but I believe it to be correct. > > Found while tracking down a related leak in evergreen context management. > --- > src/mesa/drivers/dri/radeon/radeon_common_context.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/mesa/drivers/dri/radeon/radeon_common_context.c > b/src/mesa/drivers/dri/radeon/radeon_common_context.c > index 6dec137..161a0b7 100644 > --- a/src/mesa/drivers/dri/radeon/radeon_common_context.c > +++ b/src/mesa/drivers/dri/radeon/radeon_common_context.c > @@ -245,8 +245,8 @@ void radeonDestroyContext(__DRIcontext *driContextPriv ) > _swrast_DestroyContext( &radeon->glCtx ); > > /* free atom list */ > - /* free the Mesa context data */ > - _mesa_free_context_data(&radeon->glCtx); > + /* free the Mesa context and its data */ > + _mesa_destroy_context(&radeon->glCtx); This will free(radeon), and... > /* free the option cache */ > driDestroyOptionCache(&radeon->optionCache); ...this will dereference it. The context is already freed at the bottom of this function, so I don't think this patch is necessary at all. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6][RFC] Gallium/dri2: implement blitImage
On 06/01/2014, Marek Olšák wrote :
On Sun, Jan 5, 2014 at 10:26 PM, Axel Davy wrote:
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/dri/drm/dri2.c | 49 +--
1 file changed, 47 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
b/src/gallium/state_trackers/dri/drm/dri2.c
index 2a5b7b4..89d9040 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -985,6 +985,49 @@ dri2_from_fds(__DRIscreen *screen, int width, int height,
int fourcc,
}
static void
+dri2_blit_image(__DRIcontext *context, __DRIimage *dst, __DRIimage *src,
+int dstx0, int dsty0, int dstwidth, int dstheight,
+int srcx0, int srcy0, int srcwidth, int srcheight,
+int flags)
+{
+ struct dri_context *ctx = dri_context(context);
+ struct pipe_context *pipe = ctx->st->pipe;
+ struct pipe_screen* screen = dri_screen(ctx->sPriv)->base.screen;
+ struct pipe_fence_handle *fence;
+ struct pipe_blit_info blit;
+
+ if (!dst || !src)
+ return;
+
+ memset(&blit, 0, sizeof(blit));
+ blit.dst.resource = dst->texture;
+ blit.dst.box.x = dstx0;
+ blit.dst.box.y = dsty0;
+ blit.dst.box.width = dstwidth;
+ blit.dst.box.height = dstheight;
+ blit.dst.box.depth = 1;
+ blit.dst.format = dst->texture->format;
+ blit.src.resource = src->texture;
+ blit.src.box.x = srcx0;
+ blit.src.box.y = srcy0;
+ blit.src.box.width = srcwidth;
+ blit.src.box.height = srcheight;
+ blit.src.box.depth = 1;
+ blit.src.format = src->texture->format;
+ blit.mask = PIPE_MASK_RGBA;
+ blit.filter = PIPE_TEX_FILTER_NEAREST;
+
+ pipe->blit(pipe, &blit);
+
+ pipe->flush_resource(pipe, dst->texture);
+
+ ctx->st->flush(ctx->st, 0, &fence);
+
+ if (flags & __BLIT_FLAG_FINISH)
+ (void) screen->fence_finish(screen, fence, PIPE_TIMEOUT_INFINITE);
+ screen->fence_reference(screen, &fence, NULL);
Fences might not be implemented by some drivers. I recommend setting
the fence pointer to NULL, then calling flush and then checking if
it's not NULL. Also, getting a fence incurs some overhead, so if
__BLIT_FLAG_FINISH is not set, the last parameter of st->flush should
be NULL.
Who can call this function? The X server?
Marek
Thanks for the comment.
the __BLIT_FLAG_FINISH flag is to glFinish before exporting the buffer
when rendering on a different card than the compositor. This use case
will disappear with dma-buf fences.
I'm hesitating to remove this flag, and bet that dma-buf fences will
land soon.
The blitImage function would be called for Wayland when on a different
device than the Wayland compositor,
but it can be used fro X dri3 too (when on the dedicated device).
The work done for prime support for Wayland can be taken for X dri3.
About the flush done in the function: do you think it is ok to flush
here, or that it sould be optional to flush?
Axel Davy
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] i965: Ensure that intel_bufferobj_map_range meets alignment guarantees
On 01/06/2014 10:43 AM, Kenneth Graunke wrote:
> On 01/03/2014 04:51 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> No piglit regressions on IVB.
>>
>> With minor tweaks to the arb_map_buffer_alignment-map-invalidate-range
>> test (disable the extension check, set alignment to 64 instead of
>> querying), the i965 driver would fail the test without this patch (as
>> predicted by Eric). With this patch, it passes.
>>
>> Signed-off-by: Ian Romanick
>> Cc: Eric Anholt
>> Cc: Siavash Eliasi
>> ---
>> src/mesa/drivers/dri/i965/intel_buffer_objects.c | 28
>> ++--
>> 1 file changed, 21 insertions(+), 7 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
>> b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
>> index cab805a..7bf8cae 100644
>> --- a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
>> +++ b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
>> @@ -359,20 +359,28 @@ intel_bufferobj_map_range(struct gl_context * ctx,
>> */
>> if ((access & GL_MAP_INVALIDATE_RANGE_BIT) &&
>> drm_intel_bo_busy(intel_obj->buffer)) {
>> + /* Ensure that the base alignment of the allocation meets the
>> alignment
>> + * guarantees the driver has advertised to the application.
>> + */
>> + const unsigned alignment = MAX2(64, ctx->Const.MinMapBufferAlignment);
>
> The MAX2(64, ...) seems like unnecessary complexity. We want the
> alignment to be ctx->Const.MinMapBufferAlignment (which should be bumped
> to >= 64 in a follow on patch).
I can do that. I put that in mostly for testing before Siavash's
patches land.
> With that removed, patch 1 is:
> Reviewed-by: Kenneth Graunke
>
> Nice work.
>
> I'd love to see a follow-up patch that:
> 1. Sets ctx->Const.MinMapBufferAlignment to 64
>(in brw_context.c/brw_initialize_context_constants)
> 2. Enables the extension (in intel_extensions.c)
>
> I know you'd like to turn it on for all drivers, but we may as well
> claim victory here in the meantime.
>
>> + const unsigned extra = (uintptr_t) offset % alignment;
>> +
>>if (access & GL_MAP_FLUSH_EXPLICIT_BIT) {
>> - intel_obj->range_map_buffer = malloc(length);
>> - obj->Pointer = intel_obj->range_map_buffer;
>> + intel_obj->range_map_buffer = _mesa_align_malloc(length + extra,
>> + alignment);
>> + obj->Pointer = intel_obj->range_map_buffer + extra;
>>} else {
>> intel_obj->range_map_bo = drm_intel_bo_alloc(brw->bufmgr,
>>"range map",
>> - length, 64);
>> + length + extra,
>> + alignment);
>> if (!(access & GL_MAP_READ_BIT)) {
>> drm_intel_gem_bo_map_gtt(intel_obj->range_map_bo);
>> } else {
>> drm_intel_bo_map(intel_obj->range_map_bo,
>> (access & GL_MAP_WRITE_BIT) != 0);
>> }
>> - obj->Pointer = intel_obj->range_map_bo->virtual;
>> + obj->Pointer = intel_obj->range_map_bo->virtual + extra;
>>}
>>return obj->Pointer;
>> }
>> @@ -424,7 +432,11 @@ intel_bufferobj_flush_mapped_range(struct gl_context
>> *ctx,
>>
>> temp_bo = drm_intel_bo_alloc(brw->bufmgr, "range map flush", length, 64);
>>
>> - drm_intel_bo_subdata(temp_bo, 0, length, intel_obj->range_map_buffer);
>> + /* Use obj->Pointer instead of intel_obj->range_map_buffer because the
>> +* former points to the actual mapping while the latter may be offset to
>> +* meet alignment guarantees.
>> +*/
>> + drm_intel_bo_subdata(temp_bo, 0, length, obj->Pointer);
>>
>> intel_emit_linear_blit(brw,
>>intel_obj->buffer, obj->Offset + offset,
>> @@ -456,14 +468,16 @@ intel_bufferobj_unmap(struct gl_context * ctx, struct
>> gl_buffer_object *obj)
>> * usage inside of a batchbuffer.
>> */
>>intel_batchbuffer_emit_mi_flush(brw);
>> - free(intel_obj->range_map_buffer);
>> + _mesa_align_free(intel_obj->range_map_buffer);
>>intel_obj->range_map_buffer = NULL;
>> } else if (intel_obj->range_map_bo != NULL) {
>> + const unsigned extra = obj->Pointer -
>> intel_obj->range_map_bo->virtual;
>> +
>>drm_intel_bo_unmap(intel_obj->range_map_bo);
>>
>>intel_emit_linear_blit(brw,
>> intel_obj->buffer, obj->Offset,
>> - intel_obj->range_map_bo, 0,
>> + intel_obj->range_map_bo, extra,
>> obj->Length);
>>intel_bufferobj_mark_gpu_usage(intel_obj, obj->Offset, obj->Length);
>>
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] i915: Silence warning: unused parameter warning in intel_bufferobj_buffer
On 01/06/2014 10:51 AM, Kenneth Graunke wrote: > On 01/03/2014 04:51 PM, Ian Romanick wrote: >> From: Ian Romanick >> >> intel_buffer_objects.c: In function 'old_intel_bufferobj_buffer': > > "old_"? :) There are #defines that wrap the names in i915 that are duplicates of names in i965 (for megadrivers). >> intel_buffer_objects.c:471:17: warning: unused parameter 'flag' >> [-Wunused-parameter] >> >> The parameter hasn't been used since the i915 and i965 drivers had their >> breakup. i965 got the flags, and i915 got to cry itself to sleep. >> >> Signed-off-by: Ian Romanick > > Don't worry, we threw them out in i965 too. > > Patch 3 is: > Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] i965: Warning fix
Series is
Reviewed-by: Ian Romanick
On 12/23/2013 04:08 PM, Eric Anholt wrote:
> ---
> src/mesa/drivers/dri/i965/brw_eu_emit.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
> b/src/mesa/drivers/dri/i965/brw_eu_emit.c
> index c653828..c2ca10d 100644
> --- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
> +++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
> @@ -108,8 +108,6 @@ unsigned
> brw_reg_type_to_hw_type(const struct brw_context *brw,
> enum brw_reg_type type, unsigned file)
> {
> - bool imm = file == BRW_IMMEDIATE_VALUE;
> -
> if (file == BRW_IMMEDIATE_VALUE) {
>const static int imm_hw_types[] = {
> [BRW_REGISTER_TYPE_UD] = BRW_HW_REG_TYPE_UD,
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/7] i965: Don't call the blitter on addresses it can't handle.
On 12/23/2013 04:08 PM, Eric Anholt wrote:
> Noticed by tex3d-maxsize on my next commit to check that our addresses
> don't overflow.
Should this also go to stable branches?
> ---
> src/mesa/drivers/dri/i965/intel_blit.c| 20
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 23 ---
> 2 files changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_blit.c
> b/src/mesa/drivers/dri/i965/intel_blit.c
> index 7bc289f..13cc777 100644
> --- a/src/mesa/drivers/dri/i965/intel_blit.c
> +++ b/src/mesa/drivers/dri/i965/intel_blit.c
> @@ -229,12 +229,32 @@ intel_miptree_blit(struct brw_context *brw,
> src_x += src_image_x;
> src_y += src_image_y;
>
> + /* The blitter interprets the 16-bit src x/y as a signed 16-bit value,
> +* where negative values are invalid. The values we're working with are
> +* unsigned, so make sure we don't overflow.
> +*/
> + if (src_x >= 32768 || src_y >= 32768) {
> + perf_debug("Falling back due to >=32k src offset (%d, %d)\n",
> + src_x, src_y);
> + return false;
> + }
> +
> uint32_t dst_image_x, dst_image_y;
> intel_miptree_get_image_offset(dst_mt, dst_level, dst_slice,
>&dst_image_x, &dst_image_y);
> dst_x += dst_image_x;
> dst_y += dst_image_y;
>
> + /* The blitter interprets the 16-bit destination x/y as a signed 16-bit
> +* value. The values we're working with are unsigned, so make sure we
> +* don't overflow.
> +*/
> + if (dst_x >= 32768 || dst_y >= 32768) {
> + perf_debug("Falling back due to >=32k dst offset (%d, %d)\n",
> + dst_x, dst_y);
> + return false;
> + }
> +
> if (!intelEmitCopyBlit(brw,
>src_mt->cpp,
>src_pitch,
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index de47143..0818226 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -443,7 +443,8 @@ intel_miptree_choose_tiling(struct brw_context *brw,
> if (minimum_pitch < 64)
>return I915_TILING_NONE;
>
> - if (ALIGN(minimum_pitch, 512) >= 32768) {
> + if (ALIGN(minimum_pitch, 512) >= 32768 ||
> + mt->total_width >= 32768 || mt->total_height >= 32768) {
>perf_debug("%dx%d miptree too large to blit, falling back to untiled",
> mt->total_width, mt->total_height);
>return I915_TILING_NONE;
> @@ -2233,6 +2234,22 @@ intel_miptree_release_map(struct intel_mipmap_tree *mt,
> *map = NULL;
> }
>
> +static bool
> +can_blit_slice(struct intel_mipmap_tree *mt,
> + unsigned int level, unsigned int slice)
> +{
> + uint32_t image_x;
> + uint32_t image_y;
> + intel_miptree_get_image_offset(mt, level, slice, &image_x, &image_y);
> + if (image_x >= 32768 || image_y >= 32768)
> + return false;
> +
> + if (mt->region->pitch >= 32768)
> + return false;
> +
> + return true;
> +}
> +
> static void
> intel_miptree_map_singlesample(struct brw_context *brw,
> struct intel_mipmap_tree *mt,
> @@ -2276,11 +2293,11 @@ intel_miptree_map_singlesample(struct brw_context
> *brw,
> !mt->compressed &&
> (mt->region->tiling == I915_TILING_X ||
> (brw->gen >= 6 && mt->region->tiling == I915_TILING_Y)) &&
> -mt->region->pitch < 32768) {
> +can_blit_slice(mt, level, slice)) {
>intel_miptree_map_blit(brw, mt, map, level, slice);
> } else if (mt->region->tiling != I915_TILING_NONE &&
>mt->region->bo->size >= brw->max_gtt_map_object_size) {
> - assert(mt->region->pitch < 32768);
> + assert(can_blit_slice(mt, level, slice));
>intel_miptree_map_blit(brw, mt, map, level, slice);
> #ifdef __SSE4_1__
> } else if (!(mode & GL_MAP_WRITE_BIT) && !mt->compressed) {
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/7] i965: Don't call the blitter on addresses it can't handle.
On 01/05/2014 02:28 PM, Eric Anholt wrote:
> Anuj Phogat writes:
>
>> On Mon, Dec 23, 2013 at 4:08 PM, Eric Anholt wrote:
>>> Noticed by tex3d-maxsize on my next commit to check that our addresses
>>> don't overflow.
>>> ---
>>> src/mesa/drivers/dri/i965/intel_blit.c| 20
>>> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 23 ---
>>> 2 files changed, 40 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/intel_blit.c
>>> b/src/mesa/drivers/dri/i965/intel_blit.c
>>> index 7bc289f..13cc777 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_blit.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_blit.c
>>> @@ -229,12 +229,32 @@ intel_miptree_blit(struct brw_context *brw,
>>> src_x += src_image_x;
>>> src_y += src_image_y;
>>>
>>> + /* The blitter interprets the 16-bit src x/y as a signed 16-bit value,
>>> +* where negative values are invalid. The values we're working with are
>>> +* unsigned, so make sure we don't overflow.
>>> +*/
>>> + if (src_x >= 32768 || src_y >= 32768) {
>>> + perf_debug("Falling back due to >=32k src offset (%d, %d)\n",
>>> + src_x, src_y);
>>> + return false;
>>> + }
>>> +
>>> uint32_t dst_image_x, dst_image_y;
>>> intel_miptree_get_image_offset(dst_mt, dst_level, dst_slice,
>>>&dst_image_x, &dst_image_y);
>>> dst_x += dst_image_x;
>>> dst_y += dst_image_y;
>>>
>>> + /* The blitter interprets the 16-bit destination x/y as a signed 16-bit
>>> +* value. The values we're working with are unsigned, so make sure we
>>> +* don't overflow.
>>> +*/
>>> + if (dst_x >= 32768 || dst_y >= 32768) {
>>> + perf_debug("Falling back due to >=32k dst offset (%d, %d)\n",
>>> + dst_x, dst_y);
>>> + return false;
>>> + }
>>> +
>>> if (!intelEmitCopyBlit(brw,
>>>src_mt->cpp,
>>>src_pitch,
>>> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>>> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>>> index de47143..0818226 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>>> @@ -443,7 +443,8 @@ intel_miptree_choose_tiling(struct brw_context *brw,
>>> if (minimum_pitch < 64)
>>>return I915_TILING_NONE;
>>>
>>> - if (ALIGN(minimum_pitch, 512) >= 32768) {
>>> + if (ALIGN(minimum_pitch, 512) >= 32768 ||
>>> + mt->total_width >= 32768 || mt->total_height >= 32768) {
>>>perf_debug("%dx%d miptree too large to blit, falling back to
>>> untiled",
>>> mt->total_width, mt->total_height);
>>>return I915_TILING_NONE;
>>> @@ -2233,6 +2234,22 @@ intel_miptree_release_map(struct intel_mipmap_tree
>>> *mt,
>>> *map = NULL;
>>> }
>>>
>>> +static bool
>>> +can_blit_slice(struct intel_mipmap_tree *mt,
>>> + unsigned int level, unsigned int slice)
>>> +{
>>> + uint32_t image_x;
>>> + uint32_t image_y;
>>> + intel_miptree_get_image_offset(mt, level, slice, &image_x, &image_y);
>>> + if (image_x >= 32768 || image_y >= 32768)
>>> + return false;
>>> +
>>> + if (mt->region->pitch >= 32768)
>>> + return false;
>>> +
>>> + return true;
>>> +}
>>> +
>>> static void
>>> intel_miptree_map_singlesample(struct brw_context *brw,
>>> struct intel_mipmap_tree *mt,
>>> @@ -2276,11 +2293,11 @@ intel_miptree_map_singlesample(struct brw_context
>>> *brw,
>>> !mt->compressed &&
>>> (mt->region->tiling == I915_TILING_X ||
>>> (brw->gen >= 6 && mt->region->tiling == I915_TILING_Y)) &&
>>> -mt->region->pitch < 32768) {
>>> +can_blit_slice(mt, level, slice)) {
>>>intel_miptree_map_blit(brw, mt, map, level, slice);
>>> } else if (mt->region->tiling != I915_TILING_NONE &&
>>>mt->region->bo->size >= brw->max_gtt_map_object_size) {
>>> - assert(mt->region->pitch < 32768);
>>> + assert(can_blit_slice(mt, level, slice));
>> I think the right thing to do here is:
>> - mt->region->bo->size >= brw->max_gtt_map_object_size) {
>> - assert(mt->region->pitch < 32768);
>> + mt->region->bo->size >= brw->max_gtt_map_object_size &&
>> + can_blit_slice(mt, level, slice)) {
>>
>> This allow us falling back to intel_miptree_map_gtt(). I suggested this
>> change
>> as a part of '[PATCH] i965: Fix the region's pitch condition to use blitter'.
>
> If region->bo->size >= max_gtt_map_object_size, you can't fall back to
> GTT mapping, though. Since you can't do that, previous code needs to
> have made sure you can't reach this point.
I agree with Eric - we can't fall through to the next cases, since
they'll fail too. Our only hope is to ensure giant objects are forced
untiled (which I'm pretty sure we do these days).
--Ken
_
Re: [Mesa-dev] [PATCH 3/3] i915: Silence warning: unused parameter warning in intel_bufferobj_buffer
On 01/03/2014 04:51 PM, Ian Romanick wrote: > From: Ian Romanick > > intel_buffer_objects.c: In function 'old_intel_bufferobj_buffer': "old_"? :) > intel_buffer_objects.c:471:17: warning: unused parameter 'flag' > [-Wunused-parameter] > > The parameter hasn't been used since the i915 and i965 drivers had their > breakup. i965 got the flags, and i915 got to cry itself to sleep. > > Signed-off-by: Ian Romanick Don't worry, we threw them out in i965 too. Patch 3 is: Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] i965: Ensure that intel_bufferobj_map_range meets alignment guarantees
On 01/03/2014 04:51 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> No piglit regressions on IVB.
>
> With minor tweaks to the arb_map_buffer_alignment-map-invalidate-range
> test (disable the extension check, set alignment to 64 instead of
> querying), the i965 driver would fail the test without this patch (as
> predicted by Eric). With this patch, it passes.
>
> Signed-off-by: Ian Romanick
> Cc: Eric Anholt
> Cc: Siavash Eliasi
> ---
> src/mesa/drivers/dri/i965/intel_buffer_objects.c | 28
> ++--
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
> b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
> index cab805a..7bf8cae 100644
> --- a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
> +++ b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
> @@ -359,20 +359,28 @@ intel_bufferobj_map_range(struct gl_context * ctx,
> */
> if ((access & GL_MAP_INVALIDATE_RANGE_BIT) &&
> drm_intel_bo_busy(intel_obj->buffer)) {
> + /* Ensure that the base alignment of the allocation meets the alignment
> + * guarantees the driver has advertised to the application.
> + */
> + const unsigned alignment = MAX2(64, ctx->Const.MinMapBufferAlignment);
The MAX2(64, ...) seems like unnecessary complexity. We want the
alignment to be ctx->Const.MinMapBufferAlignment (which should be bumped
to >= 64 in a follow on patch).
With that removed, patch 1 is:
Reviewed-by: Kenneth Graunke
Nice work.
I'd love to see a follow-up patch that:
1. Sets ctx->Const.MinMapBufferAlignment to 64
(in brw_context.c/brw_initialize_context_constants)
2. Enables the extension (in intel_extensions.c)
I know you'd like to turn it on for all drivers, but we may as well
claim victory here in the meantime.
> + const unsigned extra = (uintptr_t) offset % alignment;
> +
>if (access & GL_MAP_FLUSH_EXPLICIT_BIT) {
> - intel_obj->range_map_buffer = malloc(length);
> - obj->Pointer = intel_obj->range_map_buffer;
> + intel_obj->range_map_buffer = _mesa_align_malloc(length + extra,
> + alignment);
> + obj->Pointer = intel_obj->range_map_buffer + extra;
>} else {
>intel_obj->range_map_bo = drm_intel_bo_alloc(brw->bufmgr,
> "range map",
> - length, 64);
> + length + extra,
> + alignment);
>if (!(access & GL_MAP_READ_BIT)) {
> drm_intel_gem_bo_map_gtt(intel_obj->range_map_bo);
>} else {
> drm_intel_bo_map(intel_obj->range_map_bo,
>(access & GL_MAP_WRITE_BIT) != 0);
>}
> - obj->Pointer = intel_obj->range_map_bo->virtual;
> + obj->Pointer = intel_obj->range_map_bo->virtual + extra;
>}
>return obj->Pointer;
> }
> @@ -424,7 +432,11 @@ intel_bufferobj_flush_mapped_range(struct gl_context
> *ctx,
>
> temp_bo = drm_intel_bo_alloc(brw->bufmgr, "range map flush", length, 64);
>
> - drm_intel_bo_subdata(temp_bo, 0, length, intel_obj->range_map_buffer);
> + /* Use obj->Pointer instead of intel_obj->range_map_buffer because the
> +* former points to the actual mapping while the latter may be offset to
> +* meet alignment guarantees.
> +*/
> + drm_intel_bo_subdata(temp_bo, 0, length, obj->Pointer);
>
> intel_emit_linear_blit(brw,
> intel_obj->buffer, obj->Offset + offset,
> @@ -456,14 +468,16 @@ intel_bufferobj_unmap(struct gl_context * ctx, struct
> gl_buffer_object *obj)
> * usage inside of a batchbuffer.
> */
>intel_batchbuffer_emit_mi_flush(brw);
> - free(intel_obj->range_map_buffer);
> + _mesa_align_free(intel_obj->range_map_buffer);
>intel_obj->range_map_buffer = NULL;
> } else if (intel_obj->range_map_bo != NULL) {
> + const unsigned extra = obj->Pointer - intel_obj->range_map_bo->virtual;
> +
>drm_intel_bo_unmap(intel_obj->range_map_bo);
>
>intel_emit_linear_blit(brw,
>intel_obj->buffer, obj->Offset,
> - intel_obj->range_map_bo, 0,
> + intel_obj->range_map_bo, extra,
>obj->Length);
>intel_bufferobj_mark_gpu_usage(intel_obj, obj->Offset, obj->Length);
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73144] Queries on textures with borders give incorrect results
https://bugs.freedesktop.org/show_bug.cgi?id=73144 Brian Paul changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Brian Paul --- We won't be fixing this. We removed support for texture borders since few (none?) of our hardware drivers support them. When glTexImage() is called with border=1 we tweak the pixel unpack params and only store the image w/out the border. -- 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 73174] Account request
https://bugs.freedesktop.org/show_bug.cgi?id=73174 Brian Paul changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes |org |ktop.org Product|Mesa|freedesktop.org Component|Other |New Accounts --- Comment #2 from Brian Paul --- Reassigning to admins. -- 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/7] i965: Don't call the blitter on addresses it can't handle.
On Sun, Jan 5, 2014 at 2:28 PM, Eric Anholt wrote:
> Anuj Phogat writes:
>
>> On Mon, Dec 23, 2013 at 4:08 PM, Eric Anholt wrote:
>>> Noticed by tex3d-maxsize on my next commit to check that our addresses
>>> don't overflow.
>>> ---
>>> src/mesa/drivers/dri/i965/intel_blit.c| 20
>>> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 23 ---
>>> 2 files changed, 40 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/intel_blit.c
>>> b/src/mesa/drivers/dri/i965/intel_blit.c
>>> index 7bc289f..13cc777 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_blit.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_blit.c
>>> @@ -229,12 +229,32 @@ intel_miptree_blit(struct brw_context *brw,
>>> src_x += src_image_x;
>>> src_y += src_image_y;
>>>
>>> + /* The blitter interprets the 16-bit src x/y as a signed 16-bit value,
>>> +* where negative values are invalid. The values we're working with are
>>> +* unsigned, so make sure we don't overflow.
>>> +*/
>>> + if (src_x >= 32768 || src_y >= 32768) {
>>> + perf_debug("Falling back due to >=32k src offset (%d, %d)\n",
>>> + src_x, src_y);
>>> + return false;
>>> + }
>>> +
>>> uint32_t dst_image_x, dst_image_y;
>>> intel_miptree_get_image_offset(dst_mt, dst_level, dst_slice,
>>>&dst_image_x, &dst_image_y);
>>> dst_x += dst_image_x;
>>> dst_y += dst_image_y;
>>>
>>> + /* The blitter interprets the 16-bit destination x/y as a signed 16-bit
>>> +* value. The values we're working with are unsigned, so make sure we
>>> +* don't overflow.
>>> +*/
>>> + if (dst_x >= 32768 || dst_y >= 32768) {
>>> + perf_debug("Falling back due to >=32k dst offset (%d, %d)\n",
>>> + dst_x, dst_y);
>>> + return false;
>>> + }
>>> +
>>> if (!intelEmitCopyBlit(brw,
>>>src_mt->cpp,
>>>src_pitch,
>>> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>>> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>>> index de47143..0818226 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>>> @@ -443,7 +443,8 @@ intel_miptree_choose_tiling(struct brw_context *brw,
>>> if (minimum_pitch < 64)
>>>return I915_TILING_NONE;
>>>
>>> - if (ALIGN(minimum_pitch, 512) >= 32768) {
>>> + if (ALIGN(minimum_pitch, 512) >= 32768 ||
>>> + mt->total_width >= 32768 || mt->total_height >= 32768) {
>>>perf_debug("%dx%d miptree too large to blit, falling back to
>>> untiled",
>>> mt->total_width, mt->total_height);
>>>return I915_TILING_NONE;
>>> @@ -2233,6 +2234,22 @@ intel_miptree_release_map(struct intel_mipmap_tree
>>> *mt,
>>> *map = NULL;
>>> }
>>>
>>> +static bool
>>> +can_blit_slice(struct intel_mipmap_tree *mt,
>>> + unsigned int level, unsigned int slice)
>>> +{
>>> + uint32_t image_x;
>>> + uint32_t image_y;
>>> + intel_miptree_get_image_offset(mt, level, slice, &image_x, &image_y);
>>> + if (image_x >= 32768 || image_y >= 32768)
>>> + return false;
>>> +
>>> + if (mt->region->pitch >= 32768)
>>> + return false;
>>> +
>>> + return true;
>>> +}
>>> +
>>> static void
>>> intel_miptree_map_singlesample(struct brw_context *brw,
>>> struct intel_mipmap_tree *mt,
>>> @@ -2276,11 +2293,11 @@ intel_miptree_map_singlesample(struct brw_context
>>> *brw,
>>> !mt->compressed &&
>>> (mt->region->tiling == I915_TILING_X ||
>>> (brw->gen >= 6 && mt->region->tiling == I915_TILING_Y)) &&
>>> -mt->region->pitch < 32768) {
>>> +can_blit_slice(mt, level, slice)) {
>>>intel_miptree_map_blit(brw, mt, map, level, slice);
>>> } else if (mt->region->tiling != I915_TILING_NONE &&
>>>mt->region->bo->size >= brw->max_gtt_map_object_size) {
>>> - assert(mt->region->pitch < 32768);
>>> + assert(can_blit_slice(mt, level, slice));
>> I think the right thing to do here is:
>> - mt->region->bo->size >= brw->max_gtt_map_object_size) {
>> - assert(mt->region->pitch < 32768);
>> + mt->region->bo->size >= brw->max_gtt_map_object_size &&
>> + can_blit_slice(mt, level, slice)) {
>>
>> This allow us falling back to intel_miptree_map_gtt(). I suggested this
>> change
>> as a part of '[PATCH] i965: Fix the region's pitch condition to use blitter'.
>
> If region->bo->size >= max_gtt_map_object_size, you can't fall back to
> GTT mapping, though. Since you can't do that, previous code needs to
> have made sure you can't reach this point.
Yes. It makes sense.
Patch is Reviewed-by: Anuj Phogat
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-de
Re: [Mesa-dev] [PATCH 2/5] Adding checks for NULL after CALLOC
On Mon, 2014-01-06 at 12:51 -0500, Alex Deucher wrote:
> On Mon, Jan 6, 2014 at 10:15 AM, Bruno Jiménez wrote:
> > ---
> > 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..62d1a5c 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;
>
> Space between if and paren. e.g.,
>
> if (pool == NULL)
Sorry, I will do it from now on.
Thanks!
>
> >
> > 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;
> > +
>
> Same here.
>
> > 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;
> > +
>
> Same here.
>
> > 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.2
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] haiku libGL: Move from gallium target to src/hgl
On 12/31/2013 09:03 PM, Alexander von Gluck IV wrote: * The Haiku renderers need to link to libGL to function properly in all usage contexts. As mesa drivers build before gallium targets, we couldn't properly link the mesa swrast driver to the gallium libGL target for Haiku. * This is likely better as it mimics how glx is laid out ensuring the Haiku libGL is better understood. * All renderers properly link in libGL now. --- For both: Acked-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] Add more NULL checks
On Mon, Jan 6, 2014 at 10:15 AM, Bruno Jiménez wrote:
> 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
Same comment as 2/5. Please add spaces between if and parens.
Alex
> ---
> 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 62d1a5c..4f4bad2 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
Re: [Mesa-dev] [PATCH 2/5] Adding checks for NULL after CALLOC
On Mon, Jan 6, 2014 at 10:15 AM, Bruno Jiménez wrote:
> ---
> 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..62d1a5c 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;
Space between if and paren. e.g.,
if (pool == 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;
> +
Same here.
> 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;
> +
Same here.
> 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.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/7] mesa: add an index_to_target_enum() function
On 01/02/2014 05:27 PM, Maxence Le Doré wrote:
From: Maxence Le Doré
---
src/mesa/main/texobj.c | 40
1 file changed, 40 insertions(+)
diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index d6510fe..bddbc50 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -1218,6 +1218,46 @@ target_enum_to_index(const struct gl_context *ctx,
GLenum target)
/**
+ * Convert a Mesa texture target index into the corresponding
+ * GL texture target enum such as GL_TEXTURE_2D or GL_TEXTURE_3D.
+ * Note that proxy targets are not valid here.
+ * \return GL_TEXTURE_x or 0x0 if index is invalid
+ */
+static GLenum
+index_to_target_enum(struct gl_context *ctx, GLint index)
+{
+ switch (index) {
+ case TEXTURE_2D_MULTISAMPLE_INDEX:
+ return GL_TEXTURE_2D_MULTISAMPLE;
+ case TEXTURE_2D_MULTISAMPLE_ARRAY_INDEX:
+ return GL_TEXTURE_2D_MULTISAMPLE_ARRAY;
+ case TEXTURE_CUBE_ARRAY_INDEX:
+ return GL_TEXTURE_CUBE_MAP_ARRAY;
+ case TEXTURE_BUFFER_INDEX:
+ return GL_TEXTURE_BUFFER_ARB;
+ case TEXTURE_2D_ARRAY_INDEX:
+ return GL_TEXTURE_2D_ARRAY_EXT;
+ case TEXTURE_1D_ARRAY_INDEX:
+ return GL_TEXTURE_1D_ARRAY_EXT;
+ case TEXTURE_EXTERNAL_INDEX:
+ return GL_TEXTURE_EXTERNAL_OES;
+ case TEXTURE_CUBE_INDEX:
+ return GL_TEXTURE_CUBE_MAP_ARB;
+ case TEXTURE_3D_INDEX:
+ return GL_TEXTURE_3D;
+ case TEXTURE_RECT_INDEX:
+ return GL_TEXTURE_RECTANGLE_NV;
+ case TEXTURE_2D_INDEX:
+ return GL_TEXTURE_2D;
+ case TEXTURE_1D_INDEX:
+ return GL_TEXTURE_1D;
+ default:
+ return 0x0;
+ }
+}
We use 3-space indentation.
But this function could be done more efficiently:
static GLenum
index_to_target_enum(struct gl_context *ctx, GLint index)
{
static const GLenum names[] = {
GL_TEXTURE_2D_MULTISAMPLE,
GL_TEXTURE_2D_MULTISAMPLE_ARRAY,
...
}
STATIC_ASSSERT(Elements(names) == NUM_TEXTURE_TARGETS);
assert(index < NUM_TEXTURE_TARGETS);
return names[index];
}
And why is this function needed? I don't see it used in the other
patches (but maybe I missed it).
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] More null checks into glx
On 01/03/2014 05:57 AM, Juha-Pekka Heikkila wrote: Still Klocwork related patches. Juha-Pekka Heikkila (2): glx: Add missing null check in __glXNewIndirectAPI() glx: check memory allocations in __glXInitVertexArrayState() src/glx/indirect_vertex_array.c | 27 +++ src/mapi/glapi/gen/glX_proto_send.py | 2 ++ 2 files changed, 25 insertions(+), 4 deletions(-) Reviewed-by: Brian Paul I'll push these soon. Thanks. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] mesa/main: Free ctx->DrawIndirectBuffer during teardown
On 01/02/2014 11:38 AM, Aaron Watry wrote:
ctx->DrawIndirectBuffer wasn't being free'd in _mesa_free_buffer_objects
With this patch, "valgrind --leak-check=full glxgears" on evergreen (CEDAR)
now shows:
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 70,228 bytes in 651 blocks
suppressed: 0 bytes in 0 blocks
CC: "10.0"
---
src/mesa/main/bufferobj.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index a3d8f24..9336759 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -871,6 +871,8 @@ _mesa_free_buffer_objects( struct gl_context *ctx )
_mesa_reference_buffer_object(ctx, &ctx->UniformBuffer, NULL);
+ _mesa_reference_buffer_object(ctx, &ctx->DrawIndirectBuffer, NULL);
+
for (i = 0; i < MAX_COMBINED_UNIFORM_BUFFERS; i++) {
_mesa_reference_buffer_object(ctx,
&ctx->UniformBufferBindings[i].BufferObject,
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [v2] Cleaning compute_memory_pool from gallium/drivers/r600
On 01/06/2014 08:15 AM, Bruno Jiménez wrote:
Hi,
This is the second version of my previous patches.
I have cleaned a bit compute_memory_pool.c, added some
NULL checks to the code, corrected a typo and removed
an unneeded decraration of a function.
Patches 1 and 2 are the same.
Patch 3 changes Returns to @returns so doxygen can
parse it correctly.
Patch 4 is a correction of my anterior patch, as
it changed the behaviour of the code. It
also contain an explanation of the change
Patch 5 now, apart from removing the declaration
compute_memory_defrag, also removes some
comments that are already in
compute_memory_pool.c
[PATCH 1/5] Fixing a typo and some indentation
[PATCH 2/5] Adding checks for NULL after CALLOC
[PATCH 3/5] Add more NULL checks
[PATCH 4/5] Tidy a bit compute_memory_finalize_pending
[PATCH 5/5] Cleanup of compute_memory_pool.h
All the git commit messages should be prefixed with "r600g".
In patch 2&3, put a space between 'if' and '('
In patch 5, the commit message could be re-wrapped to 70 columns or so.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Use get_local_param_pointer in glProgramLocalParameters4fvEXT().
On 01/05/2014 09:10 PM, Kenneth Graunke wrote:
Using the get_local_param_pointer helper ensures that the LocalParams
arrays have actually been allocated before attempting to use them.
glProgramLocalParameters4fvEXT needs to do a bit of extra checking,
but it can be simplified since the helper has already validated the
target.
Fixes crashes in programs that use Cg (such as Awesomenauts) since
commit e5885c119de1e508099cce1c9f8ff00fab88 (mesa: Dynamically
allocate the storage for program local parameters.).
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D73136&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=gW5OVHtORWDtOYenBA%2FvNgvhol2aPx9mdsARthkvza8%3D%0A&s=9820bb2ade5ab45808e872046b14d1fbd24aca1ff1fb29a6686a5a538d37400d
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
---
src/mesa/main/arbprogram.c | 30 +++---
1 file changed, 11 insertions(+), 19 deletions(-)
diff --git a/src/mesa/main/arbprogram.c b/src/mesa/main/arbprogram.c
index 8bd3f0b..bf2a5f8 100644
--- a/src/mesa/main/arbprogram.c
+++ b/src/mesa/main/arbprogram.c
@@ -527,28 +527,20 @@ _mesa_ProgramLocalParameters4fvEXT(GLenum target, GLuint
index, GLsizei count,
_mesa_error(ctx, GL_INVALID_VALUE,
"glProgramLocalParameters4fv(count)");
}
- if (target == GL_FRAGMENT_PROGRAM_ARB
- && ctx->Extensions.ARB_fragment_program) {
- if ((index + count) > ctx->Const.FragmentProgram.MaxLocalParams) {
- _mesa_error(ctx, GL_INVALID_VALUE, "glProgramLocalParameters4fvEXT(index +
count)");
- return;
- }
- dest = ctx->FragmentProgram.Current->Base.LocalParams[index];
- }
- else if (target == GL_VERTEX_PROGRAM_ARB
-&& ctx->Extensions.ARB_vertex_program) {
- if ((index + count) > ctx->Const.VertexProgram.MaxLocalParams) {
- _mesa_error(ctx, GL_INVALID_VALUE, "glProgramLocalParameters4fvEXT(index +
count)");
+ if (get_local_param_pointer(ctx, "glProgramLocalParameters4fvEXT",
+ target, index, &dest)) {
+ GLuint maxParams = target == GL_FRAGMENT_PROGRAM_ARB ?
+ ctx->Const.FragmentProgram.MaxLocalParams :
+ ctx->Const.VertexProgram.MaxLocalParams;
+
+ if ((index + count) > maxParams) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ "glProgramLocalParameters4fvEXT(index + count)");
return;
}
- dest = ctx->VertexProgram.Current->Base.LocalParams[index];
- }
- else {
- _mesa_error(ctx, GL_INVALID_ENUM,
"glProgramLocalParameters4fvEXT(target)");
- return;
- }
- memcpy(dest, params, count * 4 * sizeof(GLfloat));
+ memcpy(dest, params, count * 4 * sizeof(GLfloat));
+ }
}
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] mesa: implement glBindBuffersBase() and gl BindBuffersRange()
On 01/03/2014 06:39 AM, servuswiege...@yahoo.de wrote:
when you create the patches with git, you can add --cover-letter to the
command line. then you get a PATCH 0/X file with an overview over all
changes and a central place where you can describe what you've done in
general/which extension etc.
On 03.01.2014 01:27, Maxence Le Doré wrote:
---
src/mesa/main/bufferobj.c | 158 ++
src/mesa/main/bufferobj.h | 9 ++-
2 files changed, 165 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index a3d8f24..bad8f90 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -2706,3 +2706,161 @@ _mesa_InvalidateBufferData(GLuint buffer)
*/
return;
}
+
+void GLAPIENTRY
+_mesa_BindBuffersBase(GLenum target, GLuint first, GLsizei count,
+ const GLuint *buffers)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ int i = 0;
+ GLboolean exceedMaxBindings = GL_FALSE;
+
+ switch(target) {
+ case GL_TRANSFORM_FEEDBACK_BUFFER:
+ first + count > ctx->Const.MaxTransformFeedbackBuffers ?
+ exceedMaxBindings = GL_TRUE : exceedMaxBindings = GL_FALSE;
+ break;
all of these are maybe more concise like this:
exceedMaxBindings = first + count >
ctx->Const.MaxTransformFeedbackBuffers ?
GL_TRUE : GL_FALSE;
Or, just:
exceedMaxBindings = first + count >
ctx->Const.MaxTransformFeedbackBuffers;
+ case GL_UNIFORM_BUFFER:
+ first + count > ctx->Const.MaxUniformBufferBindings ?
+ exceedMaxBindings = GL_TRUE : exceedMaxBindings = GL_FALSE;
+ break;
+ case GL_ATOMIC_COUNTER_BUFFER:
+ first + count > ctx->Const.MaxAtomicBufferBindings ?
+ exceedMaxBindings = GL_TRUE : exceedMaxBindings = GL_FALSE;
+ break;
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ "glBindBuffersBase(invalid target)");
+ return;
The indentation above looks wrong. We use 3 spaces.
+ }
+
+ if(exceedMaxBindings) {
Please put a space between 'if' and the opening parenthesis. Same thing
for 'switch', 'for', etc.
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glBindBuffersBase(first+count)");
+ return;
+ }
+
+ for(i = 0 ; i < count ; i++) {
+ GLuint buffer;
+ struct gl_buffer_object *bufferObj;
+
+ if(buffers == NULL)
+buffer = 0;
+ else
+buffer = buffers[i];
buffer = buffers ? buffers[i] : 0;
+
+ if(buffer != 0) {
if (buffer) {
+bufferObj = _mesa_lookup_bufferobj(ctx, buffer);
+if(bufferObj) {
+ _mesa_BindBufferBase(target, first+i, buffer);
+}
+else
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glBindBufferBase(buffer[%i] is invalid)", i);
+ }
+ else
+_mesa_BindBufferBase(target, first + i, 0);
+ }
+}
+
+void GLAPIENTRY
+_mesa_BindBuffersRange(GLenum target, GLuint first, GLsizei count,
+ const GLuint *buffers, const GLintptr *offsets,
+ const GLsizeiptr *sizes)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ int i = 0;
+ GLboolean exceedMaxBindings = GL_FALSE;
+
+ switch(target) {
+ case GL_TRANSFORM_FEEDBACK_BUFFER:
+ first + count > ctx->Const.MaxTransformFeedbackBuffers ?
+ exceedMaxBindings = GL_TRUE : exceedMaxBindings = GL_FALSE;
+ break;
+ case GL_UNIFORM_BUFFER:
+ first + count > ctx->Const.MaxUniformBufferBindings ?
+ exceedMaxBindings = GL_TRUE : exceedMaxBindings = GL_FALSE;
+ break;
+ case GL_ATOMIC_COUNTER_BUFFER:
+ first + count > ctx->Const.MaxAtomicBufferBindings ?
+ exceedMaxBindings = GL_TRUE : exceedMaxBindings = GL_FALSE;
+ break;
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ "glBindBuffersRange(invalid target)");
+ return;
+ }
+
+ if(exceedMaxBindings) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glBindBuffersRange(first+count)");
+ return;
+ }
Fix indentation.
+
+ for(i = 0 ; i < count ; i++) {
for (i = 0; i < count; i++) {
+ GLuint buffer;
+ GLintptr offset;
+ GLsizeiptr size;
+ struct gl_buffer_object *bufferObj;
+
+ if(buffers == NULL)
+buffer = 0;
+ else {
+buffer = buffers[i];
+offset = offsets[i];
+size = sizes[i];
+ }
+
+ if(buffer != 0) {
+bufferObj = _mesa_lookup_bufferobj(ctx, buffer);
+if(bufferObj) {
+ GLboolean validOffet, validSize;
"validOffset"
+
+ switch(target) {
+case GL_TRANSFORM_FEEDBACK_BUFFER:
+ (offset >= 0) ?
+ validOffset = GL_TRUE : validOffet = GL_FALSE;
validOffset = offset >= 0;
+ (size >= 0) ?
+ validSize = GL_TRUE : validSize = GL_F
Re: [Mesa-dev] [PATCH] glsl: Optimize pow(1.0, X) --> 1.0.
Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/9] tgsi: implement micro_fma() in tgsi exec machine
On Sun, Jan 5, 2014 at 12:42 AM, Maxence Le Doré
wrote:
> From: Maxence Le Doré
Huh, user.email not configured properly?
> static void
> +micro_fma(union tgsi_exec_channel *dst,
> + const union tgsi_exec_channel *src0,
> + const union tgsi_exec_channel *src1,
> + const union tgsi_exec_channel *src2)
> +{
> + dst->f[0] = fmaf(src0->f[0],src1->f[0],src2->f[0]);
fmaf isn't portable enough, no?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: gratuitous spelling pass
On 01/03/2014 04:44 PM, Nathan Kidd wrote:
From: Nathan Kidd
Fixed what I noticed; no warranty for exhaustiveness.
Signed-off-by: Nathan Kidd
---
docs/conform.html|2 +-
docs/devinfo.html|2 +-
docs/dispatch.html | 10 +-
docs/egl.html|8
docs/envvars.html|6 +++---
docs/faq.html|8
docs/opengles.html |4 ++--
docs/openvg.html |2 +-
docs/repository.html |2 +-
docs/shading.html|2 +-
docs/sourcetree.html |2 +-
docs/thanks.html |2 +-
docs/xlibdriver.html |2 +-
13 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/docs/conform.html b/docs/conform.html
index c5f8ece..5593137 100644
--- a/docs/conform.html
+++ b/docs/conform.html
@@ -19,7 +19,7 @@
The SGI OpenGL conformance tests verify correct operation of OpenGL
implementations. I, Brian Paul, have been given a copy of the tests
-for testing Mesa. The tests are not publically available.
+for testing Mesa. The tests are not publicly available.
This file has the latest results of testing Mesa with the OpenGL 1.2
diff --git a/docs/devinfo.html b/docs/devinfo.html
index a9d8b4f..d4a6dfb 100644
--- a/docs/devinfo.html
+++ b/docs/devinfo.html
@@ -206,7 +206,7 @@ exclusively for the older branch.
This "CC" syntax for patch nomination will cause patches to automatically be
copied to the mesa-stable@ mailing list when you use "git send-email" to send
patches to the mesa-dev@ mailing list. Also, if you realize that a commit
-should be nominate for the stable branch after it has already been commited,
+should be nominated for the stable branch after it has already been committed,
you can send a note directly to the mesa-sta...@lists.freedesktop.org where
the Mesa stable-branch maintainers will receive it. Be sure to mention the
commit ID of the commit of interest (as it appears in the mesa master branch).
diff --git a/docs/dispatch.html b/docs/dispatch.html
index 4b529bc..aacd01e 100644
--- a/docs/dispatch.html
+++ b/docs/dispatch.html
@@ -25,7 +25,7 @@ href="#overview">overview of Mesa's implementation.
1. Complexity of GL Dispatch
Every GL application has at least one object called a GL context.
-This object, which is an implicit parameter to ever GL function, stores all
+This object, which is an implicit parameter to every GL function, stores all
of the GL related state for the application. Every texture, every buffer
object, every enable, and much, much more is stored in the context. Since
an application can have more than one context, the context to be used is
@@ -51,7 +51,7 @@ example, glFogCoordf may operate differently
depending on whether
or not fog is enabled.
In multi-threaded environments, it is possible for each thread to have a
-differnt GL context current. This means that poor old glVertex3fv
+different GL context current. This means that poor old glVertex3fv
has to know which GL context is current in the thread where it is being
called.
@@ -207,13 +207,13 @@ few preprocessor defines.
If GLX_USE_TLS is defined, method #4 is used.
If HAVE_PTHREAD is defined, method #3 is used.
If WIN32_THREADS is defined, method #2 is used.
-If none of the preceeding are defined, method #1 is used.
+If none of the preceding are defined, method #1 is used.
Two different techniques are used to handle the various different cases.
On x86 and SPARC, a macro called GL_STUB is used. In the preamble
of the assembly source file different implementations of the macro are
-selected based on the defined preprocessor variables. The assmebly code
+selected based on the defined preprocessor variables. The assembly code
then consists of a series of invocations of the macros such as:
@@ -242,7 +242,7 @@ first technique, is to insert #ifdef within the
assembly
implementation of each function. This makes the assembly file considerably
larger (e.g., 29,332 lines for glapi_x86-64.S versus 1,155 lines for
glapi_x86.S) and causes simple changes to the function
-implementation to generate many lines of diffs. Since the assmebly files
+implementation to generate many lines of diffs. Since the assembly files
are typically generated by scripts (see below), this
isn't a significant problem.
diff --git a/docs/egl.html b/docs/egl.html
index 240cec5..dc23241 100644
--- a/docs/egl.html
+++ b/docs/egl.html
@@ -88,7 +88,7 @@ drivers will be installed to ${libdir}/egl.
List the platforms (window systems) to support. Its argument is a comma
-seprated string such as --with-egl-platforms=x11,drm. It decides
+separated string such as --with-egl-platforms=x11,drm. It decides
the platforms a driver may support. The first listed platform is also used by
the main library to decide the native platform: the platform the EGL native
types such as EGLNativeDisplayType or
@@ -223,7 +223,7 @@ the X server directly using (XCB-)DRI2 protocol.
This drive
[Mesa-dev] [PATCH 5/5] 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.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] 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..62d1a5c 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.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] 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 62d1a5c..4f4bad2 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/com
[Mesa-dev] [PATCH 4/5] 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 4f4bad2..cf183cd 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.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [v2] Cleaning compute_memory_pool from gallium/drivers/r600
Hi, This is the second version of my previous patches. I have cleaned a bit compute_memory_pool.c, added some NULL checks to the code, corrected a typo and removed an unneeded decraration of a function. Patches 1 and 2 are the same. Patch 3 changes Returns to @returns so doxygen can parse it correctly. Patch 4 is a correction of my anterior patch, as it changed the behaviour of the code. It also contain an explanation of the change Patch 5 now, apart from removing the declaration compute_memory_defrag, also removes some comments that are already in compute_memory_pool.c [PATCH 1/5] Fixing a typo and some indentation [PATCH 2/5] Adding checks for NULL after CALLOC [PATCH 3/5] Add more NULL checks [PATCH 4/5] Tidy a bit compute_memory_finalize_pending [PATCH 5/5] Cleanup of compute_memory_pool.h ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/9] gallium-tgsi: add TGSI_OPCODE_{FMA-POPCNT-MSB-LSB} description
Am 05.01.2014 01:34, schrieb Maxence Le Doré:
> FMA(a,b,c) keeps extra precision (usually 1 more bit of mantissa,
> afaik) for the result a*b and add this to c, to finally produce a
> IEEE754 32bit float result.
>
> MAD(a,b,c) product a IEEE754 32bit float product a*b and add it to C.
>
> So, fma can be slightly more accurate. An accuracy that is something
> very appreciate.
Actually in "newer" languages (such as opencl) "mad" is used to indicate
intermediate rounding does not matter, so if your cpu can do fma but not
mul+add in a single cycle it is allowed to use fma instead.
FMA OTOH of course forces no intermediate rounding.
Our tgsi definitions certainly initially were meaning intermediate
rounding should take place, I don't know if we need to keep it that way
or could repurpose that slightly (so if you require the intermediate
rounding you'd just use mul+add).
Roland
>
>
> 2014/1/5 Marek Olšák :
>> How is FMA different from MAD?
>>
>> Please document the new opcodes in src/gallium/docs/source/tgsi.rst.
>>
>> Marek
>>
>> On Sun, Jan 5, 2014 at 12:42 AM, Maxence Le Doré
>> wrote:
>>> From: Maxence Le Doré
>>>
>>> ---
>>> src/gallium/auxiliary/tgsi/tgsi_info.c | 16
>>> src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h | 6 ++
>>> src/gallium/include/pipe/p_shader_tokens.h | 9 -
>>> 3 files changed, 30 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c
>>> b/src/gallium/auxiliary/tgsi/tgsi_info.c
>>> index 0beef44..ed55940 100644
>>> --- a/src/gallium/auxiliary/tgsi/tgsi_info.c
>>> +++ b/src/gallium/auxiliary/tgsi/tgsi_info.c
>>> @@ -221,6 +221,12 @@ static const struct tgsi_opcode_info
>>> opcode_info[TGSI_OPCODE_LAST] =
>>> { 1, 3, 1, 0, 0, 0, OTHR, "TXL2", TGSI_OPCODE_TXL2 },
>>> { 1, 2, 0, 0, 0, 0, COMP, "IMUL_HI", TGSI_OPCODE_IMUL_HI },
>>> { 1, 2, 0, 0, 0, 0, COMP, "UMUL_HI", TGSI_OPCODE_UMUL_HI },
>>> + { 1, 3, 0, 0, 0, 0, COMP, "FMA", TGSI_OPCODE_FMA },
>>> + { 1, 1, 0, 0, 0, 0, COMP, "POPCNT", TGSI_OPCODE_POPCNT },
>>> + { 1, 1, 0, 0, 0, 0, COMP, "IMSB", TGSI_OPCODE_IMSB },
>>> + { 1, 1, 0, 0, 0, 0, COMP, "ILSB", TGSI_OPCODE_ILSB },
>>> + { 1, 1, 0, 0, 0, 0, COMP, "UMSB", TGSI_OPCODE_UMSB },
>>> + { 1, 1, 0, 0, 0, 0, COMP, "ULSB", TGSI_OPCODE_ULSB },
>>> };
>>>
>>> const struct tgsi_opcode_info *
>>> @@ -321,6 +327,11 @@ tgsi_opcode_infer_type( uint opcode )
>>> case TGSI_OPCODE_IABS:
>>> case TGSI_OPCODE_ISSG:
>>> case TGSI_OPCODE_IMUL_HI:
>>> + case TGSI_OPCODE_POPCNT:
>>> + case TGSI_OPCODE_ILSB:
>>> + case TGSI_OPCODE_IMSB:
>>> + case TGSI_OPCODE_ULSB:
>>> + case TGSI_OPCODE_UMSB:
>>>return TGSI_TYPE_SIGNED;
>>> default:
>>>return TGSI_TYPE_FLOAT;
>>> @@ -344,9 +355,14 @@ tgsi_opcode_infer_src_type( uint opcode )
>>> case TGSI_OPCODE_SAMPLE_I:
>>> case TGSI_OPCODE_SAMPLE_I_MS:
>>> case TGSI_OPCODE_UMUL_HI:
>>> + case TGSI_OPCODE_POPCNT:
>>> + case TGSI_OPCODE_ULSB:
>>> + case TGSI_OPCODE_UMSB:
>>>return TGSI_TYPE_UNSIGNED;
>>> case TGSI_OPCODE_IMUL_HI:
>>> case TGSI_OPCODE_I2F:
>>> + case TGSI_OPCODE_ILSB:
>>> + case TGSI_OPCODE_IMSB:
>>>return TGSI_TYPE_SIGNED;
>>> case TGSI_OPCODE_ARL:
>>> case TGSI_OPCODE_ARR:
>>> diff --git a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
>>> b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
>>> index 1ef78dd..cba0975 100644
>>> --- a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
>>> +++ b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h
>>> @@ -206,6 +206,12 @@ OP13(UCMP)
>>>
>>> OP12(IMUL_HI)
>>> OP12(UMUL_HI)
>>> +OP13(FMA)
>>> +OP11(POPCNT)
>>> +OP11(IMSB)
>>> +OP11(ILSB)
>>> +OP11(UMSB)
>>> +OP11(ULSB)
>>>
>>> #undef OP00
>>> #undef OP01
>>> diff --git a/src/gallium/include/pipe/p_shader_tokens.h
>>> b/src/gallium/include/pipe/p_shader_tokens.h
>>> index 8010902..5ed0c34 100644
>>> --- a/src/gallium/include/pipe/p_shader_tokens.h
>>> +++ b/src/gallium/include/pipe/p_shader_tokens.h
>>> @@ -453,7 +453,14 @@ struct tgsi_property_data {
>>> #define TGSI_OPCODE_IMUL_HI 180
>>> #define TGSI_OPCODE_UMUL_HI 181
>>>
>>> -#define TGSI_OPCODE_LAST182
>>> +#define TGSI_OPCODE_FMA 182
>>> +#define TGSI_OPCODE_POPCNT 183
>>> +#define TGSI_OPCODE_IMSB184
>>> +#define TGSI_OPCODE_ILSB185
>>> +#define TGSI_OPCODE_UMSB186
>>> +#define TGSI_OPCODE_ULSB187
>>> +
>>> +#define TGSI_OPCODE_LAST188
>>>
>>> #define TGSI_SAT_NONE0 /* do not saturate */
>>> #define TGSI_SAT_ZERO_ONE1 /* clamp to [0,1] */
>>> --
>>> 1.8.5.2
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztF
Re: [Mesa-dev] [PATCH 3/9] util: add fma3 or fma4 capable cpu detection
Am 05.01.2014 00:42, schrieb Maxence Le Doré:
> From: Maxence Le Doré
>
> ---
> src/gallium/auxiliary/util/u_cpu_detect.c | 5 +
> src/gallium/auxiliary/util/u_cpu_detect.h | 2 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_cpu_detect.c
> b/src/gallium/auxiliary/util/u_cpu_detect.c
> index d2d1313..19ad4fa 100644
> --- a/src/gallium/auxiliary/util/u_cpu_detect.c
> +++ b/src/gallium/auxiliary/util/u_cpu_detect.c
> @@ -371,6 +371,9 @@ util_cpu_detect(void)
> ((xgetbv() & 6) == 6);// XMM & YMM
> util_cpu_caps.has_f16c = (regs2[2] >> 29) & 1;
> util_cpu_caps.has_mmx2 = util_cpu_caps.has_sse; /* SSE cpus
> supports mmxext too */
> +
> + util_cpu_caps.has_fma3 = (regs2[2] >> 12) & 1;
> + util_cpu_caps.has_fma4 = (regs2[2] >> 16) & 1;
This isn't correct, since fma4 is only defined for amd cpus it is only
there in ecx in the extended feature flags (i.e. with initial eax value
0x8000).
And I'm wondering if we should list that as supported only when avx is
supported as this is a requirement for it (and the cpu could well
support it when the environment doesn't support avx). Though that said
this is true for f16c too actually.
Roland
> #if defined(PIPE_ARCH_X86_64)
> util_cpu_caps.has_daz = 1;
> #else
> @@ -451,6 +454,8 @@ util_cpu_detect(void)
>debug_printf("util_cpu_caps.has_xop = %u\n", util_cpu_caps.has_xop);
>debug_printf("util_cpu_caps.has_altivec = %u\n",
> util_cpu_caps.has_altivec);
>debug_printf("util_cpu_caps.has_daz = %u\n", util_cpu_caps.has_daz);
> + debug_printf("util_cpu_caps.has_fma3 = %u\n", util_cpu_caps.has_fma3);
> + debug_printf("util_cpu_caps.has_fma4 = %u\n", util_cpu_caps.has_fma4);
> }
> #endif
>
> diff --git a/src/gallium/auxiliary/util/u_cpu_detect.h
> b/src/gallium/auxiliary/util/u_cpu_detect.h
> index 5ccfc93..6802e6a 100644
> --- a/src/gallium/auxiliary/util/u_cpu_detect.h
> +++ b/src/gallium/auxiliary/util/u_cpu_detect.h
> @@ -71,6 +71,8 @@ struct util_cpu_caps {
> unsigned has_xop:1;
> unsigned has_altivec:1;
> unsigned has_daz:1;
> + unsigned has_fma3:1;
> + unsigned has_fma4:1;
> };
>
> extern struct util_cpu_caps
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] 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.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: calculate NUM_BANKS for DB correctly on CIK
On Sun, Jan 5, 2014 at 6:53 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> NUM_BANKS is not constant on CIK.
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeonsi/si_state.c | 23
> +++
> src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 5 +
> src/gallium/winsys/radeon/drm/radeon_winsys.h | 3 +++
> 3 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state.c
> b/src/gallium/drivers/radeonsi/si_state.c
> index b880ee0..3666a11 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -40,9 +40,25 @@
> #include "../radeon/r600_cs.h"
> #include "sid.h"
>
> -static uint32_t cik_num_banks(uint32_t nbanks)
> +static uint32_t cik_num_banks(struct r600_screen *rscreen, unsigned bpe,
> unsigned tile_split)
> {
> - switch (nbanks) {
> + if (rscreen->b.info.cik_macrotile_mode_array_valid) {
> + unsigned index, tileb;
> +
> + tileb = 8 * 8 * bpe;
> + tileb = MIN2(tile_split, tileb);
> +
> + for (index = 0; tileb > 64; index++) {
> + tileb >>= 1;
> + }
> +
> + assert(index < 16);
> +
> + return (rscreen->b.info.cik_macrotile_mode_array[index] >> 6)
> & 0x3;
> + }
> +
> + /* The old way. */
> + switch (rscreen->b.tiling_info.num_banks) {
> case 2:
> return V_02803C_ADDR_SURF_2_BANK;
> case 4:
> @@ -55,7 +71,6 @@ static uint32_t cik_num_banks(uint32_t nbanks)
> }
> }
>
> -
> static unsigned cik_tile_split(unsigned tile_split)
> {
> switch (tile_split) {
> @@ -1800,7 +1815,7 @@ static void si_db(struct r600_context *rctx, struct
> si_pm4_state *pm4,
> macro_aspect = cik_macro_tile_aspect(macro_aspect);
> bankw = cik_bank_wh(bankw);
> bankh = cik_bank_wh(bankh);
> - nbanks = cik_num_banks(rscreen->b.tiling_info.num_banks);
> + nbanks = cik_num_banks(rscreen, rtex->surface.bpe,
> rtex->surface.tile_split);
> tile_mode_index = si_tile_mode_index(rtex, level, false);
> pipe_config = cik_db_pipe_config(rscreen, tile_mode_index);
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> index 2cd1834..dc9d183 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> @@ -423,6 +423,11 @@ static boolean do_winsys_init(struct radeon_drm_winsys
> *ws)
> ws->info.si_tile_mode_array_valid = TRUE;
> }
>
> +if (radeon_get_drm_value(ws->fd, RADEON_INFO_CIK_MACROTILE_MODE_ARRAY,
> NULL,
> + ws->info.cik_macrotile_mode_array)) {
> +ws->info.cik_macrotile_mode_array_valid = TRUE;
> +}
> +
> return TRUE;
> }
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h
> b/src/gallium/winsys/radeon/drm/radeon_winsys.h
> index 0d0064a..55f60d3 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
> +++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
> @@ -198,6 +198,9 @@ struct radeon_info {
>
> boolean si_tile_mode_array_valid;
> uint32_tsi_tile_mode_array[32];
> +
> +boolean cik_macrotile_mode_array_valid;
> +uint32_tcik_macrotile_mode_array[16];
> };
>
> enum radeon_feature_id {
> --
> 1.8.3.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Naming everything in src/gallium/drivers/radeonsi si_*
It sounds good, but I'd like the prefix to be si_ everywhere. Marek On Mon, Jan 6, 2014 at 2:47 PM, Andreas Hartmetz wrote: > Hello, > > many of the files in radeonsi originally came from other places where > they had different names and were never renamed. > Most of them now have names that don't tell what the files are for > (r600 is not actually the first hardware supported by them, they start > at radeonsi), and even those with radeonsi are split between > radeonsi_ and si_. > si_ is shorter than radeonsi_, but inconsistent with the directory and > library name. I still think it's the best option, but no strong opinion > from me. If and when the files are renamed, the next step would be > doing the same with the r600_ struct and function names. > Does that sound good? I'll send the patches shortly if so. > > Cheers, > Andreas > ___ > 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] Naming everything in src/gallium/drivers/radeonsi si_*
Hello, many of the files in radeonsi originally came from other places where they had different names and were never renamed. Most of them now have names that don't tell what the files are for (r600 is not actually the first hardware supported by them, they start at radeonsi), and even those with radeonsi are split between radeonsi_ and si_. si_ is shorter than radeonsi_, but inconsistent with the directory and library name. I still think it's the best option, but no strong opinion from me. If and when the files are renamed, the next step would be doing the same with the r600_ struct and function names. Does that sound good? I'll send the patches shortly if so. Cheers, Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6][RFC] Gallium/dri2: implement blitImage
On Sun, Jan 5, 2014 at 10:26 PM, Axel Davy wrote:
> Signed-off-by: Axel Davy
> ---
> src/gallium/state_trackers/dri/drm/dri2.c | 49
> +--
> 1 file changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
> b/src/gallium/state_trackers/dri/drm/dri2.c
> index 2a5b7b4..89d9040 100644
> --- a/src/gallium/state_trackers/dri/drm/dri2.c
> +++ b/src/gallium/state_trackers/dri/drm/dri2.c
> @@ -985,6 +985,49 @@ dri2_from_fds(__DRIscreen *screen, int width, int
> height, int fourcc,
> }
>
> static void
> +dri2_blit_image(__DRIcontext *context, __DRIimage *dst, __DRIimage *src,
> +int dstx0, int dsty0, int dstwidth, int dstheight,
> +int srcx0, int srcy0, int srcwidth, int srcheight,
> +int flags)
> +{
> + struct dri_context *ctx = dri_context(context);
> + struct pipe_context *pipe = ctx->st->pipe;
> + struct pipe_screen* screen = dri_screen(ctx->sPriv)->base.screen;
> + struct pipe_fence_handle *fence;
> + struct pipe_blit_info blit;
> +
> + if (!dst || !src)
> + return;
> +
> + memset(&blit, 0, sizeof(blit));
> + blit.dst.resource = dst->texture;
> + blit.dst.box.x = dstx0;
> + blit.dst.box.y = dsty0;
> + blit.dst.box.width = dstwidth;
> + blit.dst.box.height = dstheight;
> + blit.dst.box.depth = 1;
> + blit.dst.format = dst->texture->format;
> + blit.src.resource = src->texture;
> + blit.src.box.x = srcx0;
> + blit.src.box.y = srcy0;
> + blit.src.box.width = srcwidth;
> + blit.src.box.height = srcheight;
> + blit.src.box.depth = 1;
> + blit.src.format = src->texture->format;
> + blit.mask = PIPE_MASK_RGBA;
> + blit.filter = PIPE_TEX_FILTER_NEAREST;
> +
> + pipe->blit(pipe, &blit);
> +
> + pipe->flush_resource(pipe, dst->texture);
> +
> + ctx->st->flush(ctx->st, 0, &fence);
> +
> + if (flags & __BLIT_FLAG_FINISH)
> + (void) screen->fence_finish(screen, fence, PIPE_TIMEOUT_INFINITE);
> + screen->fence_reference(screen, &fence, NULL);
Fences might not be implemented by some drivers. I recommend setting
the fence pointer to NULL, then calling flush and then checking if
it's not NULL. Also, getting a fence incurs some overhead, so if
__BLIT_FLAG_FINISH is not set, the last parameter of st->flush should
be NULL.
Who can call this function? The X server?
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 72877] Wrong colors with Mesa 9.2 and Mesa 10.0 on PPC Linux systems
https://bugs.freedesktop.org/show_bug.cgi?id=72877 --- Comment #5 from Christian Zigotzky --- (In reply to comment #4) > (In reply to comment #3) > > Is the bug fixed? > > Not yet. To fix it, the r600g driver needs to be adapted to changes in the > way the Gallium3D infrastructure deals with big endian hosts. Hi Michel, Thanks a lot for your answer. :-) We had a problem with wrong colors in SuperTuxKart 0.8 last year. The Irrlicht guys have released a little hack for Irrlicht on Linux PPC (http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7&t=48577). They told me that is a driver bug, and that workaround costs performance and RAM. Unfortunately this workaround isn't suitable for Mesa 9.2 and higher. At this time we have to install Mesa 9.1.X and lower on new Linux distributions like Lubuntu 13.10, Debian Sid etc. It would be nice to solve this issue because we don't need the workaround in the future. All the best, Christian -- 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 69101] prime: black window
https://bugs.freedesktop.org/show_bug.cgi?id=69101 --- Comment #11 from Alexander Mezin --- Even with UXA, I still have black window instead of fullscreen games -- 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/4] radeon: Determine the bo priority (MSAA, depth, UVD are high)
Signed-off-by: Lauri Kasanen
---
src/gallium/drivers/radeon/r600_buffer_common.c | 8
src/gallium/drivers/radeon/radeon_uvd.c | 4 ++--
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 4
src/gallium/winsys/radeon/drm/radeon_drm_bo.h | 1 +
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 2 +-
src/gallium/winsys/radeon/drm/radeon_winsys.h | 2 ++
6 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index ac5fbcc..fb8005a 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -25,6 +25,7 @@
*/
#include "r600_cs.h"
+#include "util/u_format.h"
#include "util/u_memory.h"
#include "util/u_upload_mgr.h"
#include
@@ -101,6 +102,12 @@ bool r600_init_resource(struct r600_common_screen *rscreen,
bool use_reusable_pool, unsigned usage)
{
uint32_t initial_domain, domains;
+ bool high_prio = false;
+
+ /* If it's depth or MSAA, consider it high priority */
+ if (util_format_has_depth(util_format_description(res->b.b.format)) ||
+ res->b.b.nr_samples > 1)
+ high_prio = true;
switch(usage) {
case PIPE_USAGE_STAGING:
@@ -131,6 +138,7 @@ bool r600_init_resource(struct r600_common_screen *rscreen,
res->buf = rscreen->ws->buffer_create(rscreen->ws, size, alignment,
use_reusable_pool,
+ high_prio,
initial_domain);
if (!res->buf) {
return false;
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.c
index 95757e3..1cc1997 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -168,7 +168,7 @@ static bool create_buffer(struct ruvd_decoder *dec,
struct ruvd_buffer *buffer,
unsigned size)
{
- buffer->buf = dec->ws->buffer_create(dec->ws, size, 4096, false,
+ buffer->buf = dec->ws->buffer_create(dec->ws, size, 4096, false, true,
RADEON_DOMAIN_GTT |
RADEON_DOMAIN_VRAM);
if (!buffer->buf)
return false;
@@ -1008,7 +1008,7 @@ void ruvd_join_surfaces(struct radeon_winsys* ws,
unsigned bind,
/* TODO: 2D tiling workaround */
alignment *= 2;
- pb = ws->buffer_create(ws, size, alignment, bind, RADEON_DOMAIN_VRAM);
+ pb = ws->buffer_create(ws, size, alignment, bind, true,
RADEON_DOMAIN_VRAM);
if (!pb)
return;
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 9aa1a0f..8a5eb6e 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -651,6 +651,8 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct
pb_manager *_mgr,
else if (rdesc->initial_domains & RADEON_DOMAIN_GTT)
rws->allocated_gtt += align(size, 4096);
+bo->stats.high_prio = rdesc->high_prio;
+
if (ws->bo_stats_file) {
fprintf(ws->bo_stats_file, "%p created, size %u, prio %u, @%llu\n",
bo, size,
bo->stats.high_prio, stats_time_get(ws));
@@ -871,6 +873,7 @@ radeon_winsys_bo_create(struct radeon_winsys *rws,
unsigned size,
unsigned alignment,
boolean use_reusable_pool,
+boolean high_prio,
enum radeon_bo_domain domain)
{
struct radeon_drm_winsys *ws = radeon_drm_winsys(rws);
@@ -885,6 +888,7 @@ radeon_winsys_bo_create(struct radeon_winsys *rws,
/* Additional criteria for the cache manager. */
desc.base.usage = domain;
desc.initial_domains = domain;
+desc.high_prio = high_prio;
/* Assign a buffer manager. */
if (use_reusable_pool)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
index 651694b..e93e615 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
@@ -42,6 +42,7 @@ struct radeon_bo_desc {
struct pb_desc base;
unsigned initial_domains;
+bool high_prio;
};
struct radeon_bo_stats {
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index f78b6cc..e18deb0 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -652,7 +652,7 @@ radeon_cs_create_fence(struct radeon_winsys_cs *rcs)
struct pb_buffer *fence;
/* Create a fence, which is a dummy BO. */
-fence = cs->ws->base.buffer_create(&cs->ws->base, 1, 1, TRUE,
+fence = cs->
[Mesa-dev] [PATCH 2/4] radeon: Add bo statistics dumping support
No measurable overhead when off (glxgears within 0.5%).
v2: Cosmetic changes.
Signed-off-by: Lauri Kasanen
---
src/gallium/drivers/radeon/r600_pipe_common.c | 32 +++
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 17 ++
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 9
src/gallium/winsys/radeon/drm/radeon_winsys.h | 6 +
5 files changed, 65 insertions(+)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 28921be..f649b9f 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -26,11 +26,18 @@
#include "r600_pipe_common.h"
#include "r600_cs.h"
+#include "../../winsys/radeon/drm/radeon_drm_winsys.h"
+#include "os/os_time.h"
#include "tgsi/tgsi_parse.h"
#include "util/u_format_s3tc.h"
#include "util/u_upload_mgr.h"
#include
+#ifdef __GLIBC__
+#define _GNU_SOURCE
+#include
+#endif
+
static const struct debug_named_value common_debug_options[] = {
/* logging */
{ "tex", DBG_TEX, "Print texture info" },
@@ -38,6 +45,7 @@ static const struct debug_named_value common_debug_options[]
= {
{ "compute", DBG_COMPUTE, "Print compute info" },
{ "vm", DBG_VM, "Print virtual addresses when creating resources" },
{ "trace_cs", DBG_TRACE_CS, "Trace cs and write rlockup_.c file
with faulty cs" },
+ { "bostats", DBG_BO_STATS, "Write bo statistics to
/tmp/bostats.[.name]" },
/* shaders */
{ "fs", DBG_FS, "Print fetch shaders" },
@@ -209,6 +217,24 @@ bool r600_common_screen_init(struct r600_common_screen
*rscreen,
return false;
}
+ if (rscreen->debug_flags & DBG_BO_STATS) {
+ char statsfile[80];
+ const pid_t pid = getpid();
+
+#ifdef __GLIBC__
+ snprintf(statsfile, 80, "/tmp/bostats.%u.%s", pid,
program_invocation_short_name);
+#else
+ snprintf(statsfile, 80, "/tmp/bostats.%u", pid);
+#endif
+
+ rscreen->ws->bo_stats_file = fopen(statsfile, "w");
+ if (!rscreen->ws->bo_stats_file)
+ fprintf(stderr, "Failed to open bo stats file %s\n",
statsfile);
+ else
+ fprintf(rscreen->ws->bo_stats_file, "started @%llu\n",
+ stats_time_get(ws));
+ }
+
util_format_s3tc_init();
pipe_mutex_init(rscreen->aux_context_lock);
@@ -217,6 +243,12 @@ bool r600_common_screen_init(struct r600_common_screen
*rscreen,
void r600_common_screen_cleanup(struct r600_common_screen *rscreen)
{
+ if ((rscreen->debug_flags & DBG_BO_STATS) &&
rscreen->ws->bo_stats_file) {
+ fflush(rscreen->ws->bo_stats_file);
+ fclose(rscreen->ws->bo_stats_file);
+ rscreen->ws->bo_stats_file = NULL;
+ }
+
pipe_mutex_destroy(rscreen->aux_context_lock);
rscreen->aux_context->destroy(rscreen->aux_context);
}
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index bf0b968..4c35e66 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -67,6 +67,7 @@
#define DBG_COMPUTE(1 << 2)
#define DBG_VM (1 << 3)
#define DBG_TRACE_CS (1 << 4)
+#define DBG_BO_STATS (1 << 5)
/* shaders */
#define DBG_FS (1 << 8)
#define DBG_VS (1 << 9)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index ca569a1..7543840 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -370,6 +370,7 @@ static void radeon_bo_destroy(struct pb_buffer *_buf)
{
struct radeon_bo *bo = radeon_bo(_buf);
struct radeon_bomgr *mgr = bo->mgr;
+struct radeon_winsys *ws = (struct radeon_winsys *) mgr->rws;
struct drm_gem_close args;
memset(&args, 0, sizeof(args));
@@ -399,6 +400,11 @@ static void radeon_bo_destroy(struct pb_buffer *_buf)
bo->rws->allocated_vram -= align(bo->base.size, 4096);
else if (bo->initial_domain & RADEON_DOMAIN_GTT)
bo->rws->allocated_gtt -= align(bo->base.size, 4096);
+
+if (ws->bo_stats_file) {
+fprintf(ws->bo_stats_file, "%p destroyed @%llu\n", bo,
stats_time_get(ws));
+}
+
FREE(bo);
}
@@ -450,6 +456,7 @@ static void *radeon_bo_map(struct radeon_winsys_cs_handle
*buf,
{
struct radeon_bo *bo = (struct radeon_bo*)buf;
struct radeon_drm_cs *cs = (struct radeon_drm_cs*)rcs;
+struct radeon_winsys *ws = (struct radeon_winsys *) bo->mgr->rws;
/* If it's not unsynchronized bo_map, flush CS if needed and then wait. */
if (!(usage & PIPE_TRANSFER_UNSYNCHRONIZED)) {
@@ -518,6 +525,10 @@ static void
[Mesa-dev] [PATCH 3/4] winsys/radeon: Keep bo statistics
These will be used later on for optimizing the VRAM placement.
No measurable overhead (glxgears).
Signed-off-by: Lauri Kasanen
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 3 +++
src/gallium/winsys/radeon/drm/radeon_drm_bo.h | 16
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 8
3 files changed, 27 insertions(+)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 7543840..9aa1a0f 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -529,6 +529,9 @@ static void *radeon_bo_map(struct radeon_winsys_cs_handle
*buf,
fprintf(ws->bo_stats_file, "%p cpu mapped @%llu\n", bo,
stats_time_get(ws));
}
+bo->stats.num_cpu_ops++;
+bo->stats.last_cpu_time = stats_time_get(ws);
+
return radeon_bo_do_map(bo);
}
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
index 5536bc1..651694b 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
@@ -44,6 +44,20 @@ struct radeon_bo_desc {
unsigned initial_domains;
};
+struct radeon_bo_stats {
+uint64_t num_reads;
+uint64_t num_writes;
+uint64_t num_cpu_ops;
+
+/* Milliseconds in a monotonic clock */
+uint64_t last_read_time;
+uint64_t last_write_time;
+uint64_t last_cpu_time;
+
+/* Depth, MSAA, etc. */
+bool high_prio;
+};
+
struct radeon_bo {
struct pb_buffer base;
@@ -67,6 +81,8 @@ struct radeon_bo {
boolean flinked;
uint32_t flink;
+
+struct radeon_bo_stats stats;
};
struct pb_manager *radeon_bomgr_create(struct radeon_drm_winsys *rws);
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index 4d46e85..f78b6cc 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -361,6 +361,14 @@ static unsigned radeon_drm_cs_add_reloc(struct
radeon_winsys_cs *rcs,
}
}
+if (usage & RADEON_USAGE_WRITE) {
+bo->stats.num_writes++;
+bo->stats.last_write_time = stats_time_get(ws);
+} else {
+bo->stats.num_reads++;
+bo->stats.last_read_time = stats_time_get(ws);
+}
+
return index;
}
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] winsys/radeon: Add a millisecond time function
v2: Move to a timing thread to minimize overhead.
Signed-off-by: Lauri Kasanen
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 25 +++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.h | 12 +++
2 files changed, 37 insertions(+)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 1860810..ee8ca1c 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -432,6 +432,9 @@ static void radeon_winsys_destroy(struct radeon_winsys *rws)
}
pipe_semaphore_destroy(&ws->cs_queued);
+ws->kill_timing_thread = 1;
+pipe_thread_wait(ws->timing_thread);
+
pipe_mutex_destroy(ws->hyperz_owner_mutex);
pipe_mutex_destroy(ws->cmask_owner_mutex);
pipe_mutex_destroy(ws->cs_stack_lock);
@@ -586,6 +589,22 @@ static PIPE_THREAD_ROUTINE(radeon_drm_cs_emit_ioctl, param)
return NULL;
}
+static PIPE_THREAD_ROUTINE(radeon_drm_timing_thread, param)
+{
+struct radeon_drm_winsys *ws = (struct radeon_drm_winsys *) param;
+uint64_t * const time = &ws->time;
+
+while (!ws->kill_timing_thread) {
+uint64_t tmp = os_time_get_nano() / 100;
+p_atomic_set(time, tmp);
+
+/* We want ms accuracy, so sleep for the Nyquist freq - 0.5ms */
+usleep(500);
+}
+
+return NULL;
+}
+
DEBUG_GET_ONCE_BOOL_OPTION(thread, "RADEON_THREAD", TRUE)
static PIPE_THREAD_ROUTINE(radeon_drm_cs_emit_ioctl, param);
@@ -650,6 +669,12 @@ PUBLIC struct radeon_winsys *radeon_drm_winsys_create(int
fd)
if (ws->num_cpus > 1 && debug_get_option_thread())
ws->thread = pipe_thread_create(radeon_drm_cs_emit_ioctl, ws);
+/* Set the time once to avoid races - stats_time_get may be called
+ * just after this function returns.
+ */
+ws->time = os_time_get_nano() / 100;
+ws->timing_thread = pipe_thread_create(radeon_drm_timing_thread, ws);
+
return &ws->base;
fail:
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
index ed90194..a98d6be 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
@@ -32,6 +32,7 @@
#include "radeon_winsys.h"
#include "os/os_thread.h"
+#include "os/os_time.h"
struct radeon_drm_cs;
@@ -71,6 +72,11 @@ struct radeon_drm_winsys {
int kill_thread;
int ncs;
struct radeon_drm_cs *cs_stack[RING_LAST];
+
+/* Timing thread for the stats. */
+pipe_thread timing_thread;
+int kill_timing_thread;
+uint64_t time;
};
static INLINE struct radeon_drm_winsys *
@@ -79,6 +85,12 @@ radeon_drm_winsys(struct radeon_winsys *base)
return (struct radeon_drm_winsys*)base;
}
+static INLINE unsigned long long stats_time_get(struct radeon_winsys * const
ws) {
+const struct radeon_drm_winsys * const dws = radeon_drm_winsys(ws);
+
+return p_atomic_read(&dws->time);
+}
+
void radeon_drm_ws_queue_cs(struct radeon_drm_winsys *ws, struct radeon_drm_cs
*cs);
#endif
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/5] r300g/compiler/tests: Remove an unused variable
On Sun, 5 Jan 2014 18:51:18 -0800 Tom Stellard wrote: > struct rc_test_file test_file; > + struct rc_instruction *inst; > unsigned optimizations = 1; > unsigned do_full_regalloc = 1; > - struct rc_instruction *inst; > unsigned pass = 1; This doesn't do what the title says. - Lauri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 72877] Wrong colors with Mesa 9.2 and Mesa 10.0 on PPC Linux systems
https://bugs.freedesktop.org/show_bug.cgi?id=72877 --- Comment #4 from Michel Dänzer --- (In reply to comment #3) > Is the bug fixed? Not yet. To fix it, the r600g driver needs to be adapted to changes in the way the Gallium3D infrastructure deals with big endian hosts. -- 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 1/2] radeonsi: disable HTILE for 1D-tiled depth-stencil buffers
This series is Reviewed-by: Michel Dänzer -- 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] gallium endianness and hw drivers
On Fre, 2013-12-27 at 19:41 +0100, Marek Olšák wrote: > Okay. Using Axxx for transfers only is a good idea, just please make > sure the formats are not advertised to the state tracker. Advertising the format to the state tracker is the whole point :), as it's the format that matches the X11 semantics on big endian hosts. -- 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] [PATCH] mesa: Use get_local_param_pointer in glProgramLocalParameters4fvEXT().
Le dimanche 5 janvier 2014, 20:10:17 Kenneth Graunke a écrit : > Using the get_local_param_pointer helper ensures that the LocalParams > arrays have actually been allocated before attempting to use them. > > glProgramLocalParameters4fvEXT needs to do a bit of extra checking, > but it can be simplified since the helper has already validated the > target. > > Fixes crashes in programs that use Cg (such as Awesomenauts) since > commit e5885c119de1e508099cce1c9f8ff00fab88 (mesa: Dynamically > allocate the storage for program local parameters.). > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73136 > Signed-off-by: Kenneth Graunke > Cc: Eric Anholt This fixes al least "Tiny and Big: Granpa's Leftover" and "Rocketbirds: Hardboiled Chicken" games here. -- Laurent Carlier ArchLinux Developer http://www.archlinux.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
