[Mesa-dev] [PATCH] nouveau/codegen: add missing values for OP_TXLQ into the target arrays
Also rework things so that if someone were to add an opcode without
adjusting the values in these arrays, there will be a compilation error.
This fixes a few quadop-related piglit regressions since commit
d5faf8e78603.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp | 12 +++-
src/gallium/drivers/nouveau/codegen/nv50_ir_target.h | 4 ++--
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
index 112fca7..53c3c3e 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
@@ -25,7 +25,7 @@
namespace nv50_ir {
-const uint8_t Target::operationSrcNr[OP_LAST + 1] =
+const uint8_t Target::operationSrcNr[] =
{
0, 0, // NOP, PHI
0, 0, 0, 0, // UNION, SPLIT, MERGE, CONSTRAINT
@@ -44,7 +44,7 @@ const uint8_t Target::operationSrcNr[OP_LAST + 1] =
1, 1, 2, 1, 2, // VFETCH, PFETCH, EXPORT, LINTERP, PINTERP
1, 1, // EMIT, RESTART
1, 1, 1,// TEX, TXB, TXL,
- 1, 1, 1, 1, 1, 2, // TXF, TXQ, TXD, TXG, TEXCSAA, TEXPREP
+ 1, 1, 1, 1, 1, 1, 2,// TXF, TXQ, TXD, TXG, TXLQ, TEXCSAA, TEXPREP
1, 1, 2, 2, 2, 2, 2,// SULDB, SULDP, SUSTB, SUSTP, SUREDB, SUREDP, SULEA
3, 3, 3, 3, // SUBFM, SUCLAMP, SUEAU, MADSP
0, // TEXBAR
@@ -57,7 +57,7 @@ const uint8_t Target::operationSrcNr[OP_LAST + 1] =
0
};
-const OpClass Target::operationClass[OP_LAST + 1] =
+const OpClass Target::operationClass[] =
{
// NOP; PHI; UNION, SPLIT, MERGE, CONSTRAINT
OPCLASS_OTHER,
@@ -101,10 +101,10 @@ const OpClass Target::operationClass[OP_LAST + 1] =
OPCLASS_SFU, OPCLASS_SFU,
// EMIT, RESTART
OPCLASS_CONTROL, OPCLASS_CONTROL,
- // TEX, TXB, TXL, TXF; TXQ, TXD, TXG, TEXCSAA; TEXPREP
+ // TEX, TXB, TXL, TXF; TXQ, TXD, TXG, TXLQ; TEXCSAA, TEXPREP
OPCLASS_TEXTURE, OPCLASS_TEXTURE, OPCLASS_TEXTURE, OPCLASS_TEXTURE,
OPCLASS_TEXTURE, OPCLASS_TEXTURE, OPCLASS_TEXTURE, OPCLASS_TEXTURE,
- OPCLASS_TEXTURE,
+ OPCLASS_TEXTURE, OPCLASS_TEXTURE,
// SULDB, SULDP, SUSTB, SUSTP; SUREDB, SUREDP, SULEA
OPCLASS_SURFACE, OPCLASS_SURFACE, OPCLASS_ATOMIC, OPCLASS_SURFACE,
OPCLASS_SURFACE, OPCLASS_SURFACE, OPCLASS_SURFACE,
@@ -134,6 +134,8 @@ extern Target *getTargetNV50(unsigned int chipset);
Target *Target::create(unsigned int chipset)
{
+ STATIC_ASSERT(Elements(operationSrcNr) == OP_LAST + 1);
+ STATIC_ASSERT(Elements(operationClass) == OP_LAST + 1);
switch (chipset & ~0xf) {
case 0xc0:
case 0xd0:
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.h
index 9913ca1..9eb0a1f 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.h
@@ -195,8 +195,8 @@ public:
const bool joinAnterior; // true if join is executed before the op
const bool hasSWSched; // true if code should provide scheduling data
- static const uint8_t operationSrcNr[OP_LAST + 1];
- static const OpClass operationClass[OP_LAST + 1];
+ static const uint8_t operationSrcNr[];
+ static const OpClass operationClass[];
static inline uint8_t getOpSrcNr(operation op)
{
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 68296] Using old viewport value after a window resize (content is clipped)
https://bugs.freedesktop.org/show_bug.cgi?id=68296 Kenneth Graunke changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #10 from Kenneth Graunke --- This seems to work fine for me with the latest Mesa. Feel free to reopen if this is still a problem for you. -- 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 72281] [bisected] Eufloria HD crash on start
https://bugs.freedesktop.org/show_bug.cgi?id=72281 Kenneth Graunke changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Kenneth Graunke --- Eufloria HD works for me. Presumably this was fixed by: commit 05fbb021a6329add4b37c876c0621c1dcc3d4ef9 Author: Kenneth Graunke Date: Sun Jan 5 20:03:00 2014 -0800 mesa: Use get_local_param_pointer in glProgramLocalParameters4fvEXT(). 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 (for example, Awesomenauts, Rocketbirds: Hardboiled Chicken, and Tiny and Big: Grandpa's Leftovers) 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 Reviewed-by: Brian Paul Tested-by: Laurent Carlier -- 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 5/6] i965/fs: Give up in interference check if we see a WHILE.
On 04/16/2014 11:07 AM, Matt Turner wrote:
> Rather than any old control flow. Muchnick's algorithm just checks for
> interfering writes between the MOV and the end of the program. Handling
> this when you have backward branches is hard, so don't, but there's no
> reason to bail if you see forward branches.
>
> instructions in affected programs: 4270 -> 4248 (-0.52%)
> ---
> src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> index 58f6ca7..ca7a6a8 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> @@ -98,7 +98,7 @@ can_coalesce_vars(brw::fs_live_variables *live_intervals,
> for (scan_inst = (fs_inst *)inst->next;
> scan_inst->next != NULL && ip <= live_intervals->end[var_to];
> scan_inst = (fs_inst *)scan_inst->next, ip++) {
> - if (scan_inst->is_control_flow())
> + if (scan_inst->opcode == BRW_OPCODE_WHILE)
> return false;
>
>if (scan_inst->dst.equals(inst->dst) ||
>
Patches 5-6 are:
Reviewed-by: Kenneth Graunke
I also tested L4D2 (or, at least an apitrace of it), and it continues to
work fine.
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] i965/fs: Simplify interference scan in register coalescing.
On 04/16/2014 11:07 AM, Matt Turner wrote:
> We were starting at the beginning of the instruction list, rather than
> with the MOV instruction itself. This allows us to coalesce after
> control flow.
>
> Excluding the shaders from an unreleased title, the shader-db results:
>
> total instructions in shared programs: 1603791 -> 1594215 (-0.60%)
> instructions in affected programs: 678772 -> 669196 (-1.41%)
> GAINED:5
> LOST: 0
> ---
> .../drivers/dri/i965/brw_fs_register_coalesce.cpp | 22
> +-
> 1 file changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> index 5836fb7..58f6ca7 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> @@ -73,7 +73,7 @@ is_coalesce_candidate(const fs_inst *inst, const int
> *virtual_grf_sizes)
>
> static bool
> can_coalesce_vars(brw::fs_live_variables *live_intervals,
> - const exec_list *instructions, const fs_inst *inst,
> + const exec_list *instructions, const fs_inst *inst, int ip,
>int var_to, int var_from)
> {
> if (!live_intervals->vars_interfere(var_from, var_to))
> @@ -92,21 +92,15 @@ can_coalesce_vars(brw::fs_live_variables *live_intervals,
> if (live_intervals->end[var_to] > live_intervals->end[var_from])
>return false;
>
> - int scan_ip = -1;
> -
> - foreach_list(n, instructions) {
> - fs_inst *scan_inst = (fs_inst *)n;
> - scan_ip++;
> + assert(ip >= live_intervals->start[var_to]);
>
> + fs_inst *scan_inst;
> + for (scan_inst = (fs_inst *)inst->next;
> +scan_inst->next != NULL && ip <= live_intervals->end[var_to];
This doesn't seem quite right to me. The last instruction in the list
will have scan_inst->next == the tail sentinel (so, ->next->next ==
NULL). I think you want:
!scan_inst->is_tail_sentinel() && ip <= live_intervals->end[var_to];
With that changed (or my logic rebuffed), this is:
Reviewed-by: Kenneth Graunke
> +scan_inst = (fs_inst *)scan_inst->next, ip++) {
>if (scan_inst->is_control_flow())
> return false;
>
> - if (scan_ip <= live_intervals->start[var_to])
> - continue;
> -
> - if (scan_ip > live_intervals->end[var_to])
> - break;
> -
>if (scan_inst->dst.equals(inst->dst) ||
>scan_inst->dst.equals(inst->src[0]))
> return false;
> @@ -129,9 +123,11 @@ fs_visitor::register_coalesce()
> fs_inst *mov[MAX_SAMPLER_MESSAGE_SIZE];
> int var_to[MAX_SAMPLER_MESSAGE_SIZE];
> int var_from[MAX_SAMPLER_MESSAGE_SIZE];
> + int ip = -1;
>
> foreach_list(node, &this->instructions) {
>fs_inst *inst = (fs_inst *)node;
> + ip++;
>
>if (!is_coalesce_candidate(inst, virtual_grf_sizes))
> continue;
> @@ -170,7 +166,7 @@ fs_visitor::register_coalesce()
> var_to[i] = live_intervals->var_from_vgrf[reg_to] +
> reg_to_offset[i];
> var_from[i] = live_intervals->var_from_vgrf[reg_from] + i;
>
> - if (!can_coalesce_vars(live_intervals, &instructions, inst,
> + if (!can_coalesce_vars(live_intervals, &instructions, inst, ip,
> var_to[i], var_from[i])) {
> can_coalesce = false;
> reg_from = -1;
>
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nv50: use 2d blit when src/dst have same number of samples
The 2D engine should be usable in more cases, but this fixes MS blits
between textures with the same MS settings. Otherwise a single sample is
selected to be the target texel value.
This allows other tests to work that render to a RB and then blit that
to a texture for input into a shader that uses sampler2DMS to verify it.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_surface.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
index c28abe0..9a3548a 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
@@ -1299,8 +1299,8 @@ nv50_blit_eng2d(struct nv50_context *nv50, const struct
pipe_blit_info *info)
if (src->base.base.nr_samples > dst->base.base.nr_samples) {
/* center src coorinates for proper MS resolve filtering */
- srcx += (int64_t)src->ms_x << 32;
- srcy += (int64_t)src->ms_y << 32;
+ srcx += (int64_t)1 << (src->ms_x + 31);
+ srcy += (int64_t)1 << (src->ms_y + 31);
}
dstx = info->dst.box.x << dst->ms_x;
@@ -1438,8 +1438,8 @@ nv50_blit(struct pipe_context *pipe, const struct
pipe_blit_info *info)
eng3d = TRUE;
/* FIXME: can't make this work with eng2d anymore */
- if (info->src.resource->nr_samples > 1 ||
- info->dst.resource->nr_samples > 1)
+ if ((info->src.resource->nr_samples | 1) !=
+ (info->dst.resource->nr_samples | 1))
eng3d = TRUE;
/* FIXME: find correct src coordinate adjustments */
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77582] [r600g] ogl-samples GL3.2 and GL3.3 tests doesn't run without overriding GL/GLSL version
https://bugs.freedesktop.org/show_bug.cgi?id=77582 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Mesa core --- Comment #1 from Michel Dänzer --- Mesa will probably never support higher than OpenGL 3.0 for the compatibility profile. Apps should use the core profile for higher versions. -- 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 77589] [r600g] Source engine game stopped working (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=77589 Michel Dänzer changed: What|Removed |Added CC||mar...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/fs: Implement fs_inst::force_sechalf support on Broadwell.
Back when I originally wrote this code, force_sechalf was only used for
Gen4 code, so I didn't bother hooking it up. However, it's used more
generally these days. In particular, we use it for computing
gl_SamplePosition.
Fixes Piglit's spec/ARB_sample_shading/builtin-gl-sample-position tests.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 10 ++
src/mesa/drivers/dri/i965/gen8_generator.cpp| 1 +
src/mesa/drivers/dri/i965/gen8_generator.h | 1 +
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
index ef95eb0..7fb81c7 100644
--- a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
@@ -927,10 +927,12 @@ gen8_fs_generator::generate_code(exec_list *instructions)
else
default_state.exec_size = BRW_EXECUTE_8;
- /* fs_inst::force_sechalf is only used for original Gen4 code, so we
- * don't handle it. Add qtr_control to default_state if that changes.
- */
- assert(!ir->force_sechalf);
+ if (ir->force_uncompressed || dispatch_width == 8)
+ default_state.qtr_control = GEN6_COMPRESSION_1Q;
+ else if (ir->force_sechalf)
+ default_state.qtr_control = GEN6_COMPRESSION_2Q;
+ else
+ default_state.qtr_control = GEN6_COMPRESSION_1H;
switch (ir->opcode) {
case BRW_OPCODE_MOV:
diff --git a/src/mesa/drivers/dri/i965/gen8_generator.cpp
b/src/mesa/drivers/dri/i965/gen8_generator.cpp
index b082008..dd434a7 100644
--- a/src/mesa/drivers/dri/i965/gen8_generator.cpp
+++ b/src/mesa/drivers/dri/i965/gen8_generator.cpp
@@ -87,6 +87,7 @@ gen8_generator::next_inst(unsigned opcode)
gen8_set_exec_size(inst, default_state.exec_size);
gen8_set_access_mode(inst, default_state.access_mode);
gen8_set_mask_control(inst, default_state.mask_control);
+ gen8_set_qtr_control(inst, default_state.qtr_control);
gen8_set_cond_modifier(inst, default_state.conditional_mod);
gen8_set_pred_control(inst, default_state.predicate);
gen8_set_pred_inv(inst, default_state.predicate_inverse);
diff --git a/src/mesa/drivers/dri/i965/gen8_generator.h
b/src/mesa/drivers/dri/i965/gen8_generator.h
index 1f4b7f8..b144809 100644
--- a/src/mesa/drivers/dri/i965/gen8_generator.h
+++ b/src/mesa/drivers/dri/i965/gen8_generator.h
@@ -186,6 +186,7 @@ protected:
unsigned exec_size;
unsigned access_mode;
unsigned mask_control;
+ unsigned qtr_control;
unsigned flag_subreg_nr;
unsigned conditional_mod;
unsigned predicate;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Heavy ioq3 regression in mesa (r600g/cayman/aruba)
Hi Lauri, I tested with both commit but cannot seeing something relevant, I got 60 FPS in both case. I tested with the Tremulous 1.1 test case from Phoronix Test Suite 4.8.6 (from Fedora 19 repo). The command used (for both commit) was: $ vblank_mode=0 R600_DEBUG=nohyperz phoronix-test-suite Test pts/tremulous I have a Radeon HD5850 (with 1 GB VRAM). Any idea to try to spot your issue? (decrease VRAM size?) Regards. Benjamin Le 15/04/2014 09:35, Lauri Kasanen a écrit : > Hi, > > Tremulous and Smoking Guns regressed in Mesa master, ok in 020c43f, > broken in 4ddf51db. > > Tremulous 133 to 33 fps, Smoking Guns 153 to 40. In the ok version, > hyperz was enabled by default; in the more recent master, it was > disabled by default, but enabled via the R600_DEBUG env var. The env > var applied correctly, because other games' perf reacted to it. > > This is a week old master, so it might be fixed already; just in case > it's not, I thought I'd report this, as a release is about to be > branched. Wouldn't do to have 4x regressions in a release ;) > > Anyway, that's a fairly wide area to bisect, and I'm busy with other > things, so just this email instead of a bug and a bisect. > > - Lauri > ___ > 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 1/2] i965/fs: Don't use brw_imm_* unnecessarily.
On 04/17/2014 04:04 PM, Matt Turner wrote: > Using brw_imm_* creates a source with file=HW_REG, and the scheduler > inserts barrier dependencies when it sees HW_REG. None of these are > hardware-registers in the sense that they're special and scheduling > shouldn't touch them. A few of the modified cases already have HW_REGs > for other sources, so it won't allow extra flexibility in some cases. > --- > src/mesa/drivers/dri/i965/brw_fs.cpp | 4 ++-- > src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 +++--- > 2 files changed, 5 insertions(+), 5 deletions(-) Both patches are: Reviewed-by: Kenneth Graunke I do think we should mark the fs_reg(struct brw_reg) constructor 'explicit' to avoid this problem from creeping in again. There are other cases that don't consider HW_REG && fixed_hw_reg.file == IMM, so we really want to avoid doing that and just use IMM properly. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] gallium: Add PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY
From: Tom Stellard --- src/gallium/include/pipe/p_defines.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/include/pipe/p_defines.h b/src/gallium/include/pipe/p_defines.h index a3a1ae1..93f9642 100644 --- a/src/gallium/include/pipe/p_defines.h +++ b/src/gallium/include/pipe/p_defines.h @@ -641,7 +641,8 @@ enum pipe_compute_cap PIPE_COMPUTE_CAP_MAX_LOCAL_SIZE, PIPE_COMPUTE_CAP_MAX_PRIVATE_SIZE, PIPE_COMPUTE_CAP_MAX_INPUT_SIZE, - PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE + PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE, + PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY, }; /** -- 1.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] radeon/compute: Implement PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY
From: Tom Stellard
v2: in define RADEON_INFO_MAX_SCLK use 0x1a instead of 0x19 (upstream changes)
Signed-off-by: Igor Gnatenko
r600: Correct the case MAX_CLOCK_FREQUENCY in get_compute_param
---
src/gallium/drivers/radeon/r600_pipe_common.c | 7 +++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 3 +++
src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
3 files changed, 11 insertions(+)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 7508865..957186a 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -505,6 +505,13 @@ static int r600_get_compute_param(struct pipe_screen
*screen,
}
return sizeof(uint64_t);
+ case PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY:
+ if (ret) {
+ uint32_t *max_clock_frequency = ret;
+ *max_clock_frequency = rscreen->info.max_sclk;
+ }
+ return sizeof(uint32_t);
+
default:
fprintf(stderr, "unknown PIPE_COMPUTE_CAP %d\n", param);
return 0;
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 0eb0c6a..a7f0d9e 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -316,6 +316,9 @@ static boolean do_winsys_init(struct radeon_drm_winsys *ws)
ws->info.gart_size = gem_info.gart_size;
ws->info.vram_size = gem_info.vram_size;
+radeon_get_drm_value(ws->fd, RADEON_INFO_MAX_SCLK, NULL,
+ &ws->info.max_sclk);
+
ws->num_cpus = sysconf(_SC_NPROCESSORS_ONLN);
/* Generation-specific queries. */
diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h
b/src/gallium/winsys/radeon/drm/radeon_winsys.h
index fe0617b..1cb17bb 100644
--- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
@@ -196,6 +196,7 @@ struct radeon_info {
enum chip_class chip_class;
uint32_tgart_size;
uint32_tvram_size;
+uint32_tmax_sclk;
uint32_tdrm_major; /* version */
uint32_tdrm_minor;
--
1.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] clover: Query drivers for max clock frequency
From: Tom Stellard
v2: PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY instead of
PIPE_COMPUTE_MAX_CLOCK_FREQUENCY
Signed-off-by: Igor Gnatenko
clover: Correct the returned value for max_clock_frequency
According to OpenCL 1.1 spec, the returned value must be in MHz, and we
were returning it in kHz
---
src/gallium/state_trackers/clover/api/device.cpp | 2 +-
src/gallium/state_trackers/clover/core/device.cpp | 6 ++
src/gallium/state_trackers/clover/core/device.hpp | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/api/device.cpp
b/src/gallium/state_trackers/clover/api/device.cpp
index 7bc8d0a..f980845 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -122,7 +122,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
break;
case CL_DEVICE_MAX_CLOCK_FREQUENCY:
- buf.as_scalar() = 0;
+ buf.as_scalar() = dev.max_clock_frequency();
break;
case CL_DEVICE_ADDRESS_BITS:
diff --git a/src/gallium/state_trackers/clover/core/device.cpp
b/src/gallium/state_trackers/clover/core/device.cpp
index 2c5f9b7..4ae575f 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -154,6 +154,12 @@ device::max_mem_alloc_size() const {
PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE)[0];
}
+cl_uint
+device::max_clock_frequency() const {
+ return get_compute_param(pipe,
+ PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY)[0]
/ 1000;
+}
+
std::vector
device::max_block_size() const {
auto v = get_compute_param(pipe, PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE);
diff --git a/src/gallium/state_trackers/clover/core/device.hpp
b/src/gallium/state_trackers/clover/core/device.hpp
index 433ac81..3662c6b 100644
--- a/src/gallium/state_trackers/clover/core/device.hpp
+++ b/src/gallium/state_trackers/clover/core/device.hpp
@@ -61,6 +61,7 @@ namespace clover {
cl_uint max_const_buffers() const;
size_t max_threads_per_block() const;
cl_ulong max_mem_alloc_size() const;
+ cl_uint max_clock_frequency() const;
std::vector max_block_size() const;
std::string device_name() const;
--
1.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] clover: Add support for quering CL_DEVICE_MAX_CLOCK_FREQUENCY
This series is based in Tom Stellard's 'clover-clock' branch: http://cgit.freedesktop.org/~tstellar/mesa/log/?h=clover-clock And should fix this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=73511 The only changes from the original branch are in patches 2 and 3. Patch 2 has been updated so that it applies to current master. Patch 3 has been updated so that it returns the frequency in MHz, not in kHz. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965: Don't treat HW_REGs as barriers if they're immediates.
We had a handful of cases where we'd used brw_imm_*() to generate an
immediate, rather than fs_reg(). We shouldn't do that but we shouldn't
limit scheduling flexibility on account of immediate arguments either.
---
src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
index 8cc6908..bb0461c 100644
--- a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
+++ b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
@@ -807,7 +807,9 @@ fs_instruction_scheduler::calculate_deps()
add_dep(last_accumulator_write, n);
} else if (inst->src[i].file != BAD_FILE &&
inst->src[i].file != IMM &&
- inst->src[i].file != UNIFORM) {
+ inst->src[i].file != UNIFORM &&
+(inst->src[i].file != HW_REG ||
+ inst->src[i].fixed_hw_reg.file != IMM)) {
assert(inst->src[i].file != MRF);
add_barrier_deps(n);
}
@@ -937,7 +939,9 @@ fs_instruction_scheduler::calculate_deps()
add_dep(n, last_accumulator_write);
} else if (inst->src[i].file != BAD_FILE &&
inst->src[i].file != IMM &&
- inst->src[i].file != UNIFORM) {
+ inst->src[i].file != UNIFORM &&
+(inst->src[i].file != HW_REG ||
+ inst->src[i].fixed_hw_reg.file != IMM)) {
assert(inst->src[i].file != MRF);
add_barrier_deps(n);
}
@@ -1072,7 +1076,9 @@ vec4_instruction_scheduler::calculate_deps()
add_dep(last_accumulator_write, n);
} else if (inst->src[i].file != BAD_FILE &&
inst->src[i].file != IMM &&
-inst->src[i].file != UNIFORM) {
+inst->src[i].file != UNIFORM &&
+(inst->src[i].file != HW_REG ||
+ inst->src[i].fixed_hw_reg.file != IMM)) {
/* No reads from MRF, and ATTR is already translated away */
assert(inst->src[i].file != MRF &&
inst->src[i].file != ATTR);
@@ -1169,7 +1175,9 @@ vec4_instruction_scheduler::calculate_deps()
add_dep(n, last_accumulator_write);
} else if (inst->src[i].file != BAD_FILE &&
inst->src[i].file != IMM &&
-inst->src[i].file != UNIFORM) {
+inst->src[i].file != UNIFORM &&
+(inst->src[i].file != HW_REG ||
+ inst->src[i].fixed_hw_reg.file != IMM)) {
assert(inst->src[i].file != MRF &&
inst->src[i].file != ATTR);
add_barrier_deps(n);
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965/fs: Don't use brw_imm_* unnecessarily.
Using brw_imm_* creates a source with file=HW_REG, and the scheduler
inserts barrier dependencies when it sees HW_REG. None of these are
hardware-registers in the sense that they're special and scheduling
shouldn't touch them. A few of the modified cases already have HW_REGs
for other sources, so it won't allow extra flexibility in some cases.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 4 ++--
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index c550c41..f51376e 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1311,8 +1311,8 @@ fs_visitor::emit_sampleid_setup(ir_variable *ir)
* These computations hold good for 4x multisampling as well.
*/
emit(BRW_OPCODE_AND, t1,
- fs_reg(retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_D)),
- fs_reg(brw_imm_d(0xc0)));
+ fs_reg(retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD)),
+ fs_reg(0xc0));
emit(BRW_OPCODE_SHR, t1, t1, fs_reg(5));
/* This works for both SIMD8 and SIMD16 */
emit(MOV(t2, brw_imm_v(0x3210)));
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 2aa3acd..4ce2993 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1512,7 +1512,7 @@ fs_visitor::rescale_texcoord(ir_texture *ir, fs_reg
coordinate,
fs_reg chan = coordinate;
chan.reg_offset += i;
- inst = emit(BRW_OPCODE_SEL, chan, chan, brw_imm_f(0.0));
+ inst = emit(BRW_OPCODE_SEL, chan, chan, fs_reg(0.0f));
inst->conditional_mod = BRW_CONDITIONAL_G;
/* Our parameter comes in as 1.0/width or 1.0/height,
@@ -2375,7 +2375,7 @@ fs_visitor::emit_untyped_atomic(unsigned atomic_op,
unsigned surf_index,
unsigned mlen = 0;
/* Initialize the sample mask in the message header. */
- emit(MOV(brw_uvec_mrf(8, mlen, 0), brw_imm_ud(0)))
+ emit(MOV(brw_uvec_mrf(8, mlen, 0), fs_reg(0u)))
->force_writemask_all = true;
if (fp->UsesKill) {
@@ -2420,7 +2420,7 @@ fs_visitor::emit_untyped_surface_read(unsigned
surf_index, fs_reg dst,
unsigned mlen = 0;
/* Initialize the sample mask in the message header. */
- emit(MOV(brw_uvec_mrf(8, mlen, 0), brw_imm_ud(0)))
+ emit(MOV(brw_uvec_mrf(8, mlen, 0), fs_reg(0u)))
->force_writemask_all = true;
if (fp->UsesKill) {
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77589] [r600g] Source engine game stopped working (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=77589 --- Comment #4 from Kertesz Laszlo --- Can reproduce on Radeon HD 8570D (IGP from A8-6500), r600g. I tried L4D2, Day of defeat and No More Room in Hell, all did the same - one cpu @100%, black screen and just hang there. Nothing in the Steam console. -- 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 2/2] llvmpipe: fix clearing of individual color buffers in a fb
From: Roland Scheidegger
GL (3.0) allows you to clear individual color buffers in a fb. In fact
for fbs containing both int and float/normalized color buffers this is
required (because the clearing values are otherwise undefined if applied
to all buffers). The gallium interface was changed a while ago, but llvmpipe
ignored it (hence doing such individual clears always resulted in clearing
all buffers, plus some assorted asserts due to the mixed fbs).
So change the clear command to indicate the buffer to be cleared. Also, because
indicating the buffer to be cleared would have made lp_rast_arg_cmd larger
which is unacceptable (we're trying to shrink it some day) allocate the clear
value in the scene and just pass a pointer.
There's several advantages and disadvantages here:
+ clearing individual buffers works (we could also actually bin such clears now
if they'd come through clear_render_target() if the surface is in the current
fb, though we didn't do this before for the single rb case and still don't try).
+ since there's one clear per rb, we do the format conversion in setup rather
than per bin. Aside from the (drop in the ocean...) performance advantage this
means that clearing to very small values (that is, denormal when converted to
the format) should work for small float (fp16 etc.) formats, as the util code
couldn't handle it correctly before (because cpu denorms are disabled when
executing the bin commands, screwing up the magic conversion and flushing
the values to 0, though this was not verified).
- there's some overhead for traditional old-style clear-all MRT cases, since
there's one rast clear command per rb instead of one for all rbs.
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=76976.
---
src/gallium/drivers/llvmpipe/lp_rast.c | 122 -
src/gallium/drivers/llvmpipe/lp_rast.h |8 +-
src/gallium/drivers/llvmpipe/lp_scene.c |1 -
src/gallium/drivers/llvmpipe/lp_scene.h |1 -
src/gallium/drivers/llvmpipe/lp_setup.c | 216 ---
src/gallium/drivers/llvmpipe/lp_setup_context.h |2 +-
6 files changed, 189 insertions(+), 161 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
b/src/gallium/drivers/llvmpipe/lp_rast.c
index 0ae5976..8667a6c 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -110,25 +110,6 @@ lp_rast_tile_begin(struct lp_rasterizer_task *task,
/**
- * Examine a framebuffer object to determine if any of the colorbuffers
- * use a pure integer format.
- * XXX this could be a gallium utility function if useful elsewhere.
- */
-static boolean
-is_fb_pure_integer(const struct pipe_framebuffer_state *fb)
-{
- unsigned i;
- for (i = 0; i < fb->nr_cbufs; i++) {
- if (fb->cbufs[i] &&
- util_format_is_pure_integer(fb->cbufs[i]->format)) {
- return TRUE;
- }
- }
- return FALSE;
-}
-
-
-/**
* Clear the rasterizer's current color tile.
* This is a bin command called during bin processing.
* Clear commands always clear all bound layers.
@@ -138,81 +119,40 @@ lp_rast_clear_color(struct lp_rasterizer_task *task,
const union lp_rast_cmd_arg arg)
{
const struct lp_scene *scene = task->scene;
+ unsigned cbuf = arg.clear_rb->cbuf;
+ union util_color uc;
+ enum pipe_format format;
- if (scene->fb.nr_cbufs) {
- unsigned i;
- union util_color uc;
-
- if (is_fb_pure_integer(&scene->fb)) {
- /*
- * We expect int/uint clear values here, though some APIs
- * might disagree (but in any case util_pack_color()
- * couldn't handle it)...
- */
- LP_DBG(DEBUG_RAST, "%s pure int 0x%x,0x%x,0x%x,0x%x\n", __FUNCTION__,
-arg.clear_color.ui[0],
-arg.clear_color.ui[1],
-arg.clear_color.ui[2],
-arg.clear_color.ui[3]);
-
- for (i = 0; i < scene->fb.nr_cbufs; i++) {
-enum pipe_format format = scene->fb.cbufs[i]->format;
-
-if (util_format_is_pure_sint(format)) {
- util_format_write_4i(format, arg.clear_color.i, 0, &uc, 0, 0,
0, 1, 1);
-}
-else {
- assert(util_format_is_pure_uint(format));
- util_format_write_4ui(format, arg.clear_color.ui, 0, &uc, 0, 0,
0, 1, 1);
-}
-
-util_fill_box(scene->cbufs[i].map,
- format,
- scene->cbufs[i].stride,
- scene->cbufs[i].layer_stride,
- task->x,
- task->y,
- 0,
- task->width,
- task->height,
- scene->fb_max_layer + 1,
- &uc);
- }
- }
- else {
- uint8_t clear_color[4];
+ /* we never bin clear commands for non-ex
[Mesa-dev] [PATCH 1/2] llvmpipe: (trivial) use correct LP_MIN_VECTOR_ALIGN define for alignment.
From: Roland Scheidegger
Currently it's the same value.
---
src/gallium/drivers/llvmpipe/lp_setup.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
b/src/gallium/drivers/llvmpipe/lp_setup.c
index 848a329..b4ce925 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup.c
@@ -953,7 +953,7 @@ try_update_scene_state( struct lp_setup_context *setup )
/* Alloc u8_blend_color (16 x i8) and f_blend_color (4 or 8 x f32) */
size = 4 * 16 * sizeof(uint8_t);
size += (LP_MAX_VECTOR_LENGTH / 4) * sizeof(float);
- stored = lp_scene_alloc_aligned(scene, size, LP_MAX_VECTOR_LENGTH);
+ stored = lp_scene_alloc_aligned(scene, size, LP_MIN_VECTOR_ALIGN);
if (!stored) {
assert(!new_scene);
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77596] [r600g] random and reproducible crash in Left 4 Dead 2 (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=77596 Benjamin Bellec changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org -- 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 77449] Tracker bug for all bugs related to Steam titles
https://bugs.freedesktop.org/show_bug.cgi?id=77449 Benjamin Bellec changed: What|Removed |Added Depends on||77596 -- 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/6] i965/fs: Recognize nop-MOV instructions early.
On 04/17/2014 02:45 PM, Matt Turner wrote:
> On Thu, Apr 17, 2014 at 2:25 PM, Kenneth Graunke
> wrote:
>> On 04/16/2014 11:07 AM, Matt Turner wrote:
>>> And avoid rewriting other instructions unnecessarily. Removes a few
>>> self-moves we weren't able to handle because they were components of a
>>> large VGRF.
>>>
>>> instructions in affected programs: 830 -> 826 (-0.48%)
>>> ---
>>> src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp | 16
>>> +---
>>> 1 file changed, 13 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
>>> b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
>>> index f6d9b68..8b37ed0 100644
>>> --- a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
>>> +++ b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
>>> @@ -44,6 +44,12 @@
>>> #include "brw_fs_live_variables.h"
>>>
>>> static bool
>>> +is_nop_mov(const fs_inst *inst)
>>> +{
>>> + return inst->dst.equals(inst->src[0]);
>>
>> It feels weird having a function called is_nop_mov that doesn't ensure
>> that inst->opcode == BRW_OPCODE_MOV. I know it's unnecessary, since
>> this function is only called after is_coalesce_candidate(), but...it
>> might be nice to add that check anyway, or maybe a comment or assertion.
>
> Sure, I kind of do that when I add SHADER_OPCODE_LOAD_PAYLOAD in the
> next series. I can do it now if it's important.
I would prefer to see that - it's an easy change, and makes the function
more robust.
>
>>> +}
>>> +
>>> +static bool
>>> is_coalesce_candidate(const fs_inst *inst, const int *virtual_grf_sizes)
>>> {
>>> if (inst->opcode != BRW_OPCODE_MOV ||
>>> @@ -70,9 +76,7 @@ can_coalesce_vars(brw::fs_live_variables *live_intervals,
>>>const exec_list *instructions, const fs_inst *inst,
>>>int var_to, int var_from)
>>> {
>>> - if (live_intervals->vars_interfere(var_from, var_to) &&
>>> - !inst->dst.equals(inst->src[0])) {
>>> -
>>> + if (live_intervals->vars_interfere(var_from, var_to)) {
>>>/* We know that the live ranges of A (var_from) and B (var_to)
>>> * interfere because of the ->vars_interfere() call above. If the end
>>> * of B's live range is after the end of A's range, then we know two
>>> @@ -131,6 +135,12 @@ fs_visitor::register_coalesce()
>>>if (!is_coalesce_candidate(inst, virtual_grf_sizes))
>>> continue;
>>>
>>> + if (is_nop_mov(inst)) {
>>> + inst->opcode = BRW_OPCODE_NOP;
>>> + progress = true;
>>> + continue;
>>> + }
>>
>> Having the can_coalesce_vars function alter the instruction stream also
>> seems strange. What do you think about moving the MOV->NOP code into
>> the caller? It would be outside the vars_interfere path, but I think
>> that's okay...
>
> can_coalesce_vars() doesn't modify the instruction stream?
>
> I'm not sure what you mean, but I'll try to explain. Checking for
> self-moves here, rather than in can_coalesce_vars() allows us to
> remove self-moves of single components of a large VGRF.
>
> mov vgrf4+1, vgrf4+1
>
> for instance isn't handled by the rest of register coalescing if other
> bits of vgrf4+1 can't be coalesced.
>
I'm sorry - I misread the diff. I thought you added this new hunk in
the can_coalesce_vars function, which is a boolean predicate (and
shouldn't actually /change/ things). But you didn't - you put it in
register_coalesce(). What you did makes sense.
Patches 1-3 are:
Reviewed-by: Kenneth Graunke
(with or without changes)
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77589] [r600g] Source engine game stopped working (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=77589 Penith Muncher changed: What|Removed |Added OS|All |Linux (All) -- 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 77589] [r600g] Source engine game stopped working (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=77589 Benjamin Bellec changed: What|Removed |Added Blocks||77449 -- 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 77449] Tracker bug for all bugs related to Steam titles
https://bugs.freedesktop.org/show_bug.cgi?id=77449 Benjamin Bellec changed: What|Removed |Added Depends on||77589 -- 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 77589] [r600g] Source engine game stopped working (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=77589 --- Comment #3 from bs2u...@dispostable.com --- can reproduce on AMD Radeon HD 6570 on r600g -- 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/6] i965/fs: Recognize nop-MOV instructions early.
On Thu, Apr 17, 2014 at 2:25 PM, Kenneth Graunke wrote:
> On 04/16/2014 11:07 AM, Matt Turner wrote:
>> And avoid rewriting other instructions unnecessarily. Removes a few
>> self-moves we weren't able to handle because they were components of a
>> large VGRF.
>>
>> instructions in affected programs: 830 -> 826 (-0.48%)
>> ---
>> src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp | 16 +---
>> 1 file changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
>> index f6d9b68..8b37ed0 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
>> @@ -44,6 +44,12 @@
>> #include "brw_fs_live_variables.h"
>>
>> static bool
>> +is_nop_mov(const fs_inst *inst)
>> +{
>> + return inst->dst.equals(inst->src[0]);
>
> It feels weird having a function called is_nop_mov that doesn't ensure
> that inst->opcode == BRW_OPCODE_MOV. I know it's unnecessary, since
> this function is only called after is_coalesce_candidate(), but...it
> might be nice to add that check anyway, or maybe a comment or assertion.
Sure, I kind of do that when I add SHADER_OPCODE_LOAD_PAYLOAD in the
next series. I can do it now if it's important.
>> +}
>> +
>> +static bool
>> is_coalesce_candidate(const fs_inst *inst, const int *virtual_grf_sizes)
>> {
>> if (inst->opcode != BRW_OPCODE_MOV ||
>> @@ -70,9 +76,7 @@ can_coalesce_vars(brw::fs_live_variables *live_intervals,
>>const exec_list *instructions, const fs_inst *inst,
>>int var_to, int var_from)
>> {
>> - if (live_intervals->vars_interfere(var_from, var_to) &&
>> - !inst->dst.equals(inst->src[0])) {
>> -
>> + if (live_intervals->vars_interfere(var_from, var_to)) {
>>/* We know that the live ranges of A (var_from) and B (var_to)
>> * interfere because of the ->vars_interfere() call above. If the end
>> * of B's live range is after the end of A's range, then we know two
>> @@ -131,6 +135,12 @@ fs_visitor::register_coalesce()
>>if (!is_coalesce_candidate(inst, virtual_grf_sizes))
>> continue;
>>
>> + if (is_nop_mov(inst)) {
>> + inst->opcode = BRW_OPCODE_NOP;
>> + progress = true;
>> + continue;
>> + }
>
> Having the can_coalesce_vars function alter the instruction stream also
> seems strange. What do you think about moving the MOV->NOP code into
> the caller? It would be outside the vars_interfere path, but I think
> that's okay...
can_coalesce_vars() doesn't modify the instruction stream?
I'm not sure what you mean, but I'll try to explain. Checking for
self-moves here, rather than in can_coalesce_vars() allows us to
remove self-moves of single components of a large VGRF.
mov vgrf4+1, vgrf4+1
for instance isn't handled by the rest of register coalescing if other
bits of vgrf4+1 can't be coalesced.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] i965/fs: Recognize nop-MOV instructions early.
On 04/16/2014 11:07 AM, Matt Turner wrote:
> And avoid rewriting other instructions unnecessarily. Removes a few
> self-moves we weren't able to handle because they were components of a
> large VGRF.
>
> instructions in affected programs: 830 -> 826 (-0.48%)
> ---
> src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> index f6d9b68..8b37ed0 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> @@ -44,6 +44,12 @@
> #include "brw_fs_live_variables.h"
>
> static bool
> +is_nop_mov(const fs_inst *inst)
> +{
> + return inst->dst.equals(inst->src[0]);
It feels weird having a function called is_nop_mov that doesn't ensure
that inst->opcode == BRW_OPCODE_MOV. I know it's unnecessary, since
this function is only called after is_coalesce_candidate(), but...it
might be nice to add that check anyway, or maybe a comment or assertion.
> +}
> +
> +static bool
> is_coalesce_candidate(const fs_inst *inst, const int *virtual_grf_sizes)
> {
> if (inst->opcode != BRW_OPCODE_MOV ||
> @@ -70,9 +76,7 @@ can_coalesce_vars(brw::fs_live_variables *live_intervals,
>const exec_list *instructions, const fs_inst *inst,
>int var_to, int var_from)
> {
> - if (live_intervals->vars_interfere(var_from, var_to) &&
> - !inst->dst.equals(inst->src[0])) {
> -
> + if (live_intervals->vars_interfere(var_from, var_to)) {
>/* We know that the live ranges of A (var_from) and B (var_to)
> * interfere because of the ->vars_interfere() call above. If the end
> * of B's live range is after the end of A's range, then we know two
> @@ -131,6 +135,12 @@ fs_visitor::register_coalesce()
>if (!is_coalesce_candidate(inst, virtual_grf_sizes))
> continue;
>
> + if (is_nop_mov(inst)) {
> + inst->opcode = BRW_OPCODE_NOP;
> + progress = true;
> + continue;
> + }
Having the can_coalesce_vars function alter the instruction stream also
seems strange. What do you think about moving the MOV->NOP code into
the caller? It would be outside the vars_interfere path, but I think
that's okay...
> +
>if (reg_from != inst->src[0].reg) {
> reg_from = inst->src[0].reg;
>
>
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77589] [r600g] Source engine game stopped working (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=77589 --- Comment #2 from VOT Productions --- Can reproduce bug on Radeon HD 7750 (radeonsi) -- 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 77589] [r600g] Source engine game stopped working (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=77589 --- Comment #1 from Benjamin Bellec --- It also hits RV770. -- 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 77589] [r600g] Source engine game stopped working (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=77589 Benjamin Bellec changed: What|Removed |Added Attachment #97529|text/plain |image/png 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 77589] [r600g] Source engine game stopped working (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=77589 Benjamin Bellec changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org CC||b.bel...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Retype pre-Gen6 varying pull load destination to UW.
Kenneth Graunke writes: > This sets up the proper execution mask for sends in SIMD16 mode. > > Fixes Piglit's glsl-fs-normalmatrix, glsl-fs-uniform-array-2, > glsl-fs-uniform-array-6, and glsl-fs-uniform-array-7 on Ironlake, > which regressed when I enabled SIMD16 pull parameter support in > commit b207e88b25e526d0f1ada7b19605b880a27866dc. > > Signed-off-by: Kenneth Graunke > Cc: Eric Anholt Reviewed-by: Eric Anholt pgpYasISz3yaQ.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Add glBlitFramebuffer to commands affected by conditional rendering
It would be nice to pick it up to the stable branches.
Adding mesa-sta...@lists.freedesktop.org.
On Wed, Apr 16, 2014 at 10:48 PM, Kenneth Graunke wrote:
> On 04/07/2014 10:55 AM, Anuj Phogat wrote:
>> Fixes failures in Khronos OpenGL CTS test conditional_render_test9
>>
>> Signed-off-by: Anuj Phogat
>> ---
>> src/mesa/drivers/dri/i965/intel_fbo.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
>> b/src/mesa/drivers/dri/i965/intel_fbo.c
>> index d0e1349..b5b93a6 100644
>> --- a/src/mesa/drivers/dri/i965/intel_fbo.c
>> +++ b/src/mesa/drivers/dri/i965/intel_fbo.c
>> @@ -38,6 +38,7 @@
>> #include "main/image.h"
>> #include "main/hash_table.h"
>> #include "main/set.h"
>> +#include "main/condrender.h"
>>
>> #include "swrast/swrast.h"
>> #include "drivers/common/meta.h"
>> @@ -833,6 +834,13 @@ intel_blit_framebuffer(struct gl_context *ctx,
>> GLint dstX0, GLint dstY0, GLint dstX1, GLint dstY1,
>> GLbitfield mask, GLenum filter)
>> {
>> + /* Page 679 of OpenGL 4.4 spec says:
>> +*"Added BlitFramebuffer to commands affected by conditional
>> rendering in
>> +* section 10.10 (Bug 9562)."
>> +*/
>> + if (!_mesa_check_conditional_render(ctx))
>> + return;
>> +
>> mask = brw_blorp_framebuffer(brw_context(ctx),
>> srcX0, srcY0, srcX1, srcY1,
>> dstX0, dstY0, dstX1, dstY1,
>>
>
> Reviewed-by: Kenneth Graunke
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/omx/enc: replace omx buffer with texture buffer
From: Leo Liu
Signed-off-by: Leo Liu
---
src/gallium/state_trackers/omx/vid_enc.c | 214 ++-
1 file changed, 185 insertions(+), 29 deletions(-)
diff --git a/src/gallium/state_trackers/omx/vid_enc.c
b/src/gallium/state_trackers/omx/vid_enc.c
index 88d15a9..8a95999 100644
--- a/src/gallium/state_trackers/omx/vid_enc.c
+++ b/src/gallium/state_trackers/omx/vid_enc.c
@@ -50,6 +50,7 @@
#include "pipe/p_video_codec.h"
#include "state_tracker/drm_driver.h"
#include "util/u_memory.h"
+#include "vl/vl_video_buffer.h"
#include "entrypoint.h"
#include "vid_enc.h"
@@ -64,6 +65,9 @@ struct encode_task {
struct input_buf_private {
struct list_head tasks;
+
+ struct pipe_resource *resource;
+ struct pipe_transfer *transfer;
};
struct output_buf_private {
@@ -78,6 +82,10 @@ static OMX_ERRORTYPE vid_enc_GetParameter(OMX_HANDLETYPE
handle, OMX_INDEXTYPE i
static OMX_ERRORTYPE vid_enc_SetConfig(OMX_HANDLETYPE handle, OMX_INDEXTYPE
idx, OMX_PTR config);
static OMX_ERRORTYPE vid_enc_GetConfig(OMX_HANDLETYPE handle, OMX_INDEXTYPE
idx, OMX_PTR config);
static OMX_ERRORTYPE vid_enc_MessageHandler(OMX_COMPONENTTYPE *comp,
internalRequestMessageType *msg);
+static OMX_ERRORTYPE vid_enc_AllocateInBuffer(omx_base_PortType *port,
OMX_INOUT OMX_BUFFERHEADERTYPE **buf,
+ OMX_IN OMX_U32 idx, OMX_IN
OMX_PTR private, OMX_IN OMX_U32 size);
+static OMX_ERRORTYPE vid_enc_UseInBuffer(omx_base_PortType *port,
OMX_BUFFERHEADERTYPE **buf, OMX_U32 idx,
+ OMX_PTR private, OMX_U32 size, OMX_U8
*mem);
static OMX_ERRORTYPE vid_enc_FreeInBuffer(omx_base_PortType *port, OMX_U32
idx, OMX_BUFFERHEADERTYPE *buf);
static OMX_ERRORTYPE vid_enc_EncodeFrame(omx_base_PortType *port,
OMX_BUFFERHEADERTYPE *buf);
static OMX_ERRORTYPE vid_enc_AllocateOutBuffer(omx_base_PortType *comp,
OMX_INOUT OMX_BUFFERHEADERTYPE **buf,
@@ -226,6 +234,8 @@ static OMX_ERRORTYPE vid_enc_Constructor(OMX_COMPONENTTYPE
*comp, OMX_STRING nam
port->sPortParam.nBufferCountMin = 4;
port->Port_SendBufferFunction = vid_enc_EncodeFrame;
+ port->Port_AllocateBuffer = vid_enc_AllocateInBuffer;
+ port->Port_UseBuffer = vid_enc_UseInBuffer;
port->Port_FreeBuffer = vid_enc_FreeInBuffer;
port = (omx_base_video_PortType
*)priv->ports[OMX_BASE_FILTER_OUTPUTPORT_INDEX];
@@ -293,6 +303,42 @@ static OMX_ERRORTYPE vid_enc_Destructor(OMX_COMPONENTTYPE
*comp)
return omx_workaround_Destructor(comp);
}
+static OMX_ERRORTYPE enc_AllocateBackTexture(omx_base_PortType *port,
+ struct pipe_resource **resource,
+ struct pipe_transfer **transfer,
+ OMX_U8 **map)
+{
+ OMX_COMPONENTTYPE* comp = port->standCompContainer;
+ vid_enc_PrivateType *priv = comp->pComponentPrivate;
+ struct pipe_resource buf_templ;
+ struct pipe_box box = {};
+ OMX_U8 *ptr;
+
+ memset(&buf_templ, 0, sizeof buf_templ);
+ buf_templ.target = PIPE_TEXTURE_2D;
+ buf_templ.format = PIPE_FORMAT_I8_UNORM;
+ buf_templ.bind = PIPE_BIND_LINEAR;
+ buf_templ.usage = PIPE_USAGE_STAGING;
+ buf_templ.flags = 0;
+ buf_templ.width0 = port->sPortParam.format.video.nFrameWidth;
+ buf_templ.height0 = port->sPortParam.format.video.nFrameHeight * 3 / 2;
+ buf_templ.depth0 = 1;
+ buf_templ.array_size = 1;
+
+ *resource = priv->s_pipe->screen->resource_create(priv->s_pipe->screen,
&buf_templ);
+ if (!*resource)
+ return OMX_ErrorInsufficientResources;
+
+ box.width = (*resource)->width0;
+ box.height = (*resource)->height0;
+ box.depth = (*resource)->depth0;
+ ptr = priv->s_pipe->transfer_map(priv->s_pipe, *resource, 0,
PIPE_TRANSFER_WRITE, &box, transfer);
+ if (map)
+ *map = ptr;
+
+ return OMX_ErrorNone;
+}
+
static OMX_ERRORTYPE vid_enc_SetParameter(OMX_HANDLETYPE handle, OMX_INDEXTYPE
idx, OMX_PTR param)
{
OMX_COMPONENTTYPE *comp = handle;
@@ -313,12 +359,20 @@ static OMX_ERRORTYPE vid_enc_SetParameter(OMX_HANDLETYPE
handle, OMX_INDEXTYPE i
if (def->nPortIndex == OMX_BASE_FILTER_INPUTPORT_INDEX) {
omx_base_video_PortType *port;
unsigned framesize;
+ struct pipe_resource *resource;
+ struct pipe_transfer *transfer;
port = (omx_base_video_PortType
*)priv->ports[OMX_BASE_FILTER_INPUTPORT_INDEX];
- framesize = port->sPortParam.format.video.nFrameWidth*
+ enc_AllocateBackTexture(priv->ports[OMX_BASE_FILTER_INPUTPORT_INDEX],
+ &resource, &transfer, NULL);
+ port->sPortParam.format.video.nStride = transfer->stride;
+ pipe_transfer_unmap(priv->s_pipe, transfer);
+ pipe_resource_reference(&resource, NULL);
+
+ framesize = port->sPortParam.format.video.nStride *
port->sPortParam.format.video.nFrameHeight;
port->sPortParam.
Re: [Mesa-dev] "gallium/targets: add missing library dependencies"
Hi,
Should commit 902dc61f886c0d719ce25894bbc8032ede0f409b
("gallium/targets: add missing library dependencies") be queued for
inclusion in 10.1.1 too?
At least, build of version 10.1 fails on libxatracker.so with the errors
like this one:
Making all in xa-vmwgfx
gmake[3]: Entering directory
`/home/eugene/rpmbuild/BUILD/Mesa-10.1.0/src/gallium/targets/xa-vmwgfx'
CC vmw_target.lo
CXXLDlibxatracker.la
../../../../src/gallium/winsys/svga/drm/.libs/libsvgadrm.a(vmw_screen_dri.o):
In function `vmw_drm_surface_get_handle':
/home/eugene/rpmbuild/BUILD/Mesa-10.1.0/src/gallium/winsys/svga/drm/vmw_screen_dri.c:361:
undefined reference to `drmPrimeHandleToFD'
This is due to missing $(LIBDRM_LIBS) in libxatracker_la_LIBADD = ... in
src/gallium/targets/xa/Makefile.am
Regards,
Eugene
--
Eugene Shatokhin, ROSA
www.rosalab.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Allow explicit binding on atomics again
Chris Forbes writes: > As of 943b2d52bf5, layout(binding) on an atomic would fail the assertion > here. > > Signed-off-by: Chris Forbes > Cc: Ian Romanick Tested-by: Carl Worth (That is, on my Intel laptop this patch fixes all the regressions I saw on 10.1 and otherwise passes all piglit tests just fine.) Ian, if you're good with this patch, then we can land it in master and 10.1 and finally cut the 10.1.1 release. -Carl -- carl.d.wo...@intel.com pgp8HT3_ZLQ3h.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 74717] r600g: 'invalid read' linking geometry shader
https://bugs.freedesktop.org/show_bug.cgi?id=74717 --- Comment #20 from Benjamin Bellec --- (In reply to comment #18) > (In reply to comment #16) > > > $ MESA_GL_VERSION_OVERRIDE=3.2 MESA_GLSL_VERSION_OVERRIDE=150 > > ./build/Release/gl-320-primitive-shading > > OpenGL Version Needed 3.2 ( 3.2 Found ) > > 0:22(34): error: length called on unsized array > > 0:24(23): error: unsized array index must be constant > > 0:25(18): error: unsized array index must be constant > > > > Erreur de segmentation (core dumped) > > > > => I got a black screen during 1 or 2 seconds and then close with a > > segfault. > > > > > > Note that I can launch Unigine Valley (which requires GL3.2 or GL3.3 I don't > > remember) without problem and without overriding the GL version envvar. > > Please try current Mesa git and look here: > > https://bugs.freedesktop.org/show_bug.cgi?id=76394 > > Greetings, > Dieter I will follow bug 76394 since I was in fact not hit by this one (74717). -- You are receiving this mail because: You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] Old, outstanding patches nominated for the stable branch
Anuj Phogat writes: > Patch is present on master: > commit 6bd2472a8b9a969d06dc110bd30ccd8daf713959 Thanks. And that's in 10.1 already as well. Sorry I'd missed it. > I've pushed few more patches which I was holding back to push along > with many others still under review. > commit cb6566f9df61bfc84c27b382ba3e494bbac782d9 > commit 313566825405c33f26a0471a997ec4c79fae6b08 > commit fdd8bebc22f167f19d9cafbe2e7c189cb3720bcb Great. I'll get these soon. (If not in 10.1.1, then in 10.1.2). -Carl -- carl.d.wo...@intel.com pgpT3Uuhpq6zq.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Old, outstanding patches nominated for the stable branch
On Wednesday 16 April 2014, Carl Worth wrote: > Hi folks, > > Here are patches that were nominated for the stable branch over one > month ago, but have apparently not yet landed on master. Maybe some of > these have been neglected or missed in the review process? > > nv30: report the correct max varying limit (Jan 29, Ilia Mirkin) > > mesa: Fix error code generation in glReadPixels() (Feb 14, Anuj Phogat) > > mesa: Add GL_TEXTURE_CUBE_MAP_ARRAY to > legal_get_tex_level_parameter_target() (Feb 14, Anuj Phogat) > > dri3: Enable GLX_MESA_query_renderer on DRI3 too (Feb 20, Ian Romanick) > > mesa: Don't use derived vertex state in > api_arrayelt.c (Feb 27, Fredrik Höglund) This patch hasn't landed yet because it hasn't received any reviews. I would appreciate it if someone could take a look at it. Fredrik ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa/mesa] Check for dladdr(), rather than assuming we have it if we have RTLD_DEFAULT
On 09/04/2014 14:53, Jonathan Gray wrote:
> On Sun, Apr 06, 2014 at 03:30:43PM +0100, Jon TURNEY wrote:
>> Unfortunately, Cygwin defines RTLD_DEFAULT (for glibc compatibility), but
>> can't
>> provide dladdr(), so add a check for dladdr()
>>
>> ---
>> configure.ac | 6 ++
>> src/mesa/drivers/dri/common/megadriver_stub.c | 7 +++
>> 2 files changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 878b24a..bbbed79 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -480,6 +480,12 @@ AC_CHECK_FUNC([dlopen], [DEFINES="$DEFINES
>> -DHAVE_DLOPEN"],
>> [DEFINES="$DEFINES -DHAVE_DLOPEN"; DLOPEN_LIBS="-ldl"])])
>> AC_SUBST([DLOPEN_LIBS])
>>
>> +dnl Check if that library also has dladdr
>> +SAVE_LDFLAGS="$LDFLAGS"
>
> The case here is wrong and won't work as intended unless changed to
> save_LDFLAGS.
Good catch.
> Otherwise the patch seems fine, though it will break the scons build till
> those files are updated?
Updated patch attached with what I think are the appropriate scons runes added
(and sent to the right mailing list this time! :-) ).
>From e0cd88529e0851aa7b3da59c8c74a3954ff93e7c Mon Sep 17 00:00:00 2001
From: Jon TURNEY
Date: Sat, 5 Apr 2014 17:11:45 +0100
Subject: [PATCH] Check for dladdr(), rather than assuming we have it if we
have RTLD_DEFAULT
Unfortunately, Cygwin defines RTLD_DEFAULT (for glibc compatibility), but can't
provide dladdr(), so add a check for dladdr()
Since I don't think scons is ever used to build for Cygwin, just set HAVE_DLADDR
in SConscript, assuming that if we have RTLD_DEFAULT, we have dladdr().
Cc: Jonathan Gray
Signed-off-by: Jon TURNEY
Reviewed-by: Eric Anholt
---
configure.ac | 6 ++
src/mesa/drivers/dri/common/SConscript| 1 +
src/mesa/drivers/dri/common/megadriver_stub.c | 7 +++
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5c01038..17cc2d1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -480,6 +480,12 @@ AC_CHECK_FUNC([dlopen], [DEFINES="$DEFINES -DHAVE_DLOPEN"],
[DEFINES="$DEFINES -DHAVE_DLOPEN"; DLOPEN_LIBS="-ldl"])])
AC_SUBST([DLOPEN_LIBS])
+dnl Check if that library also has dladdr
+save_LDFLAGS="$LDFLAGS"
+LDFLAGS="$LDFLAGS $DLOPEN_LIBS"
+AC_CHECK_FUNCS([dladdr])
+LDFLAGS="$save_LDFLAGS"
+
case "$host_os" in
darwin*|mingw*)
;;
diff --git a/src/mesa/drivers/dri/common/SConscript
b/src/mesa/drivers/dri/common/SConscript
index 8b15532..41f6356 100644
--- a/src/mesa/drivers/dri/common/SConscript
+++ b/src/mesa/drivers/dri/common/SConscript
@@ -30,6 +30,7 @@ drienv.Replace(CPPPATH = [
driswenv = drienv.Clone()
driswenv.Append(CPPDEFINES = [
'__NOT_HAVE_DRM_H',
+'HAVE_DLADDR',
])
drienv.PkgUseModules('DRM')
diff --git a/src/mesa/drivers/dri/common/megadriver_stub.c
b/src/mesa/drivers/dri/common/megadriver_stub.c
index 7b6d134..d085080 100644
--- a/src/mesa/drivers/dri/common/megadriver_stub.c
+++ b/src/mesa/drivers/dri/common/megadriver_stub.c
@@ -28,10 +28,9 @@
/* We need GNU extensions to dlfcn.h in order to provide backward
* compatibility for the older DRI driver loader mechanism. (dladdr,
- * Dl_info, and RTLD_DEFAULT are only defined when _GNU_SOURCE is
- * defined.)
+ * Dl_info, and RTLD_DEFAULT)
*/
-#ifdef RTLD_DEFAULT
+#if defined(RTLD_DEFAULT) && defined(HAVE_DLADDR)
#define MEGADRIVER_STUB_MAX_EXTENSIONS 10
#define LIB_PATH_SUFFIX "_dri.so"
@@ -148,7 +147,7 @@ megadriver_stub_init(void)
}
}
-#endif /* RTLD_DEFAULT */
+#endif /* RTLD_DEFAULT && HAVE_DLADDR */
static const
__DRIconfig **stub_error_init_screen(__DRIscreen *psp)
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 0/5] XA composite and perf improvements and fixes
On 04/17/2014 12:48 AM, Rob Clark wrote:
> On Wed, Apr 16, 2014 at 9:09 AM, Thomas Hellstrom
> wrote:
>> Hi, Rob,
>>
>> Do you think we can push patches 1 trough 3 with a CC to stable for
>> patch 3?
> yes please.. you can push, or I can.. I was just waiting to hear back
> from you on the later patches. I meant to propose merging the first 3
> but got distracted with other things ;-)
>
>
OK, so I've pushed the three first patches ( I added your reviewed-by on
the third, It looked from our email discussion like you have revied it).
I also took a liberty of reworking the fourth patch a bit. By sending
solid colors to the fragment shader using shader constants the
xa_renderer code becomes a lot nicer. I've attached the patches to this
email. (I have no intentions to "steal" your work so feel free to add
tags or use the code in any way you see fit :) ). I haven't tested
extensively but I don't see the rendercheck errors with these patches. I
still have a rendering problem when enabling solid fills, though, but I
suspect that's a vmwgfx bug.
As for the fifth patch, it seems to me like if the source is xrgb and
the dest is alpha, we could be using a solid fill path with (1, 0, 0, 0)
source color, without alterations to the fragment shader? Likewise if
mask is xrgb and we're not using component alpha, that's equivalent to
no mask regardless of destination?
Thanks
Thomas
>From bfa1e504961e0980bb2b40c1ac271691a2d8aebe Mon Sep 17 00:00:00 2001
From: Thomas Hellstrom
Date: Thu, 17 Apr 2014 08:06:22 +0200
Subject: [PATCH 1/2] st/xa: Enable solid fill with (non-solid) mask
Based on work by Rob Clark.
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_composite.c | 94 +++-
src/gallium/state_trackers/xa/xa_context.c | 2 +-
src/gallium/state_trackers/xa/xa_priv.h | 2 +-
src/gallium/state_trackers/xa/xa_renderer.c | 47 --
src/gallium/state_trackers/xa/xa_tgsi.c | 13 ++--
5 files changed, 73 insertions(+), 85 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_composite.c b/src/gallium/state_trackers/xa/xa_composite.c
index 7ae35a1..de57518 100644
--- a/src/gallium/state_trackers/xa/xa_composite.c
+++ b/src/gallium/state_trackers/xa/xa_composite.c
@@ -125,6 +125,7 @@ blend_for_op(struct xa_composite_blend *blend,
if (xa_blends[i].op == op) {
*blend = xa_blends[i];
supported = TRUE;
+ break;
}
}
@@ -224,18 +225,12 @@ xa_composite_check_accelerated(const struct xa_composite *comp)
}
-if (src_pic->src_pict) {
- if (src_pic->src_pict->type != xa_src_pict_solid_fill)
+if (src_pic->src_pict && src_pic->src_pict->type != xa_src_pict_solid_fill)
return -XA_ERR_INVAL;
- /*
- * Currently we don't support solid fill with a mask.
- * We can easily do that, but that would require shader,
- * sampler view setup and vertex setup modification.
- */
- if (comp->mask)
- return -XA_ERR_INVAL;
-}
+/* No solid masks for now. */
+if (comp->mask && comp->mask->src_pict)
+return -XA_ERR_INVAL;
if (blend_for_op(&blend, comp->op, comp->src, comp->mask, comp->dst)) {
struct xa_picture *mask = comp->mask;
@@ -337,7 +332,7 @@ bind_shaders(struct xa_context *ctx, const struct xa_composite *comp)
if (src_pic->src_pict) {
if (src_pic->src_pict->type == xa_src_pict_solid_fill) {
- fs_traits |= FS_SOLID_FILL | FS_FILL;
+ fs_traits |= FS_SOLID_FILL;
vs_traits |= VS_SOLID_FILL;
xa_pixel_to_float4(src_pic->src_pict->solid_fill.color,
ctx->solid_color);
@@ -392,38 +387,32 @@ bind_samplers(struct xa_context *ctx,
struct pipe_context *pipe = ctx->pipe;
struct xa_picture *src_pic = comp->src;
struct xa_picture *mask_pic = comp->mask;
+int num_samplers = 0;
-ctx->num_bound_samplers = 0;
-
+xa_ctx_sampler_views_destroy(ctx);
memset(&src_sampler, 0, sizeof(struct pipe_sampler_state));
memset(&mask_sampler, 0, sizeof(struct pipe_sampler_state));
-if (src_pic) {
- if (ctx->has_solid_color) {
- samplers[0] = NULL;
- pipe_sampler_view_reference(&ctx->bound_sampler_views[0], NULL);
- } else {
- unsigned src_wrap = xa_repeat_to_gallium(src_pic->wrap);
- int filter;
-
- (void) xa_filter_to_gallium(src_pic->filter, &filter);
-
- src_sampler.wrap_s = src_wrap;
- src_sampler.wrap_t = src_wrap;
- src_sampler.min_img_filter = filter;
- src_sampler.mag_img_filter = filter;
- src_sampler.min_mip_filter = PIPE_TEX_MIPFILTER_NEAREST;
- src_sampler.normalized_coords = 1;
- samplers[0] = &src_sampler;
- ctx->num_bound_samplers = 1;
- u_sampler_view_default_template(&view_templ,
- src_pic->srf->tex,
- src_pic->srf->tex->format);
- src_view = pipe->create_sampler_view(pipe, src_pic->srf->tex,
- &view_templ);
- pipe_sampler_view_reference(&ctx->bound_sampler_views[0], NULL);
- ctx->bound_sampler_views[0] = src_view;
- }
+if (src_pic && !ctx->has_
Re: [Mesa-dev] [PATCH] glsl: Small optimization for constant conditionals
Hi Kenneth,
El 2014-04-17 08:57, Kenneth Graunke escribió:
On 04/15/2014 03:30 AM, Iago Toral Quiroga wrote:
Once the relevant branch has been identified do not iterate over the
instructions in the branch, do a linked list insertion instead to
avoid the
loop.
---
src/glsl/opt_if_simplification.cpp | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
Oh, this is nicer.
Reviewed-by: Kenneth Graunke
and pushed.
By the way, usually people send cover letters for patches when there's
a
large series, but not for a single patch. If you have extra commentary
about a patch, you can put that here, below the "---" and the diffstat.
(Anything below the "---" won't be part of the commit message when
applied with "git am".)
Thanks for the review and for the tip! I will do this next time.
diff --git a/src/glsl/opt_if_simplification.cpp
b/src/glsl/opt_if_simplification.cpp
index 2bec825..e05f031 100644
--- a/src/glsl/opt_if_simplification.cpp
+++ b/src/glsl/opt_if_simplification.cpp
@@ -90,15 +90,9 @@ ir_if_simplification_visitor::visit_leave(ir_if
*ir)
* that matters out.
*/
if (condition_constant->value.b[0]) {
-foreach_list_safe(n, &ir->then_instructions) {
- ir_instruction *then_ir = (ir_instruction *) n;
- ir->insert_before(then_ir);
-}
+ ir->insert_before(&ir->then_instructions);
} else {
-foreach_list_safe(n, &ir->else_instructions) {
- ir_instruction *else_ir = (ir_instruction *) n;
- ir->insert_before(else_ir);
-}
+ ir->insert_before(&ir->else_instructions);
}
ir->remove();
this->made_progress = true;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glsl: Fix redeclaration rules for gl_FragCoord.
Correct, this doesn't try to tackle the link-time cases at all.
After sending these out, Anuj told me that he had similar patches
pending review. Unfortunate to duplicate effort, but it's what I get
for doing a bunch of random bug-stomping, I guess :)
Hopefully we can pick the best ideas from both series.
On Thu, Apr 17, 2014 at 6:29 PM, Kenneth Graunke wrote:
> On 04/12/2014 10:30 PM, Chris Forbes wrote:
>> The ARB_fragment_coord_conventions spec, section 4.3.x (Input Layout
>> Qualifiers) says:
>>
>> "All redeclarations of gl_FragCoord in all fragment shaders in a
>> single program must have the same set of qualifiers. Within any
>> shader, the first redeclarations of gl_FragCoord must appear before
>> any use of gl_FragCoord."
>>
>> Fixes piglit's tests:
>>arb_fragment_coord_conventions/compiler/redeclaration-after-use
>>arb_fragment_coord_conventions/compiler/redeclaration-around-use
>>
>> glsl-1.50/compiler/fragment_coord_conventions/layout-qualifiers-conflicting-case-1
>>
>> glsl-1.50/compiler/fragment_coord_conventions/layout-qualifiers-conflicting-case-2
>>
>> Signed-off-by: Chris Forbes
>> ---
>> src/glsl/ast_to_hir.cpp | 20
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
>> index 9b9d511..d1eb3e2 100644
>> --- a/src/glsl/ast_to_hir.cpp
>> +++ b/src/glsl/ast_to_hir.cpp
>> @@ -2715,9 +2715,29 @@ get_variable_being_redeclared(ir_variable *var,
>> YYLTYPE loc,
>>/* Allow redeclaration of gl_FragCoord for ARB_fcc layout
>> * qualifiers.
>> */
>> +
>> + if (earlier->data.how_declared != ir_var_declared_implicitly
>> + && (earlier->data.origin_upper_left != var->data.origin_upper_left
>> + || earlier->data.pixel_center_integer !=
>> var->data.pixel_center_integer)) {
>> + _mesa_glsl_error(&loc, state,
>> + "Inconsistent redeclarations of gl_FragCoord");
>> + }
>> +
>>earlier->data.origin_upper_left = var->data.origin_upper_left;
>>earlier->data.pixel_center_integer = var->data.pixel_center_integer;
>>
>> + if (earlier->data.used &&
>> + earlier->data.how_declared == ir_var_declared_implicitly) {
>> + /* ARB_fragment_coord_conventions spec Section 4.3.x.1
>> + * (Input Layout Qualifier) says:
>> + *
>> + * "Within any shader, the first redeclarations of gl_FragCoord
>> + * must appear before any use of gl_FragCoord."
>> + */
>> + _mesa_glsl_error(&loc, state,
>> + "First redeclaration of gl_FragCoord must appear
>> before any use");
>> + }
>> +
>>/* According to section 4.3.7 of the GLSL 1.30 spec,
>> * the following built-in varaibles can be redeclared with an
>> * interpolation qualifier:
>>
>
> It seems like this will catch multiple, inconsistent redeclarations
> within a single fragment shader...but the spec text quoted indicates
> that redeclarations in all fragment shaders being linked together into a
> single program need to be consistent.
>
> I don't see any code to handle that in linker*.cpp, so presumably we
> ought to add that as well. Regardless, this is a good improvement!
>
> Both patches are:
> Reviewed-by: Kenneth Graunke
>
> Thanks, Chris.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xa: Cache render target surface
Otherwise it will trick the gallium driver into thinking that the render
target has actually changed (due to different pipe_surface pointing to
same underlying pipe_resource). This is really badness for tiling GPUs
like adreno.
This also appears to fix a rendering error with Motif on vmwgfx.
Why that is is still under investigation.
Based on an idea by Rob Clark.
Cc: "10.0 10.1"
Signed-off-by: Thomas Hellstrom
Reviewed-by: Rob Clark
---
src/gallium/state_trackers/xa/xa_context.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_context.c
b/src/gallium/state_trackers/xa/xa_context.c
index 867999a..37de45b 100644
--- a/src/gallium/state_trackers/xa/xa_context.c
+++ b/src/gallium/state_trackers/xa/xa_context.c
@@ -78,6 +78,8 @@ xa_context_destroy(struct xa_context *r)
}
xa_ctx_sampler_views_destroy(r);
+if (r->srf)
+pipe_surface_reference(&r->srf, NULL);
if (r->cso) {
cso_release_all(r->cso);
@@ -185,8 +187,15 @@ xa_ctx_srf_create(struct xa_context *ctx, struct
xa_surface *dst)
struct pipe_screen *screen = ctx->pipe->screen;
struct pipe_surface srf_templ;
-if (ctx->srf)
- return -XA_ERR_INVAL;
+/*
+ * Cache surfaces unless we change render target
+ */
+if (ctx->srf) {
+if (ctx->srf->texture == dst->tex)
+return XA_ERR_NONE;
+
+pipe_surface_reference(&ctx->srf, NULL);
+}
if (!screen->is_format_supported(screen, dst->tex->format,
PIPE_TEXTURE_2D, 0,
@@ -204,7 +213,10 @@ xa_ctx_srf_create(struct xa_context *ctx, struct
xa_surface *dst)
void
xa_ctx_srf_destroy(struct xa_context *ctx)
{
-pipe_surface_reference(&ctx->srf, NULL);
+/*
+ * Cache surfaces unless we change render target.
+ * Final destruction on context destroy.
+ */
}
XA_EXPORT int
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 74717] r600g: 'invalid read' linking geometry shader
https://bugs.freedesktop.org/show_bug.cgi?id=74717 Török Edwin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from Török Edwin --- (In reply to comment #18) > Please try current Mesa git and look here: > > https://bugs.freedesktop.org/show_bug.cgi?id=76394 > Thanks, the invalid read is fixed, valgrind shows no errors. I get a similar output like you in bug #76394, so closing this one. -- You are receiving this mail because: You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 3/7] linker: Fold set_uniform_binding into call site
On 04/16/2014 04:59 PM, Carl Worth wrote: > Ian Romanick writes: >> variable. That's never passed to set_uniform_binding, and it's easier >> to just remove the function (especially for later patches in the series) >> than to add another parameter. > > Hi Ian, > > I should have looked closer at this commit when I was reviewing it for > the stable series. > > The commit message and structure of the patch led me to believe that a > function was being inlined without a behavioral change. > > However, the new assert is causing regressions for the following piglit > tests: > > all/spec/ARB_shader_atomic_counters > active-counters > compiler/ > expression-allowed.frag > default-partition > fragment-discard > function-argument > > Such as: > > $ ./bin/arb_shader_atomic_counters-active-counters -fbo -auto > arb_shader_atomic_counters-active-counters: > ../../src/glsl/link_uniform_initializers.cpp:257: void > link_set_uniform_initializers(gl_shader_program*): Assertion `!"Explicit > binding not on a sampler or UBO."' failed. > Aborted > > Other than this set of regressions, I like the state of the 10.1 branch > I have. What do you recommend? > > -Carl For what it's worth, Chris Forbes sent out a patch which purports to fix this: http://lists.freedesktop.org/archives/mesa-dev/2014-April/057718.html signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
