[Mesa-dev] [PATCH 1/2] nvc0/ir: use manual TXD when offsets are involved
Something about how we're implementing offsets for TXD is wrong, just
flip to the generic quadop-based implementation in that case.
This is the minimal fix appropriate for backporting.
Signed-off-by: Ilia Mirkin
Cc:
---
src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 0e24db7..398b28f 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -769,7 +769,8 @@ NVC0LoweringPass::handleTXD(TexInstruction *txd)
if (dim > 2 ||
txd->tex.target.isCube() ||
arg > 4 ||
- txd->tex.target.isShadow())
+ txd->tex.target.isShadow() ||
+ txd->tex.useOffsets)
return handleManualTXD(txd);
for (int c = 0; c < dim; ++c) {
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] nvc0/ir: fill offset in properly for TXD
Apparently TXD wants its offset differently than TEX, accepting it in
the upper bits of the layer index. Unclear what happens when this is
combined with indirect sampler indexing.
Signed-off-by: Ilia Mirkin
---
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 47 --
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 398b28f..ac2a770 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -639,12 +639,14 @@ NVC0LoweringPass::handleTEX(TexInstruction *i)
if (i->tex.useOffsets) {
int n, c;
int s = i->srcCount(0xff, true);
- if (i->tex.target.isShadow())
- s--;
- if (i->srcExists(s)) // move potential predicate out of the way
- i->moveSources(s, 1);
- if (i->tex.useOffsets == 4 && i->srcExists(s + 1))
- i->moveSources(s + 1, 1);
+ if (i->op != OP_TXD) {
+ if (i->tex.target.isShadow())
+s--;
+ if (i->srcExists(s)) // move potential predicate out of the way
+i->moveSources(s, 1);
+ if (i->tex.useOffsets == 4 && i->srcExists(s + 1))
+i->moveSources(s + 1, 1);
+ }
if (i->op == OP_TXG) {
// Either there is 1 offset, which goes into the 2 low bytes of the
// first source, or there are 4 offsets, which go into 2 sources (8
@@ -673,7 +675,22 @@ NVC0LoweringPass::handleTEX(TexInstruction *i)
assert(i->offset[0][c].getImmediate(val));
imm |= (val.reg.data.u32 & 0xf) << (c * 4);
}
- i->setSrc(s, bld.loadImm(NULL, imm));
+ if (i->op == OP_TXD) {
+// The offset goes into the upper 16 bits of the array index. So
+// create it if it's not already there, and INSBF it if it already
+// is.
+if (i->tex.target.isArray()) {
+ bld.mkOp3(OP_INSBF, TYPE_U32, i->getSrc(0),
+ bld.loadImm(NULL, imm), bld.mkImm(0xc10),
+ i->getSrc(0));
+} else {
+ for (int s = dim; s >= 1; --s)
+ i->setSrc(s, i->getSrc(s - 1));
+ i->setSrc(0, bld.loadImm(NULL, imm << 16));
+}
+ } else {
+i->setSrc(s, bld.loadImm(NULL, imm));
+ }
}
}
@@ -759,20 +776,24 @@ bool
NVC0LoweringPass::handleTXD(TexInstruction *txd)
{
int dim = txd->tex.target.getDim();
- int arg = txd->tex.target.getArgCount();
+ unsigned arg = txd->tex.target.getArgCount();
+ unsigned expected_args = arg;
+
+ if (!txd->tex.target.isArray() && txd->tex.useOffsets)
+ expected_args++;
+
+ if (expected_args > 4 || dim > 2 || txd->tex.target.isShadow())
+ txd->op = OP_TEX;
handleTEX(txd);
while (txd->srcExists(arg))
++arg;
txd->tex.derivAll = true;
- if (dim > 2 ||
- txd->tex.target.isCube() ||
- arg > 4 ||
- txd->tex.target.isShadow() ||
- txd->tex.useOffsets)
+ if (txd->op == OP_TEX)
return handleManualTXD(txd);
+ assert(arg == expected_args);
for (int c = 0; c < dim; ++c) {
txd->setSrc(arg + c * 2 + 0, txd->dPdx[c]);
txd->setSrc(arg + c * 2 + 1, txd->dPdy[c]);
--
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 11/13] i965: Make backend_instruction usable from C.
On Wed, Jul 2, 2014 at 6:59 AM, Pohjolainen, Topi wrote: > On Mon, Jun 30, 2014 at 02:40:42PM -0700, Matt Turner wrote: >> With a hack to place an exec_node in the struct in C to be at the same >> location as the inherited exec_node in C++. > > Are you planning to eventually have one but not the other? I'd kind of like to transition to embedding the exec_node, rather than inheriting so that we can use the types from C. For this series, I don't even use .link from backend_instruction. I just need to add exec_node to backend_instruction so that it has the same structure in C as C++ (and I can access some of the fields from C). > If this is just > temporary it does not make a lot difference but otherwise I would rather > have these with different names. I'm not sure what you mean. > How big a task would it be to teach plusplus logic to use the C-type? I don't think it should be too difficult to switch, now that it's easy to find the uses of the foreach* macros that cast to fs_inst or vec4_instruction. That might actually let us do things like putting instructions in multiple lists (one giant list, and a per-basic block list). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nvc0: do quadops on the right texture coordinates for TXD
handleTEX moves the layer as the first argument. This makes sure that
the quadops deal with the texture coordinates.
Signed-off-by: Ilia Mirkin
Cc:
---
src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 8f26645..0e24db7 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -712,6 +712,7 @@ NVC0LoweringPass::handleManualTXD(TexInstruction *i)
Value *zero = bld.loadImm(bld.getSSA(), 0);
int l, c;
const int dim = i->tex.target.getDim();
+ const int array = i->tex.target.isArray();
i->op = OP_TEX; // no need to clone dPdx/dPdy later
@@ -722,7 +723,7 @@ NVC0LoweringPass::handleManualTXD(TexInstruction *i)
for (l = 0; l < 4; ++l) {
// mov coordinates from lane l to all lanes
for (c = 0; c < dim; ++c)
- bld.mkQuadop(0x00, crd[c], l, i->getSrc(c), zero);
+ bld.mkQuadop(0x00, crd[c], l, i->getSrc(c + array), zero);
// add dPdx from lane l to lanes dx
for (c = 0; c < dim; ++c)
bld.mkQuadop(qOps[l][0], crd[c], l, i->dPdx[c].get(), crd[c]);
@@ -732,7 +733,7 @@ NVC0LoweringPass::handleManualTXD(TexInstruction *i)
// texture
bld.insert(tex = cloneForward(func, i));
for (c = 0; c < dim; ++c)
- tex->setSrc(c, crd[c]);
+ tex->setSrc(c + array, crd[c]);
// save results
for (c = 0; i->defExists(c); ++c) {
Instruction *mov;
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] gallium: switch dedicated centroid field to interpolation location
The new location field can be either center, centroid, or sample, which
indicates the location that the shader should interpolate at.
Signed-off-by: Ilia Mirkin
---
I tried to make sure I hit all the uses, but I guess a bunch of drivers don't
look at the Centroid field at all?
src/gallium/auxiliary/tgsi/tgsi_build.c | 8
src/gallium/auxiliary/tgsi/tgsi_dump.c| 5 +++--
src/gallium/auxiliary/tgsi/tgsi_scan.c| 2 +-
src/gallium/auxiliary/tgsi/tgsi_scan.h| 2 +-
src/gallium/auxiliary/tgsi/tgsi_strings.c | 7 +++
src/gallium/auxiliary/tgsi/tgsi_strings.h | 2 ++
src/gallium/auxiliary/tgsi/tgsi_ureg.c| 12 ++--
src/gallium/auxiliary/tgsi/tgsi_ureg.h| 2 +-
src/gallium/drivers/ilo/shader/toy_tgsi.c | 2 +-
src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 2 +-
src/gallium/drivers/r600/r600_shader.c| 4 ++--
src/gallium/drivers/radeonsi/si_shader.c | 6 +++---
src/gallium/include/pipe/p_shader_tokens.h| 9 +++--
src/mesa/state_tracker/st_glsl_to_tgsi.cpp| 5 +++--
src/mesa/state_tracker/st_glsl_to_tgsi.h | 2 +-
src/mesa/state_tracker/st_program.c | 13 +
16 files changed, 52 insertions(+), 31 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_build.c
b/src/gallium/auxiliary/tgsi/tgsi_build.c
index 7621b6a..bef5c75 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_build.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_build.c
@@ -200,7 +200,7 @@ tgsi_default_declaration_interp( void )
struct tgsi_declaration_interp di;
di.Interpolate = TGSI_INTERPOLATE_CONSTANT;
- di.Centroid = 0;
+ di.Location = TGSI_INTERPOLATE_LOC_CENTER;
di.CylindricalWrap = 0;
di.Padding = 0;
@@ -209,7 +209,7 @@ tgsi_default_declaration_interp( void )
static struct tgsi_declaration_interp
tgsi_build_declaration_interp(unsigned interpolate,
- unsigned centroid,
+ unsigned interpolate_location,
unsigned cylindrical_wrap,
struct tgsi_declaration *declaration,
struct tgsi_header *header)
@@ -217,7 +217,7 @@ tgsi_build_declaration_interp(unsigned interpolate,
struct tgsi_declaration_interp di;
di.Interpolate = interpolate;
- di.Centroid = centroid;
+ di.Location = interpolate_location;
di.CylindricalWrap = cylindrical_wrap;
di.Padding = 0;
@@ -433,7 +433,7 @@ tgsi_build_full_declaration(
size++;
*di = tgsi_build_declaration_interp(full_decl->Interp.Interpolate,
- full_decl->Interp.Centroid,
+ full_decl->Interp.Location,
full_decl->Interp.CylindricalWrap,
declaration,
header);
diff --git a/src/gallium/auxiliary/tgsi/tgsi_dump.c
b/src/gallium/auxiliary/tgsi/tgsi_dump.c
index 8e09bac..884d8cf 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_dump.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_dump.c
@@ -349,8 +349,9 @@ iter_declaration(
ENM( decl->Interp.Interpolate, tgsi_interpolate_names );
}
- if (decl->Interp.Centroid) {
- TXT( ", CENTROID" );
+ if (decl->Interp.Location != TGSI_INTERPOLATE_LOC_CENTER) {
+ TXT( ", " );
+ ENM( decl->Interp.Location, tgsi_interpolate_locations );
}
if (decl->Interp.CylindricalWrap) {
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index 00fdcfb..563d2c5 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c
@@ -187,7 +187,7 @@ tgsi_scan_shader(const struct tgsi_token *tokens,
info->input_semantic_name[reg] = (ubyte) semName;
info->input_semantic_index[reg] = (ubyte) semIndex;
info->input_interpolate[reg] =
(ubyte)fulldecl->Interp.Interpolate;
- info->input_centroid[reg] = (ubyte)fulldecl->Interp.Centroid;
+ info->input_interpolate_loc[reg] =
(ubyte)fulldecl->Interp.Location;
info->input_cylindrical_wrap[reg] =
(ubyte)fulldecl->Interp.CylindricalWrap;
info->num_inputs++;
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.h
b/src/gallium/auxiliary/tgsi/tgsi_scan.h
index 0be2feb..1869b41 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.h
@@ -45,7 +45,7 @@ struct tgsi_shader_info
ubyte input_semantic_name[PIPE_MAX_SHADER_INPUTS]; /**< TGSI_SEMANTIC_x */
ubyte input_semantic_index[PIPE_MAX_SHADER_INPUTS];
ubyte input_interpolate[PIPE_MA
[Mesa-dev] [PATCH 3/3] tgsi: add interpolation location modifier support to text parser
Signed-off-by: Ilia Mirkin
---
nouveau_compiler standalone binary uses the text representation for shader
input, so this is necessary to be able to test the centroid/sample stuff
src/gallium/auxiliary/tgsi/tgsi_text.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c
b/src/gallium/auxiliary/tgsi/tgsi_text.c
index 7e50d8d..c6134c5 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_text.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_text.c
@@ -1368,6 +1368,23 @@ static boolean parse_declaration( struct translate_ctx
*ctx )
}
}
+ cur = ctx->cur;
+ eat_opt_white( &cur );
+ if (*cur == ',' && !is_vs_input) {
+ uint i;
+
+ cur++;
+ eat_opt_white( &cur );
+ for (i = 0; i < TGSI_INTERPOLATE_LOC_COUNT; i++) {
+ if (str_match_nocase_whole( &cur, tgsi_interpolate_locations[i] )) {
+decl.Interp.Location = i;
+
+ctx->cur = cur;
+break;
+ }
+ }
+ }
+
advance = tgsi_build_full_declaration(
&decl,
ctx->tokens_cur,
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] mesa/st: add per sample shading state to fp key and set interpolation
This enables a gallium driver not to care about the semantics of
ARB_sample_shading vs ARB_gpu_shader5 sample attributes. When
ARB_sample_shading-style sample shading is enabled, all of the fp inputs
are marked for interpolation at the sample location.
Signed-off-by: Ilia Mirkin
---
I _think_ I got this right... at least the tests still pass. But my
understanding of all the various update atoms, etc is really weak... please
read carefully :)
Now that I understand all this interpolation stuff better, I see why it was
suggested I add proper per-sample interpolation first and the
ARB_sample_shading stuff second. Oh well...
src/mesa/state_tracker/st_atom_shader.c | 6 +-
src/mesa/state_tracker/st_program.c | 3 +++
src/mesa/state_tracker/st_program.h | 3 +++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_atom_shader.c
b/src/mesa/state_tracker/st_atom_shader.c
index 67c6157..6515a98 100644
--- a/src/mesa/state_tracker/st_atom_shader.c
+++ b/src/mesa/state_tracker/st_atom_shader.c
@@ -89,6 +89,10 @@ update_fp( struct st_context *st )
key.clamp_color = st->clamp_frag_color_in_shader &&
st->ctx->Color._ClampFragmentColor;
+ /* Ignore sample qualifier while computing this flag. */
+ key.persample_shading =
+ _mesa_get_min_invocations_per_fragment(st->ctx, &stfp->Base, true) > 1;
+
st->fp_variant = st_get_fp_variant(st, stfp, &key);
st_reference_fragprog(st, &st->fp, stfp);
@@ -108,7 +112,7 @@ update_fp( struct st_context *st )
const struct st_tracked_state st_update_fp = {
"st_update_fp", /* name */
{ /* dirty */
- _NEW_BUFFERS,/* mesa */
+ _NEW_BUFFERS | _NEW_MULTISAMPLE, /* mesa */
ST_NEW_FRAGMENT_PROGRAM /* st */
},
update_fp /* update */
diff --git a/src/mesa/state_tracker/st_program.c
b/src/mesa/state_tracker/st_program.c
index b603759..9d7b7c4 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -548,6 +548,9 @@ st_translate_fragment_program(struct st_context *st,
else
interpLocation[slot] = TGSI_INTERPOLATE_LOC_CENTER;
+ if (key->persample_shading)
+interpLocation[slot] = TGSI_INTERPOLATE_LOC_SAMPLE;
+
switch (attr) {
case VARYING_SLOT_POS:
input_semantic_name[slot] = TGSI_SEMANTIC_POSITION;
diff --git a/src/mesa/state_tracker/st_program.h
b/src/mesa/state_tracker/st_program.h
index ce9174f..9a5b6a8 100644
--- a/src/mesa/state_tracker/st_program.h
+++ b/src/mesa/state_tracker/st_program.h
@@ -58,6 +58,9 @@ struct st_fp_variant_key
/** for ARB_color_buffer_float */
GLuint clamp_color:1;
+
+ /** for ARB_sample_shading */
+ GLuint persample_shading:1;
};
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80933] New: Fullscreen OpenGL programs (e.g. games) crash if focus lost then regained, something to do with automatic compositing suspension
https://bugs.freedesktop.org/show_bug.cgi?id=80933 Priority: medium Bug ID: 80933 Assignee: mesa-dev@lists.freedesktop.org Summary: Fullscreen OpenGL programs (e.g. games) crash if focus lost then regained, something to do with automatic compositing suspension Severity: normal Classification: Unclassified OS: Linux (All) Reporter: nrfoconnor+freedesk...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 10.2 Component: Other Product: Mesa See also: https://github.com/ValveSoftware/Dota-2/issues/886 Yes, the above link is specific to Dota 2, though I've found that I have the exact same problem with all other *fullscreen* programs (including Flash and Silverlight plugins running in Wine/Pipelight): namely, if the program loses focus for whatever reason (something appears in front of it, I use my Alt-Tab window switch hotkey, et cetera), then occasionally when I return to the program in question, it crashes. The problem seems to be related to compositing window managers and the feature they have to automatically suspend compositing. Disabling compositing, as well as disabling the automatic suspension feature, causes the problem to cease. And due to the nature of the feature in question, running the game in "window mode" also avoids the problem. Having redirected both stderr and stdout to a log file in the case of Civilization V, no error message seems to be present when the crash occurs. Silverlight in Wine/Pipelight brings up a mockup of the Windows "Program has encountered an error" dialog, so I suspect Linux native programs merely segfault or something equally unhelpful in troubleshooting. :V I believe this is a bug within Mesa, and not my drivers or window manager, because the above link shows the problem occuring across multiple driver and WM combinations (and my own tests have ruled out the possibility of it being a bug in the specific program). With KDE/KWin, the workaround is painless - if you disable the automatic suspension feature in the advanced tab of its "Desktop Effects" page, the problem ceases and you can forget it was ever a problem to begin with. I am unsure of the instructions for other window managers, but I would imagine they have a similar checkbox stashed away somewhere, or you can of course disable compositing entirely if you prefer. -- 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] nv50/ir: ignore bias for samplerCubeShadow on nv50
Unfortunately there's no good way to do this on the nv50 shader isa.
Dropping the bias seems preferable to doing the compare post-filtering.
Signed-off-by: Ilia Mirkin
Cc:
---
src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
index ed06def..e283424 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
@@ -797,6 +797,16 @@ NV50LoweringPreSSA::handleTXB(TexInstruction *i)
const CondCode cc[4] = { CC_EQU, CC_S, CC_C, CC_O };
int l, d;
+ // We can't actually apply bias *and* do a compare for a cube
+ // texture. Since the compare has to be done before the filtering, just
+ // drop the bias on the floor.
+ if (i->tex.target == TEX_TARGET_CUBE_SHADOW) {
+ i->op = OP_TEX;
+ i->setSrc(3, i->getSrc(4));
+ i->setSrc(4, NULL);
+ return handleTEX(i);
+ }
+
handleTEX(i);
Value *bias = i->getSrc(i->tex.target.getArgCount());
if (bias->isUniform())
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] nv50/ir: retrieve shadow compare from first arg
This can only happen with texture(samplerCubeShadow, bias), where the compare will be in the first argument. Signed-off-by: Ilia Mirkin Cc: --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp index 9b7c490..af3a87c 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp @@ -2504,7 +2504,7 @@ Converter::handleInstruction(const struct tgsi_full_instruction *insn) break; case TGSI_OPCODE_TXB2: case TGSI_OPCODE_TXL2: - handleTEX(dst0, 2, 2, 0x10, 0x11, 0x00, 0x00); + handleTEX(dst0, 2, 2, 0x10, 0x0f, 0x00, 0x00); break; case TGSI_OPCODE_SAMPLE: case TGSI_OPCODE_SAMPLE_B: -- 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 1/2] st/mesa: fix samplerCubeShadow with bias
Ah yes, my bad. I did try to look at all the stuff, but it doesn't
help that e.g. the texture man page is wrong for samplerCubeShadow
(http://www.opengl.org/sdk/docs/man/html/texture.xhtml -- it lists the
argument as vec3... I did double-check in the GL 4.4 spec, and it's
correct there with a vec4).
OK, so this patch seems good... would still be *awesome* if you (or
someone else) could add TEX2/TXB2/TXL2 entries in the tgsi doc for
people like me who don't know what's up. One question is whether DX
allows this even though GL doesn't, but I'm less concerned about that.
On Fri, Jul 4, 2014 at 4:00 PM, Marek Olšák wrote:
> samplerCubeArrayShadow cannot be used with lod and bias in GLSL 4.40,
> so it's impossible to get TXL or TXB with it.
>
> Some sampler types are more limited than others. For example,
> samplerCubeArrayShadow can only be used with this:
>
> float texture(gsamplerCubeArrayShadow sampler, vec4 P, float compare)
>
> textureLod is supported for 1DArrayShadow, but not for 2DArrayShadow, etc.
>
> See the specification.
>
> Marek
>
> On Fri, Jul 4, 2014 at 9:48 PM, Ilia Mirkin wrote:
>> On Fri, Jul 4, 2014 at 3:30 PM, Ilia Mirkin wrote:
>>> On Fri, Jul 4, 2014 at 2:49 PM, Ilia Mirkin wrote:
On Fri, Jul 4, 2014 at 8:10 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> It has 5 coordinates: (x,y,z,depth,lodbias)
>
> Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Ilia Mirkin
Although I still haven't worked out what else is wrong with nouveau...
nv50 hits an assert, while nvc0 just generates wrong code. But it does
look like your patch is correct.
>>>
>>> Actually this makes the TXL2 instruction pretty confusing =/
>>>
>>> Right now it's always just used for cube arrays, so the shadow/lod are
>>> in a fixed position (first and second components of second arg). I
>>> think that behaviour should be maintained -- for example, TXB
>>> (http://gallium.readthedocs.org/en/latest/tgsi.html#opcode-TXB) always
>>> has the bias in the 'w' component [ugh, should fix the docs on that,
>>> it says 'z']. Same with TXL.
>>
>> Err, sorry, I got confused between TXL and TXB. But my point still stands.
>>
>> Unless we're doing something horribly wrong in nouveau, it appears
>> that for cube arrays, the lod is in src1.x and shadow is in src1.y,
>> while for the samplerCubeShadow case, lod is in src1.x while shadow is
>> in src0.w. Once I adjusted that, the texture(bias) CubeShadow case
>> started passing.
>>
>> In any case, it'd be great of TEX2/TXB2/TXL2 could be documented in
>> the TGSI docs...
>>
>> -ilia
>>
>>>
>>> -ilia
>>>
> ---
> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index 9e19431..65ef89c 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -2820,7 +2820,13 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
>}
>break;
> case ir_txb:
> - opcode = is_cube_array ? TGSI_OPCODE_TXB2 : TGSI_OPCODE_TXB;
> + if (is_cube_array ||
> + sampler_type == glsl_type::samplerCubeShadow_type) {
> + opcode = TGSI_OPCODE_TXB2;
> + }
> + else {
> + opcode = TGSI_OPCODE_TXB;
> + }
>ir->lod_info.bias->accept(this);
>lod_info = this->result;
>if (ir->offset) {
> --
> 1.9.1
>
> ___
> 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] st/mesa: fix samplerCubeShadow with bias
samplerCubeArrayShadow cannot be used with lod and bias in GLSL 4.40,
so it's impossible to get TXL or TXB with it.
Some sampler types are more limited than others. For example,
samplerCubeArrayShadow can only be used with this:
float texture(gsamplerCubeArrayShadow sampler, vec4 P, float compare)
textureLod is supported for 1DArrayShadow, but not for 2DArrayShadow, etc.
See the specification.
Marek
On Fri, Jul 4, 2014 at 9:48 PM, Ilia Mirkin wrote:
> On Fri, Jul 4, 2014 at 3:30 PM, Ilia Mirkin wrote:
>> On Fri, Jul 4, 2014 at 2:49 PM, Ilia Mirkin wrote:
>>> On Fri, Jul 4, 2014 at 8:10 AM, Marek Olšák wrote:
From: Marek Olšák
It has 5 coordinates: (x,y,z,depth,lodbias)
Cc: mesa-sta...@lists.freedesktop.org
>>>
>>> Reviewed-by: Ilia Mirkin
>>>
>>> Although I still haven't worked out what else is wrong with nouveau...
>>> nv50 hits an assert, while nvc0 just generates wrong code. But it does
>>> look like your patch is correct.
>>
>> Actually this makes the TXL2 instruction pretty confusing =/
>>
>> Right now it's always just used for cube arrays, so the shadow/lod are
>> in a fixed position (first and second components of second arg). I
>> think that behaviour should be maintained -- for example, TXB
>> (http://gallium.readthedocs.org/en/latest/tgsi.html#opcode-TXB) always
>> has the bias in the 'w' component [ugh, should fix the docs on that,
>> it says 'z']. Same with TXL.
>
> Err, sorry, I got confused between TXL and TXB. But my point still stands.
>
> Unless we're doing something horribly wrong in nouveau, it appears
> that for cube arrays, the lod is in src1.x and shadow is in src1.y,
> while for the samplerCubeShadow case, lod is in src1.x while shadow is
> in src0.w. Once I adjusted that, the texture(bias) CubeShadow case
> started passing.
>
> In any case, it'd be great of TEX2/TXB2/TXL2 could be documented in
> the TGSI docs...
>
> -ilia
>
>>
>> -ilia
>>
>>>
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 9e19431..65ef89c 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -2820,7 +2820,13 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
}
break;
case ir_txb:
- opcode = is_cube_array ? TGSI_OPCODE_TXB2 : TGSI_OPCODE_TXB;
+ if (is_cube_array ||
+ sampler_type == glsl_type::samplerCubeShadow_type) {
+ opcode = TGSI_OPCODE_TXB2;
+ }
+ else {
+ opcode = TGSI_OPCODE_TXB;
+ }
ir->lod_info.bias->accept(this);
lod_info = this->result;
if (ir->offset) {
--
1.9.1
___
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] st/mesa: fix samplerCubeShadow with bias
On Fri, Jul 4, 2014 at 3:30 PM, Ilia Mirkin wrote:
> On Fri, Jul 4, 2014 at 2:49 PM, Ilia Mirkin wrote:
>> On Fri, Jul 4, 2014 at 8:10 AM, Marek Olšák wrote:
>>> From: Marek Olšák
>>>
>>> It has 5 coordinates: (x,y,z,depth,lodbias)
>>>
>>> Cc: mesa-sta...@lists.freedesktop.org
>>
>> Reviewed-by: Ilia Mirkin
>>
>> Although I still haven't worked out what else is wrong with nouveau...
>> nv50 hits an assert, while nvc0 just generates wrong code. But it does
>> look like your patch is correct.
>
> Actually this makes the TXL2 instruction pretty confusing =/
>
> Right now it's always just used for cube arrays, so the shadow/lod are
> in a fixed position (first and second components of second arg). I
> think that behaviour should be maintained -- for example, TXB
> (http://gallium.readthedocs.org/en/latest/tgsi.html#opcode-TXB) always
> has the bias in the 'w' component [ugh, should fix the docs on that,
> it says 'z']. Same with TXL.
Err, sorry, I got confused between TXL and TXB. But my point still stands.
Unless we're doing something horribly wrong in nouveau, it appears
that for cube arrays, the lod is in src1.x and shadow is in src1.y,
while for the samplerCubeShadow case, lod is in src1.x while shadow is
in src0.w. Once I adjusted that, the texture(bias) CubeShadow case
started passing.
In any case, it'd be great of TEX2/TXB2/TXL2 could be documented in
the TGSI docs...
-ilia
>
> -ilia
>
>>
>>> ---
>>> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 8 +++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>>> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>>> index 9e19431..65ef89c 100644
>>> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>>> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>>> @@ -2820,7 +2820,13 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
>>>}
>>>break;
>>> case ir_txb:
>>> - opcode = is_cube_array ? TGSI_OPCODE_TXB2 : TGSI_OPCODE_TXB;
>>> + if (is_cube_array ||
>>> + sampler_type == glsl_type::samplerCubeShadow_type) {
>>> + opcode = TGSI_OPCODE_TXB2;
>>> + }
>>> + else {
>>> + opcode = TGSI_OPCODE_TXB;
>>> + }
>>>ir->lod_info.bias->accept(this);
>>>lod_info = this->result;
>>>if (ir->offset) {
>>> --
>>> 1.9.1
>>>
>>> ___
>>> 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] st/mesa: fix samplerCubeShadow with bias
On Fri, Jul 4, 2014 at 2:49 PM, Ilia Mirkin wrote:
> On Fri, Jul 4, 2014 at 8:10 AM, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> It has 5 coordinates: (x,y,z,depth,lodbias)
>>
>> Cc: mesa-sta...@lists.freedesktop.org
>
> Reviewed-by: Ilia Mirkin
>
> Although I still haven't worked out what else is wrong with nouveau...
> nv50 hits an assert, while nvc0 just generates wrong code. But it does
> look like your patch is correct.
Actually this makes the TXL2 instruction pretty confusing =/
Right now it's always just used for cube arrays, so the shadow/lod are
in a fixed position (first and second components of second arg). I
think that behaviour should be maintained -- for example, TXB
(http://gallium.readthedocs.org/en/latest/tgsi.html#opcode-TXB) always
has the bias in the 'w' component [ugh, should fix the docs on that,
it says 'z']. Same with TXL.
-ilia
>
>> ---
>> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>> index 9e19431..65ef89c 100644
>> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>> @@ -2820,7 +2820,13 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
>>}
>>break;
>> case ir_txb:
>> - opcode = is_cube_array ? TGSI_OPCODE_TXB2 : TGSI_OPCODE_TXB;
>> + if (is_cube_array ||
>> + sampler_type == glsl_type::samplerCubeShadow_type) {
>> + opcode = TGSI_OPCODE_TXB2;
>> + }
>> + else {
>> + opcode = TGSI_OPCODE_TXB;
>> + }
>>ir->lod_info.bias->accept(this);
>>lod_info = this->result;
>>if (ir->offset) {
>> --
>> 1.9.1
>>
>> ___
>> 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] st/mesa: fix samplerCubeShadow with bias
On Fri, Jul 4, 2014 at 8:10 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> It has 5 coordinates: (x,y,z,depth,lodbias)
>
> Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Ilia Mirkin
Although I still haven't worked out what else is wrong with nouveau...
nv50 hits an assert, while nvc0 just generates wrong code. But it does
look like your patch is correct.
> ---
> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index 9e19431..65ef89c 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -2820,7 +2820,13 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
>}
>break;
> case ir_txb:
> - opcode = is_cube_array ? TGSI_OPCODE_TXB2 : TGSI_OPCODE_TXB;
> + if (is_cube_array ||
> + sampler_type == glsl_type::samplerCubeShadow_type) {
> + opcode = TGSI_OPCODE_TXB2;
> + }
> + else {
> + opcode = TGSI_OPCODE_TXB;
> + }
>ir->lod_info.bias->accept(this);
>lod_info = this->result;
>if (ir->offset) {
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/1] gallivm, llvmpipe: Handle MSAA textures in emit_fetch_texels in a preliminary fashion to prevent a crash in a Piglit test.
--- src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c index 3d7df3e..4bf9242 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c @@ -2329,9 +2329,11 @@ emit_fetch_texels( struct lp_build_tgsi_soa_context *bld, dims = 1; break; case TGSI_TEXTURE_2D: + case TGSI_TEXTURE_2D_MSAA: case TGSI_TEXTURE_RECT: dims = 2; break; + case TGSI_TEXTURE_2D_ARRAY_MSAA: case TGSI_TEXTURE_2D_ARRAY: layer_coord = 2; dims = 2; -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] R600/SI: fix shadow mapping for 1D and 2D array textures
On Thu, Jul 03, 2014 at 06:26:04PM +0200, Marek Olšák wrote:
> From: Marek Olšák
Reviewed-by: Tom Stellard
>
> It was conflicting with def TEX_SHADOW_ARRAY, which also handles them.
> ---
> lib/Target/R600/R600Instructions.td | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/Target/R600/R600Instructions.td
> b/lib/Target/R600/R600Instructions.td
> index 73fa345..704507d 100644
> --- a/lib/Target/R600/R600Instructions.td
> +++ b/lib/Target/R600/R600Instructions.td
> @@ -216,7 +216,7 @@ class R600_REDUCTION inst, dag ins, string asm,
> list pattern,
> def TEX_SHADOW : PatLeaf<
>(imm),
>[{uint32_t TType = (uint32_t)N->getZExtValue();
> -return (TType >= 6 && TType <= 8) || (TType >= 11 && TType <= 13);
> +return (TType >= 6 && TType <= 8) || TType == 13;
>}]
> >;
>
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 2/2] meta: Add a meta implementation of GL_ARB_clear_texture
Here is version 3 of the glClearTexImage implementation. I figured out
I could avoid the whole issue of preserving the glClearColor state by
using glClearBuffer instead of glClear. I think the patch is a lot
neater this way.
I also fixed using sRGB textures and explicitly disabled dithering.
- Neil
--- >8 --- (use git am --scissors to automatically chop here)
Adds an implementation of the ClearTexSubImage driver entry point that tries
to set up an FBO to render to the texture and then calls glClearBuffer with a
scissor to perform the actual clear. If an FBO can't be created for the
texture then it will fall back to using _mesa_store_ClearTexSubImage.
When used in combination with _mesa_store_ClearTexSubImage this should provide
an implementation that works for all DRI-based drivers. However as this has
only been tested with the i965 driver it is currently only enabled there.
v2: Only enable the extension for the i965 driver instead of all DRI drivers.
Remove an unnecessary goto. Don't require GL_ARB_framebuffer_object. Add
some more comments.
v3: Use glClearBuffer* to avoid having to modify glClearColor and friends.
Handle sRGB textures. Explicitly disable dithering.
Reviewed-by: Topi Pohjolainen
---
src/mesa/drivers/common/driverfuncs.c| 1 +
src/mesa/drivers/common/meta.c | 189 +++
src/mesa/drivers/common/meta.h | 7 +
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
4 files changed, 198 insertions(+)
diff --git a/src/mesa/drivers/common/driverfuncs.c
b/src/mesa/drivers/common/driverfuncs.c
index 6ece5d8..4f0f7a6 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -95,6 +95,7 @@ _mesa_init_driver_functions(struct dd_function_table *driver)
driver->TexImage = _mesa_store_teximage;
driver->TexSubImage = _mesa_store_texsubimage;
driver->GetTexImage = _mesa_meta_GetTexImage;
+ driver->ClearTexSubImage = _mesa_meta_ClearTexSubImage;
driver->CopyTexSubImage = _mesa_meta_CopyTexSubImage;
driver->GenerateMipmap = _mesa_meta_GenerateMipmap;
driver->TestProxyTexImage = _mesa_test_proxy_teximage;
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 10dd418..a47b7b9 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -40,6 +40,7 @@
#include "main/blit.h"
#include "main/bufferobj.h"
#include "main/buffers.h"
+#include "main/clear.h"
#include "main/colortab.h"
#include "main/condrender.h"
#include "main/depth.h"
@@ -47,6 +48,7 @@
#include "main/fbobject.h"
#include "main/feedback.h"
#include "main/formats.h"
+#include "main/format_unpack.h"
#include "main/glformats.h"
#include "main/image.h"
#include "main/macros.h"
@@ -71,6 +73,7 @@
#include "main/teximage.h"
#include "main/texparam.h"
#include "main/texstate.h"
+#include "main/texstore.h"
#include "main/transformfeedback.h"
#include "main/uniforms.h"
#include "main/varray.h"
@@ -3347,3 +3350,189 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x,
GLfloat y, GLfloat z,
_mesa_meta_end(ctx);
}
+
+static bool
+cleartexsubimage_color(struct gl_context *ctx,
+ struct gl_texture_image *texImage,
+ const GLvoid *clearValue,
+ GLint zoffset)
+{
+ mesa_format format;
+ union gl_color_union colorValue;
+ GLenum datatype;
+ GLenum status;
+
+ _mesa_meta_bind_fbo_image(GL_COLOR_ATTACHMENT0, texImage, zoffset);
+
+ status = _mesa_CheckFramebufferStatus(GL_DRAW_FRAMEBUFFER);
+ if (status != GL_FRAMEBUFFER_COMPLETE)
+ return false;
+
+ /* We don't want to apply an sRGB conversion so override the format */
+ format = _mesa_get_srgb_format_linear(texImage->TexFormat);
+ datatype = _mesa_get_format_datatype(format);
+
+ switch (datatype) {
+ case GL_UNSIGNED_INT:
+ case GL_INT:
+ if (clearValue)
+ _mesa_unpack_uint_rgba_row(format, 1, clearValue,
+(GLuint (*)[4]) colorValue.ui);
+ else
+ memset(&colorValue, 0, sizeof colorValue);
+ if (datatype == GL_INT)
+ glClearBufferiv(GL_COLOR, 0, colorValue.i);
+ else
+ glClearBufferuiv(GL_COLOR, 0, colorValue.ui);
+ break;
+ default:
+ if (clearValue)
+ _mesa_unpack_rgba_row(format, 1, clearValue,
+ (GLfloat (*)[4]) colorValue.f);
+ else
+ memset(&colorValue, 0, sizeof colorValue);
+ glClearBufferfv(GL_COLOR, 0, colorValue.f);
+ break;
+ }
+
+ return true;
+}
+
+static bool
+cleartexsubimage_depth_stencil(struct gl_context *ctx,
+ struct gl_texture_image *texImage,
+ const GLvoid *clearValue,
+ GLint zoffset)
+{
+ GLint stencilValue;
+ GLfloat depthValue;
+ GLenum status;
+
+ _mesa_meta_bind_fbo_image(GL_DEPTH_ATTACHMENT,
[Mesa-dev] [PATCH 1/2] meta: Add a state flag for the GL_DITHER
The Meta implementation of glClearTexSubImage is going to want to ensure that
dithering is disabled so that it can get a consistent color across the whole
texture when clearing. This adds a state flag to easily save it and set it to
the default value when performing meta operations.
---
src/mesa/drivers/common/meta.c | 8
src/mesa/drivers/common/meta.h | 4
2 files changed, 12 insertions(+)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index f1f5729..10dd418 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -505,6 +505,11 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield state)
_mesa_set_enable(ctx, GL_COLOR_LOGIC_OP, GL_FALSE);
}
+ if (state & MESA_META_DITHER) {
+ save->DitherFlag = ctx->Color.DitherFlag;
+ _mesa_set_enable(ctx, GL_DITHER, GL_TRUE);
+ }
+
if (state & MESA_META_COLOR_MASK) {
memcpy(save->ColorMask, ctx->Color.ColorMask,
sizeof(ctx->Color.ColorMask));
@@ -875,6 +880,9 @@ _mesa_meta_end(struct gl_context *ctx)
_mesa_set_enable(ctx, GL_COLOR_LOGIC_OP, save->ColorLogicOpEnabled);
}
+ if (state & MESA_META_DITHER)
+ _mesa_set_enable(ctx, GL_DITHER, save->DitherFlag);
+
if (state & MESA_META_COLOR_MASK) {
GLuint i;
for (i = 0; i < ctx->Const.MaxDrawBuffers; i++) {
diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h
index 765f8df..b8d992c 100644
--- a/src/mesa/drivers/common/meta.h
+++ b/src/mesa/drivers/common/meta.h
@@ -59,6 +59,7 @@
#define MESA_META_FRAMEBUFFER_SRGB 0x20
#define MESA_META_OCCLUSION_QUERY 0x40
#define MESA_META_DRAW_BUFFERS 0x80
+#define MESA_META_DITHER 0x100
/**\}*/
/**
@@ -84,6 +85,9 @@ struct save_state
GLbitfield BlendEnabled;
GLboolean ColorLogicOpEnabled;
+ /** MESA_META_DITHER */
+ GLboolean DitherFlag;
+
/** MESA_META_COLOR_MASK */
GLubyte ColorMask[MAX_DRAW_BUFFERS][4];
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: fix u_default_transfer_inline_write for textures
Am 03.07.2014 18:29, schrieb Marek Olšák:
> From: Marek Olšák
>
> This doesn't fix any known issue. In fact, radeon drivers ignore all
> the discard flags for textures and implicitly do "discard range"
> for any write transfer.
>
> Cc: mesa-sta...@lists.freedesktop.org
> ---
> src/gallium/auxiliary/util/u_transfer.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_transfer.c
> b/src/gallium/auxiliary/util/u_transfer.c
> index 7804f2a..71da35d 100644
> --- a/src/gallium/auxiliary/util/u_transfer.c
> +++ b/src/gallium/auxiliary/util/u_transfer.c
> @@ -25,8 +25,8 @@ void u_default_transfer_inline_write( struct pipe_context
> *pipe,
> usage |= PIPE_TRANSFER_WRITE;
>
> /* transfer_inline_write implicitly discards the rewritten buffer range */
> - /* XXX this looks very broken for non-buffer resources having more than
> one dim. */
> - if (box->x == 0 && box->width == resource->width0) {
> + if (resource->target == PIPE_BUFFER &&
> + box->x == 0 && box->width == resource->width0) {
>usage |= PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE;
> } else {
>usage |= PIPE_TRANSFER_DISCARD_RANGE;
>
Reviewed-by: Roland Scheidegger
I guess it would be possible to also do this for non-buffer resources,
by checking all appropriate dimensions. But probably not worth it
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] clover: Enable cl_khr_fp64 for devices that support doubles v2
On Fri, Jul 04, 2014 at 05:25:42PM +0200, Francisco Jerez wrote:
> Tom Stellard writes:
>
> > On Fri, Jul 04, 2014 at 12:28:05PM +0200, Francisco Jerez wrote:
> >> Tom Stellard writes:
> >>
> >> > On Fri, Jul 04, 2014 at 12:28:20AM +0200, Francisco Jerez wrote:
> >> >> Tom Stellard writes:
> >> >>
> >> >> > On Thu, Jul 03, 2014 at 01:12:07AM +0200, Francisco Jerez wrote:
> >> >> >> Tom Stellard writes:
> >> >> >>
> >> >> >> > On Thu, Jun 26, 2014 at 04:15:39PM +0200, Francisco Jerez wrote:
> >> >> >> >> Tom Stellard writes:
> >> >> >> >>
> >> >> >> >> > v2:
> >> >> >> >> > - Report correct values for
> >> >> >> >> > CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE and
> >> >> >> >> > CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE.
> >> >> >> >> > - Only define cl_khr_fp64 if the extension is supported.
> >> >> >> >> > - Remove trailing space from extension string.
> >> >> >> >> > - Rename device query function from cl_khr_fp86() to
> >> >> >> >> > has_doubles().
> >> >> >> >> > ---
> >> >> >> >> > src/gallium/state_trackers/clover/api/device.cpp | 6
> >> >> >> >> > +++---
> >> >> >> >> > src/gallium/state_trackers/clover/core/device.cpp | 6
> >> >> >> >> > ++
> >> >> >> >> > src/gallium/state_trackers/clover/core/device.hpp | 1 +
> >> >> >> >> > src/gallium/state_trackers/clover/core/program.cpp| 5 -
> >> >> >> >> > src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 -
> >> >> >> >> > 5 files changed, 14 insertions(+), 5 deletions(-)
> >> >> >> >> >
> >> >> >> >> > diff --git a/src/gallium/state_trackers/clover/api/device.cpp
> >> >> >> >> > b/src/gallium/state_trackers/clover/api/device.cpp
> >> >> >> >> > index 7006702..1176668 100644
> >> >> >> >> > --- a/src/gallium/state_trackers/clover/api/device.cpp
> >> >> >> >> > +++ b/src/gallium/state_trackers/clover/api/device.cpp
> >> >> >> >> > @@ -145,7 +145,7 @@ clGetDeviceInfo(cl_device_id d_dev,
> >> >> >> >> > cl_device_info param,
> >> >> >> >> >break;
> >> >> >> >> >
> >> >> >> >> > case CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE:
> >> >> >> >> > - buf.as_scalar() = 2;
> >> >> >> >> > + buf.as_scalar() = dev.has_doubles() ? 2 : 0;
> >> >> >> >> >break;
> >> >> >> >> >
> >> >> >> >> > case CL_DEVICE_PREFERRED_VECTOR_WIDTH_HALF:
> >> >> >> >> > @@ -290,7 +290,7 @@ clGetDeviceInfo(cl_device_id d_dev,
> >> >> >> >> > cl_device_info param,
> >> >> >> >> >break;
> >> >> >> >> >
> >> >> >> >> > case CL_DEVICE_EXTENSIONS:
> >> >> >> >> > - buf.as_string() = "";
> >> >> >> >> > + buf.as_string() = dev.has_doubles() ? "cl_khr_fp64" : "";
> >> >> >> >> >break;
> >> >> >> >> >
> >> >> >> >> > case CL_DEVICE_PLATFORM:
> >> >> >> >> > @@ -322,7 +322,7 @@ clGetDeviceInfo(cl_device_id d_dev,
> >> >> >> >> > cl_device_info param,
> >> >> >> >> >break;
> >> >> >> >> >
> >> >> >> >> > case CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE:
> >> >> >> >> > - buf.as_scalar() = 2;
> >> >> >> >> > + buf.as_scalar() = dev.has_doubles() ? 2 : 0;
> >> >> >> >> >break;
> >> >> >> >> >
> >> >> >> >> > case CL_DEVICE_NATIVE_VECTOR_WIDTH_HALF:
> >> >> >> >> > diff --git a/src/gallium/state_trackers/clover/core/device.cpp
> >> >> >> >> > b/src/gallium/state_trackers/clover/core/device.cpp
> >> >> >> >> > index bc6b761..6bf33e0 100644
> >> >> >> >> > --- a/src/gallium/state_trackers/clover/core/device.cpp
> >> >> >> >> > +++ b/src/gallium/state_trackers/clover/core/device.cpp
> >> >> >> >> > @@ -193,6 +193,12 @@ device::half_fp_config() const {
> >> >> >> >> > return CL_FP_DENORM | CL_FP_INF_NAN |
> >> >> >> >> > CL_FP_ROUND_TO_NEAREST;
> >> >> >> >> > }
> >> >> >> >> >
> >> >> >> >> > +bool
> >> >> >> >> > +device::has_doubles() const {
> >> >> >> >> > + return pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
> >> >> >> >> > + PIPE_SHADER_CAP_DOUBLES);
> >> >> >> >> > +}
> >> >> >> >> > +
> >> >> >> >> > 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 16831ab..025c648 100644
> >> >> >> >> > --- a/src/gallium/state_trackers/clover/core/device.hpp
> >> >> >> >> > +++ b/src/gallium/state_trackers/clover/core/device.hpp
> >> >> >> >> > @@ -66,6 +66,7 @@ namespace clover {
> >> >> >> >> >cl_device_fp_config single_fp_config() const;
> >> >> >> >> >cl_device_fp_config double_fp_config() const;
> >> >> >> >> >cl_device_fp_config half_fp_config() const;
> >> >> >> >> > + bool has_doubles() const;
> >> >> >> >> >
> >> >> >> >> >std::vector max_block_size() const;
> >> >> >> >> >std::string device_name() const;
> >> >> >> >> > diff --git a/src/gallium/state_trackers/clover/cor
Re: [Mesa-dev] [PATCH 5/5] clover: Enable cl_khr_fp64 for devices that support doubles v2
Tom Stellard writes:
> On Fri, Jul 04, 2014 at 12:28:05PM +0200, Francisco Jerez wrote:
>> Tom Stellard writes:
>>
>> > On Fri, Jul 04, 2014 at 12:28:20AM +0200, Francisco Jerez wrote:
>> >> Tom Stellard writes:
>> >>
>> >> > On Thu, Jul 03, 2014 at 01:12:07AM +0200, Francisco Jerez wrote:
>> >> >> Tom Stellard writes:
>> >> >>
>> >> >> > On Thu, Jun 26, 2014 at 04:15:39PM +0200, Francisco Jerez wrote:
>> >> >> >> Tom Stellard writes:
>> >> >> >>
>> >> >> >> > v2:
>> >> >> >> > - Report correct values for
>> >> >> >> > CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE and
>> >> >> >> > CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE.
>> >> >> >> > - Only define cl_khr_fp64 if the extension is supported.
>> >> >> >> > - Remove trailing space from extension string.
>> >> >> >> > - Rename device query function from cl_khr_fp86() to
>> >> >> >> > has_doubles().
>> >> >> >> > ---
>> >> >> >> > src/gallium/state_trackers/clover/api/device.cpp | 6 +++---
>> >> >> >> > src/gallium/state_trackers/clover/core/device.cpp | 6 ++
>> >> >> >> > src/gallium/state_trackers/clover/core/device.hpp | 1 +
>> >> >> >> > src/gallium/state_trackers/clover/core/program.cpp| 5 -
>> >> >> >> > src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 -
>> >> >> >> > 5 files changed, 14 insertions(+), 5 deletions(-)
>> >> >> >> >
>> >> >> >> > diff --git a/src/gallium/state_trackers/clover/api/device.cpp
>> >> >> >> > b/src/gallium/state_trackers/clover/api/device.cpp
>> >> >> >> > index 7006702..1176668 100644
>> >> >> >> > --- a/src/gallium/state_trackers/clover/api/device.cpp
>> >> >> >> > +++ b/src/gallium/state_trackers/clover/api/device.cpp
>> >> >> >> > @@ -145,7 +145,7 @@ clGetDeviceInfo(cl_device_id d_dev,
>> >> >> >> > cl_device_info param,
>> >> >> >> >break;
>> >> >> >> >
>> >> >> >> > case CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE:
>> >> >> >> > - buf.as_scalar() = 2;
>> >> >> >> > + buf.as_scalar() = dev.has_doubles() ? 2 : 0;
>> >> >> >> >break;
>> >> >> >> >
>> >> >> >> > case CL_DEVICE_PREFERRED_VECTOR_WIDTH_HALF:
>> >> >> >> > @@ -290,7 +290,7 @@ clGetDeviceInfo(cl_device_id d_dev,
>> >> >> >> > cl_device_info param,
>> >> >> >> >break;
>> >> >> >> >
>> >> >> >> > case CL_DEVICE_EXTENSIONS:
>> >> >> >> > - buf.as_string() = "";
>> >> >> >> > + buf.as_string() = dev.has_doubles() ? "cl_khr_fp64" : "";
>> >> >> >> >break;
>> >> >> >> >
>> >> >> >> > case CL_DEVICE_PLATFORM:
>> >> >> >> > @@ -322,7 +322,7 @@ clGetDeviceInfo(cl_device_id d_dev,
>> >> >> >> > cl_device_info param,
>> >> >> >> >break;
>> >> >> >> >
>> >> >> >> > case CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE:
>> >> >> >> > - buf.as_scalar() = 2;
>> >> >> >> > + buf.as_scalar() = dev.has_doubles() ? 2 : 0;
>> >> >> >> >break;
>> >> >> >> >
>> >> >> >> > case CL_DEVICE_NATIVE_VECTOR_WIDTH_HALF:
>> >> >> >> > diff --git a/src/gallium/state_trackers/clover/core/device.cpp
>> >> >> >> > b/src/gallium/state_trackers/clover/core/device.cpp
>> >> >> >> > index bc6b761..6bf33e0 100644
>> >> >> >> > --- a/src/gallium/state_trackers/clover/core/device.cpp
>> >> >> >> > +++ b/src/gallium/state_trackers/clover/core/device.cpp
>> >> >> >> > @@ -193,6 +193,12 @@ device::half_fp_config() const {
>> >> >> >> > return CL_FP_DENORM | CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
>> >> >> >> > }
>> >> >> >> >
>> >> >> >> > +bool
>> >> >> >> > +device::has_doubles() const {
>> >> >> >> > + return pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
>> >> >> >> > + PIPE_SHADER_CAP_DOUBLES);
>> >> >> >> > +}
>> >> >> >> > +
>> >> >> >> > 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 16831ab..025c648 100644
>> >> >> >> > --- a/src/gallium/state_trackers/clover/core/device.hpp
>> >> >> >> > +++ b/src/gallium/state_trackers/clover/core/device.hpp
>> >> >> >> > @@ -66,6 +66,7 @@ namespace clover {
>> >> >> >> >cl_device_fp_config single_fp_config() const;
>> >> >> >> >cl_device_fp_config double_fp_config() const;
>> >> >> >> >cl_device_fp_config half_fp_config() const;
>> >> >> >> > + bool has_doubles() const;
>> >> >> >> >
>> >> >> >> >std::vector max_block_size() const;
>> >> >> >> >std::string device_name() const;
>> >> >> >> > diff --git a/src/gallium/state_trackers/clover/core/program.cpp
>> >> >> >> > b/src/gallium/state_trackers/clover/core/program.cpp
>> >> >> >> > index e09c3aa..f65f321 100644
>> >> >> >> > --- a/src/gallium/state_trackers/clover/core/program.cpp
>> >> >> >> > +++ b/src/gallium/state_trackers/clover/core/program.cpp
>> >> >> >> > @@ -95,7 +95,10 @@ program::bu
Re: [Mesa-dev] [PATCH 5/5] clover: Enable cl_khr_fp64 for devices that support doubles v2
On Fri, Jul 04, 2014 at 12:28:05PM +0200, Francisco Jerez wrote:
> Tom Stellard writes:
>
> > On Fri, Jul 04, 2014 at 12:28:20AM +0200, Francisco Jerez wrote:
> >> Tom Stellard writes:
> >>
> >> > On Thu, Jul 03, 2014 at 01:12:07AM +0200, Francisco Jerez wrote:
> >> >> Tom Stellard writes:
> >> >>
> >> >> > On Thu, Jun 26, 2014 at 04:15:39PM +0200, Francisco Jerez wrote:
> >> >> >> Tom Stellard writes:
> >> >> >>
> >> >> >> > v2:
> >> >> >> > - Report correct values for CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE
> >> >> >> > and
> >> >> >> > CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE.
> >> >> >> > - Only define cl_khr_fp64 if the extension is supported.
> >> >> >> > - Remove trailing space from extension string.
> >> >> >> > - Rename device query function from cl_khr_fp86() to
> >> >> >> > has_doubles().
> >> >> >> > ---
> >> >> >> > src/gallium/state_trackers/clover/api/device.cpp | 6 +++---
> >> >> >> > src/gallium/state_trackers/clover/core/device.cpp | 6 ++
> >> >> >> > src/gallium/state_trackers/clover/core/device.hpp | 1 +
> >> >> >> > src/gallium/state_trackers/clover/core/program.cpp| 5 -
> >> >> >> > src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 -
> >> >> >> > 5 files changed, 14 insertions(+), 5 deletions(-)
> >> >> >> >
> >> >> >> > diff --git a/src/gallium/state_trackers/clover/api/device.cpp
> >> >> >> > b/src/gallium/state_trackers/clover/api/device.cpp
> >> >> >> > index 7006702..1176668 100644
> >> >> >> > --- a/src/gallium/state_trackers/clover/api/device.cpp
> >> >> >> > +++ b/src/gallium/state_trackers/clover/api/device.cpp
> >> >> >> > @@ -145,7 +145,7 @@ clGetDeviceInfo(cl_device_id d_dev,
> >> >> >> > cl_device_info param,
> >> >> >> >break;
> >> >> >> >
> >> >> >> > case CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE:
> >> >> >> > - buf.as_scalar() = 2;
> >> >> >> > + buf.as_scalar() = dev.has_doubles() ? 2 : 0;
> >> >> >> >break;
> >> >> >> >
> >> >> >> > case CL_DEVICE_PREFERRED_VECTOR_WIDTH_HALF:
> >> >> >> > @@ -290,7 +290,7 @@ clGetDeviceInfo(cl_device_id d_dev,
> >> >> >> > cl_device_info param,
> >> >> >> >break;
> >> >> >> >
> >> >> >> > case CL_DEVICE_EXTENSIONS:
> >> >> >> > - buf.as_string() = "";
> >> >> >> > + buf.as_string() = dev.has_doubles() ? "cl_khr_fp64" : "";
> >> >> >> >break;
> >> >> >> >
> >> >> >> > case CL_DEVICE_PLATFORM:
> >> >> >> > @@ -322,7 +322,7 @@ clGetDeviceInfo(cl_device_id d_dev,
> >> >> >> > cl_device_info param,
> >> >> >> >break;
> >> >> >> >
> >> >> >> > case CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE:
> >> >> >> > - buf.as_scalar() = 2;
> >> >> >> > + buf.as_scalar() = dev.has_doubles() ? 2 : 0;
> >> >> >> >break;
> >> >> >> >
> >> >> >> > case CL_DEVICE_NATIVE_VECTOR_WIDTH_HALF:
> >> >> >> > diff --git a/src/gallium/state_trackers/clover/core/device.cpp
> >> >> >> > b/src/gallium/state_trackers/clover/core/device.cpp
> >> >> >> > index bc6b761..6bf33e0 100644
> >> >> >> > --- a/src/gallium/state_trackers/clover/core/device.cpp
> >> >> >> > +++ b/src/gallium/state_trackers/clover/core/device.cpp
> >> >> >> > @@ -193,6 +193,12 @@ device::half_fp_config() const {
> >> >> >> > return CL_FP_DENORM | CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
> >> >> >> > }
> >> >> >> >
> >> >> >> > +bool
> >> >> >> > +device::has_doubles() const {
> >> >> >> > + return pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
> >> >> >> > + PIPE_SHADER_CAP_DOUBLES);
> >> >> >> > +}
> >> >> >> > +
> >> >> >> > 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 16831ab..025c648 100644
> >> >> >> > --- a/src/gallium/state_trackers/clover/core/device.hpp
> >> >> >> > +++ b/src/gallium/state_trackers/clover/core/device.hpp
> >> >> >> > @@ -66,6 +66,7 @@ namespace clover {
> >> >> >> >cl_device_fp_config single_fp_config() const;
> >> >> >> >cl_device_fp_config double_fp_config() const;
> >> >> >> >cl_device_fp_config half_fp_config() const;
> >> >> >> > + bool has_doubles() const;
> >> >> >> >
> >> >> >> >std::vector max_block_size() const;
> >> >> >> >std::string device_name() const;
> >> >> >> > diff --git a/src/gallium/state_trackers/clover/core/program.cpp
> >> >> >> > b/src/gallium/state_trackers/clover/core/program.cpp
> >> >> >> > index e09c3aa..f65f321 100644
> >> >> >> > --- a/src/gallium/state_trackers/clover/core/program.cpp
> >> >> >> > +++ b/src/gallium/state_trackers/clover/core/program.cpp
> >> >> >> > @@ -95,7 +95,10 @@ program::build_status(const device &dev) const {
> >> >> >> >
> >> >> >> > std::string
> >> >> >> > program::build_opts(const device
Re: [Mesa-dev] What are some good beginner's tasks for Mesa?
On Thu, Jul 03, 2014 at 10:33:41PM -0500, Darius Goad wrote: > Hello. I'm trying to get my feet wet with Mesa, and I was wondering > what some good tasks for me would be. Thanks again. > What hardware do you have? What are you interested in working on? -Tom > - Darius Goad > ___ > 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 v2 5/5] meta: Add a meta implementation of GL_ARB_clear_texture
"Pohjolainen, Topi" writes: > Oh, I didn't realize that. Should we fix and put this into > _mesa_meta_begin/_mesa_meta_end instead? Yes, perhaps that would be a good idea. I will try writing a separate patch for that. Thinking about it a bit more I also realised I'm not handling sRGB textures correctly. I need to ensure that GL_FRAMEBUFFER_SRGB is disabled otherwise it will apply the sRGB conversion when doing the clear. I also now realise that _mesa_unpack_uint_rgba_row unapplies the sRGB conversion. I am using that to calculate the value to give to glClearColor so I need to stop it from doing that too. I was wondering whether we should also ensure that GL_DITHER is disabled because it affects glClear. For example if we were rendering to a 16-bit texture with a clear color that is in-between values we would want it to pick a single value for all the texels instead of dithering. However in practice I don't think this matters because the clear value is first converted to the same format as the texture before being passed to the driver so it should be impossible to end up with a clear value that would cause dithering. It might be nice to disable it anyway though just to be on the safe side. Regards, - Neil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st/mesa: fix samplerCubeShadow with bias
From: Marek Olšák
It has 5 coordinates: (x,y,z,depth,lodbias)
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 9e19431..65ef89c 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -2820,7 +2820,13 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
}
break;
case ir_txb:
- opcode = is_cube_array ? TGSI_OPCODE_TXB2 : TGSI_OPCODE_TXB;
+ if (is_cube_array ||
+ sampler_type == glsl_type::samplerCubeShadow_type) {
+ opcode = TGSI_OPCODE_TXB2;
+ }
+ else {
+ opcode = TGSI_OPCODE_TXB;
+ }
ir->lod_info.bias->accept(this);
lod_info = this->result;
if (ir->offset) {
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] radeonsi: fix samplerCubeShadow with bias
From: Marek Olšák
Pack the depth value before overwriting it with cube coordinates.
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeonsi/si_shader.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index f0650f4..be43748 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1634,12 +1634,6 @@ static void tex_fetch_args(
if (opcode == TGSI_OPCODE_TXB2)
address[count++] = lp_build_emit_fetch(bld_base, inst, 1, 0);
- if (target == TGSI_TEXTURE_CUBE ||
- target == TGSI_TEXTURE_CUBE_ARRAY ||
- target == TGSI_TEXTURE_SHADOWCUBE ||
- target == TGSI_TEXTURE_SHADOWCUBE_ARRAY)
- radeon_llvm_emit_prepare_cube_coords(bld_base, emit_data,
coords);
-
/* Pack depth comparison value */
if (tgsi_is_shadow_sampler(target) && opcode != TGSI_OPCODE_LODQ) {
if (target == TGSI_TEXTURE_SHADOWCUBE_ARRAY) {
@@ -1650,6 +1644,12 @@ static void tex_fetch_args(
}
}
+ if (target == TGSI_TEXTURE_CUBE ||
+ target == TGSI_TEXTURE_CUBE_ARRAY ||
+ target == TGSI_TEXTURE_SHADOWCUBE ||
+ target == TGSI_TEXTURE_SHADOWCUBE_ARRAY)
+ radeon_llvm_emit_prepare_cube_coords(bld_base, emit_data,
coords);
+
/* Pack user derivatives */
if (opcode == TGSI_OPCODE_TXD) {
for (chan = 0; chan < 2; chan++) {
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM
On 3 July 2014 10:48, Boris BREZILLON wrote: [snip] > Perfect! > Emil, could you add me in Cc of this future submission ? > Of course :) -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] clover: Enable cl_khr_fp64 for devices that support doubles v2
Tom Stellard writes:
> On Fri, Jul 04, 2014 at 12:28:20AM +0200, Francisco Jerez wrote:
>> Tom Stellard writes:
>>
>> > On Thu, Jul 03, 2014 at 01:12:07AM +0200, Francisco Jerez wrote:
>> >> Tom Stellard writes:
>> >>
>> >> > On Thu, Jun 26, 2014 at 04:15:39PM +0200, Francisco Jerez wrote:
>> >> >> Tom Stellard writes:
>> >> >>
>> >> >> > v2:
>> >> >> > - Report correct values for CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE
>> >> >> > and
>> >> >> > CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE.
>> >> >> > - Only define cl_khr_fp64 if the extension is supported.
>> >> >> > - Remove trailing space from extension string.
>> >> >> > - Rename device query function from cl_khr_fp86() to has_doubles().
>> >> >> > ---
>> >> >> > src/gallium/state_trackers/clover/api/device.cpp | 6 +++---
>> >> >> > src/gallium/state_trackers/clover/core/device.cpp | 6 ++
>> >> >> > src/gallium/state_trackers/clover/core/device.hpp | 1 +
>> >> >> > src/gallium/state_trackers/clover/core/program.cpp| 5 -
>> >> >> > src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 -
>> >> >> > 5 files changed, 14 insertions(+), 5 deletions(-)
>> >> >> >
>> >> >> > diff --git a/src/gallium/state_trackers/clover/api/device.cpp
>> >> >> > b/src/gallium/state_trackers/clover/api/device.cpp
>> >> >> > index 7006702..1176668 100644
>> >> >> > --- a/src/gallium/state_trackers/clover/api/device.cpp
>> >> >> > +++ b/src/gallium/state_trackers/clover/api/device.cpp
>> >> >> > @@ -145,7 +145,7 @@ clGetDeviceInfo(cl_device_id d_dev,
>> >> >> > cl_device_info param,
>> >> >> >break;
>> >> >> >
>> >> >> > case CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE:
>> >> >> > - buf.as_scalar() = 2;
>> >> >> > + buf.as_scalar() = dev.has_doubles() ? 2 : 0;
>> >> >> >break;
>> >> >> >
>> >> >> > case CL_DEVICE_PREFERRED_VECTOR_WIDTH_HALF:
>> >> >> > @@ -290,7 +290,7 @@ clGetDeviceInfo(cl_device_id d_dev,
>> >> >> > cl_device_info param,
>> >> >> >break;
>> >> >> >
>> >> >> > case CL_DEVICE_EXTENSIONS:
>> >> >> > - buf.as_string() = "";
>> >> >> > + buf.as_string() = dev.has_doubles() ? "cl_khr_fp64" : "";
>> >> >> >break;
>> >> >> >
>> >> >> > case CL_DEVICE_PLATFORM:
>> >> >> > @@ -322,7 +322,7 @@ clGetDeviceInfo(cl_device_id d_dev,
>> >> >> > cl_device_info param,
>> >> >> >break;
>> >> >> >
>> >> >> > case CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE:
>> >> >> > - buf.as_scalar() = 2;
>> >> >> > + buf.as_scalar() = dev.has_doubles() ? 2 : 0;
>> >> >> >break;
>> >> >> >
>> >> >> > case CL_DEVICE_NATIVE_VECTOR_WIDTH_HALF:
>> >> >> > diff --git a/src/gallium/state_trackers/clover/core/device.cpp
>> >> >> > b/src/gallium/state_trackers/clover/core/device.cpp
>> >> >> > index bc6b761..6bf33e0 100644
>> >> >> > --- a/src/gallium/state_trackers/clover/core/device.cpp
>> >> >> > +++ b/src/gallium/state_trackers/clover/core/device.cpp
>> >> >> > @@ -193,6 +193,12 @@ device::half_fp_config() const {
>> >> >> > return CL_FP_DENORM | CL_FP_INF_NAN | CL_FP_ROUND_TO_NEAREST;
>> >> >> > }
>> >> >> >
>> >> >> > +bool
>> >> >> > +device::has_doubles() const {
>> >> >> > + return pipe->get_shader_param(pipe, PIPE_SHADER_COMPUTE,
>> >> >> > + PIPE_SHADER_CAP_DOUBLES);
>> >> >> > +}
>> >> >> > +
>> >> >> > 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 16831ab..025c648 100644
>> >> >> > --- a/src/gallium/state_trackers/clover/core/device.hpp
>> >> >> > +++ b/src/gallium/state_trackers/clover/core/device.hpp
>> >> >> > @@ -66,6 +66,7 @@ namespace clover {
>> >> >> >cl_device_fp_config single_fp_config() const;
>> >> >> >cl_device_fp_config double_fp_config() const;
>> >> >> >cl_device_fp_config half_fp_config() const;
>> >> >> > + bool has_doubles() const;
>> >> >> >
>> >> >> >std::vector max_block_size() const;
>> >> >> >std::string device_name() const;
>> >> >> > diff --git a/src/gallium/state_trackers/clover/core/program.cpp
>> >> >> > b/src/gallium/state_trackers/clover/core/program.cpp
>> >> >> > index e09c3aa..f65f321 100644
>> >> >> > --- a/src/gallium/state_trackers/clover/core/program.cpp
>> >> >> > +++ b/src/gallium/state_trackers/clover/core/program.cpp
>> >> >> > @@ -95,7 +95,10 @@ program::build_status(const device &dev) const {
>> >> >> >
>> >> >> > std::string
>> >> >> > program::build_opts(const device &dev) const {
>> >> >> > - return _opts.count(&dev) ? _opts.find(&dev)->second : "";
>> >> >> > + std::string opts = _opts.count(&dev) ? _opts.find(&dev)->second
>> >> >> > : "";
>> >> >> > + if (dev.has_doubles())
>> >> >> > + opts.append(" -Dcl_khr_fp64");
>> >> >> >
Re: [Mesa-dev] [PATCH 8/9] i965: Check after malloc success in intel_miptree_alloc_hiz()
On 04.07.2014 00:21, Kenneth Graunke wrote:
> On Thursday, July 03, 2014 11:13:18 AM Juha-Pekka Heikkila wrote:
>> Signed-off-by: Juha-Pekka Heikkila
>> ---
>> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> index 2ab0faa..30030d1 100644
>> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> @@ -1399,6 +1399,10 @@ intel_miptree_alloc_hiz(struct brw_context *brw,
>>
>>for (int layer = 0; layer < mt->level[level].depth; ++layer) {
>> struct intel_resolve_map *m = malloc(sizeof(struct
> intel_resolve_map));
>> + if (!m) {
>> +_mesa_error_no_memory(__func__);
>> +return false;
>> + }
>> exec_node_init(&m->link);
>> m->level = level;
>> m->layer = layer;
>>
>
> NAK. This might shut up the tool, but it's almost certainly not correct.
> You're leaving HiZ enabled for a level, but in a broken state.
>
> At the very least, I would expect to see mt->level[level].has_hiz = false. I
> don't know if that's sufficient.
>
> On Gen7+, HiZ is just an optional optimization, so you should be able to just
> turn it off, and have everything continue working, without needing to report
> an GL_OUT_OF_MEMORY error.
>
> In particular, you should be able to replace the malloc call here with "m =
> NULL", simulating a 100% malloc failure rate, and run Piglit. If you've
> solved this problem correctly, everything will continue working - there will
> be no crashes, no extra GL errors, and all the tests should continue passing.
Just out of curiosity, should such behavior be favored? There are other
places also where "out of memory" could be temporarily dodged but
should it be dodged? I'm thinking if allocation fails on these
structures it is already here quite fatal since if I don't report error
from this failure it probably will be very next allocation failing
unavoidably.
As is I see new crashes on Piglit when I force error here. There are two
types of crashes, ones where inside piglit asserting glError fails and
others where is SIGSEGV result. Did not yet check where SIGSEGV is
coming from.
>
> On Sandybridge we're probably just screwed, since failing to alloc HiZ (at
> least for level 0) means we need to disable separate stencil as well. I
> highly recommend ignoring that problem for now.
>
> --Ken
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/9] i965: check malloc return value in intel_resolve_map_set()
On 04.07.2014 00:29, Kenneth Graunke wrote:
> On Thursday, July 03, 2014 11:13:12 AM Juha-Pekka Heikkila wrote:
>> Signed-off-by: Juha-Pekka Heikkila
>> ---
>> src/mesa/drivers/dri/i965/intel_resolve_map.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_resolve_map.c
> b/src/mesa/drivers/dri/i965/intel_resolve_map.c
>> index bf6bcf2..bb45231 100644
>> --- a/src/mesa/drivers/dri/i965/intel_resolve_map.c
>> +++ b/src/mesa/drivers/dri/i965/intel_resolve_map.c
>> @@ -22,6 +22,7 @@
>> */
>>
>> #include "intel_resolve_map.h"
>> +#include "main/imports.h"
>>
>> #include
>> #include
>> @@ -46,6 +47,11 @@ intel_resolve_map_set(struct exec_list *resolve_map,
>> }
>>
>> struct intel_resolve_map *m = malloc(sizeof(struct intel_resolve_map));
>> + if (m == NULL) {
>> + _mesa_error_no_memory(__func__);
>> + return;
>> + }
>> +
>> exec_node_init(&m->link);
>> m->level = level;
>> m->layer = layer;
>>
>
> NAK.
>
On this I see Piglit giving new crashes when I force error here but all
of the crashes come with comment:
Mesa: User error: GL_OUT_OF_MEMORY in out of memory in intel_resolve_map_set
fbo-depthstencil:
/home/jheikkil/workspace/piglit/tests/fbo/fbo-depthstencil.c:483:
piglit_display: Assertion `piglit_dispatch_glGetError() == 0' failed.
I though that is acceptable since the failure is forced?
/Juha-Pekka
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH demos 1/2] demos: Fix make distcheck
Signed-off-by: Andreas Boll --- src/xdemos/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/xdemos/Makefile.am b/src/xdemos/Makefile.am index 0bdf13d..cfd23b1 100644 --- a/src/xdemos/Makefile.am +++ b/src/xdemos/Makefile.am @@ -79,7 +79,8 @@ xrotfontdemo_SOURCES = \ glxinfo_SOURCES = \ glxinfo.c \ - glinfo_common.c + glinfo_common.c \ + glinfo_common.h glthreads_LDADD = -lpthread glxgears_fbconfig_LDADD = libpbutil.la -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH demos 2/2] configure.ac: Fix help text
Matches behavior with action-if-not-given Signed-off-by: Andreas Boll --- configure.ac | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/configure.ac b/configure.ac index cd523c1..09c2cd5 100644 --- a/configure.ac +++ b/configure.ac @@ -111,7 +111,7 @@ DEMO_LIBS="$DEMO_LIBS $GLU_LIBS" AC_ARG_ENABLE([egl], [AS_HELP_STRING([--enable-egl], -[enable EGL library @<:@default=no@:>@])], +[enable EGL library @<:@default=auto@:>@])], [egl_enabled="$enableval"], [egl_enabled=auto]) if test "x$egl_enabled" != "xno"; then @@ -119,7 +119,7 @@ if test "x$egl_enabled" != "xno"; then fi AC_ARG_ENABLE([gles1], [AS_HELP_STRING([--enable-gles1], -[enable support for OpenGL ES 1.x API @<:@default=no@:>@])], +[enable support for OpenGL ES 1.x API @<:@default=auto@:>@])], [glesv1_enabled="$enableval"], [glesv1_enabled=auto]) if test "x$glesv1_enabled" != "xno"; then @@ -127,7 +127,7 @@ if test "x$glesv1_enabled" != "xno"; then fi AC_ARG_ENABLE([gles2], [AS_HELP_STRING([--enable-gles2], -[enable support for OpenGL ES 2.x API @<:@default=no@:>@])], +[enable support for OpenGL ES 2.x API @<:@default=auto@:>@])], [glesv2_enabled="$enableval"], [glesv2_enabled=auto]) if test "x$glesv2_enabled" != "xno"; then @@ -135,7 +135,7 @@ if test "x$glesv2_enabled" != "xno"; then fi AC_ARG_ENABLE([vg], [AS_HELP_STRING([--enable-vg], -[enable support for OpenVG API @<:@default=no@:>@])], +[enable support for OpenVG API @<:@default=auto@:>@])], [vg_enabled="$enableval"], [vg_enabled=auto]) if test "x$vg_enabled" != "xno"; then @@ -143,7 +143,7 @@ if test "x$vg_enabled" != "xno"; then fi AC_ARG_ENABLE([osmesa], [AS_HELP_STRING([--enable-osmesa], -[enable OSMesa library @<:@default=no@:>@])], +[enable OSMesa library @<:@default=auto@:>@])], [osmesa_enabled="$enableval"], [osmesa_enabled=auto]) if test "x$osmesa_enabled" != "xno"; then @@ -151,7 +151,7 @@ if test "x$osmesa_enabled" != "xno"; then fi AC_ARG_ENABLE([libdrm], [AS_HELP_STRING([--enable-libdrm], -[enable support for libdrm @<:@default=no@:>@])], +[enable support for libdrm @<:@default=auto@:>@])], [drm_enabled="$enableval"], [drm_enabled=auto]) if test "x$drm_enabled" != "xno"; then @@ -196,7 +196,7 @@ DEMO_CFLAGS="$DEMO_CFLAGS $CWARNFLAGS" AC_ARG_ENABLE([x11], [AS_HELP_STRING([--enable-x11], -[enable support for X11 @<:@default=no@:>@])], +[enable support for X11 @<:@default=auto@:>@])], [x11_enabled="$enableval"], [x11_enabled=auto]) if test "x$x11_enabled" != "xno"; then @@ -216,7 +216,7 @@ fi dnl GBM is needed for EGL on KMS AC_ARG_ENABLE([gbm], [AS_HELP_STRING([--enable-gbm], -[enable support for GBM @<:@default=no@:>@])], +[enable support for GBM @<:@default=auto@:>@])], [gbm_enabled="$enableval"], [gbm_enabled=auto]) if test "x$gbm_enabled" != "xno"; then @@ -226,7 +226,7 @@ fi dnl FreeType2 is needed by an OpenVG demo AC_ARG_ENABLE([freetype2], [AS_HELP_STRING([--enable-freetype2], -[enable support for FreeType2 @<:@default=no@:>@])], +[enable support for FreeType2 @<:@default=auto@:>@])], [freetype2_enabled="$enableval"], [freetype2_enabled=auto]) if test "x$freetype2_enabled" != "xno"; then -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] i965: Avoid null access in fs_generator::generate_code()
On Thu, Jul 03, 2014 at 05:31:19PM +0300, Juha-Pekka Heikkila wrote:
> On 03.07.2014 16:26, Pohjolainen, Topi wrote:
> > On Thu, Jul 03, 2014 at 11:13:17AM +0300, Juha-Pekka Heikkila wrote:
> >> Avoid null access while printing debug infos. On the same go
> >> change local variable name to avoid confusion because there
> >> already is class member with same name.
> >>
> >> Signed-off-by: Juha-Pekka Heikkila
> >> ---
> >> src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 8 ++--
> >> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> >> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> >> index 52e88d4..6e201d1 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> >> +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> >> @@ -1783,9 +1783,13 @@ fs_generator::generate_code(exec_list *instructions)
> >>dispatch_width, before_size / 16, before_size, after_size,
> >>100.0f * (before_size - after_size) / before_size);
> >>
> >
> > I had to check the context a bit, just before there is:
> >
> > if (prog) {
> > ...
> > } else if (fp) {
> > ...
> > } else {
> > fprintf(stderr, "Native code for blorp program (SIMD%d
> > dispatch):\n",
> > dispatch_width);
> > }
> >
> > As I remembered you are now addressing the special case of blorp programs.
> > After your change we can't dump them anymore (using env setting
> > INTEL_DEBUG=blorp).
>
> We should go to dump_assembly even if prog is NULL? When looking at
> dump_assembly I see prog being used only at intel_asm_printer around
> line 55 where it goes like:
>
> if (last_annotation_ir != annotation[i].ir) {
> last_annotation_ir = annotation[i].ir;
> if (last_annotation_ir) {
> fprintf(stderr, " ");
> if (!prog->Instructions)
>fprint_ir(stderr, annotation[i].ir);
> else {
>const struct prog_instruction *pi =
> (const struct prog_instruction *)annotation[i].ir;
>fprintf(stderr, "%d: ",
>(int)(pi - prog->Instructions));
>_mesa_fprint_instruction_opt(stderr,
> pi,
> 0, PROG_PRINT_DEBUG, NULL);
> }
> fprintf(stderr, "\n");
> }
>
> Line 55 is that "if (!prog->Instructions)".
>
> "if (last_annotation_ir != annotation[i].ir)" never matches when prog is
> also NULL?
In blorp there are no annotations and hence this path is not taken. So yes,
we should allow dumping without prog but then probably just ignore
annotations altogether.
I think the long term plan is still to get rid of blorp programs and
something simple should suffice, I think.
>
> >> - const struct gl_program *prog = fp ? &fp->Base : NULL;
> >> + const struct gl_program *fp_prog = fp ? &fp->Base : NULL;
> >> +
> >> + if (fp_prog) {
> >> + dump_assembly(p->store, annotation.ann_count, annotation.ann,
> >> brw,
> >> + fp_prog);
> >> + }
> >>
> >> - dump_assembly(p->store, annotation.ann_count, annotation.ann, brw,
> >> prog);
> >>ralloc_free(annotation.ann);
> >> }
> >> }
> >> --
> >> 1.8.1.2
> >>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH demos 0/3] demos release plan and glxinfo: Print more limits
On Fri, 2014-07-04 at 03:40 -0400, Ilia Mirkin wrote: > On Fri, Jul 4, 2014 at 3:37 AM, Steven Newbury > wrote: > > On Thu, 2014-07-03 at 10:47 +0200, Andreas Boll wrote: > > > 2014-07-03 7:39 GMT+02:00 Steven Newbury > > > : > > > > On Wed, 2014-07-02 at 21:04 +0200, Andreas Boll wrote: > > > > > > > > > > > I'd like to make a new demos release on Friday, July 4th. > > > > > The last release was on February 24th, 2013. Additionally > > > > > this > > > > > release is needed to fix the build with mesa 10.2. > > > > > (fdo#78101) > > > > > > > > > > > > Any objections? > > > > > > > > > > > > Also I'd like to get these 3 patches included in the new > > > > > release. > > > > > > > > > > > > Andreas. > > > > > > > > > > > > > > > > > > > Fredrik Höglund (3): > > > > > glxinfo: Print XFB, TBO, and UBO limits > > > > > glxinfo: Print GL_ARB_vertex_attrib_binding limits > > > > > glxinfo: Print GL_EXT_texture_array limits > > > > > > > > > > > >src/xdemos/glinfo_common.c | 30 > > > > > ++ > > > > >1 file changed, 30 insertions(+) > > > > > > > > > > > > > > > > > What about extending eglinfo to have switches to enable > > > > printing > > > > glxinfo > > > > style output for each supported API? > > > > > > > > > > > > > Sounds good, feel free to send a patch. > > > Although I'm not planning to hold off this release. > > > I can make further releases when required. > > > > > > > > > > I've been giving this some more thought, it occurs to me that > > since > > there's already es1_info/es2_info progs, what's really needed is > > an > > EGL version of glxinfo/wglinfo (egl_glinfo?) which should be able > > to > > share the glinfo_common code. > > > > > While digging though the existing code I noticed the above > > mentioned > > es*_info program only works with X11 EGL, that should probably be > > improved too... > > > > > Shall I see if I can code something up to get glinfo output > > through > > EGL? Would this be he best approach? > > I'm sure I'm missing something, but what's wrong with eglinfo? > > http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglinfo.c > > It doesn't share the glinfo_common code, but that should be easily > arranged, I would think. Of course it's an option to extend eglinfo with switches to select API, but there is already es*_info, which is what made me thing it might be the better approach. I'm perfectly happy to hack on eglinfo instead! :-) signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH demos 0/3] demos release plan and glxinfo: Print more limits
On Fri, Jul 4, 2014 at 3:37 AM, Steven Newbury wrote: > On Thu, 2014-07-03 at 10:47 +0200, Andreas Boll wrote: >> 2014-07-03 7:39 GMT+02:00 Steven Newbury : >> > On Wed, 2014-07-02 at 21:04 +0200, Andreas Boll wrote: >> > > >> > > I'd like to make a new demos release on Friday, July 4th. >> > > The last release was on February 24th, 2013. Additionally this >> > > release is needed to fix the build with mesa 10.2. (fdo#78101) >> > > > >> > > Any objections? >> > > > >> > > Also I'd like to get these 3 patches included in the new >> > > release. >> > > > >> > > Andreas. >> > > > >> > > > >> > > Fredrik Höglund (3): >> > >glxinfo: Print XFB, TBO, and UBO limits >> > >glxinfo: Print GL_ARB_vertex_attrib_binding limits >> > >glxinfo: Print GL_EXT_texture_array limits >> > > > >> > > src/xdemos/glinfo_common.c | 30 ++ >> > > 1 file changed, 30 insertions(+) >> > > > >> > > >> > What about extending eglinfo to have switches to enable printing >> > glxinfo >> > style output for each supported API? >> > > >> >> Sounds good, feel free to send a patch. >> Although I'm not planning to hold off this release. >> I can make further releases when required. >> >> > I've been giving this some more thought, it occurs to me that since > there's already es1_info/es2_info progs, what's really needed is an > EGL version of glxinfo/wglinfo (egl_glinfo?) which should be able to > share the glinfo_common code. > > While digging though the existing code I noticed the above mentioned > es*_info program only works with X11 EGL, that should probably be > improved too... > > Shall I see if I can code something up to get glinfo output through > EGL? Would this be he best approach? I'm sure I'm missing something, but what's wrong with eglinfo? http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglinfo.c It doesn't share the glinfo_common code, but that should be easily arranged, I would think. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH demos 0/3] demos release plan and glxinfo: Print more limits
On Thu, 2014-07-03 at 10:47 +0200, Andreas Boll wrote: > 2014-07-03 7:39 GMT+02:00 Steven Newbury : > > On Wed, 2014-07-02 at 21:04 +0200, Andreas Boll wrote: > > > > > > I'd like to make a new demos release on Friday, July 4th. > > > The last release was on February 24th, 2013. Additionally this > > > release is needed to fix the build with mesa 10.2. (fdo#78101) > > > > > > > Any objections? > > > > > > > Also I'd like to get these 3 patches included in the new > > > release. > > > > > > > Andreas. > > > > > > > > > > > Fredrik Höglund (3): > > >glxinfo: Print XFB, TBO, and UBO limits > > >glxinfo: Print GL_ARB_vertex_attrib_binding limits > > >glxinfo: Print GL_EXT_texture_array limits > > > > > > > src/xdemos/glinfo_common.c | 30 ++ > > > 1 file changed, 30 insertions(+) > > > > > > > > > What about extending eglinfo to have switches to enable printing > > glxinfo > > style output for each supported API? > > > > > Sounds good, feel free to send a patch. > Although I'm not planning to hold off this release. > I can make further releases when required. > > I've been giving this some more thought, it occurs to me that since there's already es1_info/es2_info progs, what's really needed is an EGL version of glxinfo/wglinfo (egl_glinfo?) which should be able to share the glinfo_common code. While digging though the existing code I noticed the above mentioned es*_info program only works with X11 EGL, that should probably be improved too... Shall I see if I can code something up to get glinfo output through EGL? Would this be he best approach? signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] i965/gen7: Don't allocate hiz miptree structure
On Wednesday, July 02, 2014 12:33:16 PM Jordan Justen wrote:
> On Wed, Jul 2, 2014 at 5:39 AM, Pohjolainen, Topi
> wrote:
> > On Tue, Jul 01, 2014 at 04:53:06PM -0700, Jordan Justen wrote:
> >> We now skip allocating a hiz miptree for gen7. Instead, we calculate
> >> the required hiz buffer parameters and allocate a bo directly.
> >>
> >> Signed-off-by: Jordan Justen
> >> ---
> >> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 67
++-
> >> 1 file changed, 65 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> >> index 8719c29..b308b0c 100644
> >> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> >> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> >> @@ -823,7 +823,10 @@ intel_miptree_release(struct intel_mipmap_tree **mt)
> >>drm_intel_bo_unreference((*mt)->bo);
> >>intel_miptree_release(&(*mt)->stencil_mt);
> >>if ((*mt)->hiz_buf) {
> >> - intel_miptree_release(&(*mt)->hiz_buf->mt);
> >> + if ((*mt)->hiz_buf->mt)
> >> +intel_miptree_release(&(*mt)->hiz_buf->mt);
> >> + else
> >> +drm_intel_bo_unreference((*mt)->hiz_buf->bo);
> >> free((*mt)->hiz_buf);
> >>}
> >>intel_miptree_release(&(*mt)->mcs_mt);
> >> @@ -1375,6 +1378,61 @@ intel_miptree_level_enable_hiz(struct brw_context
*brw,
> >>
> >>
> >> static struct intel_miptree_aux_buffer *
> >> +intel_hiz_buf_create(struct brw_context *brw,
> >> + struct intel_mipmap_tree *mt)
> >> +{
> >> + unsigned hz_width, hz_height;
> >> + unsigned H0, h0, h1, Z0;
> >> + const unsigned j = 8;
> >
> > This could read 'vertical_align' instead of 'j'.
>
> I wanted to stick with the 'j' terminology from the docs. Although,
> I'm not consistent about sticking with the docs, so how about a v2
> where I'm more consistent about that?
I tend to prefer the more descriptive name as well. How about:
const unsigned vertical_align = 8; /* 'j' in the docs */
In other places, we've called this align_h, which I hate (is 'h' height or
horizontal?)
But, it's up to you.
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glxinfo: remove query of GL_MAX_VERTEX_ATTRIB_STRIDE
Both patches are
Reviewed-by: Andreas Boll
Thanks for fixing this issue!
I'll make the release after this series has been merged.
Andreas.
2014-07-03 16:19 GMT+02:00 Brian Paul :
> This is not part of the GL_ARB_vertex_attrib_binding extension.
> It's part of OpenGL 4.4.
> Fixes compilation failure if glext.h doesn't have the GL 4.4 #defines.
> ---
> src/xdemos/glinfo_common.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c
> index 1326a86..4360e53 100644
> --- a/src/xdemos/glinfo_common.c
> +++ b/src/xdemos/glinfo_common.c
> @@ -563,7 +563,6 @@ print_limits(const char *extensions, const char
> *oglstring, int version,
> #endif
> #if defined (GL_ARB_vertex_attrib_binding)
>{ 1, GL_MAX_VERTEX_ATTRIB_RELATIVE_OFFSET,
> "GL_MAX_VERTEX_ATTRIB_RELATIVE_OFFSET", "GL_ARB_vertex_attrib_binding" },
> - { 1, GL_MAX_VERTEX_ATTRIB_STRIDE, "GL_MAX_VERTEX_ATTRIB_STRIDE",
> "GL_ARB_vertex_attrib_binding" },
>{ 1, GL_MAX_VERTEX_ATTRIB_BINDINGS, "GL_MAX_VERTEX_ATTRIB_BINDINGS",
> "GL_ARB_vertex_attrib_binding" },
> #endif
>{ 0, (GLenum) 0, NULL, NULL }
> --
> 1.7.10.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
