Re: [Mesa-dev] [PATCH 1/2] tgsi: texture types
So, afaiu, everything that might insert a sampler is using tgsi_transform_shader()? There aren't too many of those, and I think I can fix them up to not violate that constraint. (It does occur to me that I may end up needing to fix u_blitter to differentiate between blitting float vs int to avoid some regressions in freedreno, since I'd no longer be using shader variants based on bound samplers.. but I guess that is unrelated and a separate patch) BR, -R On Wed, Jun 10, 2015 at 2:55 PM, Roland Scheidegger wrote: > My biggest problem with that is the initial case I saw as a problem: > draw is going to modify these shaders in some cases (aaline stage for > example), adding its own sampler, and it doesn't know anything about > distinguishing shaders with sampler views or without. > The same goes for any other potential code which may modify shaders > similarly - needs to be modified not just to always use sampler views > but use them based on if the incoming shader already uses them or not. > Which conceptually looks worse to me. But otherwise I agree this should > work. > > Roland > > > Am 10.06.2015 um 20:30 schrieb Rob Clark: >> Hmm, at least tgsi_text_translate() doesn't appear to use tgsi_ureg.. >> and there are still a number of users of tgsi_text_translate().. I >> guess handling this in tgsi_ureg would avoid fixing all the tgsi_ureg >> users, but that still leaves a lot of others. Changing them all still >> seems to be too intrusive to me. >> >> (And also, I have a large collection of saved tgsi shaders that I use >> for standalone testing of my shader compiler and don't really like the >> idea of fixing up 700 or 800 tgsi shaders by hand :-P) >> >> That said, looking at the code like llvmpipe where Roland/Jose where >> thinking we might have problems.. by making the assumption that we >> never mix TEX* and SAMPLE* opc's, I think we can loosen the >> restriction to: >> >> for TEX* instructions, the tgsi must either *not* include SVIEW, or >> *must* include a matching SVIEW[idx] for every SAMP[idx] >> >> Which is a restriction that glsl_to_tgsi follows. >> >> If you follow this restriction, then for TEX* shaders which have >> SVIEW's, file_max[TGSI_FILE_SAMPLER_VIEW] == >> file_max[TGSI_FILE_SAMPLER] and file_mask[TGSI_FILE_SAMPLER_VIEW] == >> file_mask[TGSI_FILE_SAMPLER].. so code takes a different but >> equivalent path. And for TEX* shaders which don't have SVIEW's >> everything continues to work as before. >> >> With this approach, we don't have to fix up everything to create >> SVIEW[idx] for every SAMP[idx], as long as glsl_to_tgsi always creates >> SVIEW[idx] for each SAMP[idx], and any other tgsi generator that later >> adds SVIEW support for TEX* instructions follows the same pattern. >> >> So, tl;dr: I think really all I need to add to this patch is add blurb >> in tgsi.rst to explain this restriction and usage of SVIEW for TEX* >> >> Thoughts? >> >> BR, >> -R >> >> On Tue, Jun 9, 2015 at 1:20 PM, Marek Olšák wrote: >>> If you only want to modify TGSI and not all the users, you only have >>> to fix tgsi_ureg. tgsi_ureg is a layer that can hide a lot of small >>> ugly details if needed, including sampler view declarations when the >>> users don't even know about them. >>> >>> Marek >>> >>> >>> >>> >>> >>> On Tue, Jun 9, 2015 at 6:01 PM, Rob Clark wrote: >>>> On Tue, Jun 9, 2015 at 9:32 AM, Roland Scheidegger >>>> wrote: >>>>> Am 09.06.2015 um 15:00 schrieb Rob Clark: >>>>>> On Tue, Jun 9, 2015 at 5:01 AM, Jose Fonseca wrote: >>>>>>> On 09/06/15 04:03, Rob Clark wrote: >>>>>>>> >>>>>>>> On Mon, Jun 8, 2015 at 10:50 PM, Roland Scheidegger >>>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Am 09.06.2015 um 04:40 schrieb Rob Clark: >>>>>>>>>> >>>>>>>>>> On Mon, Jun 8, 2015 at 10:36 PM, Roland Scheidegger >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Am 09.06.2015 um 04:20 schrieb Rob Clark: >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Jun 8, 2015 at 9:40 PM, Roland Scheidegger >>>>>>>>>>>> wrote: >>>>>>>>&g
Re: [Mesa-dev] [PATCH 1/2] tgsi: texture types
that is starting to look more attractive, mostly just because tgsi_transform stuff is so cumbersome.. (I did start thinking about just adding type to decl's in general, since really it would be better to have for type information for IN's and OUT's too.. but then decided I'd probably rather spend my time on support in mesa st to go straight from glsl to nir and bypass tgsi, rather than going down that rabbit hole) BR, -R On Wed, Jun 10, 2015 at 3:51 PM, Marek Olšák wrote: > There is also the option of adding the sampler type to either the SAMP > declaration or texture instructions. This will move us further away > from adopting SVIEW, but I don't see that happening for OpenGL anyway. > > Marek > > On Wed, Jun 10, 2015 at 8:59 PM, Rob Clark wrote: >> So, afaiu, everything that might insert a sampler is using >> tgsi_transform_shader()? There aren't too many of those, and I think >> I can fix them up to not violate that constraint. >> >> (It does occur to me that I may end up needing to fix u_blitter to >> differentiate between blitting float vs int to avoid some regressions >> in freedreno, since I'd no longer be using shader variants based on >> bound samplers.. but I guess that is unrelated and a separate patch) >> >> BR, >> -R >> >> On Wed, Jun 10, 2015 at 2:55 PM, Roland Scheidegger >> wrote: >>> My biggest problem with that is the initial case I saw as a problem: >>> draw is going to modify these shaders in some cases (aaline stage for >>> example), adding its own sampler, and it doesn't know anything about >>> distinguishing shaders with sampler views or without. >>> The same goes for any other potential code which may modify shaders >>> similarly - needs to be modified not just to always use sampler views >>> but use them based on if the incoming shader already uses them or not. >>> Which conceptually looks worse to me. But otherwise I agree this should >>> work. >>> >>> Roland >>> >>> >>> Am 10.06.2015 um 20:30 schrieb Rob Clark: >>>> Hmm, at least tgsi_text_translate() doesn't appear to use tgsi_ureg.. >>>> and there are still a number of users of tgsi_text_translate().. I >>>> guess handling this in tgsi_ureg would avoid fixing all the tgsi_ureg >>>> users, but that still leaves a lot of others. Changing them all still >>>> seems to be too intrusive to me. >>>> >>>> (And also, I have a large collection of saved tgsi shaders that I use >>>> for standalone testing of my shader compiler and don't really like the >>>> idea of fixing up 700 or 800 tgsi shaders by hand :-P) >>>> >>>> That said, looking at the code like llvmpipe where Roland/Jose where >>>> thinking we might have problems.. by making the assumption that we >>>> never mix TEX* and SAMPLE* opc's, I think we can loosen the >>>> restriction to: >>>> >>>> for TEX* instructions, the tgsi must either *not* include SVIEW, or >>>> *must* include a matching SVIEW[idx] for every SAMP[idx] >>>> >>>> Which is a restriction that glsl_to_tgsi follows. >>>> >>>> If you follow this restriction, then for TEX* shaders which have >>>> SVIEW's, file_max[TGSI_FILE_SAMPLER_VIEW] == >>>> file_max[TGSI_FILE_SAMPLER] and file_mask[TGSI_FILE_SAMPLER_VIEW] == >>>> file_mask[TGSI_FILE_SAMPLER].. so code takes a different but >>>> equivalent path. And for TEX* shaders which don't have SVIEW's >>>> everything continues to work as before. >>>> >>>> With this approach, we don't have to fix up everything to create >>>> SVIEW[idx] for every SAMP[idx], as long as glsl_to_tgsi always creates >>>> SVIEW[idx] for each SAMP[idx], and any other tgsi generator that later >>>> adds SVIEW support for TEX* instructions follows the same pattern. >>>> >>>> So, tl;dr: I think really all I need to add to this patch is add blurb >>>> in tgsi.rst to explain this restriction and usage of SVIEW for TEX* >>>> >>>> Thoughts? >>>> >>>> BR, >>>> -R >>>> >>>> On Tue, Jun 9, 2015 at 1:20 PM, Marek Olšák wrote: >>>>> If you only want to modify TGSI and not all the users, you only have >>>>> to fix tgsi_ureg. tgsi_ureg is a layer that can hide a lot of small >>>>> ugly details if needed, including sampler view declarations when the
Re: [Mesa-dev] [PATCH 1/2] tgsi: texture types
On Wed, Jun 10, 2015 at 5:13 PM, Jose Fonseca wrote: > I think it make sense for us to start using SVIEW regardless, and uniformize > things. > > > Even if GLSL will never support independent texture/samplers, D3D10, OpenCL, > Metal, and potential SPIR-V all do. > > Roland, could you prepare a patch for llvmpipe, so that it infers from > SAMPLE_* opcode count instead of SVIEW for, and therefore unblock Rob? > fwiw, I've got the three tgsi_transform_shader() cases which insert a SAMP updated to insert also an SVIEW if the shader is already using SVIEW's.. this should be enough to keep llvmpipe happy without changes. I'll send this plus tgsi.rst update shortly. Going forward, I will have to make u_blitter keep track of int/unsigned/float variants (which it seems to do already for msaa resolve but not other cases), and similar treatment for some freedreno internally generated shaders (used to restore the tile buffer). > > BTW, even if you avoid intermediate TGSI on GLSL -> NIR, don't you still > need to handle TGSI generated by the state tracker? (For things like blits, > and mipmap generation, identity shaders, clear shaders, etc) > yeah.. rough idea was add a 'const void *preferred_ir' to pipe_shader_state, which could be NIR or whatever based on PIPE_SHADER_CAP_PREFERRED_IR. Or it could be NULL in which case you get tgsi tokens ptr instead and have to call tgsi_to_nir yourself. I didn't see an easy way around that, given u_blitter, other state trackers, etc. The biggest reason that I expect to want to go straight glsl->nir in the future is when nir gains mediump support, since that can be a bit perf win on mobile (gles oriented) hw, and it didn't seem like fun to have to plumb that through tgsi and tgsi_to_nir.. BR, -R > > Jose > > > > On 10/06/15 21:07, Rob Clark wrote: >> >> that is starting to look more attractive, mostly just because >> tgsi_transform stuff is so cumbersome.. >> >> (I did start thinking about just adding type to decl's in general, >> since really it would be better to have for type information for IN's >> and OUT's too.. but then decided I'd probably rather spend my time on >> support in mesa st to go straight from glsl to nir and bypass tgsi, >> rather than going down that rabbit hole) >> >> BR, >> -R >> >> On Wed, Jun 10, 2015 at 3:51 PM, Marek Olšák wrote: >>> >>> There is also the option of adding the sampler type to either the SAMP >>> declaration or texture instructions. This will move us further away >>> from adopting SVIEW, but I don't see that happening for OpenGL anyway. >>> >>> Marek >>> >>> On Wed, Jun 10, 2015 at 8:59 PM, Rob Clark wrote: >>>> >>>> So, afaiu, everything that might insert a sampler is using >>>> tgsi_transform_shader()? There aren't too many of those, and I think >>>> I can fix them up to not violate that constraint. >>>> >>>> (It does occur to me that I may end up needing to fix u_blitter to >>>> differentiate between blitting float vs int to avoid some regressions >>>> in freedreno, since I'd no longer be using shader variants based on >>>> bound samplers.. but I guess that is unrelated and a separate patch) >>>> >>>> BR, >>>> -R >>>> >>>> On Wed, Jun 10, 2015 at 2:55 PM, Roland Scheidegger >>>> wrote: >>>>> >>>>> My biggest problem with that is the initial case I saw as a problem: >>>>> draw is going to modify these shaders in some cases (aaline stage for >>>>> example), adding its own sampler, and it doesn't know anything about >>>>> distinguishing shaders with sampler views or without. >>>>> The same goes for any other potential code which may modify shaders >>>>> similarly - needs to be modified not just to always use sampler views >>>>> but use them based on if the incoming shader already uses them or not. >>>>> Which conceptually looks worse to me. But otherwise I agree this should >>>>> work. >>>>> >>>>> Roland >>>>> >>>>> >>>>> Am 10.06.2015 um 20:30 schrieb Rob Clark: >>>>>> >>>>>> Hmm, at least tgsi_text_translate() doesn't appear to use tgsi_ureg.. >>>>>> and there are still a number of users of tgsi_text_translate().. I >>>>>> guess handling this in tgsi_ureg would avoid fixing all the tgsi_ureg >>>>>> users, but that still leaves a lot
Re: [Mesa-dev] Request for Mentorship
On Wed, Jun 10, 2015 at 7:28 PM, Emil Velikov wrote: > On 5 June 2015 at 22:08, Rob Clark wrote: >> so, maybe a bit off topic (and maybe doesn't really help with the >> whole finding a mentor thing).. but a sort of wish-list thing for >> piglit that I've had in the back of my head is something like "tig" >> for piglit. I suppose it doesn't have to necessarily be a curses >> based UI, it could be gui.. but a lot of times while I find myself >> searching through results.json to find cmdline to re-run failed tests, >> which is kind of time consuming. Some sort of front-end to piglit >> which would let me do things like filter on test status, then see >> output/results and if I want re-run the selected test(s) would be kind >> of nice. >> > Sounds like exactly what the html test summary provides. Although I'm > not sure how many people actually use it - json seems to be more > popular nowadays :-) I even recall naggin' on Dylan when things broke > on an occasion or two. except html is neither interactive nor fast/convenient ;-) The use case I'm thinking of is mostly driver devel/debug where I want to check if some updated version of a change I am working on fixed the regressions, and that sort of thing. (Or re-run the failed tests with some FD_MESA_DEBUG env var debug flag.) So ability to re-run individual tests (or group of tests based on filtered result status, etc) is what I'm looking for. Versus digging through .json or html to find individual cmdlines for some 100's of tests ;-) > -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/7] util/pstipple: updates for SVIEW decls
From: Rob Clark
To allow for shaders which use SVIEW decls for TEX* instructions, we
need to preserve the constraint that the shader either has no SVIEW's or
it has one matching SVIEW for each SAMP.
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/util/u_pstipple.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_pstipple.c
b/src/gallium/auxiliary/util/u_pstipple.c
index 0a20bdb..4ab1994 100644
--- a/src/gallium/auxiliary/util/u_pstipple.c
+++ b/src/gallium/auxiliary/util/u_pstipple.c
@@ -55,7 +55,7 @@
#include "tgsi/tgsi_scan.h"
/** Approx number of new tokens for instructions in pstip_transform_inst() */
-#define NUM_NEW_TOKENS 50
+#define NUM_NEW_TOKENS 53
static void
@@ -262,6 +262,7 @@ pstip_transform_prolog(struct tgsi_transform_context *ctx)
(struct pstip_transform_context *) ctx;
int wincoordInput;
int texTemp;
+ int sampIdx;
/* find free texture sampler */
pctx->freeSampler = free_bit(pctx->samplersUsed);
@@ -280,9 +281,24 @@ pstip_transform_prolog(struct tgsi_transform_context *ctx)
TGSI_INTERPOLATE_LINEAR);
}
+ sampIdx = pctx->hasFixedUnit ? pctx->fixedUnit : pctx->freeSampler;
+
/* declare new sampler */
- tgsi_transform_sampler_decl(ctx,
- pctx->hasFixedUnit ? pctx->fixedUnit : pctx->freeSampler);
+ tgsi_transform_sampler_decl(ctx, sampIdx);
+
+ /* if the src shader has SVIEW decl's for each SAMP decl, we
+* need to continue the trend and ensure there is a matching
+* SVIEW for the new SAMP we just created
+*/
+ if (pctx->info.file_max[TGSI_FILE_SAMPLER_VIEW] != -1) {
+ tgsi_transform_sampler_view_decl(ctx,
+ sampIdx,
+ TGSI_TEXTURE_2D,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT);
+ }
/* Declare temp[0] reg if not already declared.
* We can always use temp[0] since this code is before
@@ -321,8 +337,7 @@ pstip_transform_prolog(struct tgsi_transform_context *ctx)
tgsi_transform_tex_2d_inst(ctx,
TGSI_FILE_TEMPORARY, texTemp,
TGSI_FILE_TEMPORARY, texTemp,
- pctx->hasFixedUnit ? pctx->fixedUnit
- : pctx->freeSampler);
+ sampIdx);
/* KILL_IF -texTemp; # if -texTemp < 0, kill fragment */
tgsi_transform_kill_inst(ctx,
--
2.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/7] draw: updates to support SVIEW decls
From: Rob Clark
To allow for shaders which use SVIEW decls for TEX* instructions, we
need to preserve the constraint that the shader either has no SVIEW's or
it has one matching SVIEW for each SAMP.
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/draw/draw_pipe_aaline.c | 20 +++-
src/gallium/auxiliary/draw/draw_pipe_pstipple.c | 20 +++-
2 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
index 2f14efe..27c69dd 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
@@ -51,7 +51,7 @@
/** Approx number of new tokens for instructions in aa_transform_inst() */
-#define NUM_NEW_TOKENS 50
+#define NUM_NEW_TOKENS 53
/**
@@ -137,6 +137,7 @@ struct aa_transform_context {
uint tempsUsed; /**< bitmask */
int colorOutput; /**< which output is the primary color */
uint samplersUsed; /**< bitfield of samplers used */
+ bool hasSview;
int freeSampler; /** an available sampler for the pstipple */
int maxInput, maxGeneric; /**< max input index found */
int colorTemp, texTemp; /**< temp registers */
@@ -165,6 +166,9 @@ aa_transform_decl(struct tgsi_transform_context *ctx,
aactx->samplersUsed |= 1 << i;
}
}
+ else if (decl->Declaration.File == TGSI_FILE_SAMPLER_VIEW) {
+ aactx->hasSview = true;
+ }
else if (decl->Declaration.File == TGSI_FILE_INPUT) {
if ((int) decl->Range.Last > aactx->maxInput)
aactx->maxInput = decl->Range.Last;
@@ -232,6 +236,20 @@ aa_transform_prolog(struct tgsi_transform_context *ctx)
/* declare new sampler */
tgsi_transform_sampler_decl(ctx, aactx->freeSampler);
+ /* if the src shader has SVIEW decl's for each SAMP decl, we
+* need to continue the trend and ensure there is a matching
+* SVIEW for the new SAMP we just created
+*/
+ if (aactx->hasSview) {
+ tgsi_transform_sampler_view_decl(ctx,
+ aactx->freeSampler,
+ TGSI_TEXTURE_2D,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT);
+ }
+
/* declare new temp regs */
tgsi_transform_temp_decl(ctx, aactx->texTemp);
tgsi_transform_temp_decl(ctx, aactx->colorTemp);
diff --git a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
index 8f21c46..1e6ebe6 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
@@ -53,7 +53,7 @@
/** Approx number of new tokens for instructions in pstip_transform_inst() */
-#define NUM_NEW_TOKENS 50
+#define NUM_NEW_TOKENS 53
/**
@@ -126,6 +126,7 @@ struct pstip_transform_context {
int wincoordInput;
int maxInput;
uint samplersUsed; /**< bitfield of samplers used */
+ bool hasSview;
int freeSampler; /** an available sampler for the pstipple */
int texTemp; /**< temp registers */
int numImmed;
@@ -149,6 +150,9 @@ pstip_transform_decl(struct tgsi_transform_context *ctx,
pctx->samplersUsed |= 1 << i;
}
}
+ else if (decl->Declaration.File == TGSI_FILE_SAMPLER_VIEW) {
+ pctx->hasSview = true;
+ }
else if (decl->Declaration.File == TGSI_FILE_INPUT) {
pctx->maxInput = MAX2(pctx->maxInput, (int) decl->Range.Last);
if (decl->Semantic.Name == TGSI_SEMANTIC_POSITION)
@@ -232,6 +236,20 @@ pstip_transform_prolog(struct tgsi_transform_context *ctx)
/* declare new sampler */
tgsi_transform_sampler_decl(ctx, pctx->freeSampler);
+ /* if the src shader has SVIEW decl's for each SAMP decl, we
+* need to continue the trend and ensure there is a matching
+* SVIEW for the new SAMP we just created
+*/
+ if (pctx->hasSview) {
+ tgsi_transform_sampler_view_decl(ctx,
+ pctx->freeSampler,
+ TGSI_TEXTURE_2D,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT);
+ }
+
/* declare new temp regs */
tgsi_transform_temp_decl(ctx, pctx->texTemp);
--
2.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/7] tgsi: update docs for SVIEW usage with TEX* instructions
From: Rob Clark Based on mailing list discussion here: http://lists.freedesktop.org/archives/mesa-dev/2014-November/071583.html Signed-off-by: Rob Clark --- src/gallium/docs/source/tgsi.rst | 12 1 file changed, 12 insertions(+) diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst index f77702a..89ca172 100644 --- a/src/gallium/docs/source/tgsi.rst +++ b/src/gallium/docs/source/tgsi.rst @@ -2965,6 +2965,18 @@ resource can be one of BUFFER, 1D, 2D, 3D, 1DArray and 2DArray. type must be 1 or 4 entries (if specifying on a per-component level) out of UNORM, SNORM, SINT, UINT and FLOAT. +For TEX\* style texture sample opcodes (as opposed to SAMPLE\* opcodes +which take an explicit SVIEW[#] source register), there may be optionally +SVIEW[#] declarations. In this case, the SVIEW index is implied by the +SAMP index, and there must be a corresponding SVIEW[#] declaration for +each SAMP[#] declaration. Drivers are free to ignore this if they wish. +But note in particular that some drivers need to know the sampler type +(float/int/unsigned) in order to generate the correct code, so cases +where integer textures are sampled, SVIEW[#] declarations should be +used. + +NOTE: It is NOT legal to mix SAMPLE\* style opcodes and TEX\* opcodes +in the same shader. Declaration Resource -- 2.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/7] gallium/ttn: add texture-type support
From: Rob Clark
v2: rebased on using SVIEW to hold type information
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 44 -
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 1702b41..d0291e5 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -58,6 +58,9 @@ struct ttn_compile {
struct ttn_reg_info *temp_regs;
nir_ssa_def **imm_defs;
+ unsigned num_samp_types;
+ nir_alu_type *samp_types;
+
nir_register *addr_reg;
/**
@@ -156,6 +159,30 @@ ttn_emit_declaration(struct ttn_compile *c)
/* Nothing to record for system values. */
} else if (file == TGSI_FILE_SAMPLER) {
/* Nothing to record for samplers. */
+ } else if (file == TGSI_FILE_SAMPLER_VIEW) {
+ struct tgsi_declaration_sampler_view *sview = &decl->SamplerView;
+ nir_alu_type type;
+
+ debug_assert((sview->ReturnTypeX == sview->ReturnTypeY) &&
+ (sview->ReturnTypeX == sview->ReturnTypeZ) &&
+ (sview->ReturnTypeX == sview->ReturnTypeW));
+
+ switch (sview->ReturnTypeX) {
+ case TGSI_RETURN_TYPE_SINT:
+ type = nir_type_int;
+ break;
+ case TGSI_RETURN_TYPE_UINT:
+ type = nir_type_unsigned;
+ break;
+ case TGSI_RETURN_TYPE_FLOAT:
+ default:
+ type = nir_type_float;
+ break;
+ }
+
+ for (i = 0; i < array_size; i++) {
+ c->samp_types[decl->Range.First + i] = type;
+ }
} else {
nir_variable *var;
assert(file == TGSI_FILE_INPUT ||
@@ -1026,7 +1053,7 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
struct tgsi_full_instruction *tgsi_inst = &c->token->FullInstruction;
nir_tex_instr *instr;
nir_texop op;
- unsigned num_srcs, samp = 1, i;
+ unsigned num_srcs, samp = 1, sview, i;
switch (tgsi_inst->Instruction.Opcode) {
case TGSI_OPCODE_TEX:
@@ -1105,6 +1132,18 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
assert(tgsi_inst->Src[samp].Register.File == TGSI_FILE_SAMPLER);
instr->sampler_index = tgsi_inst->Src[samp].Register.Index;
+ /* TODO if we supported any opc's which take an explicit SVIEW
+* src, we would use that here instead. But for the "legacy"
+* texture opc's the SVIEW index is same as SAMP index:
+*/
+ sview = instr->sampler_index;
+
+ if (sview < c->num_samp_types) {
+ instr->dest_type = c->samp_types[sview];
+ } else {
+ instr->dest_type = nir_type_float;
+ }
+
unsigned src_number = 0;
instr->src[src_number].src =
@@ -1710,6 +1749,9 @@ tgsi_to_nir(const void *tgsi_tokens,
c->imm_defs = rzalloc_array(c, nir_ssa_def *,
scan.file_max[TGSI_FILE_IMMEDIATE] + 1);
+ c->num_samp_types = scan.file_max[TGSI_FILE_SAMPLER_VIEW] + 1;
+ c->samp_types = rzalloc_array(c, nir_alu_type, c->num_samp_types);
+
c->if_stack = rzalloc_array(c, struct exec_list *,
(scan.opcode_count[TGSI_OPCODE_IF] +
scan.opcode_count[TGSI_OPCODE_UIF]) * 2);
--
2.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/7] util/blitter (and friends): generate appropriate SVIEW decls
From: Rob Clark
Some hardware needs to know the sampler type. Update the blit related
shaders to include SVIEW decl.
Signed-off-by: Rob Clark
---
Possibly I should have refactored the existing code to pass around a
return_type rather than doing the is_uint/is_sint thing everywhere.
And this does kind of ignore UNORM/SNORM.. although I'm not really
sure that we need shader variants for UNORM/SNORM (we don't have this
information in GLSL IR or NIR IR, and I don't know any hw that doesn't
just treat those as FLOAT in the shader compiler). Anyways, sending
it out as-is for comments.
src/gallium/auxiliary/util/u_blit.c | 32 +
src/gallium/auxiliary/util/u_blitter.c| 42
src/gallium/auxiliary/util/u_simple_shaders.c | 69 +++
src/gallium/auxiliary/util/u_simple_shaders.h | 15 --
src/gallium/auxiliary/util/u_tests.c | 3 +-
src/gallium/tests/trivial/quad-tex.c | 2 +-
6 files changed, 132 insertions(+), 31 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blit.c
b/src/gallium/auxiliary/util/u_blit.c
index 3f3b5fe..0062d96 100644
--- a/src/gallium/auxiliary/util/u_blit.c
+++ b/src/gallium/auxiliary/util/u_blit.c
@@ -65,7 +65,7 @@ struct blit_state
struct pipe_vertex_element velem[2];
void *vs;
- void *fs[PIPE_MAX_TEXTURE_TYPES][TGSI_WRITEMASK_XYZW + 1];
+ void *fs[PIPE_MAX_TEXTURE_TYPES][TGSI_WRITEMASK_XYZW + 1][3];
struct pipe_resource *vbuf; /**< quad vertices */
unsigned vbuf_slot;
@@ -135,15 +135,17 @@ void
util_destroy_blit(struct blit_state *ctx)
{
struct pipe_context *pipe = ctx->pipe;
- unsigned i, j;
+ unsigned i, j, k;
if (ctx->vs)
pipe->delete_vs_state(pipe, ctx->vs);
for (i = 0; i < Elements(ctx->fs); i++) {
for (j = 0; j < Elements(ctx->fs[i]); j++) {
- if (ctx->fs[i][j])
-pipe->delete_fs_state(pipe, ctx->fs[i][j]);
+ for (k = 0; k < Elements(ctx->fs[i][j]); k++) {
+if (ctx->fs[i][j][k])
+ pipe->delete_fs_state(pipe, ctx->fs[i][j][k]);
+ }
}
}
@@ -158,18 +160,31 @@ util_destroy_blit(struct blit_state *ctx)
*/
static INLINE void
set_fragment_shader(struct blit_state *ctx, uint writemask,
+enum pipe_format format,
enum pipe_texture_target pipe_tex)
{
- if (!ctx->fs[pipe_tex][writemask]) {
+ boolean is_uint = util_format_is_pure_uint(format);
+ boolean is_sint = util_format_is_pure_sint(format);
+ unsigned type;
+
+ if (is_uint)
+ type = 0;
+ else if (is_sint)
+ type = 1;
+ else
+ type = 2;
+
+ if (!ctx->fs[pipe_tex][writemask][type]) {
unsigned tgsi_tex = util_pipe_tex_to_tgsi_tex(pipe_tex, 0);
- ctx->fs[pipe_tex][writemask] =
+ ctx->fs[pipe_tex][writemask][type] =
util_make_fragment_tex_shader_writemask(ctx->pipe, tgsi_tex,
TGSI_INTERPOLATE_LINEAR,
- writemask);
+ writemask,
+ is_uint, is_sint);
}
- cso_set_fragment_shader_handle(ctx->cso, ctx->fs[pipe_tex][writemask]);
+ cso_set_fragment_shader_handle(ctx->cso,
ctx->fs[pipe_tex][writemask][type]);
}
@@ -571,6 +586,7 @@ util_blit_pixels_tex(struct blit_state *ctx,
/* shaders */
set_fragment_shader(ctx, TGSI_WRITEMASK_XYZW,
+ src_sampler_view->format,
src_sampler_view->texture->target);
set_vertex_shader(ctx);
cso_set_tessctrl_shader_handle(ctx->cso, NULL);
diff --git a/src/gallium/auxiliary/util/u_blitter.c
b/src/gallium/auxiliary/util/u_blitter.c
index 16bf90f..27e0d10 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -81,6 +81,8 @@ struct blitter_context_priv
/* FS which outputs a color from a texture,
where the index is PIPE_TEXTURE_* to be sampled. */
void *fs_texfetch_col[PIPE_MAX_TEXTURE_TYPES];
+ void *fs_texfetch_col_uint[PIPE_MAX_TEXTURE_TYPES];
+ void *fs_texfetch_col_sint[PIPE_MAX_TEXTURE_TYPES];
/* FS which outputs a depth from a texture,
where the index is PIPE_TEXTURE_* to be sampled. */
@@ -90,6 +92,8 @@ struct blitter_context_priv
/* FS which outputs one sample from a multisample texture. */
void *fs_texfetch_col_msaa[PIPE_MAX_TEXTURE_TYPES];
+ void *fs_texfetch_col_msaa_uint[PIPE_MAX_TEXTURE_TYPES];
+ void *fs_texfetch_col_msaa_sint[PIPE_MAX_TEXTURE_TYPES];
void *fs_texfetch_depth_msaa[PIPE_MAX_TEXTURE_TYPES];
void *fs_texfetch_depthstencil_msaa[PIPE_MAX_TEXTURE_TYPES];
void *fs_texfetch_stencil_msaa[PIPE_MAX_TEXTURE_TYPES];
@@ -438,6 +442,10 @@ void util_blitter_destroy(struct blitter_context
[Mesa-dev] [PATCH 6/7] glsl_to_tgsi: add SVIEW decl support
From: Rob Clark
Freedreno needs sampler type information to deal with int/uint textures.
To accomplish this, start creating sampler-view declarations, as
suggested here:
http://lists.freedesktop.org/archives/mesa-dev/2014-November/071583.html
create a sampler-view with index matching the sampler, to encode the
texture type (ie. SINT/UINT/FLOAT). Ie:
DCL SVIEW[n], 2D, UINT
DCL SAMP[n]
TEX OUT[1], IN[1], SAMP[n]
For tgsi texture instructions which do not take an explicit SVIEW
argument, the SVIEW index is implied by the SAMP index.
Signed-off-by: Rob Clark
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 29 +
1 file changed, 29 insertions(+)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 0e60d95..ce8f2ea 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -239,6 +239,7 @@ public:
st_src_reg sampler; /**< sampler register */
int sampler_array_size; /**< 1-based size of sampler array, 1 if not array
*/
int tex_target; /**< One of TEXTURE_*_INDEX */
+ glsl_base_type tex_type;
GLboolean tex_shadow;
st_src_reg tex_offsets[MAX_GLSL_TEXTURE_OFFSET];
@@ -345,6 +346,8 @@ public:
int num_address_regs;
int samplers_used;
+ glsl_base_type sampler_types[PIPE_MAX_SAMPLERS];
+ int sampler_targets[PIPE_MAX_SAMPLERS]; /**< One of TGSI_TEXTURE_* */
bool indirect_addr_consts;
int wpos_transform_const;
@@ -3323,6 +3326,8 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
assert(!"Should not get here.");
}
+ inst->tex_type = ir->type->base_type;
+
this->result = result_src;
}
@@ -3471,6 +3476,11 @@ count_resources(glsl_to_tgsi_visitor *v, gl_program
*prog)
for (int i = 0; i < inst->sampler_array_size; i++) {
v->samplers_used |= 1 << (inst->sampler.index + i);
+debug_assert(i < (int)ARRAY_SIZE(v->sampler_types));
+v->sampler_types[i] = inst->tex_type;
+v->sampler_targets[i] =
+ st_translate_texture_target(inst->tex_target, inst->tex_shadow);
+
if (inst->tex_shadow) {
prog->ShadowSamplers |= 1 << (inst->sampler.index + i);
}
@@ -5529,7 +5539,26 @@ st_translate_program(
/* texture samplers */
for (i = 0; i <
ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxTextureImageUnits; i++) {
if (program->samplers_used & (1 << i)) {
+ unsigned type;
+
t->samplers[i] = ureg_DECL_sampler(ureg, i);
+
+ switch (program->sampler_types[i]) {
+ case GLSL_TYPE_INT:
+type = TGSI_RETURN_TYPE_SINT;
+break;
+ case GLSL_TYPE_UINT:
+type = TGSI_RETURN_TYPE_UINT;
+break;
+ case GLSL_TYPE_FLOAT:
+type = TGSI_RETURN_TYPE_FLOAT;
+break;
+ default:
+unreachable("not reached");
+ }
+
+ ureg_DECL_sampler_view( ureg, i, program->sampler_targets[i],
+ type, type, type, type );
}
}
--
2.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/7] tgsi/transform: add support for SVIEW decls
From: Rob Clark
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/tgsi/tgsi_transform.h | 24
1 file changed, 24 insertions(+)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_transform.h
b/src/gallium/auxiliary/tgsi/tgsi_transform.h
index 921aa906..e7de49e 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_transform.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_transform.h
@@ -143,6 +143,30 @@ tgsi_transform_sampler_decl(struct tgsi_transform_context
*ctx,
ctx->emit_declaration(ctx, &decl);
}
+static INLINE void
+tgsi_transform_sampler_view_decl(struct tgsi_transform_context *ctx,
+ unsigned index,
+ unsigned target,
+ unsigned return_type_x,
+ unsigned return_type_y,
+ unsigned return_type_z,
+ unsigned return_type_w)
+{
+ struct tgsi_full_declaration decl;
+
+ decl = tgsi_default_full_declaration();
+ decl.Declaration.File = TGSI_FILE_SAMPLER_VIEW;
+ decl.Declaration.UsageMask = 0xf;
+ decl.Range.First =
+ decl.Range.Last = index;
+ decl.SamplerView.Resource = target;
+ decl.SamplerView.ReturnTypeX = return_type_x;
+ decl.SamplerView.ReturnTypeY = return_type_y;
+ decl.SamplerView.ReturnTypeZ = return_type_z;
+ decl.SamplerView.ReturnTypeW = return_type_w;
+
+ ctx->emit_declaration(ctx, &decl);
+}
static INLINE void
tgsi_transform_immediate_decl(struct tgsi_transform_context *ctx,
--
2.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/7] util/blitter (and friends): generate appropriate SVIEW decls
On Thu, Jun 11, 2015 at 10:53 AM, Roland Scheidegger wrote:
> For 1-4/7, 6/7:
> Reviewed-by: Roland Scheidegger
>
> I think though using two exclusive booleans is really ugly. Probably
> should just use a tgsi_return_type enum instead indeed, and treat the
> unorm/snorm cases as float. I'm not entirely sure what the unorm/snorm
> types are for neither, this is a d3d10-ism but I'm not sure it serves
> much purpose (since, of course, for the purposes of the shader, the
> results indeed are floats). At least for now llvmpipe actually doesn't
> use that information (as we recompile the shader anyway if the texture
> "type" changes in the actually bound sampler views we get all the
> information from there).
>
>
> (FWIW I believe there's a slight catch with the
> util_format_is_pure_uint/sint functions - because right now in gallium
> it is sort of ok to sample from things like D24S8 textures, which means
> the depth component is sampled (so same as D24X8, opposed to X24S8), and
> depending if the D or S channel is first the answer may not quite be
> right...)
fwiw, the u_blitter (or rather u_simple_shader) is actually creating
separate samplers for depth+stencil. So I don't *think* we use
_is_pure_uint/sint() on zs formats..
Currently I'm always treating stencil SVIEW as uint and depth SVIEW as
float (since at least from u_format.csv this seemed to be the case..)
BR,
-R
> Roland
>
> Am 11.06.2015 um 02:14 schrieb Rob Clark:
>> From: Rob Clark
>>
>> Some hardware needs to know the sampler type. Update the blit related
>> shaders to include SVIEW decl.
>>
>> Signed-off-by: Rob Clark
>> ---
>> Possibly I should have refactored the existing code to pass around a
>> return_type rather than doing the is_uint/is_sint thing everywhere.
>> And this does kind of ignore UNORM/SNORM.. although I'm not really
>> sure that we need shader variants for UNORM/SNORM (we don't have this
>> information in GLSL IR or NIR IR, and I don't know any hw that doesn't
>> just treat those as FLOAT in the shader compiler). Anyways, sending
>> it out as-is for comments.
>>
>> src/gallium/auxiliary/util/u_blit.c | 32 +
>> src/gallium/auxiliary/util/u_blitter.c| 42
>> src/gallium/auxiliary/util/u_simple_shaders.c | 69
>> +++
>> src/gallium/auxiliary/util/u_simple_shaders.h | 15 --
>> src/gallium/auxiliary/util/u_tests.c | 3 +-
>> src/gallium/tests/trivial/quad-tex.c | 2 +-
>> 6 files changed, 132 insertions(+), 31 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/util/u_blit.c
>> b/src/gallium/auxiliary/util/u_blit.c
>> index 3f3b5fe..0062d96 100644
>> --- a/src/gallium/auxiliary/util/u_blit.c
>> +++ b/src/gallium/auxiliary/util/u_blit.c
>> @@ -65,7 +65,7 @@ struct blit_state
>> struct pipe_vertex_element velem[2];
>>
>> void *vs;
>> - void *fs[PIPE_MAX_TEXTURE_TYPES][TGSI_WRITEMASK_XYZW + 1];
>> + void *fs[PIPE_MAX_TEXTURE_TYPES][TGSI_WRITEMASK_XYZW + 1][3];
>>
>> struct pipe_resource *vbuf; /**< quad vertices */
>> unsigned vbuf_slot;
>> @@ -135,15 +135,17 @@ void
>> util_destroy_blit(struct blit_state *ctx)
>> {
>> struct pipe_context *pipe = ctx->pipe;
>> - unsigned i, j;
>> + unsigned i, j, k;
>>
>> if (ctx->vs)
>>pipe->delete_vs_state(pipe, ctx->vs);
>>
>> for (i = 0; i < Elements(ctx->fs); i++) {
>>for (j = 0; j < Elements(ctx->fs[i]); j++) {
>> - if (ctx->fs[i][j])
>> -pipe->delete_fs_state(pipe, ctx->fs[i][j]);
>> + for (k = 0; k < Elements(ctx->fs[i][j]); k++) {
>> +if (ctx->fs[i][j][k])
>> + pipe->delete_fs_state(pipe, ctx->fs[i][j][k]);
>> + }
>>}
>> }
>>
>> @@ -158,18 +160,31 @@ util_destroy_blit(struct blit_state *ctx)
>> */
>> static INLINE void
>> set_fragment_shader(struct blit_state *ctx, uint writemask,
>> +enum pipe_format format,
>> enum pipe_texture_target pipe_tex)
>> {
>> - if (!ctx->fs[pipe_tex][writemask]) {
>> + boolean is_uint = util_format_is_pure_uint(format);
>> + boolean is_sint = util_format_is_pure_sint(format);
>> + unsigned type;
>> +
>> + if (is_uint)
>> + type = 0;
>> + else if (is_sint)
>> + type = 1;
>> + else
>> + type = 2;
>> +
[Mesa-dev] [PATCH 4/7] util/pstipple: updates for SVIEW decls
From: Rob Clark
To allow for shaders which use SVIEW decls for TEX* instructions, we
need to preserve the constraint that the shader either has no SVIEW's or
it has one matching SVIEW for each SAMP.
Signed-off-by: Rob Clark
Reviewed-by: Roland Scheidegger
---
src/gallium/auxiliary/util/u_pstipple.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_pstipple.c
b/src/gallium/auxiliary/util/u_pstipple.c
index 0a20bdb..1f65672 100644
--- a/src/gallium/auxiliary/util/u_pstipple.c
+++ b/src/gallium/auxiliary/util/u_pstipple.c
@@ -55,7 +55,7 @@
#include "tgsi/tgsi_scan.h"
/** Approx number of new tokens for instructions in pstip_transform_inst() */
-#define NUM_NEW_TOKENS 50
+#define NUM_NEW_TOKENS 53
static void
@@ -262,6 +262,7 @@ pstip_transform_prolog(struct tgsi_transform_context *ctx)
(struct pstip_transform_context *) ctx;
int wincoordInput;
int texTemp;
+ int sampIdx;
/* find free texture sampler */
pctx->freeSampler = free_bit(pctx->samplersUsed);
@@ -280,9 +281,21 @@ pstip_transform_prolog(struct tgsi_transform_context *ctx)
TGSI_INTERPOLATE_LINEAR);
}
+ sampIdx = pctx->hasFixedUnit ? pctx->fixedUnit : pctx->freeSampler;
+
/* declare new sampler */
- tgsi_transform_sampler_decl(ctx,
- pctx->hasFixedUnit ? pctx->fixedUnit : pctx->freeSampler);
+ tgsi_transform_sampler_decl(ctx, sampIdx);
+
+ /* if the src shader has SVIEW decl's for each SAMP decl, we
+* need to continue the trend and ensure there is a matching
+* SVIEW for the new SAMP we just created
+*/
+ if (pctx->info.file_max[TGSI_FILE_SAMPLER_VIEW] != -1) {
+ tgsi_transform_sampler_view_decl(ctx,
+ sampIdx,
+ TGSI_TEXTURE_2D,
+ TGSI_RETURN_TYPE_FLOAT);
+ }
/* Declare temp[0] reg if not already declared.
* We can always use temp[0] since this code is before
@@ -321,8 +334,7 @@ pstip_transform_prolog(struct tgsi_transform_context *ctx)
tgsi_transform_tex_2d_inst(ctx,
TGSI_FILE_TEMPORARY, texTemp,
TGSI_FILE_TEMPORARY, texTemp,
- pctx->hasFixedUnit ? pctx->fixedUnit
- : pctx->freeSampler);
+ sampIdx);
/* KILL_IF -texTemp; # if -texTemp < 0, kill fragment */
tgsi_transform_kill_inst(ctx,
--
2.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/7] tgsi: update docs for SVIEW usage with TEX* instructions
From: Rob Clark Based on mailing list discussion here: http://lists.freedesktop.org/archives/mesa-dev/2014-November/071583.html Signed-off-by: Rob Clark Reviewed-by: Roland Scheidegger --- src/gallium/docs/source/tgsi.rst | 12 1 file changed, 12 insertions(+) diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst index f77702a..89ca172 100644 --- a/src/gallium/docs/source/tgsi.rst +++ b/src/gallium/docs/source/tgsi.rst @@ -2965,6 +2965,18 @@ resource can be one of BUFFER, 1D, 2D, 3D, 1DArray and 2DArray. type must be 1 or 4 entries (if specifying on a per-component level) out of UNORM, SNORM, SINT, UINT and FLOAT. +For TEX\* style texture sample opcodes (as opposed to SAMPLE\* opcodes +which take an explicit SVIEW[#] source register), there may be optionally +SVIEW[#] declarations. In this case, the SVIEW index is implied by the +SAMP index, and there must be a corresponding SVIEW[#] declaration for +each SAMP[#] declaration. Drivers are free to ignore this if they wish. +But note in particular that some drivers need to know the sampler type +(float/int/unsigned) in order to generate the correct code, so cases +where integer textures are sampled, SVIEW[#] declarations should be +used. + +NOTE: It is NOT legal to mix SAMPLE\* style opcodes and TEX\* opcodes +in the same shader. Declaration Resource -- 2.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/7] tgsi/transform: add support for SVIEW decls
From: Rob Clark
TODO single return_type (use enum)
v2: single return_type arg, and use enum
Signed-off-by: Rob Clark
Reviewed-by: Roland Scheidegger
---
src/gallium/auxiliary/tgsi/tgsi_transform.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_transform.h
b/src/gallium/auxiliary/tgsi/tgsi_transform.h
index 921aa906..39d7688 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_transform.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_transform.h
@@ -143,6 +143,27 @@ tgsi_transform_sampler_decl(struct tgsi_transform_context
*ctx,
ctx->emit_declaration(ctx, &decl);
}
+static INLINE void
+tgsi_transform_sampler_view_decl(struct tgsi_transform_context *ctx,
+ unsigned index,
+ unsigned target,
+ enum tgsi_return_type type)
+{
+ struct tgsi_full_declaration decl;
+
+ decl = tgsi_default_full_declaration();
+ decl.Declaration.File = TGSI_FILE_SAMPLER_VIEW;
+ decl.Declaration.UsageMask = 0xf;
+ decl.Range.First =
+ decl.Range.Last = index;
+ decl.SamplerView.Resource = target;
+ decl.SamplerView.ReturnTypeX = type;
+ decl.SamplerView.ReturnTypeY = type;
+ decl.SamplerView.ReturnTypeZ = type;
+ decl.SamplerView.ReturnTypeW = type;
+
+ ctx->emit_declaration(ctx, &decl);
+}
static INLINE void
tgsi_transform_immediate_decl(struct tgsi_transform_context *ctx,
--
2.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/7] glsl_to_tgsi: add SVIEW decl support
From: Rob Clark
Freedreno needs sampler type information to deal with int/uint textures.
To accomplish this, start creating sampler-view declarations, as
suggested here:
http://lists.freedesktop.org/archives/mesa-dev/2014-November/071583.html
create a sampler-view with index matching the sampler, to encode the
texture type (ie. SINT/UINT/FLOAT). Ie:
DCL SVIEW[n], 2D, UINT
DCL SAMP[n]
TEX OUT[1], IN[1], SAMP[n]
For tgsi texture instructions which do not take an explicit SVIEW
argument, the SVIEW index is implied by the SAMP index.
Signed-off-by: Rob Clark
Reviewed-by: Roland Scheidegger
Reviewed-by: Marek Olšák
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 29 +
1 file changed, 29 insertions(+)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 0e60d95..ce8f2ea 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -239,6 +239,7 @@ public:
st_src_reg sampler; /**< sampler register */
int sampler_array_size; /**< 1-based size of sampler array, 1 if not array
*/
int tex_target; /**< One of TEXTURE_*_INDEX */
+ glsl_base_type tex_type;
GLboolean tex_shadow;
st_src_reg tex_offsets[MAX_GLSL_TEXTURE_OFFSET];
@@ -345,6 +346,8 @@ public:
int num_address_regs;
int samplers_used;
+ glsl_base_type sampler_types[PIPE_MAX_SAMPLERS];
+ int sampler_targets[PIPE_MAX_SAMPLERS]; /**< One of TGSI_TEXTURE_* */
bool indirect_addr_consts;
int wpos_transform_const;
@@ -3323,6 +3326,8 @@ glsl_to_tgsi_visitor::visit(ir_texture *ir)
assert(!"Should not get here.");
}
+ inst->tex_type = ir->type->base_type;
+
this->result = result_src;
}
@@ -3471,6 +3476,11 @@ count_resources(glsl_to_tgsi_visitor *v, gl_program
*prog)
for (int i = 0; i < inst->sampler_array_size; i++) {
v->samplers_used |= 1 << (inst->sampler.index + i);
+debug_assert(i < (int)ARRAY_SIZE(v->sampler_types));
+v->sampler_types[i] = inst->tex_type;
+v->sampler_targets[i] =
+ st_translate_texture_target(inst->tex_target, inst->tex_shadow);
+
if (inst->tex_shadow) {
prog->ShadowSamplers |= 1 << (inst->sampler.index + i);
}
@@ -5529,7 +5539,26 @@ st_translate_program(
/* texture samplers */
for (i = 0; i <
ctx->Const.Program[MESA_SHADER_FRAGMENT].MaxTextureImageUnits; i++) {
if (program->samplers_used & (1 << i)) {
+ unsigned type;
+
t->samplers[i] = ureg_DECL_sampler(ureg, i);
+
+ switch (program->sampler_types[i]) {
+ case GLSL_TYPE_INT:
+type = TGSI_RETURN_TYPE_SINT;
+break;
+ case GLSL_TYPE_UINT:
+type = TGSI_RETURN_TYPE_UINT;
+break;
+ case GLSL_TYPE_FLOAT:
+type = TGSI_RETURN_TYPE_FLOAT;
+break;
+ default:
+unreachable("not reached");
+ }
+
+ ureg_DECL_sampler_view( ureg, i, program->sampler_targets[i],
+ type, type, type, type );
}
}
--
2.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/7] gallium/ttn: add texture-type support
From: Rob Clark
v2: rebased on using SVIEW to hold type information
Signed-off-by: Rob Clark
Reviewed-by: Eric Anholt
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 44 -
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 1702b41..d0291e5 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -58,6 +58,9 @@ struct ttn_compile {
struct ttn_reg_info *temp_regs;
nir_ssa_def **imm_defs;
+ unsigned num_samp_types;
+ nir_alu_type *samp_types;
+
nir_register *addr_reg;
/**
@@ -156,6 +159,30 @@ ttn_emit_declaration(struct ttn_compile *c)
/* Nothing to record for system values. */
} else if (file == TGSI_FILE_SAMPLER) {
/* Nothing to record for samplers. */
+ } else if (file == TGSI_FILE_SAMPLER_VIEW) {
+ struct tgsi_declaration_sampler_view *sview = &decl->SamplerView;
+ nir_alu_type type;
+
+ debug_assert((sview->ReturnTypeX == sview->ReturnTypeY) &&
+ (sview->ReturnTypeX == sview->ReturnTypeZ) &&
+ (sview->ReturnTypeX == sview->ReturnTypeW));
+
+ switch (sview->ReturnTypeX) {
+ case TGSI_RETURN_TYPE_SINT:
+ type = nir_type_int;
+ break;
+ case TGSI_RETURN_TYPE_UINT:
+ type = nir_type_unsigned;
+ break;
+ case TGSI_RETURN_TYPE_FLOAT:
+ default:
+ type = nir_type_float;
+ break;
+ }
+
+ for (i = 0; i < array_size; i++) {
+ c->samp_types[decl->Range.First + i] = type;
+ }
} else {
nir_variable *var;
assert(file == TGSI_FILE_INPUT ||
@@ -1026,7 +1053,7 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
struct tgsi_full_instruction *tgsi_inst = &c->token->FullInstruction;
nir_tex_instr *instr;
nir_texop op;
- unsigned num_srcs, samp = 1, i;
+ unsigned num_srcs, samp = 1, sview, i;
switch (tgsi_inst->Instruction.Opcode) {
case TGSI_OPCODE_TEX:
@@ -1105,6 +1132,18 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
assert(tgsi_inst->Src[samp].Register.File == TGSI_FILE_SAMPLER);
instr->sampler_index = tgsi_inst->Src[samp].Register.Index;
+ /* TODO if we supported any opc's which take an explicit SVIEW
+* src, we would use that here instead. But for the "legacy"
+* texture opc's the SVIEW index is same as SAMP index:
+*/
+ sview = instr->sampler_index;
+
+ if (sview < c->num_samp_types) {
+ instr->dest_type = c->samp_types[sview];
+ } else {
+ instr->dest_type = nir_type_float;
+ }
+
unsigned src_number = 0;
instr->src[src_number].src =
@@ -1710,6 +1749,9 @@ tgsi_to_nir(const void *tgsi_tokens,
c->imm_defs = rzalloc_array(c, nir_ssa_def *,
scan.file_max[TGSI_FILE_IMMEDIATE] + 1);
+ c->num_samp_types = scan.file_max[TGSI_FILE_SAMPLER_VIEW] + 1;
+ c->samp_types = rzalloc_array(c, nir_alu_type, c->num_samp_types);
+
c->if_stack = rzalloc_array(c, struct exec_list *,
(scan.opcode_count[TGSI_OPCODE_IF] +
scan.opcode_count[TGSI_OPCODE_UIF]) * 2);
--
2.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/7] draw: updates to support SVIEW decls
From: Rob Clark
To allow for shaders which use SVIEW decls for TEX* instructions, we
need to preserve the constraint that the shader either has no SVIEW's or
it has one matching SVIEW for each SAMP.
Signed-off-by: Rob Clark
Reviewed-by: Roland Scheidegger
---
src/gallium/auxiliary/draw/draw_pipe_aaline.c | 17 -
src/gallium/auxiliary/draw/draw_pipe_pstipple.c | 17 -
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
index 2f14efe..936046e 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
@@ -51,7 +51,7 @@
/** Approx number of new tokens for instructions in aa_transform_inst() */
-#define NUM_NEW_TOKENS 50
+#define NUM_NEW_TOKENS 53
/**
@@ -137,6 +137,7 @@ struct aa_transform_context {
uint tempsUsed; /**< bitmask */
int colorOutput; /**< which output is the primary color */
uint samplersUsed; /**< bitfield of samplers used */
+ bool hasSview;
int freeSampler; /** an available sampler for the pstipple */
int maxInput, maxGeneric; /**< max input index found */
int colorTemp, texTemp; /**< temp registers */
@@ -165,6 +166,9 @@ aa_transform_decl(struct tgsi_transform_context *ctx,
aactx->samplersUsed |= 1 << i;
}
}
+ else if (decl->Declaration.File == TGSI_FILE_SAMPLER_VIEW) {
+ aactx->hasSview = true;
+ }
else if (decl->Declaration.File == TGSI_FILE_INPUT) {
if ((int) decl->Range.Last > aactx->maxInput)
aactx->maxInput = decl->Range.Last;
@@ -232,6 +236,17 @@ aa_transform_prolog(struct tgsi_transform_context *ctx)
/* declare new sampler */
tgsi_transform_sampler_decl(ctx, aactx->freeSampler);
+ /* if the src shader has SVIEW decl's for each SAMP decl, we
+* need to continue the trend and ensure there is a matching
+* SVIEW for the new SAMP we just created
+*/
+ if (aactx->hasSview) {
+ tgsi_transform_sampler_view_decl(ctx,
+ aactx->freeSampler,
+ TGSI_TEXTURE_2D,
+ TGSI_RETURN_TYPE_FLOAT);
+ }
+
/* declare new temp regs */
tgsi_transform_temp_decl(ctx, aactx->texTemp);
tgsi_transform_temp_decl(ctx, aactx->colorTemp);
diff --git a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
index 8f21c46..445f195 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
@@ -53,7 +53,7 @@
/** Approx number of new tokens for instructions in pstip_transform_inst() */
-#define NUM_NEW_TOKENS 50
+#define NUM_NEW_TOKENS 53
/**
@@ -126,6 +126,7 @@ struct pstip_transform_context {
int wincoordInput;
int maxInput;
uint samplersUsed; /**< bitfield of samplers used */
+ bool hasSview;
int freeSampler; /** an available sampler for the pstipple */
int texTemp; /**< temp registers */
int numImmed;
@@ -149,6 +150,9 @@ pstip_transform_decl(struct tgsi_transform_context *ctx,
pctx->samplersUsed |= 1 << i;
}
}
+ else if (decl->Declaration.File == TGSI_FILE_SAMPLER_VIEW) {
+ pctx->hasSview = true;
+ }
else if (decl->Declaration.File == TGSI_FILE_INPUT) {
pctx->maxInput = MAX2(pctx->maxInput, (int) decl->Range.Last);
if (decl->Semantic.Name == TGSI_SEMANTIC_POSITION)
@@ -232,6 +236,17 @@ pstip_transform_prolog(struct tgsi_transform_context *ctx)
/* declare new sampler */
tgsi_transform_sampler_decl(ctx, pctx->freeSampler);
+ /* if the src shader has SVIEW decl's for each SAMP decl, we
+* need to continue the trend and ensure there is a matching
+* SVIEW for the new SAMP we just created
+*/
+ if (pctx->hasSview) {
+ tgsi_transform_sampler_view_decl(ctx,
+ pctx->freeSampler,
+ TGSI_TEXTURE_2D,
+ TGSI_RETURN_TYPE_FLOAT);
+ }
+
/* declare new temp regs */
tgsi_transform_temp_decl(ctx, pctx->texTemp);
--
2.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/7] util/blitter (and friends): generate appropriate SVIEW decls
From: Rob Clark
Some hardware needs to know the sampler type. Update the blit related
shaders to include SVIEW decl.
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/util/u_blit.c | 35 +---
src/gallium/auxiliary/util/u_blitter.c| 53 +-
src/gallium/auxiliary/util/u_simple_shaders.c | 78 ---
src/gallium/auxiliary/util/u_simple_shaders.h | 16 +++---
src/gallium/auxiliary/util/u_tests.c | 3 +-
src/gallium/tests/trivial/quad-tex.c | 2 +-
6 files changed, 140 insertions(+), 47 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blit.c
b/src/gallium/auxiliary/util/u_blit.c
index 3f3b5fe..e3f3055 100644
--- a/src/gallium/auxiliary/util/u_blit.c
+++ b/src/gallium/auxiliary/util/u_blit.c
@@ -65,7 +65,7 @@ struct blit_state
struct pipe_vertex_element velem[2];
void *vs;
- void *fs[PIPE_MAX_TEXTURE_TYPES][TGSI_WRITEMASK_XYZW + 1];
+ void *fs[PIPE_MAX_TEXTURE_TYPES][TGSI_WRITEMASK_XYZW + 1][3];
struct pipe_resource *vbuf; /**< quad vertices */
unsigned vbuf_slot;
@@ -135,15 +135,17 @@ void
util_destroy_blit(struct blit_state *ctx)
{
struct pipe_context *pipe = ctx->pipe;
- unsigned i, j;
+ unsigned i, j, k;
if (ctx->vs)
pipe->delete_vs_state(pipe, ctx->vs);
for (i = 0; i < Elements(ctx->fs); i++) {
for (j = 0; j < Elements(ctx->fs[i]); j++) {
- if (ctx->fs[i][j])
-pipe->delete_fs_state(pipe, ctx->fs[i][j]);
+ for (k = 0; k < Elements(ctx->fs[i][j]); k++) {
+if (ctx->fs[i][j][k])
+ pipe->delete_fs_state(pipe, ctx->fs[i][j][k]);
+ }
}
}
@@ -158,18 +160,34 @@ util_destroy_blit(struct blit_state *ctx)
*/
static INLINE void
set_fragment_shader(struct blit_state *ctx, uint writemask,
+enum pipe_format format,
enum pipe_texture_target pipe_tex)
{
- if (!ctx->fs[pipe_tex][writemask]) {
+ enum tgsi_return_type stype;
+ unsigned idx;
+
+ if (util_format_is_pure_uint(format)) {
+ stype = TGSI_RETURN_TYPE_UINT;
+ idx = 0;
+ } else if (util_format_is_pure_sint(format)) {
+ stype = TGSI_RETURN_TYPE_SINT;
+ idx = 1;
+ } else {
+ stype = TGSI_RETURN_TYPE_FLOAT;
+ idx = 2;
+ }
+
+ if (!ctx->fs[pipe_tex][writemask][idx]) {
unsigned tgsi_tex = util_pipe_tex_to_tgsi_tex(pipe_tex, 0);
- ctx->fs[pipe_tex][writemask] =
+ ctx->fs[pipe_tex][writemask][idx] =
util_make_fragment_tex_shader_writemask(ctx->pipe, tgsi_tex,
TGSI_INTERPOLATE_LINEAR,
- writemask);
+ writemask,
+ stype);
}
- cso_set_fragment_shader_handle(ctx->cso, ctx->fs[pipe_tex][writemask]);
+ cso_set_fragment_shader_handle(ctx->cso, ctx->fs[pipe_tex][writemask][idx]);
}
@@ -571,6 +589,7 @@ util_blit_pixels_tex(struct blit_state *ctx,
/* shaders */
set_fragment_shader(ctx, TGSI_WRITEMASK_XYZW,
+ src_sampler_view->format,
src_sampler_view->texture->target);
set_vertex_shader(ctx);
cso_set_tessctrl_shader_handle(ctx->cso, NULL);
diff --git a/src/gallium/auxiliary/util/u_blitter.c
b/src/gallium/auxiliary/util/u_blitter.c
index 16bf90f..5dfe2c7 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -81,6 +81,8 @@ struct blitter_context_priv
/* FS which outputs a color from a texture,
where the index is PIPE_TEXTURE_* to be sampled. */
void *fs_texfetch_col[PIPE_MAX_TEXTURE_TYPES];
+ void *fs_texfetch_col_uint[PIPE_MAX_TEXTURE_TYPES];
+ void *fs_texfetch_col_sint[PIPE_MAX_TEXTURE_TYPES];
/* FS which outputs a depth from a texture,
where the index is PIPE_TEXTURE_* to be sampled. */
@@ -90,6 +92,8 @@ struct blitter_context_priv
/* FS which outputs one sample from a multisample texture. */
void *fs_texfetch_col_msaa[PIPE_MAX_TEXTURE_TYPES];
+ void *fs_texfetch_col_msaa_uint[PIPE_MAX_TEXTURE_TYPES];
+ void *fs_texfetch_col_msaa_sint[PIPE_MAX_TEXTURE_TYPES];
void *fs_texfetch_depth_msaa[PIPE_MAX_TEXTURE_TYPES];
void *fs_texfetch_depthstencil_msaa[PIPE_MAX_TEXTURE_TYPES];
void *fs_texfetch_stencil_msaa[PIPE_MAX_TEXTURE_TYPES];
@@ -438,6 +442,10 @@ void util_blitter_destroy(struct blitter_context *blitter)
for (i = 0; i < PIPE_MAX_TEXTURE_TYPES; i++) {
if (ctx->fs_texfetch_col[i])
ctx->delete_fs_state(pipe, ctx->fs_texfetch_col[i]);
+ if (ctx->fs_texfetch_col_sint[i])
+ ctx->delete_fs_state(pipe, ctx->fs_texfetch_col_sint[i]);
+ if (ctx->fs_texfetch_col_uint[i])
+ ctx->delete_fs_state(pipe, ctx->fs_te
Re: [Mesa-dev] [PATCH 5/7] util/blitter (and friends): generate appropriate SVIEW decls
On Thu, Jun 11, 2015 at 4:51 PM, Roland Scheidegger wrote:
> Am 11.06.2015 um 22:38 schrieb Rob Clark:
>> From: Rob Clark
>>
>> Some hardware needs to know the sampler type. Update the blit related
>> shaders to include SVIEW decl.
>>
>> Signed-off-by: Rob Clark
>> ---
>> src/gallium/auxiliary/util/u_blit.c | 35 +---
>> src/gallium/auxiliary/util/u_blitter.c| 53 +-
>> src/gallium/auxiliary/util/u_simple_shaders.c | 78
>> ---
>> src/gallium/auxiliary/util/u_simple_shaders.h | 16 +++---
>> src/gallium/auxiliary/util/u_tests.c | 3 +-
>> src/gallium/tests/trivial/quad-tex.c | 2 +-
>> 6 files changed, 140 insertions(+), 47 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/util/u_blit.c
>> b/src/gallium/auxiliary/util/u_blit.c
>> index 3f3b5fe..e3f3055 100644
>> --- a/src/gallium/auxiliary/util/u_blit.c
>> +++ b/src/gallium/auxiliary/util/u_blit.c
>> @@ -65,7 +65,7 @@ struct blit_state
>> struct pipe_vertex_element velem[2];
>>
>> void *vs;
>> - void *fs[PIPE_MAX_TEXTURE_TYPES][TGSI_WRITEMASK_XYZW + 1];
>> + void *fs[PIPE_MAX_TEXTURE_TYPES][TGSI_WRITEMASK_XYZW + 1][3];
>>
>> struct pipe_resource *vbuf; /**< quad vertices */
>> unsigned vbuf_slot;
>> @@ -135,15 +135,17 @@ void
>> util_destroy_blit(struct blit_state *ctx)
>> {
>> struct pipe_context *pipe = ctx->pipe;
>> - unsigned i, j;
>> + unsigned i, j, k;
>>
>> if (ctx->vs)
>>pipe->delete_vs_state(pipe, ctx->vs);
>>
>> for (i = 0; i < Elements(ctx->fs); i++) {
>>for (j = 0; j < Elements(ctx->fs[i]); j++) {
>> - if (ctx->fs[i][j])
>> -pipe->delete_fs_state(pipe, ctx->fs[i][j]);
>> + for (k = 0; k < Elements(ctx->fs[i][j]); k++) {
>> +if (ctx->fs[i][j][k])
>> + pipe->delete_fs_state(pipe, ctx->fs[i][j][k]);
>> + }
>>}
>> }
>>
>> @@ -158,18 +160,34 @@ util_destroy_blit(struct blit_state *ctx)
>> */
>> static INLINE void
>> set_fragment_shader(struct blit_state *ctx, uint writemask,
>> +enum pipe_format format,
>> enum pipe_texture_target pipe_tex)
>> {
>> - if (!ctx->fs[pipe_tex][writemask]) {
>> + enum tgsi_return_type stype;
>> + unsigned idx;
>> +
>> + if (util_format_is_pure_uint(format)) {
>> + stype = TGSI_RETURN_TYPE_UINT;
>> + idx = 0;
>> + } else if (util_format_is_pure_sint(format)) {
>> + stype = TGSI_RETURN_TYPE_SINT;
>> + idx = 1;
>> + } else {
>> + stype = TGSI_RETURN_TYPE_FLOAT;
>> + idx = 2;
>> + }
>> +
>> + if (!ctx->fs[pipe_tex][writemask][idx]) {
>>unsigned tgsi_tex = util_pipe_tex_to_tgsi_tex(pipe_tex, 0);
>>
>> - ctx->fs[pipe_tex][writemask] =
>> + ctx->fs[pipe_tex][writemask][idx] =
>> util_make_fragment_tex_shader_writemask(ctx->pipe, tgsi_tex,
>> TGSI_INTERPOLATE_LINEAR,
>> - writemask);
>> + writemask,
>> + stype);
>> }
>>
>> - cso_set_fragment_shader_handle(ctx->cso, ctx->fs[pipe_tex][writemask]);
>> + cso_set_fragment_shader_handle(ctx->cso,
>> ctx->fs[pipe_tex][writemask][idx]);
>> }
>>
>>
>> @@ -571,6 +589,7 @@ util_blit_pixels_tex(struct blit_state *ctx,
>>
>> /* shaders */
>> set_fragment_shader(ctx, TGSI_WRITEMASK_XYZW,
>> + src_sampler_view->format,
>> src_sampler_view->texture->target);
>> set_vertex_shader(ctx);
>> cso_set_tessctrl_shader_handle(ctx->cso, NULL);
>> diff --git a/src/gallium/auxiliary/util/u_blitter.c
>> b/src/gallium/auxiliary/util/u_blitter.c
>> index 16bf90f..5dfe2c7 100644
>> --- a/src/gallium/auxiliary/util/u_blitter.c
>> +++ b/src/gallium/auxiliary/util/u_blitter.c
>> @@ -81,6 +81,8 @@ struct blitter_context_priv
>> /* FS which outputs a color from a texture,
>>where the index is PIPE_TEXTURE_* to be sampled. */
>> void *fs_texfetch_col[PIPE_MAX_TEXTURE_TYPES];
>> + void *fs_texfetch_col_uint[PIPE_MAX_TEXTURE_TYPES];
>> + void *fs_texfetch_c
Re: [Mesa-dev] [PATCH 5/7] util/blitter (and friends): generate appropriate SVIEW decls
On Thu, Jun 11, 2015 at 5:47 PM, Brian Paul wrote:
> On 06/11/2015 02:38 PM, Rob Clark wrote:
>>
>> From: Rob Clark
>>
>> Some hardware needs to know the sampler type. Update the blit related
>> shaders to include SVIEW decl.
>>
>> Signed-off-by: Rob Clark
>> ---
>> src/gallium/auxiliary/util/u_blit.c | 35 +---
>> src/gallium/auxiliary/util/u_blitter.c| 53 +-
>> src/gallium/auxiliary/util/u_simple_shaders.c | 78
>> ---
>> src/gallium/auxiliary/util/u_simple_shaders.h | 16 +++---
>> src/gallium/auxiliary/util/u_tests.c | 3 +-
>> src/gallium/tests/trivial/quad-tex.c | 2 +-
>> 6 files changed, 140 insertions(+), 47 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/util/u_blit.c
>> b/src/gallium/auxiliary/util/u_blit.c
>> index 3f3b5fe..e3f3055 100644
>> --- a/src/gallium/auxiliary/util/u_blit.c
>> +++ b/src/gallium/auxiliary/util/u_blit.c
>> @@ -65,7 +65,7 @@ struct blit_state
>> struct pipe_vertex_element velem[2];
>>
>> void *vs;
>> - void *fs[PIPE_MAX_TEXTURE_TYPES][TGSI_WRITEMASK_XYZW + 1];
>> + void *fs[PIPE_MAX_TEXTURE_TYPES][TGSI_WRITEMASK_XYZW + 1][3];
>>
>> struct pipe_resource *vbuf; /**< quad vertices */
>> unsigned vbuf_slot;
>> @@ -135,15 +135,17 @@ void
>> util_destroy_blit(struct blit_state *ctx)
>> {
>> struct pipe_context *pipe = ctx->pipe;
>> - unsigned i, j;
>> + unsigned i, j, k;
>>
>> if (ctx->vs)
>> pipe->delete_vs_state(pipe, ctx->vs);
>>
>> for (i = 0; i < Elements(ctx->fs); i++) {
>> for (j = 0; j < Elements(ctx->fs[i]); j++) {
>> - if (ctx->fs[i][j])
>> -pipe->delete_fs_state(pipe, ctx->fs[i][j]);
>> + for (k = 0; k < Elements(ctx->fs[i][j]); k++) {
>> +if (ctx->fs[i][j][k])
>> + pipe->delete_fs_state(pipe, ctx->fs[i][j][k]);
>> + }
>> }
>> }
>>
>> @@ -158,18 +160,34 @@ util_destroy_blit(struct blit_state *ctx)
>>*/
>> static INLINE void
>> set_fragment_shader(struct blit_state *ctx, uint writemask,
>> +enum pipe_format format,
>> enum pipe_texture_target pipe_tex)
>> {
>> - if (!ctx->fs[pipe_tex][writemask]) {
>> + enum tgsi_return_type stype;
>> + unsigned idx;
>> +
>> + if (util_format_is_pure_uint(format)) {
>> + stype = TGSI_RETURN_TYPE_UINT;
>> + idx = 0;
>> + } else if (util_format_is_pure_sint(format)) {
>> + stype = TGSI_RETURN_TYPE_SINT;
>> + idx = 1;
>> + } else {
>> + stype = TGSI_RETURN_TYPE_FLOAT;
>> + idx = 2;
>> + }
>> +
>> + if (!ctx->fs[pipe_tex][writemask][idx]) {
>> unsigned tgsi_tex = util_pipe_tex_to_tgsi_tex(pipe_tex, 0);
>>
>> - ctx->fs[pipe_tex][writemask] =
>> + ctx->fs[pipe_tex][writemask][idx] =
>>util_make_fragment_tex_shader_writemask(ctx->pipe, tgsi_tex,
>>
>> TGSI_INTERPOLATE_LINEAR,
>> - writemask);
>> + writemask,
>> + stype);
>> }
>>
>> - cso_set_fragment_shader_handle(ctx->cso,
>> ctx->fs[pipe_tex][writemask]);
>> + cso_set_fragment_shader_handle(ctx->cso,
>> ctx->fs[pipe_tex][writemask][idx]);
>> }
>>
>>
>> @@ -571,6 +589,7 @@ util_blit_pixels_tex(struct blit_state *ctx,
>>
>> /* shaders */
>> set_fragment_shader(ctx, TGSI_WRITEMASK_XYZW,
>> + src_sampler_view->format,
>> src_sampler_view->texture->target);
>> set_vertex_shader(ctx);
>> cso_set_tessctrl_shader_handle(ctx->cso, NULL);
>> diff --git a/src/gallium/auxiliary/util/u_blitter.c
>> b/src/gallium/auxiliary/util/u_blitter.c
>> index 16bf90f..5dfe2c7 100644
>> --- a/src/gallium/auxiliary/util/u_blitter.c
>> +++ b/src/gallium/auxiliary/util/u_blitter.c
>> @@ -81,6 +81,8 @@ struct blitter_context_priv
>> /* FS which outputs a color from a texture,
>> where the index is PIPE_TEXTURE_* to be sampled. */
>> void *fs_texfetch_col[PIPE_MAX_TEXTURE_TYPES];
>> + void *fs_texfetch_col_uint[PIPE_MAX_TEXTURE_TYPES];
>> + void *fs_te
Re: [Mesa-dev] [PATCH 5/7] util/blitter (and friends): generate appropriate SVIEW decls
On Thu, Jun 11, 2015 at 8:36 PM, Roland Scheidegger wrote:
> Am 12.06.2015 um 02:02 schrieb Rob Clark:
>> On Thu, Jun 11, 2015 at 5:47 PM, Brian Paul wrote:
>>> On 06/11/2015 02:38 PM, Rob Clark wrote:
>>>>
>>>> From: Rob Clark
>>>>
>>>> Some hardware needs to know the sampler type. Update the blit related
>>>> shaders to include SVIEW decl.
>>>>
>>>> Signed-off-by: Rob Clark
>>>> ---
>>>> src/gallium/auxiliary/util/u_blit.c | 35 +---
>>>> src/gallium/auxiliary/util/u_blitter.c| 53 +-
>>>> src/gallium/auxiliary/util/u_simple_shaders.c | 78
>>>> ---
>>>> src/gallium/auxiliary/util/u_simple_shaders.h | 16 +++---
>>>> src/gallium/auxiliary/util/u_tests.c | 3 +-
>>>> src/gallium/tests/trivial/quad-tex.c | 2 +-
>>>> 6 files changed, 140 insertions(+), 47 deletions(-)
>>>>
>>>> diff --git a/src/gallium/auxiliary/util/u_blit.c
>>>> b/src/gallium/auxiliary/util/u_blit.c
>>>> index 3f3b5fe..e3f3055 100644
>>>> --- a/src/gallium/auxiliary/util/u_blit.c
>>>> +++ b/src/gallium/auxiliary/util/u_blit.c
>>>> @@ -65,7 +65,7 @@ struct blit_state
>>>> struct pipe_vertex_element velem[2];
>>>>
>>>> void *vs;
>>>> - void *fs[PIPE_MAX_TEXTURE_TYPES][TGSI_WRITEMASK_XYZW + 1];
>>>> + void *fs[PIPE_MAX_TEXTURE_TYPES][TGSI_WRITEMASK_XYZW + 1][3];
>>>>
>>>> struct pipe_resource *vbuf; /**< quad vertices */
>>>> unsigned vbuf_slot;
>>>> @@ -135,15 +135,17 @@ void
>>>> util_destroy_blit(struct blit_state *ctx)
>>>> {
>>>> struct pipe_context *pipe = ctx->pipe;
>>>> - unsigned i, j;
>>>> + unsigned i, j, k;
>>>>
>>>> if (ctx->vs)
>>>> pipe->delete_vs_state(pipe, ctx->vs);
>>>>
>>>> for (i = 0; i < Elements(ctx->fs); i++) {
>>>> for (j = 0; j < Elements(ctx->fs[i]); j++) {
>>>> - if (ctx->fs[i][j])
>>>> -pipe->delete_fs_state(pipe, ctx->fs[i][j]);
>>>> + for (k = 0; k < Elements(ctx->fs[i][j]); k++) {
>>>> +if (ctx->fs[i][j][k])
>>>> + pipe->delete_fs_state(pipe, ctx->fs[i][j][k]);
>>>> + }
>>>> }
>>>> }
>>>>
>>>> @@ -158,18 +160,34 @@ util_destroy_blit(struct blit_state *ctx)
>>>>*/
>>>> static INLINE void
>>>> set_fragment_shader(struct blit_state *ctx, uint writemask,
>>>> +enum pipe_format format,
>>>> enum pipe_texture_target pipe_tex)
>>>> {
>>>> - if (!ctx->fs[pipe_tex][writemask]) {
>>>> + enum tgsi_return_type stype;
>>>> + unsigned idx;
>>>> +
>>>> + if (util_format_is_pure_uint(format)) {
>>>> + stype = TGSI_RETURN_TYPE_UINT;
>>>> + idx = 0;
>>>> + } else if (util_format_is_pure_sint(format)) {
>>>> + stype = TGSI_RETURN_TYPE_SINT;
>>>> + idx = 1;
>>>> + } else {
>>>> + stype = TGSI_RETURN_TYPE_FLOAT;
>>>> + idx = 2;
>>>> + }
>>>> +
>>>> + if (!ctx->fs[pipe_tex][writemask][idx]) {
>>>> unsigned tgsi_tex = util_pipe_tex_to_tgsi_tex(pipe_tex, 0);
>>>>
>>>> - ctx->fs[pipe_tex][writemask] =
>>>> + ctx->fs[pipe_tex][writemask][idx] =
>>>>util_make_fragment_tex_shader_writemask(ctx->pipe, tgsi_tex,
>>>>
>>>> TGSI_INTERPOLATE_LINEAR,
>>>> - writemask);
>>>> + writemask,
>>>> + stype);
>>>> }
>>>>
>>>> - cso_set_fragment_shader_handle(ctx->cso,
>>>> ctx->fs[pipe_tex][writemask]);
>>>> + cso_set_fragment_shader_handle(ctx->cso,
>>>> ctx->fs[pipe_tex][writemask][idx]);
>>>> }
>>>>
>>>>
>>>> @@ -571,6 +589,7 @@ util_blit_pixels_tex(struct blit_state *ctx,
>>>>
>>>> /*
Re: [Mesa-dev] [PATCH 5/7] util/blitter (and friends): generate appropriate SVIEW decls
On Fri, Jun 12, 2015 at 9:47 AM, Rob Clark wrote:
> On Thu, Jun 11, 2015 at 8:36 PM, Roland Scheidegger
> wrote:
>> Am 12.06.2015 um 02:02 schrieb Rob Clark:
>>> On Thu, Jun 11, 2015 at 5:47 PM, Brian Paul wrote:
>>>> On 06/11/2015 02:38 PM, Rob Clark wrote:
>>>>>
>>>>> From: Rob Clark
>>>>>
>>>>> Some hardware needs to know the sampler type. Update the blit related
>>>>> shaders to include SVIEW decl.
>>>>>
>>>>> Signed-off-by: Rob Clark
>>>>> ---
>>>>> src/gallium/auxiliary/util/u_blit.c | 35 +---
>>>>> src/gallium/auxiliary/util/u_blitter.c| 53 +-
>>>>> src/gallium/auxiliary/util/u_simple_shaders.c | 78
>>>>> ---
>>>>> src/gallium/auxiliary/util/u_simple_shaders.h | 16 +++---
>>>>> src/gallium/auxiliary/util/u_tests.c | 3 +-
>>>>> src/gallium/tests/trivial/quad-tex.c | 2 +-
>>>>> 6 files changed, 140 insertions(+), 47 deletions(-)
>>>>>
>>>>> diff --git a/src/gallium/auxiliary/util/u_blit.c
>>>>> b/src/gallium/auxiliary/util/u_blit.c
>>>>> index 3f3b5fe..e3f3055 100644
>>>>> --- a/src/gallium/auxiliary/util/u_blit.c
>>>>> +++ b/src/gallium/auxiliary/util/u_blit.c
>>>>> @@ -65,7 +65,7 @@ struct blit_state
>>>>> struct pipe_vertex_element velem[2];
>>>>>
>>>>> void *vs;
>>>>> - void *fs[PIPE_MAX_TEXTURE_TYPES][TGSI_WRITEMASK_XYZW + 1];
>>>>> + void *fs[PIPE_MAX_TEXTURE_TYPES][TGSI_WRITEMASK_XYZW + 1][3];
>>>>>
>>>>> struct pipe_resource *vbuf; /**< quad vertices */
>>>>> unsigned vbuf_slot;
>>>>> @@ -135,15 +135,17 @@ void
>>>>> util_destroy_blit(struct blit_state *ctx)
>>>>> {
>>>>> struct pipe_context *pipe = ctx->pipe;
>>>>> - unsigned i, j;
>>>>> + unsigned i, j, k;
>>>>>
>>>>> if (ctx->vs)
>>>>> pipe->delete_vs_state(pipe, ctx->vs);
>>>>>
>>>>> for (i = 0; i < Elements(ctx->fs); i++) {
>>>>> for (j = 0; j < Elements(ctx->fs[i]); j++) {
>>>>> - if (ctx->fs[i][j])
>>>>> -pipe->delete_fs_state(pipe, ctx->fs[i][j]);
>>>>> + for (k = 0; k < Elements(ctx->fs[i][j]); k++) {
>>>>> +if (ctx->fs[i][j][k])
>>>>> + pipe->delete_fs_state(pipe, ctx->fs[i][j][k]);
>>>>> + }
>>>>> }
>>>>> }
>>>>>
>>>>> @@ -158,18 +160,34 @@ util_destroy_blit(struct blit_state *ctx)
>>>>>*/
>>>>> static INLINE void
>>>>> set_fragment_shader(struct blit_state *ctx, uint writemask,
>>>>> +enum pipe_format format,
>>>>> enum pipe_texture_target pipe_tex)
>>>>> {
>>>>> - if (!ctx->fs[pipe_tex][writemask]) {
>>>>> + enum tgsi_return_type stype;
>>>>> + unsigned idx;
>>>>> +
>>>>> + if (util_format_is_pure_uint(format)) {
>>>>> + stype = TGSI_RETURN_TYPE_UINT;
>>>>> + idx = 0;
>>>>> + } else if (util_format_is_pure_sint(format)) {
>>>>> + stype = TGSI_RETURN_TYPE_SINT;
>>>>> + idx = 1;
>>>>> + } else {
>>>>> + stype = TGSI_RETURN_TYPE_FLOAT;
>>>>> + idx = 2;
>>>>> + }
>>>>> +
>>>>> + if (!ctx->fs[pipe_tex][writemask][idx]) {
>>>>> unsigned tgsi_tex = util_pipe_tex_to_tgsi_tex(pipe_tex, 0);
>>>>>
>>>>> - ctx->fs[pipe_tex][writemask] =
>>>>> + ctx->fs[pipe_tex][writemask][idx] =
>>>>>util_make_fragment_tex_shader_writemask(ctx->pipe, tgsi_tex,
>>>>>
>>>>> TGSI_INTERPOLATE_LINEAR,
>>>>> - writemask);
>>>>> + writemask,
>>>>> + stype);
>>>>> }
>>>>>
[Mesa-dev] [RFC shader-db] Add support for shadertoy tests
Attached script grabs shaders from shadertoy, and dumps them out as
.shader_test files which can be run through shader-db for compiler
testing.
shadertoy only gives you a fragment shader (which works based on
gl_FragCoord), so a generic vertex shader is used. And a blurb is
inserted for the pre-defined uniforms and main() function (which just
calls shadertoy mainImage() fxn).
---
TODO I guess we'd actually have to parse the shader to figure out if
the sampler uniforms were meant to be 2D/cube/etc. Maybe we just
commit samplers we get from the script and massage them by hand?
PS. don't make fun of my py too much.. I'm a newb and figuring it
out as I go
grab-shadertoy.py | 63 +++
1 file changed, 63 insertions(+)
create mode 100755 grab-shadertoy.py
diff --git a/grab-shadertoy.py b/grab-shadertoy.py
new file mode 100755
index 000..74e9d10
--- /dev/null
+++ b/grab-shadertoy.py
@@ -0,0 +1,63 @@
+#!/usr/bin/env python3
+
+
+import requests, json
+
+url = 'https://www.shadertoy.com/api/v1/shaders'
+key = '?key=NdnKw7'
+
+# Get the list of shaders
+r = requests.get(url + key)
+j = r.json()
+print('Found ' + str(j['Shaders']) + ' shaders')
+
+shader_ids = j['Results']
+for id in shader_ids:
+print('Fetching shader: ' + str(id))
+r = requests.get(url + '/' + id + key)
+j = r.json()
+s = j['Shader']
+info = s['info']
+print('Name: ' + info['name'])
+print('Description: ' + info['description'])
+i = 0;
+for p in s['renderpass']:
+fobj = open('shaders/shadertoy/' + str(id) + '_' + str(i) +
'.shader_test', 'w')
+#print('Inputs: ' + str(p['inputs']))
+#print('Outputs: ' + str(p['outputs']))
+fobj.write('[require]\n')
+fobj.write('GLSL >= 1.30\n')
+fobj.write('\n');
+fobj.write('[fragment shader]\n')
+fobj.write('#version 130\n')
+# Shadertoy inserts some uniforms, so we need to do the same:
+fobj.write('uniform vec3 iResolution;\n');
+fobj.write('uniform float iGlobalTime;\n');
+fobj.write('uniform float iChannelTime[4];\n');
+fobj.write('uniform vec4 iMouse;\n');
+fobj.write('uniform vec4 iDate;\n');
+fobj.write('uniform float iSampleRate;\n');
+fobj.write('uniform vec3 iChannelResolution[4];\n');
+# TODO probably need to parse the shader to figure out if
2d/cubemap/etc
+fobj.write('uniform sampler2D iChannel0;\n');
+fobj.write('uniform sampler2D iChannel1;\n');
+fobj.write('uniform sampler2D iChannel2;\n');
+fobj.write('uniform sampler2D iChannel3;\n');
+# Actual shadertoy shader body:
+fobj.write(p['code'])
+# Shadertoy shader uses mainImage(out vec4 fragColor, in vec2
fragCoord)
+# so we need to insert a main:
+fobj.write('\nvoid main() { mainImage(gl_FragColor, gl_FragCoord.xy);
}\n')
+fobj.write('\n\n')
+# And a generic vertex shader:
+fobj.write('[vertex shader]\n')
+fobj.write('#version 130\n')
+fobj.write('in vec2 position;\n')
+fobj.write('\n')
+fobj.write('void main()\n')
+fobj.write('{\n')
+fobj.write(' gl_Position = vec4(position, 0.0, 1.0);\n')
+fobj.write('}\n')
+
+fobj.close()
+i = 1 + i
--
2.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Wed, Jun 17, 2015 at 2:27 PM, Connor Abbott wrote:
> So, as is, this patch isn't quite correct. When I originally wrote
> NIR, the idea was that the size of each instruction would be explicit
> -- that is, each instruction has it's own size, and the size of
> registers/SSA values was merely a hint to say "by the way, you
> actually need this many components based on all the things that use
> this value/register." In other words, you could smash num_components
> to 4 for everything, and it would still work. Then, we could just
> shrink num_components on demand as we got rid of uses of things.
> That's why we have functions like nir_tex_instr_src_size(),
> nir_tex_instr_dest_size(), and nir_ssa_alu_instr_src_components() that
> seem like they're doing the same thing that these functions -- in most
> cases, you actually want those functions instead of these. Maybe we
> were figuring out the register/value # of components a few times, and
> perhaps some of times it was broken, but it seems like adding these
> functions would only add to the confusion.
>
> Now, in hindsight, it seems like that might not be the best idea. In
> other words, I can see how it would make sense to turn
> nir_tex_instr_src_size() etc. into assertions in the validator that
> check that nir_(src|dest)_num_components() equals what you would
> expect, and it's probably a good idea. But I don't want people to use
> these functions without knowing what they're doing until we do that
> cleanup.
hmm, fortunately I hadn't pushed my loops branch yet, since still need
to work out how to make variables/arrays work w/ >1 block (since in
nir-land variables are not ssa)..
(really I want phi's for variables too.. the way I turn arrays into
fanin/collect fanout/split works on the backend for dealing with
arrays in ssa form (other than making instruction graph large) but the
way I go from nir to ir3 currently assumes I get nir phi's everywhere
I need an ir3 phi)
Anyways, maybe I'll just move the helpers into ir3 for now until the
is_packed stuff is purged..
BR,
-R
>
> On Mon, Jun 8, 2015 at 12:45 PM, Rob Clark wrote:
>> From: Rob Clark
>>
>> I need something like this in a couple places. And didn't see anything
>> like it anywhere.
>>
>> Signed-off-by: Rob Clark
>> ---
>> v2: Added similar helper for nir_src, and cleaned up a few places that
>> open coded this. There are a couple left (such as validate_alu_src())
>> but that handle is_packed differently so I thought it best to leave
>> them as-is.
>>
>> src/glsl/nir/nir.h | 18 ++
>> src/glsl/nir/nir_from_ssa.c | 10 ++
>> src/glsl/nir/nir_validate.c | 4 +---
>> 3 files changed, 21 insertions(+), 11 deletions(-)
>>
>> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
>> index 697d37e..06bbb0c 100644
>> --- a/src/glsl/nir/nir.h
>> +++ b/src/glsl/nir/nir.h
>> @@ -541,6 +541,24 @@ typedef struct {
>> #define nir_foreach_def_safe(reg, dest) \
>> list_for_each_entry_safe(nir_dest, dest, &(reg)->defs, reg.def_link)
>>
>> +static inline unsigned
>> +nir_dest_num_components(nir_dest *dest)
>> +{
>> + if (dest->is_ssa)
>> + return dest->ssa.num_components;
>> + else
>> + return dest->reg.reg->num_components;
>> +}
>> +
>> +static inline unsigned
>> +nir_src_num_components(nir_src *src)
>> +{
>> + if (src->is_ssa)
>> + return src->ssa->num_components;
>> + else
>> + return src->reg.reg->num_components;
>> +}
>> +
>> static inline nir_src
>> nir_src_for_ssa(nir_ssa_def *def)
>> {
>> diff --git a/src/glsl/nir/nir_from_ssa.c b/src/glsl/nir/nir_from_ssa.c
>> index 67733e6..23c798d 100644
>> --- a/src/glsl/nir/nir_from_ssa.c
>> +++ b/src/glsl/nir/nir_from_ssa.c
>> @@ -553,10 +553,7 @@ emit_copy(nir_parallel_copy_instr *pcopy, nir_src src,
>> nir_src dest_src,
>>dest_src.reg.indirect == NULL &&
>>dest_src.reg.base_offset == 0);
>>
>> - if (src.is_ssa)
>> - assert(src.ssa->num_components >= dest_src.reg.reg->num_components);
>> - else
>> - assert(src.reg.reg->num_components >=
>> dest_src.reg.reg->num_components);
>> + assert(nir_src_num_components(&src) ==
>> nir_src_num_components(&dest_src));
>>
>> nir_alu_instr *mov = nir_alu_instr_create(mem_ctx, nir_op_imov);
>> nir_src_copy(&mov->src[0].src, &src, mem_ctx);
>> @@ -712,10 +709,7 @@ resolve_parallel_copy(nir_para
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Thu, Jun 18, 2015 at 1:23 AM, Connor Abbott wrote: > On Wed, Jun 17, 2015 at 12:02 PM, Rob Clark wrote: >> On Wed, Jun 17, 2015 at 2:27 PM, Connor Abbott wrote: >>> So, as is, this patch isn't quite correct. When I originally wrote >>> NIR, the idea was that the size of each instruction would be explicit >>> -- that is, each instruction has it's own size, and the size of >>> registers/SSA values was merely a hint to say "by the way, you >>> actually need this many components based on all the things that use >>> this value/register." In other words, you could smash num_components >>> to 4 for everything, and it would still work. Then, we could just >>> shrink num_components on demand as we got rid of uses of things. >>> That's why we have functions like nir_tex_instr_src_size(), >>> nir_tex_instr_dest_size(), and nir_ssa_alu_instr_src_components() that >>> seem like they're doing the same thing that these functions -- in most >>> cases, you actually want those functions instead of these. Maybe we >>> were figuring out the register/value # of components a few times, and >>> perhaps some of times it was broken, but it seems like adding these >>> functions would only add to the confusion. >>> >>> Now, in hindsight, it seems like that might not be the best idea. In >>> other words, I can see how it would make sense to turn >>> nir_tex_instr_src_size() etc. into assertions in the validator that >>> check that nir_(src|dest)_num_components() equals what you would >>> expect, and it's probably a good idea. But I don't want people to use >>> these functions without knowing what they're doing until we do that >>> cleanup. >> >> hmm, fortunately I hadn't pushed my loops branch yet, since still need >> to work out how to make variables/arrays work w/ >1 block (since in >> nir-land variables are not ssa).. >> >> (really I want phi's for variables too.. the way I turn arrays into >> fanin/collect fanout/split works on the backend for dealing with >> arrays in ssa form (other than making instruction graph large) but the >> way I go from nir to ir3 currently assumes I get nir phi's everywhere >> I need an ir3 phi) > > Right... we explicitly decided not to support SSA form for arrays in > NIR, since it seemed like a pretty bad idea. SSA form assumes that > inserting copies for the things you're SSA-ifying is relatively > inexpensive, and both SSA-based register allocation and algorithms for > converting out of SSA make no guarantees about not inserting > potentially unnecessary copies. This is a good compromise for smaller > things, but not for your array of (say) 64 things where inserting an > extra copy is rather disastrous. You can do it if you want and shoot > yourself in the foot, but NIR isn't going to help you there -- we > won't write a to-SSA pass for something which doesn't make much sense > in the first place. > in ir3 my solution is to add sufficient dependencies between instructions so the array accesses don't get re-ordered and they all collapse down to a single name per array element/slot >> >> Anyways, maybe I'll just move the helpers into ir3 for now until the >> is_packed stuff is purged.. > > is_packed? what does that have to do with it? I suspect that there > might be some places where you're using this function instead of the > others I mentioned, and you actually want to use the latter, although > I haven't seen the code so I can't be sure. But of course, there's > always the option of actually going and fixing it :) because I was in a hurry and didn't actually read your original reply (and assumed it was continuation of discussion about nuking is_packed from irc) So the place where I was using it is actually for phi instructions (and actually just for an assert at the moment), so those fxns you mention don't do me much good. Somehow, I think it is still a good idea to un-open-code the figuring out of # of src/dst components. Sure it makes sense to have validate code ensure that those are same as nir_tex_instr_src_size(), nir_tex_instr_dest_size(), and nir_ssa_alu_instr_src_components() give. But that doesn't preclude adding these two functions. BR, -R > >> >> BR, >> -R >> >> >>> >>> On Mon, Jun 8, 2015 at 12:45 PM, Rob Clark wrote: >>>> From: Rob Clark >>>> >>>> I need something like this in a couple places. And didn't see anything >>>> like it anywhere. >>>> >>>> Signed-off-
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Thu, Jun 18, 2015 at 11:01 AM, Connor Abbott wrote: (really I want phi's for variables too.. the way I turn arrays into fanin/collect fanout/split works on the backend for dealing with arrays in ssa form (other than making instruction graph large) but the way I go from nir to ir3 currently assumes I get nir phi's everywhere I need an ir3 phi) >>> >>> Right... we explicitly decided not to support SSA form for arrays in >>> NIR, since it seemed like a pretty bad idea. SSA form assumes that >>> inserting copies for the things you're SSA-ifying is relatively >>> inexpensive, and both SSA-based register allocation and algorithms for >>> converting out of SSA make no guarantees about not inserting >>> potentially unnecessary copies. This is a good compromise for smaller >>> things, but not for your array of (say) 64 things where inserting an >>> extra copy is rather disastrous. You can do it if you want and shoot >>> yourself in the foot, but NIR isn't going to help you there -- we >>> won't write a to-SSA pass for something which doesn't make much sense >>> in the first place. >>> >> >> in ir3 my solution is to add sufficient dependencies between >> instructions so the array accesses don't get re-ordered and they all >> collapse down to a single name per array element/slot > > It's not about getting reordered, it's about interference. The problem > is that as soon as you do basically any optimization at all (even copy > propagation), you can wind up with a situation where the sources and > destination of a phi node interfere with each other and you have to > insert extra mov's. And even if you keep everything exactly the same, > with an SSA-based register allocator, there's always the chance that > it'll screw up anyways and allocate something over your array and > force you to insert a mov. You could force the array to be allocated > to a single hardware register, but then it's not really an SSA value > anymore -- it's a hardware register, and you can't treat it like an > SSA value anymore in your allocator, and so adding phi nodes and > whatnot for it in your IR doesn't make much sense. But the point I'm trying to make is that I need the links from src to dest that I get in SSA form for *scheduling* (for example, to know how many delay slots are needed between two instructions). For things like if/else, I would need to consider number of cycles since either possible assigner. For everything else, the phi nodes (in ir3, not in nir) give me this. Arrays are not special (since they are allocated in registers) when it comes to cycle counts. BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Thu, Jun 18, 2015 at 12:42 PM, Rob Clark wrote: > On Thu, Jun 18, 2015 at 11:01 AM, Connor Abbott wrote: >>>>> (really I want phi's for variables too.. the way I turn arrays into >>>>> fanin/collect fanout/split works on the backend for dealing with >>>>> arrays in ssa form (other than making instruction graph large) but the >>>>> way I go from nir to ir3 currently assumes I get nir phi's everywhere >>>>> I need an ir3 phi) >>>> >>>> Right... we explicitly decided not to support SSA form for arrays in >>>> NIR, since it seemed like a pretty bad idea. SSA form assumes that >>>> inserting copies for the things you're SSA-ifying is relatively >>>> inexpensive, and both SSA-based register allocation and algorithms for >>>> converting out of SSA make no guarantees about not inserting >>>> potentially unnecessary copies. This is a good compromise for smaller >>>> things, but not for your array of (say) 64 things where inserting an >>>> extra copy is rather disastrous. You can do it if you want and shoot >>>> yourself in the foot, but NIR isn't going to help you there -- we >>>> won't write a to-SSA pass for something which doesn't make much sense >>>> in the first place. >>>> >>> >>> in ir3 my solution is to add sufficient dependencies between >>> instructions so the array accesses don't get re-ordered and they all >>> collapse down to a single name per array element/slot >> >> It's not about getting reordered, it's about interference. The problem >> is that as soon as you do basically any optimization at all (even copy >> propagation), you can wind up with a situation where the sources and >> destination of a phi node interfere with each other and you have to >> insert extra mov's. And even if you keep everything exactly the same, >> with an SSA-based register allocator, there's always the chance that >> it'll screw up anyways and allocate something over your array and >> force you to insert a mov. You could force the array to be allocated >> to a single hardware register, but then it's not really an SSA value >> anymore -- it's a hardware register, and you can't treat it like an >> SSA value anymore in your allocator, and so adding phi nodes and >> whatnot for it in your IR doesn't make much sense. > > > But the point I'm trying to make is that I need the links from src to > dest that I get in SSA form for *scheduling* (for example, to know how > many delay slots are needed between two instructions). For things > like if/else, I would need to consider number of cycles since either > possible assigner. For everything else, the phi nodes (in ir3, not in > nir) give me this. Arrays are not special (since they are allocated > in registers) when it comes to cycle counts. (or rather, instructions that write to arrays are not special...) > > BR, > -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Thu, Jun 18, 2015 at 1:27 PM, Connor Abbott wrote:
> On Thu, Jun 18, 2015 at 9:42 AM, Rob Clark wrote:
>> On Thu, Jun 18, 2015 at 11:01 AM, Connor Abbott wrote:
>>>>>> (really I want phi's for variables too.. the way I turn arrays into
>>>>>> fanin/collect fanout/split works on the backend for dealing with
>>>>>> arrays in ssa form (other than making instruction graph large) but the
>>>>>> way I go from nir to ir3 currently assumes I get nir phi's everywhere
>>>>>> I need an ir3 phi)
>>>>>
>>>>> Right... we explicitly decided not to support SSA form for arrays in
>>>>> NIR, since it seemed like a pretty bad idea. SSA form assumes that
>>>>> inserting copies for the things you're SSA-ifying is relatively
>>>>> inexpensive, and both SSA-based register allocation and algorithms for
>>>>> converting out of SSA make no guarantees about not inserting
>>>>> potentially unnecessary copies. This is a good compromise for smaller
>>>>> things, but not for your array of (say) 64 things where inserting an
>>>>> extra copy is rather disastrous. You can do it if you want and shoot
>>>>> yourself in the foot, but NIR isn't going to help you there -- we
>>>>> won't write a to-SSA pass for something which doesn't make much sense
>>>>> in the first place.
>>>>>
>>>>
>>>> in ir3 my solution is to add sufficient dependencies between
>>>> instructions so the array accesses don't get re-ordered and they all
>>>> collapse down to a single name per array element/slot
>>>
>>> It's not about getting reordered, it's about interference. The problem
>>> is that as soon as you do basically any optimization at all (even copy
>>> propagation), you can wind up with a situation where the sources and
>>> destination of a phi node interfere with each other and you have to
>>> insert extra mov's. And even if you keep everything exactly the same,
>>> with an SSA-based register allocator, there's always the chance that
>>> it'll screw up anyways and allocate something over your array and
>>> force you to insert a mov. You could force the array to be allocated
>>> to a single hardware register, but then it's not really an SSA value
>>> anymore -- it's a hardware register, and you can't treat it like an
>>> SSA value anymore in your allocator, and so adding phi nodes and
>>> whatnot for it in your IR doesn't make much sense.
>>
>>
>> But the point I'm trying to make is that I need the links from src to
>> dest that I get in SSA form for *scheduling* (for example, to know how
>> many delay slots are needed between two instructions). For things
>> like if/else, I would need to consider number of cycles since either
>> possible assigner. For everything else, the phi nodes (in ir3, not in
>> nir) give me this. Arrays are not special (since they are allocated
>> in registers) when it comes to cycle counts.
>>
>> BR,
>> -R
>
> Except that they still are special, and you need to account for that
> when you set up scheduling dependencies for them. For example, imagine
> that you have an array A accessed in a loop:
>
> while (...) {
> ... = A[i];
> A[i] = ...;
> }
>
> if you lower the array to SSA, this will give you something like:
>
> while (...) {
> A_1 = phi(A_0, A_2);
> ... = A_1[i];
> A_2 = Update(A_1, i, ...); /* makes a copy with the i'th element changed
> */
> }
>
> and when you set up scheduling dependencies, you'll miss the false
> write-after-read dependency between the access and the update, meaning
> you could end up with:
>
> while (...) {
> A_1 = phi(A_0, A_2);
> A_2 = Update(A_1, i, ...);
> ... = A_1[i];
> }
>
> and now the number of instructions in your shader has exploded since
> you have to insert a copy somewhere. You could add all the false
> dependencies by yourself, and force it into the same register, but by
> that point you've already given up all the advantages that SSA has to
> offer and inserting phi nodes is a rather pointless exercise.
except, like I said, for the purpose of scheduling realizing that
there are two dependency paths to consider for figuring out the
required number of delay slots..
That said, having to re-invent the to-ssa pass in my backend is
something I was hoping to avoid.. so I'm thinking of other
alternatives. But currently the depth calculations (used for
scheduling), dead code elimination (used if nothing else to clean
things up when generating binning-pass shader), scheduling, and even
to some degree RA, depend on this use-def graph between instructions.
BR,
-R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Thu, Jun 18, 2015 at 2:34 PM, Connor Abbott wrote:
> On Thu, Jun 18, 2015 at 11:19 AM, Rob Clark wrote:
>> On Thu, Jun 18, 2015 at 1:27 PM, Connor Abbott wrote:
>>> On Thu, Jun 18, 2015 at 9:42 AM, Rob Clark wrote:
>>>> On Thu, Jun 18, 2015 at 11:01 AM, Connor Abbott
>>>> wrote:
>>>>>>>> (really I want phi's for variables too.. the way I turn arrays into
>>>>>>>> fanin/collect fanout/split works on the backend for dealing with
>>>>>>>> arrays in ssa form (other than making instruction graph large) but the
>>>>>>>> way I go from nir to ir3 currently assumes I get nir phi's everywhere
>>>>>>>> I need an ir3 phi)
>>>>>>>
>>>>>>> Right... we explicitly decided not to support SSA form for arrays in
>>>>>>> NIR, since it seemed like a pretty bad idea. SSA form assumes that
>>>>>>> inserting copies for the things you're SSA-ifying is relatively
>>>>>>> inexpensive, and both SSA-based register allocation and algorithms for
>>>>>>> converting out of SSA make no guarantees about not inserting
>>>>>>> potentially unnecessary copies. This is a good compromise for smaller
>>>>>>> things, but not for your array of (say) 64 things where inserting an
>>>>>>> extra copy is rather disastrous. You can do it if you want and shoot
>>>>>>> yourself in the foot, but NIR isn't going to help you there -- we
>>>>>>> won't write a to-SSA pass for something which doesn't make much sense
>>>>>>> in the first place.
>>>>>>>
>>>>>>
>>>>>> in ir3 my solution is to add sufficient dependencies between
>>>>>> instructions so the array accesses don't get re-ordered and they all
>>>>>> collapse down to a single name per array element/slot
>>>>>
>>>>> It's not about getting reordered, it's about interference. The problem
>>>>> is that as soon as you do basically any optimization at all (even copy
>>>>> propagation), you can wind up with a situation where the sources and
>>>>> destination of a phi node interfere with each other and you have to
>>>>> insert extra mov's. And even if you keep everything exactly the same,
>>>>> with an SSA-based register allocator, there's always the chance that
>>>>> it'll screw up anyways and allocate something over your array and
>>>>> force you to insert a mov. You could force the array to be allocated
>>>>> to a single hardware register, but then it's not really an SSA value
>>>>> anymore -- it's a hardware register, and you can't treat it like an
>>>>> SSA value anymore in your allocator, and so adding phi nodes and
>>>>> whatnot for it in your IR doesn't make much sense.
>>>>
>>>>
>>>> But the point I'm trying to make is that I need the links from src to
>>>> dest that I get in SSA form for *scheduling* (for example, to know how
>>>> many delay slots are needed between two instructions). For things
>>>> like if/else, I would need to consider number of cycles since either
>>>> possible assigner. For everything else, the phi nodes (in ir3, not in
>>>> nir) give me this. Arrays are not special (since they are allocated
>>>> in registers) when it comes to cycle counts.
>>>>
>>>> BR,
>>>> -R
>>>
>>> Except that they still are special, and you need to account for that
>>> when you set up scheduling dependencies for them. For example, imagine
>>> that you have an array A accessed in a loop:
>>>
>>> while (...) {
>>> ... = A[i];
>>> A[i] = ...;
>>> }
>>>
>>> if you lower the array to SSA, this will give you something like:
>>>
>>> while (...) {
>>> A_1 = phi(A_0, A_2);
>>> ... = A_1[i];
>>> A_2 = Update(A_1, i, ...); /* makes a copy with the i'th element
>>> changed */
>>> }
>>>
>>> and when you set up scheduling dependencies, you'll miss the false
>>> write-after-read dependency between the access and the update, meaning
>>> you could end up with:
>>>
>>> while (...) {
>>> A_1 = phi(A_0, A_2);
>>> A_2 = Update(A_1, i, .
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Fri, Jun 19, 2015 at 6:21 PM, Connor Abbott wrote:
> On Thu, Jun 18, 2015 at 12:04 PM, Rob Clark wrote:
>> On Thu, Jun 18, 2015 at 2:34 PM, Connor Abbott wrote:
>>> On Thu, Jun 18, 2015 at 11:19 AM, Rob Clark wrote:
>>>> On Thu, Jun 18, 2015 at 1:27 PM, Connor Abbott wrote:
>>>>> On Thu, Jun 18, 2015 at 9:42 AM, Rob Clark wrote:
>>>>>> On Thu, Jun 18, 2015 at 11:01 AM, Connor Abbott
>>>>>> wrote:
>>>>>>>>>> (really I want phi's for variables too.. the way I turn arrays into
>>>>>>>>>> fanin/collect fanout/split works on the backend for dealing with
>>>>>>>>>> arrays in ssa form (other than making instruction graph large) but
>>>>>>>>>> the
>>>>>>>>>> way I go from nir to ir3 currently assumes I get nir phi's everywhere
>>>>>>>>>> I need an ir3 phi)
>>>>>>>>>
>>>>>>>>> Right... we explicitly decided not to support SSA form for arrays in
>>>>>>>>> NIR, since it seemed like a pretty bad idea. SSA form assumes that
>>>>>>>>> inserting copies for the things you're SSA-ifying is relatively
>>>>>>>>> inexpensive, and both SSA-based register allocation and algorithms for
>>>>>>>>> converting out of SSA make no guarantees about not inserting
>>>>>>>>> potentially unnecessary copies. This is a good compromise for smaller
>>>>>>>>> things, but not for your array of (say) 64 things where inserting an
>>>>>>>>> extra copy is rather disastrous. You can do it if you want and shoot
>>>>>>>>> yourself in the foot, but NIR isn't going to help you there -- we
>>>>>>>>> won't write a to-SSA pass for something which doesn't make much sense
>>>>>>>>> in the first place.
>>>>>>>>>
>>>>>>>>
>>>>>>>> in ir3 my solution is to add sufficient dependencies between
>>>>>>>> instructions so the array accesses don't get re-ordered and they all
>>>>>>>> collapse down to a single name per array element/slot
>>>>>>>
>>>>>>> It's not about getting reordered, it's about interference. The problem
>>>>>>> is that as soon as you do basically any optimization at all (even copy
>>>>>>> propagation), you can wind up with a situation where the sources and
>>>>>>> destination of a phi node interfere with each other and you have to
>>>>>>> insert extra mov's. And even if you keep everything exactly the same,
>>>>>>> with an SSA-based register allocator, there's always the chance that
>>>>>>> it'll screw up anyways and allocate something over your array and
>>>>>>> force you to insert a mov. You could force the array to be allocated
>>>>>>> to a single hardware register, but then it's not really an SSA value
>>>>>>> anymore -- it's a hardware register, and you can't treat it like an
>>>>>>> SSA value anymore in your allocator, and so adding phi nodes and
>>>>>>> whatnot for it in your IR doesn't make much sense.
>>>>>>
>>>>>>
>>>>>> But the point I'm trying to make is that I need the links from src to
>>>>>> dest that I get in SSA form for *scheduling* (for example, to know how
>>>>>> many delay slots are needed between two instructions). For things
>>>>>> like if/else, I would need to consider number of cycles since either
>>>>>> possible assigner. For everything else, the phi nodes (in ir3, not in
>>>>>> nir) give me this. Arrays are not special (since they are allocated
>>>>>> in registers) when it comes to cycle counts.
>>>>>>
>>>>>> BR,
>>>>>> -R
>>>>>
>>>>> Except that they still are special, and you need to account for that
>>>>> when you set up scheduling dependencies for them. For example, imagine
>>>>> that you have an array A accessed in a loop:
>>>>>
>>>>> while (...) {
>>>>> ... = A[i];
>>>>> A[i] = ...;
>>>>> }
>>>&
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Fri, Jun 19, 2015 at 6:21 PM, Connor Abbott wrote: >>> and the RA has to >>> split live-ranges of other things and deal with arrays specially too >>> in order to not introduce extra array copies. >> >> If I did spilling/rematerialization.. but I don't. > > If you force every array into a specific register range, and assume > that every array is live since the beginning of the program, then you > may not have to do that. But then, again, this means that inserting > phi nodes doesn't help you at all in the register allocator. If you're > doing anything else, then you certainly will have to split live > ranges, even without spilling, since you may run into a situation > where the array becomes live, but there isn't a big enough slot to fit > it in even if the register pressure is low enough for everything to > fit. In any case, you'll have to know the original array where each > value came from in order to not accidentally generate copies, so why > bother inserting phi nodes at all? I don't disagree with you.. fragmentation of the register space could be an issue.. it just isn't the biggest issue right now (and because of the hard requirement of ensuring sufficient instruction cycles between producer and consumer, any mov's inserted in RA would require re-scheduling) Anyways, that is basically an different topic. BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: add helper to get # of src/dest components
On Fri, Jun 19, 2015 at 6:45 PM, Connor Abbott wrote: > On Thu, Jun 18, 2015 at 12:04 PM, Rob Clark wrote: >> It is only vaguely an issue at the moment >> because the priority-queue scheduler that replaced what is on master >> does very badly with wide/shallow shaders, ie. like >> glsl-fs-convolution-1... ie. shaders with a lot of instructions at >> minimum depth.. (but I have some ideas to fix that) >> > > P.S. what does your heuristic currently look like? I was working on > i965 scheduling, and after some discussion, this is what I did: > > http://cgit.freedesktop.org/~cwabbott0/mesa/commit/?h=i965-sched&id=2d46e424327082bbc67758d05e6e102cbcd56d89 > > it's called "delay" in that code for some reason instead of "depth" > (or, even better, critical path length), but you should get the > idea... choose the earliest thing we can schedule, and then among > those pick the thing with the largest depth. current heuristic is just depth. But if we have a large # of instructions with depth==1 those end up getting scheduled first increasing the register pressure.. (although on thinking about it, seems like I have something backwards, maybe I end up taking from the head of the depth sorted list instead of tail.. I should check that.. I hadn't really spent any time at all playing w/ the heuristic yet.. I just noticed that glsl-fs-convolution was a good example case of where I end up doing badly at the moment) BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC] gallium/hud: fix issue w/ tgsi_to_nir
From: Rob Clark
Ok, so actually there is a ttn issue here to fix as well.. but it
brought up a question in my mind. When ttn sees something like
DCL IN[0..1]
it will treat that as an array (which in the end will result in
constraints about where the registers get allocated. Which is not
really ideal.
With glsl we don't actually get input arrays (but instead a bunch
of MOV's to a TEMP array) currently. So I'm not quite sure how
an actual input array should look. (But my preference would be
IN[a..b] for arrays and IN[c] otherwise)
---
src/gallium/auxiliary/hud/hud_context.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 6a124f7..2b6d3a7 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -1163,7 +1163,8 @@ hud_create(struct pipe_context *pipe, struct cso_context
*cso)
{
static const char *vertex_shader_text = {
"VERT\n"
- "DCL IN[0..1]\n"
+ "DCL IN[0]\n"
+ "DCL IN[1]\n"
"DCL OUT[0], POSITION\n"
"DCL OUT[1], COLOR[0]\n" /* color */
"DCL OUT[2], GENERIC[0]\n" /* texcoord */
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC shader-db] Add support for shadertoy tests
On Tue, Jun 23, 2015 at 7:27 PM, Dylan Baker wrote:
> I have a couple of python pointers for you, feel free to take them or
> leave them.
cool, thanks..
What do others think about including shadertoy in shader-db? If it is
a useful thing, I'll clean up my script and re-submit..
And if we include it, should we commit the scripts we pull down for
repeatable results and just keep the script as something to resync and
pull in new shaders? (Esp. given that a small percentage need some
hand massaging.. I haven't figured out a good way to
reliably/programatically figure out if the samplers should actually be
2d/3d/cube..)
That said, I think the shaderdb shaders are a fairly, umm, unique
stress test of a shader compiler.. and the API to scrape shaders seems
to convenient to ignore..
BR,
-R
> Dylan
>
> On Tue, Jun 16, 2015 at 03:46:50PM -0400, Rob Clark wrote:
>> Attached script grabs shaders from shadertoy, and dumps them out as
>> .shader_test files which can be run through shader-db for compiler
>> testing.
>>
>> shadertoy only gives you a fragment shader (which works based on
>> gl_FragCoord), so a generic vertex shader is used. And a blurb is
>> inserted for the pre-defined uniforms and main() function (which just
>> calls shadertoy mainImage() fxn).
>>
>> ---
>> TODO I guess we'd actually have to parse the shader to figure out if
>> the sampler uniforms were meant to be 2D/cube/etc. Maybe we just
>> commit samplers we get from the script and massage them by hand?
>>
>> PS. don't make fun of my py too much.. I'm a newb and figuring it
>> out as I go
>
> I'm trying not to make fun, but I do have quite a few pointers for you.
>
>>
>> grab-shadertoy.py | 63
>> +++
>> 1 file changed, 63 insertions(+)
>> create mode 100755 grab-shadertoy.py
>>
>> diff --git a/grab-shadertoy.py b/grab-shadertoy.py
>> new file mode 100755
>> index 000..74e9d10
>> --- /dev/null
>> +++ b/grab-shadertoy.py
>> @@ -0,0 +1,63 @@
>> +#!/usr/bin/env python3
>> +
>> +
>> +import requests, json
>
> You're not actually using json
>
>> +
>> +url = 'https://www.shadertoy.com/api/v1/shaders'
>> +key = '?key=NdnKw7'
>> +
>> +# Get the list of shaders
>> +r = requests.get(url + key)
>> +j = r.json()
>> +print('Found ' + str(j['Shaders']) + ' shaders')
>
> If you use format you can avoid calling str() on everything, and make
> things more readable using format rather than concatenation:
> print('Found {} shaders'.format(j['Shaders']))
>
>> +
>> +shader_ids = j['Results']
>> +for id in shader_ids:
>> +print('Fetching shader: ' + str(id))
>> +r = requests.get(url + '/' + id + key)
>> +j = r.json()
>> +s = j['Shader']
>> +info = s['info']
>> +print('Name: ' + info['name'])
>> +print('Description: ' + info['description'])
>> +i = 0;
>
> python has a cool builtin called enumerate for doing this:
> for i, p in enmerate(s['renderpass']):
>
> Also, I know it's easy to forget, but python doesn't use ';' at the end
> of lines, it allows them, but they look weird to pythonistas
>
>> +for p in s['renderpass']:
>> +fobj = open('shaders/shadertoy/' + str(id) + '_' + str(i) +
>> '.shader_test', 'w')
>
> with str.format this would look like:
> with open('shaders/shadertoy/{}_{}.shader_test'.format(id, i), 'w') as fobj:
>
>> +#print('Inputs: ' + str(p['inputs']))
>> +#print('Outputs: ' + str(p['outputs']))
>> +fobj.write('[require]\n')
>> +fobj.write('GLSL >= 1.30\n')
>> +fobj.write('\n');
>> +fobj.write('[fragment shader]\n')
>> +fobj.write('#version 130\n')
>> +# Shadertoy inserts some uniforms, so we need to do the same:
>> +fobj.write('uniform vec3 iResolution;\n');
>> +fobj.write('uniform float iGlobalTime;\n');
>> +fobj.write('uniform float iChannelTime[4];\n');
>> +fobj.write('uniform vec4 iMouse;\n');
>> +fobj.write('uniform vec4 iDate;\n');
>> +fobj.write('uniform float iSampleRat
Re: [Mesa-dev] [RFC] gallium/hud: fix issue w/ tgsi_to_nir
Ok, I *thought* we didn't get ArrayID on IN/OUT, but only TEMP? If it
is safe to assume that we always get ArrayID that makes it much
easier.
BR,
-R
On Wed, Jun 24, 2015 at 5:39 AM, Marek Olšák wrote:
> It's not an array, because the ArrayID is 0. It's a valid non-array
> declaration. If any TGSI user doesn't understand it, that user should
> be fixed.
>
> Marek
>
> On Tue, Jun 23, 2015 at 3:20 PM, Rob Clark wrote:
>> From: Rob Clark
>>
>> Ok, so actually there is a ttn issue here to fix as well.. but it
>> brought up a question in my mind. When ttn sees something like
>>
>> DCL IN[0..1]
>>
>> it will treat that as an array (which in the end will result in
>> constraints about where the registers get allocated. Which is not
>> really ideal.
>>
>> With glsl we don't actually get input arrays (but instead a bunch
>> of MOV's to a TEMP array) currently. So I'm not quite sure how
>> an actual input array should look. (But my preference would be
>> IN[a..b] for arrays and IN[c] otherwise)
>> ---
>> src/gallium/auxiliary/hud/hud_context.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/auxiliary/hud/hud_context.c
>> b/src/gallium/auxiliary/hud/hud_context.c
>> index 6a124f7..2b6d3a7 100644
>> --- a/src/gallium/auxiliary/hud/hud_context.c
>> +++ b/src/gallium/auxiliary/hud/hud_context.c
>> @@ -1163,7 +1163,8 @@ hud_create(struct pipe_context *pipe, struct
>> cso_context *cso)
>> {
>>static const char *vertex_shader_text = {
>> "VERT\n"
>> - "DCL IN[0..1]\n"
>> + "DCL IN[0]\n"
>> + "DCL IN[1]\n"
>> "DCL OUT[0], POSITION\n"
>> "DCL OUT[1], COLOR[0]\n" /* color */
>> "DCL OUT[2], GENERIC[0]\n" /* texcoord */
>> --
>> 2.4.3
>>
>> ___
>> 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] [RFC] gallium/hud: fix issue w/ tgsi_to_nir
On Wed, Jun 24, 2015 at 12:31 PM, Marek Olšák wrote:
> Yes, ArrayID != 0 means it's an array, otherwise it's just a compact
> way to add declarations.
ok.. hmm, I guess tgsi.rst needs an update then..
> I recently added the array support for inputs and outputs, we just
> need to enable it on non-radeon non-swrast drivers:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=b6ebe7eabf54936a02acc0968e718e0c264a73f5
ok, in principle (after fixing ttn based on the assumption that we
won't get indirect access if ArrayID==0, and now that tgsi f/e is
dropped) freedreno should be ok for array in/out's.. I'll enable the
cap and see what happens after fixing ttn and debugging some indirect
issues (seems either there is something I don't understand about the
hw yet, or maybe an a4xx bug.. right now shaders that I think should
work aren't and I'm in android hell trying to get some more traces
from blob :-/)
BR,
-R
> It would be nice to enable the arrays on all drivers instead of
> working around it indefinitely.
>
> Marek
>
> On Wed, Jun 24, 2015 at 1:31 PM, Rob Clark wrote:
>> Ok, I *thought* we didn't get ArrayID on IN/OUT, but only TEMP? If it
>> is safe to assume that we always get ArrayID that makes it much
>> easier.
>>
>> BR,
>> -R
>>
>> On Wed, Jun 24, 2015 at 5:39 AM, Marek Olšák wrote:
>>> It's not an array, because the ArrayID is 0. It's a valid non-array
>>> declaration. If any TGSI user doesn't understand it, that user should
>>> be fixed.
>>>
>>> Marek
>>>
>>> On Tue, Jun 23, 2015 at 3:20 PM, Rob Clark wrote:
>>>> From: Rob Clark
>>>>
>>>> Ok, so actually there is a ttn issue here to fix as well.. but it
>>>> brought up a question in my mind. When ttn sees something like
>>>>
>>>> DCL IN[0..1]
>>>>
>>>> it will treat that as an array (which in the end will result in
>>>> constraints about where the registers get allocated. Which is not
>>>> really ideal.
>>>>
>>>> With glsl we don't actually get input arrays (but instead a bunch
>>>> of MOV's to a TEMP array) currently. So I'm not quite sure how
>>>> an actual input array should look. (But my preference would be
>>>> IN[a..b] for arrays and IN[c] otherwise)
>>>> ---
>>>> src/gallium/auxiliary/hud/hud_context.c | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/src/gallium/auxiliary/hud/hud_context.c
>>>> b/src/gallium/auxiliary/hud/hud_context.c
>>>> index 6a124f7..2b6d3a7 100644
>>>> --- a/src/gallium/auxiliary/hud/hud_context.c
>>>> +++ b/src/gallium/auxiliary/hud/hud_context.c
>>>> @@ -1163,7 +1163,8 @@ hud_create(struct pipe_context *pipe, struct
>>>> cso_context *cso)
>>>> {
>>>>static const char *vertex_shader_text = {
>>>> "VERT\n"
>>>> - "DCL IN[0..1]\n"
>>>> + "DCL IN[0]\n"
>>>> + "DCL IN[1]\n"
>>>> "DCL OUT[0], POSITION\n"
>>>> "DCL OUT[1], COLOR[0]\n" /* color */
>>>> "DCL OUT[2], GENERIC[0]\n" /* texcoord */
>>>> --
>>>> 2.4.3
>>>>
>>>> ___
>>>> 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] [RFC] gallium/hud: fix issue w/ tgsi_to_nir
tgsi.rst currently says:
If no ArrayID is specified with an indirect addressing operand the whole
register file might be accessed by this operand. This is strongly discouraged
and will prevent packing of scalar/vec2 arrays and effective alias analysis.
I'd be pretty happy to remove it and replace it w/ something to the
effect of indirect addressing where no ArrayID is specified is
undefined :-)
BR,
-R
On Wed, Jun 24, 2015 at 6:17 PM, Marek Olšák wrote:
> Indirect addressing without the ArrayID is undefined in the general
> case. You need the ArrayID to be able to tell where the array
> declaration starts and what its semantic name is.
>
> Marek
>
> On Wed, Jun 24, 2015 at 8:35 PM, Rob Clark wrote:
>> On Wed, Jun 24, 2015 at 12:31 PM, Marek Olšák wrote:
>>> Yes, ArrayID != 0 means it's an array, otherwise it's just a compact
>>> way to add declarations.
>>
>> ok.. hmm, I guess tgsi.rst needs an update then..
>>
>>> I recently added the array support for inputs and outputs, we just
>>> need to enable it on non-radeon non-swrast drivers:
>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=b6ebe7eabf54936a02acc0968e718e0c264a73f5
>>
>> ok, in principle (after fixing ttn based on the assumption that we
>> won't get indirect access if ArrayID==0, and now that tgsi f/e is
>> dropped) freedreno should be ok for array in/out's.. I'll enable the
>> cap and see what happens after fixing ttn and debugging some indirect
>> issues (seems either there is something I don't understand about the
>> hw yet, or maybe an a4xx bug.. right now shaders that I think should
>> work aren't and I'm in android hell trying to get some more traces
>> from blob :-/)
>>
>> BR,
>> -R
>>
>>> It would be nice to enable the arrays on all drivers instead of
>>> working around it indefinitely.
>>>
>>> Marek
>>>
>>> On Wed, Jun 24, 2015 at 1:31 PM, Rob Clark wrote:
>>>> Ok, I *thought* we didn't get ArrayID on IN/OUT, but only TEMP? If it
>>>> is safe to assume that we always get ArrayID that makes it much
>>>> easier.
>>>>
>>>> BR,
>>>> -R
>>>>
>>>> On Wed, Jun 24, 2015 at 5:39 AM, Marek Olšák wrote:
>>>>> It's not an array, because the ArrayID is 0. It's a valid non-array
>>>>> declaration. If any TGSI user doesn't understand it, that user should
>>>>> be fixed.
>>>>>
>>>>> Marek
>>>>>
>>>>> On Tue, Jun 23, 2015 at 3:20 PM, Rob Clark wrote:
>>>>>> From: Rob Clark
>>>>>>
>>>>>> Ok, so actually there is a ttn issue here to fix as well.. but it
>>>>>> brought up a question in my mind. When ttn sees something like
>>>>>>
>>>>>> DCL IN[0..1]
>>>>>>
>>>>>> it will treat that as an array (which in the end will result in
>>>>>> constraints about where the registers get allocated. Which is not
>>>>>> really ideal.
>>>>>>
>>>>>> With glsl we don't actually get input arrays (but instead a bunch
>>>>>> of MOV's to a TEMP array) currently. So I'm not quite sure how
>>>>>> an actual input array should look. (But my preference would be
>>>>>> IN[a..b] for arrays and IN[c] otherwise)
>>>>>> ---
>>>>>> src/gallium/auxiliary/hud/hud_context.c | 3 ++-
>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/src/gallium/auxiliary/hud/hud_context.c
>>>>>> b/src/gallium/auxiliary/hud/hud_context.c
>>>>>> index 6a124f7..2b6d3a7 100644
>>>>>> --- a/src/gallium/auxiliary/hud/hud_context.c
>>>>>> +++ b/src/gallium/auxiliary/hud/hud_context.c
>>>>>> @@ -1163,7 +1163,8 @@ hud_create(struct pipe_context *pipe, struct
>>>>>> cso_context *cso)
>>>>>> {
>>>>>>static const char *vertex_shader_text = {
>>>>>> "VERT\n"
>>>>>> - "DCL IN[0..1]\n"
>>>>>> + "DCL IN[0]\n"
>>>>>> + "DCL IN[1]\n"
>>>>>> "DCL OUT[0], POSITION\n"
>>>>>> "DCL OUT[1], COLOR[0]\n" /* color */
>>>>>> "DCL OUT[2], GENERIC[0]\n" /* texcoord */
>>>>>> --
>>>>>> 2.4.3
>>>>>>
>>>>>> ___
>>>>>> 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] [RFC] gallium/hud: fix issue w/ tgsi_to_nir
I'd be a big fan of letting it go.. if needed for old ARB shader stuff we can give entire IN/OUT file ArrayID==1.. if someone points me in the right direction I don't mind going and poking at it since the whole assuming-the-worst thing if ArrayID==0 is not so nice for register allocation.. BR, -R On Wed, Jun 24, 2015 at 10:38 PM, Roland Scheidegger wrote: > I thought this was needed by something in the gl state tracker. relative > addressing with ARB_vp maybe, can't remember... > I dunno if all places where this is used are fixed up it can go. > > Roland > > > Am 25.06.2015 um 01:31 schrieb Rob Clark: >> tgsi.rst currently says: >> >> >> If no ArrayID is specified with an indirect addressing operand the whole >> register file might be accessed by this operand. This is strongly discouraged >> and will prevent packing of scalar/vec2 arrays and effective alias analysis. >> >> >> I'd be pretty happy to remove it and replace it w/ something to the >> effect of indirect addressing where no ArrayID is specified is >> undefined :-) >> >> BR, >> -R >> >> On Wed, Jun 24, 2015 at 6:17 PM, Marek Olšák wrote: >>> Indirect addressing without the ArrayID is undefined in the general >>> case. You need the ArrayID to be able to tell where the array >>> declaration starts and what its semantic name is. >>> >>> Marek >>> >>> On Wed, Jun 24, 2015 at 8:35 PM, Rob Clark wrote: >>>> On Wed, Jun 24, 2015 at 12:31 PM, Marek Olšák wrote: >>>>> Yes, ArrayID != 0 means it's an array, otherwise it's just a compact >>>>> way to add declarations. >>>> >>>> ok.. hmm, I guess tgsi.rst needs an update then.. >>>> >>>>> I recently added the array support for inputs and outputs, we just >>>>> need to enable it on non-radeon non-swrast drivers: >>>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=b6ebe7eabf54936a02acc0968e718e0c264a73f5 >>>> >>>> ok, in principle (after fixing ttn based on the assumption that we >>>> won't get indirect access if ArrayID==0, and now that tgsi f/e is >>>> dropped) freedreno should be ok for array in/out's.. I'll enable the >>>> cap and see what happens after fixing ttn and debugging some indirect >>>> issues (seems either there is something I don't understand about the >>>> hw yet, or maybe an a4xx bug.. right now shaders that I think should >>>> work aren't and I'm in android hell trying to get some more traces >>>> from blob :-/) >>>> >>>> BR, >>>> -R >>>> >>>>> It would be nice to enable the arrays on all drivers instead of >>>>> working around it indefinitely. >>>>> >>>>> Marek >>>>> >>>>> On Wed, Jun 24, 2015 at 1:31 PM, Rob Clark wrote: >>>>>> Ok, I *thought* we didn't get ArrayID on IN/OUT, but only TEMP? If it >>>>>> is safe to assume that we always get ArrayID that makes it much >>>>>> easier. >>>>>> >>>>>> BR, >>>>>> -R >>>>>> >>>>>> On Wed, Jun 24, 2015 at 5:39 AM, Marek Olšák wrote: >>>>>>> It's not an array, because the ArrayID is 0. It's a valid non-array >>>>>>> declaration. If any TGSI user doesn't understand it, that user should >>>>>>> be fixed. >>>>>>> >>>>>>> Marek >>>>>>> >>>>>>> On Tue, Jun 23, 2015 at 3:20 PM, Rob Clark wrote: >>>>>>>> From: Rob Clark >>>>>>>> >>>>>>>> Ok, so actually there is a ttn issue here to fix as well.. but it >>>>>>>> brought up a question in my mind. When ttn sees something like >>>>>>>> >>>>>>>> DCL IN[0..1] >>>>>>>> >>>>>>>> it will treat that as an array (which in the end will result in >>>>>>>> constraints about where the registers get allocated. Which is not >>>>>>>> really ideal. >>>>>>>> >>>>>>>> With glsl we don't actually get input arrays (but instead a bunch >>>>>>>> of MOV's to a TEMP array) currently. So I'm not quite sure how >>>>>>>> an actual input array s
Re: [Mesa-dev] [RFC] gallium/hud: fix issue w/ tgsi_to_nir
hmm, well I still think tgsi.rst should get some clarification, if for
no other reason than I misunderstood it (and therefore sooner or later
I guess someone else will too)..
I can take a shot at a doc patch..
BR,
-R
On Thu, Jun 25, 2015 at 8:00 AM, Marek Olšák wrote:
> This documentation was only written for TEMPs. I agree that TEMP
> indexing doesn't necessarily need arrays to work, but INPUT and OUTPUT
> indexing always needs them.
>
> Marek
>
> On Thu, Jun 25, 2015 at 1:31 AM, Rob Clark wrote:
>> tgsi.rst currently says:
>>
>>
>> If no ArrayID is specified with an indirect addressing operand the whole
>> register file might be accessed by this operand. This is strongly discouraged
>> and will prevent packing of scalar/vec2 arrays and effective alias analysis.
>>
>>
>> I'd be pretty happy to remove it and replace it w/ something to the
>> effect of indirect addressing where no ArrayID is specified is
>> undefined :-)
>>
>> BR,
>> -R
>>
>> On Wed, Jun 24, 2015 at 6:17 PM, Marek Olšák wrote:
>>> Indirect addressing without the ArrayID is undefined in the general
>>> case. You need the ArrayID to be able to tell where the array
>>> declaration starts and what its semantic name is.
>>>
>>> Marek
>>>
>>> On Wed, Jun 24, 2015 at 8:35 PM, Rob Clark wrote:
>>>> On Wed, Jun 24, 2015 at 12:31 PM, Marek Olšák wrote:
>>>>> Yes, ArrayID != 0 means it's an array, otherwise it's just a compact
>>>>> way to add declarations.
>>>>
>>>> ok.. hmm, I guess tgsi.rst needs an update then..
>>>>
>>>>> I recently added the array support for inputs and outputs, we just
>>>>> need to enable it on non-radeon non-swrast drivers:
>>>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=b6ebe7eabf54936a02acc0968e718e0c264a73f5
>>>>
>>>> ok, in principle (after fixing ttn based on the assumption that we
>>>> won't get indirect access if ArrayID==0, and now that tgsi f/e is
>>>> dropped) freedreno should be ok for array in/out's.. I'll enable the
>>>> cap and see what happens after fixing ttn and debugging some indirect
>>>> issues (seems either there is something I don't understand about the
>>>> hw yet, or maybe an a4xx bug.. right now shaders that I think should
>>>> work aren't and I'm in android hell trying to get some more traces
>>>> from blob :-/)
>>>>
>>>> BR,
>>>> -R
>>>>
>>>>> It would be nice to enable the arrays on all drivers instead of
>>>>> working around it indefinitely.
>>>>>
>>>>> Marek
>>>>>
>>>>> On Wed, Jun 24, 2015 at 1:31 PM, Rob Clark wrote:
>>>>>> Ok, I *thought* we didn't get ArrayID on IN/OUT, but only TEMP? If it
>>>>>> is safe to assume that we always get ArrayID that makes it much
>>>>>> easier.
>>>>>>
>>>>>> BR,
>>>>>> -R
>>>>>>
>>>>>> On Wed, Jun 24, 2015 at 5:39 AM, Marek Olšák wrote:
>>>>>>> It's not an array, because the ArrayID is 0. It's a valid non-array
>>>>>>> declaration. If any TGSI user doesn't understand it, that user should
>>>>>>> be fixed.
>>>>>>>
>>>>>>> Marek
>>>>>>>
>>>>>>> On Tue, Jun 23, 2015 at 3:20 PM, Rob Clark wrote:
>>>>>>>> From: Rob Clark
>>>>>>>>
>>>>>>>> Ok, so actually there is a ttn issue here to fix as well.. but it
>>>>>>>> brought up a question in my mind. When ttn sees something like
>>>>>>>>
>>>>>>>> DCL IN[0..1]
>>>>>>>>
>>>>>>>> it will treat that as an array (which in the end will result in
>>>>>>>> constraints about where the registers get allocated. Which is not
>>>>>>>> really ideal.
>>>>>>>>
>>>>>>>> With glsl we don't actually get input arrays (but instead a bunch
>>>>>>>> of MOV's to a TEMP array) currently. So I'm not quite sure how
>>>>>>>> an actual input array should look. (But my preference would be
>>>>>>>> IN[a..b] for arrays and IN[c] otherwise)
>>>>>>>> ---
>>>>>>>> src/gallium/auxiliary/hud/hud_context.c | 3 ++-
>>>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/src/gallium/auxiliary/hud/hud_context.c
>>>>>>>> b/src/gallium/auxiliary/hud/hud_context.c
>>>>>>>> index 6a124f7..2b6d3a7 100644
>>>>>>>> --- a/src/gallium/auxiliary/hud/hud_context.c
>>>>>>>> +++ b/src/gallium/auxiliary/hud/hud_context.c
>>>>>>>> @@ -1163,7 +1163,8 @@ hud_create(struct pipe_context *pipe, struct
>>>>>>>> cso_context *cso)
>>>>>>>> {
>>>>>>>>static const char *vertex_shader_text = {
>>>>>>>> "VERT\n"
>>>>>>>> - "DCL IN[0..1]\n"
>>>>>>>> + "DCL IN[0]\n"
>>>>>>>> + "DCL IN[1]\n"
>>>>>>>> "DCL OUT[0], POSITION\n"
>>>>>>>> "DCL OUT[1], COLOR[0]\n" /* color */
>>>>>>>> "DCL OUT[2], GENERIC[0]\n" /* texcoord */
>>>>>>>> --
>>>>>>>> 2.4.3
>>>>>>>>
>>>>>>>> ___
>>>>>>>> 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] [RFC] gallium/hud: fix issue w/ tgsi_to_nir
I had a quick look at enabling this for freedreno.. although looks
like it is going to take some work in tgsi_to_nir and/or nir.. the
problem is we end up w/ a register array (rather than variable array
like we do for TEMP arrays).. ie. for something copying from a TEMP
array to an OUT array, we end up like:
vec4 ssa_35 = intrinsic load_var () (arr_2[0]) ()
vec4 ssa_36 = fmov ssa_35
r1[0] = fmov ssa_36
vec4 ssa_37 = intrinsic load_var () (arr_2[1]) ()
vec4 ssa_38 = fmov ssa_37
r1[1] = fmov ssa_38
vec4 ssa_39 = intrinsic load_var () (arr_2[2]) ()
vec4 ssa_40 = fmov ssa_39
r1[2] = fmov ssa_40
vec4 ssa_41 = intrinsic load_var () (arr_2[3]) ()
vec4 ssa_42 = fmov ssa_41
r1[3] = fmov ssa_42
vec4 ssa_43 = fmov r2
r0 = fmov ssa_43
intrinsic store_output (r0) () (0)
intrinsic store_output (r1[0]) () (1)
intrinsic store_output (r1[1]) () (2)
intrinsic store_output (r1[2]) () (3)
intrinsic store_output (r1[3]) () (4)
the r1[] array ends up not getting converted into SSA and hitting an
assert when we try to lower to scalar.. I'm not really sure the best
way to handle this
BR,
-R
On Wed, Jun 24, 2015 at 12:31 PM, Marek Olšák wrote:
> Yes, ArrayID != 0 means it's an array, otherwise it's just a compact
> way to add declarations.
>
> I recently added the array support for inputs and outputs, we just
> need to enable it on non-radeon non-swrast drivers:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=b6ebe7eabf54936a02acc0968e718e0c264a73f5
>
> It would be nice to enable the arrays on all drivers instead of
> working around it indefinitely.
>
> Marek
>
> On Wed, Jun 24, 2015 at 1:31 PM, Rob Clark wrote:
>> Ok, I *thought* we didn't get ArrayID on IN/OUT, but only TEMP? If it
>> is safe to assume that we always get ArrayID that makes it much
>> easier.
>>
>> BR,
>> -R
>>
>> On Wed, Jun 24, 2015 at 5:39 AM, Marek Olšák wrote:
>>> It's not an array, because the ArrayID is 0. It's a valid non-array
>>> declaration. If any TGSI user doesn't understand it, that user should
>>> be fixed.
>>>
>>> Marek
>>>
>>> On Tue, Jun 23, 2015 at 3:20 PM, Rob Clark wrote:
>>>> From: Rob Clark
>>>>
>>>> Ok, so actually there is a ttn issue here to fix as well.. but it
>>>> brought up a question in my mind. When ttn sees something like
>>>>
>>>> DCL IN[0..1]
>>>>
>>>> it will treat that as an array (which in the end will result in
>>>> constraints about where the registers get allocated. Which is not
>>>> really ideal.
>>>>
>>>> With glsl we don't actually get input arrays (but instead a bunch
>>>> of MOV's to a TEMP array) currently. So I'm not quite sure how
>>>> an actual input array should look. (But my preference would be
>>>> IN[a..b] for arrays and IN[c] otherwise)
>>>> ---
>>>> src/gallium/auxiliary/hud/hud_context.c | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/src/gallium/auxiliary/hud/hud_context.c
>>>> b/src/gallium/auxiliary/hud/hud_context.c
>>>> index 6a124f7..2b6d3a7 100644
>>>> --- a/src/gallium/auxiliary/hud/hud_context.c
>>>> +++ b/src/gallium/auxiliary/hud/hud_context.c
>>>> @@ -1163,7 +1163,8 @@ hud_create(struct pipe_context *pipe, struct
>>>> cso_context *cso)
>>>> {
>>>>static const char *vertex_shader_text = {
>>>> "VERT\n"
>>>> - "DCL IN[0..1]\n"
>>>> + "DCL IN[0]\n"
>>>> + "DCL IN[1]\n"
>>>> "DCL OUT[0], POSITION\n"
>>>> "DCL OUT[1], COLOR[0]\n" /* color */
>>>> "DCL OUT[2], GENERIC[0]\n" /* texcoord */
>>>> --
>>>> 2.4.3
>>>>
>>>> ___
>>>> 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 5/7] gallium/ttn: don't upset nir_validate w/ BRK's
From: Rob Clark
Previously we were unconditionally doing ttn_get_src() even for
instructions with no src's. Which created a lot of unnecessary
load_const instructions. These were mostly harmless since NIR opt
passes would strip them back out. But for an ENDIF following a
BRK, it would result in load_const instructions created after the
NIR break instruction. Which nir_validate dislikes.
But we can actually just dtrt by using NumSrcRegs instead.
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 1ad8c68..bf7eb2f 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -1510,7 +1510,7 @@ ttn_emit_instruction(struct ttn_compile *c)
return;
nir_ssa_def *src[TGSI_FULL_MAX_SRC_REGISTERS];
- for (i = 0; i < TGSI_FULL_MAX_SRC_REGISTERS; i++) {
+ for (i = 0; i < tgsi_inst->Instruction.NumSrcRegs; i++) {
src[i] = ttn_get_src(c, &tgsi_inst->Src[i]);
}
nir_alu_dest dest = ttn_get_dest(c, tgsi_dst);
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/7] gallium/ttn: add TXB2
From: Rob Clark
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index e202ce6..1ad8c68 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -1087,6 +1087,11 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
op = nir_texop_txb;
num_srcs = 2;
break;
+ case TGSI_OPCODE_TXB2:
+ op = nir_texop_txb;
+ num_srcs = 2;
+ samp = 2;
+ break;
case TGSI_OPCODE_TXL:
op = nir_texop_txl;
num_srcs = 2;
@@ -1188,6 +1193,12 @@ ttn_tex(struct ttn_compile *c, nir_alu_dest dest,
nir_ssa_def **src)
src_number++;
}
+ if (tgsi_inst->Instruction.Opcode == TGSI_OPCODE_TXB2) {
+ instr->src[src_number].src = nir_src_for_ssa(ttn_channel(b, src[1], X));
+ instr->src[src_number].src_type = nir_tex_src_bias;
+ src_number++;
+ }
+
if (tgsi_inst->Instruction.Opcode == TGSI_OPCODE_TXL) {
instr->src[src_number].src = nir_src_for_ssa(ttn_channel(b, src[0], W));
instr->src[src_number].src_type = nir_tex_src_lod;
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/7] nir: cleanup open-coded instruction casts
From: Rob Clark
Signed-off-by: Rob Clark
---
src/glsl/nir/nir_lower_alu_to_scalar.c | 2 +-
src/glsl/nir/nir_lower_vec_to_movs.c | 2 +-
src/glsl/nir/nir_search.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/glsl/nir/nir_lower_alu_to_scalar.c
b/src/glsl/nir/nir_lower_alu_to_scalar.c
index 25bba4e..5d15fb2 100644
--- a/src/glsl/nir/nir_lower_alu_to_scalar.c
+++ b/src/glsl/nir/nir_lower_alu_to_scalar.c
@@ -164,7 +164,7 @@ lower_alu_to_scalar_block(nir_block *block, void *data)
{
nir_foreach_instr_safe(block, instr) {
if (instr->type == nir_instr_type_alu)
- lower_alu_instr_scalar((nir_alu_instr *)instr, data);
+ lower_alu_instr_scalar(nir_instr_as_alu(instr), data);
}
return true;
diff --git a/src/glsl/nir/nir_lower_vec_to_movs.c
b/src/glsl/nir/nir_lower_vec_to_movs.c
index 602853e..e6d522f 100644
--- a/src/glsl/nir/nir_lower_vec_to_movs.c
+++ b/src/glsl/nir/nir_lower_vec_to_movs.c
@@ -90,7 +90,7 @@ lower_vec_to_movs_block(nir_block *block, void *mem_ctx)
if (instr->type != nir_instr_type_alu)
continue;
- nir_alu_instr *vec = (nir_alu_instr *)instr;
+ nir_alu_instr *vec = nir_instr_as_alu(instr);
switch (vec->op) {
case nir_op_vec2:
diff --git a/src/glsl/nir/nir_search.c b/src/glsl/nir/nir_search.c
index 0c4e48c..c33d6c3 100644
--- a/src/glsl/nir/nir_search.c
+++ b/src/glsl/nir/nir_search.c
@@ -48,7 +48,7 @@ src_is_bool(nir_src src)
return false;
if (src.ssa->parent_instr->type != nir_instr_type_alu)
return false;
- return alu_instr_is_bool((nir_alu_instr *)src.ssa->parent_instr);
+ return alu_instr_is_bool(nir_instr_as_alu(src.ssa->parent_instr));
}
static bool
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/7] gallium/ttn: partial fix for output arrays
From: Rob Clark
It isn't quite yet practical to enable TGSI_ANY_INOUT_DECL_RANGE shader
cap yet, at least not in drivers that need lower_to_scalar pass (which
right now is all of the ttn users), since the register arrays do not get
converted to SSA, which angers nir_lower_alu_to_scalar.
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index a189559..e202ce6 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -1735,9 +1735,11 @@ ttn_add_output_stores(struct ttn_compile *c)
for (i = 0; i < array_len; i++) {
nir_intrinsic_instr *store =
nir_intrinsic_instr_create(b->shader, nir_intrinsic_store_output);
+ unsigned loc = var->data.driver_location + i;
store->num_components = 4;
- store->const_index[0] = var->data.driver_location + i;
- store->src[0].reg.reg = c->output_regs[var->data.driver_location].reg;
+ store->const_index[0] = loc;
+ store->src[0].reg.reg = c->output_regs[loc].reg;
+ store->src[0].reg.base_offset = c->output_regs[loc].offset;
nir_instr_insert_after_cf_list(b->cf_node_list, &store->instr);
}
}
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/7] gallium/ttn: IN/OUT are only array if ArrayID != 0
From: Rob Clark
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 143 ++--
1 file changed, 81 insertions(+), 62 deletions(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 065bbf0..a189559 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -184,7 +184,8 @@ ttn_emit_declaration(struct ttn_compile *c)
c->samp_types[decl->Range.First + i] = type;
}
} else {
- nir_variable *var;
+ bool is_array = (array_size > 1);
+
assert(file == TGSI_FILE_INPUT ||
file == TGSI_FILE_OUTPUT ||
file == TGSI_FILE_CONSTANT);
@@ -193,76 +194,94 @@ ttn_emit_declaration(struct ttn_compile *c)
if ((file == TGSI_FILE_CONSTANT) && decl->Declaration.Dimension)
return;
- var = rzalloc(b->shader, nir_variable);
- var->data.driver_location = decl->Range.First;
-
- var->type = glsl_vec4_type();
- if (array_size > 1)
- var->type = glsl_array_type(var->type, array_size);
+ if ((file == TGSI_FILE_INPUT) || (file == TGSI_FILE_OUTPUT)) {
+ is_array = (is_array && decl->Declaration.Array &&
+ (decl->Array.ArrayID != 0));
+ }
- switch (file) {
- case TGSI_FILE_INPUT:
- var->data.read_only = true;
- var->data.mode = nir_var_shader_in;
- var->name = ralloc_asprintf(var, "in_%d", decl->Range.First);
+ for (i = 0; i < array_size; i++) {
+ unsigned idx = decl->Range.First + i;
+ nir_variable *var = rzalloc(b->shader, nir_variable);
- /* We should probably translate to a VERT_ATTRIB_* or VARYING_SLOT_*
- * instead, but nothing in NIR core is looking at the value
- * currently, and this is less change to drivers.
- */
- var->data.location = decl->Semantic.Name;
- var->data.index = decl->Semantic.Index;
+ var->data.driver_location = idx;
- /* We definitely need to translate the interpolation field, because
- * nir_print will decode it.
- */
- switch (decl->Interp.Interpolate) {
- case TGSI_INTERPOLATE_CONSTANT:
-var->data.interpolation = INTERP_QUALIFIER_FLAT;
-break;
- case TGSI_INTERPOLATE_LINEAR:
-var->data.interpolation = INTERP_QUALIFIER_NOPERSPECTIVE;
-break;
- case TGSI_INTERPOLATE_PERSPECTIVE:
-var->data.interpolation = INTERP_QUALIFIER_SMOOTH;
-break;
- }
-
- exec_list_push_tail(&b->shader->inputs, &var->node);
- break;
- case TGSI_FILE_OUTPUT: {
- /* Since we can't load from outputs in the IR, we make temporaries
- * for the outputs and emit stores to the real outputs at the end of
- * the shader.
- */
- nir_register *reg = nir_local_reg_create(b->impl);
- reg->num_components = 4;
- if (array_size > 1)
-reg->num_array_elems = array_size;
+ var->type = glsl_vec4_type();
+ if (is_array)
+var->type = glsl_array_type(var->type, array_size);
- var->data.mode = nir_var_shader_out;
- var->name = ralloc_asprintf(var, "out_%d", decl->Range.First);
+ switch (file) {
+ case TGSI_FILE_INPUT:
+var->data.read_only = true;
+var->data.mode = nir_var_shader_in;
+var->name = ralloc_asprintf(var, "in_%d", idx);
- var->data.location = decl->Semantic.Name;
- var->data.index = decl->Semantic.Index;
+/* We should probably translate to a VERT_ATTRIB_* or
VARYING_SLOT_*
+ * instead, but nothing in NIR core is looking at the value
+ * currently, and this is less change to drivers.
+ */
+var->data.location = decl->Semantic.Name;
+var->data.index = decl->Semantic.Index;
- for (i = 0; i < array_size; i++) {
-c->output_regs[decl->Range.First + i].offset = i;
-c->output_regs[decl->Range.First + i].reg = reg;
+/* We definitely need to translate the interpolation field, because
+ * nir_print will decode it.
+ */
+switch (decl->Interp.Interpolate) {
+case TGSI_INTERPOLATE_CONSTANT:
+ var->data.interpolation = INTERP_QUALIFIER_FLAT;
+ break;
+case TGSI_INTERPOLATE_LINEAR:
+ var->data.interpolation = INTERP_QUALIFIER_NOPERSPECTIVE;
+ break;
+case TGSI_INTERPOLATE_PERSPECTIVE:
+ var->data.interpolation =
[Mesa-dev] [PATCH 6/7] nir/lower_phis_to_scalar: undef is trivially scalarizable
From: Rob Clark Signed-off-by: Rob Clark --- src/glsl/nir/nir_lower_phis_to_scalar.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/glsl/nir/nir_lower_phis_to_scalar.c b/src/glsl/nir/nir_lower_phis_to_scalar.c index a57d253..739170d 100644 --- a/src/glsl/nir/nir_lower_phis_to_scalar.c +++ b/src/glsl/nir/nir_lower_phis_to_scalar.c @@ -75,6 +75,7 @@ is_phi_src_scalarizable(nir_phi_src *src, return should_lower_phi(nir_instr_as_phi(src_instr), state); case nir_instr_type_load_const: + case nir_instr_type_ssa_undef: /* These are trivially scalarizable */ return true; -- 2.4.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/7] smattering of tgsi/ttn/nir fixes
From: Rob Clark Mostly ttn fixes, plus a couple small nir fixes/cleanups, and a doc patch to clairify ArrayID usage Rob Clark (7): tgsi: update docs for ArrayID usage gallium/ttn: IN/OUT are only array if ArrayID != 0 gallium/ttn: partial fix for output arrays gallium/ttn: add TXB2 gallium/ttn: don't upset nir_validate w/ BRK's nir/lower_phis_to_scalar: undef is trivially scalarizable nir: cleanup open-coded instruction casts src/gallium/auxiliary/nir/tgsi_to_nir.c | 162 +++- src/gallium/docs/source/tgsi.rst| 1 + src/glsl/nir/nir_lower_alu_to_scalar.c | 2 +- src/glsl/nir/nir_lower_phis_to_scalar.c | 1 + src/glsl/nir/nir_lower_vec_to_movs.c| 2 +- src/glsl/nir/nir_search.c | 2 +- 6 files changed, 102 insertions(+), 68 deletions(-) -- 2.4.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/7] tgsi: update docs for ArrayID usage
From: Rob Clark Signed-off-by: Rob Clark --- src/gallium/docs/source/tgsi.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst index 89ca172..4e869e7 100644 --- a/src/gallium/docs/source/tgsi.rst +++ b/src/gallium/docs/source/tgsi.rst @@ -2603,6 +2603,7 @@ not relative to the specified declaration If no ArrayID is specified with an indirect addressing operand the whole register file might be accessed by this operand. This is strongly discouraged and will prevent packing of scalar/vec2 arrays and effective alias analysis. +This is only legal for TEMP and CONST register files. Declaration Semantic -- 2.4.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] gallium/hud: fix issue w/ tgsi_to_nir
On Sat, Jun 27, 2015 at 12:57 PM, Connor Abbott wrote: > On Sat, Jun 27, 2015 at 6:48 AM, Rob Clark wrote: >> I had a quick look at enabling this for freedreno.. although looks >> like it is going to take some work in tgsi_to_nir and/or nir.. the >> problem is we end up w/ a register array (rather than variable array >> like we do for TEMP arrays).. ie. for something copying from a TEMP >> array to an OUT array, we end up like: >> >> vec4 ssa_35 = intrinsic load_var () (arr_2[0]) () >> vec4 ssa_36 = fmov ssa_35 >> r1[0] = fmov ssa_36 >> vec4 ssa_37 = intrinsic load_var () (arr_2[1]) () >> vec4 ssa_38 = fmov ssa_37 >> r1[1] = fmov ssa_38 >> vec4 ssa_39 = intrinsic load_var () (arr_2[2]) () >> vec4 ssa_40 = fmov ssa_39 >> r1[2] = fmov ssa_40 >> vec4 ssa_41 = intrinsic load_var () (arr_2[3]) () >> vec4 ssa_42 = fmov ssa_41 >> r1[3] = fmov ssa_42 >> vec4 ssa_43 = fmov r2 >> r0 = fmov ssa_43 >> intrinsic store_output (r0) () (0) >> intrinsic store_output (r1[0]) () (1) >> intrinsic store_output (r1[1]) () (2) >> intrinsic store_output (r1[2]) () (3) >> intrinsic store_output (r1[3]) () (4) >> >> the r1[] array ends up not getting converted into SSA and hitting an >> assert when we try to lower to scalar.. I'm not really sure the best >> way to handle this > > Well, the frontend shouldn't really be generating register arrays... > they're for backends, not frontends, and it's curently impossible to > eliminate them without extra information about the stride that I've > been hesitant to add, and even then they're more of a pain for > optimization passes. I'm not sure the exact place where ttn is > emitting a register array, but if you fix it to use a variable > instead, vars_to_ssa should clean it up. I was thinking about this, since I'd already done the same for TEMP file arrays.. How should that end up looking, though, from the perspective of store_output? Can store_output reference a variable, or do I have to do a move into ssa and then pass the ssa src to store_output (effectively duplicating the lowering IN/OUT arrays that tgsi currently does in ttn) BR, -R >> >> BR, >> -R >> >> On Wed, Jun 24, 2015 at 12:31 PM, Marek Olšák wrote: >>> Yes, ArrayID != 0 means it's an array, otherwise it's just a compact >>> way to add declarations. >>> >>> I recently added the array support for inputs and outputs, we just >>> need to enable it on non-radeon non-swrast drivers: >>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=b6ebe7eabf54936a02acc0968e718e0c264a73f5 >>> >>> It would be nice to enable the arrays on all drivers instead of >>> working around it indefinitely. >>> >>> Marek >>> >>> On Wed, Jun 24, 2015 at 1:31 PM, Rob Clark wrote: >>>> Ok, I *thought* we didn't get ArrayID on IN/OUT, but only TEMP? If it >>>> is safe to assume that we always get ArrayID that makes it much >>>> easier. >>>> >>>> BR, >>>> -R >>>> >>>> On Wed, Jun 24, 2015 at 5:39 AM, Marek Olšák wrote: >>>>> It's not an array, because the ArrayID is 0. It's a valid non-array >>>>> declaration. If any TGSI user doesn't understand it, that user should >>>>> be fixed. >>>>> >>>>> Marek >>>>> >>>>> On Tue, Jun 23, 2015 at 3:20 PM, Rob Clark wrote: >>>>>> From: Rob Clark >>>>>> >>>>>> Ok, so actually there is a ttn issue here to fix as well.. but it >>>>>> brought up a question in my mind. When ttn sees something like >>>>>> >>>>>> DCL IN[0..1] >>>>>> >>>>>> it will treat that as an array (which in the end will result in >>>>>> constraints about where the registers get allocated. Which is not >>>>>> really ideal. >>>>>> >>>>>> With glsl we don't actually get input arrays (but instead a bunch >>>>>> of MOV's to a TEMP array) currently. So I'm not quite sure how >>>>>> an actual input array should look. (But my preference would be >>>>>> IN[a..b] for arrays and IN[c] otherwise) >>>>>> --- >>>>>> src/gallium/auxiliary/hud/hud_context.c | 3 ++- >>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>&g
Re: [Mesa-dev] [PATCH] gallium/ttn: mark location specially in nir for color0-writes-all
Connor, btw, how does glsl_to_nir handle this?
I guess at some point we want to try to align ttn w/ gtn (ie. cleanup
the whole nir with a tgsi accent thing)..
not that this would be the worst of the ttn vs gtn diff's in the
current state, so it is fine if there isn't a better way to do it
right now.. but I would like to start moving towards using nir
#define's for semantic names/indexes, etc, rather than tgsi or glsl
specific ones.. in the end the driver shouldn't have to care if the
nir came from tgsi/glsl/spirv/etc
BR,
-R
On Sat, Jun 27, 2015 at 5:38 PM, Ilia Mirkin wrote:
> We need to distinguish a shader that has separate writes to each MRT
> from one which is supposed to write the data from MRT 0 to all the MRTs.
> In TGSI this is done with a property. NIR doesn't have that, so encode
> it as a funny location and decode on the other end.
>
> Signed-off-by: Ilia Mirkin
> ---
>
> This fixes bin/fbo-drawbuffers-none gl_FragColor when I additionally
> initialize the "default" colors to a register other than r0.x -- as is
> this happens to work by luck.
>
> Also fix up vc4 to ignore this for now.
>
> src/gallium/auxiliary/nir/tgsi_to_nir.c | 7 ++-
> src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c | 4
> src/gallium/drivers/vc4/vc4_program.c| 6 ++
> 3 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
> b/src/gallium/auxiliary/nir/tgsi_to_nir.c
> index bf7eb2f..4130697 100644
> --- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
> +++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
> @@ -253,7 +253,12 @@ ttn_emit_declaration(struct ttn_compile *c)
> var->name = ralloc_asprintf(var, "out_%d", idx);
>
> var->data.location = decl->Semantic.Name;
> -var->data.index = decl->Semantic.Index;
> +if (decl->Semantic.Name == TGSI_SEMANTIC_COLOR &&
> +decl->Semantic.Index == 0 &&
> +
> c->scan->properties[TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS])
> + var->data.index = -1;
> +else
> + var->data.index = decl->Semantic.Index;
>
> if (is_array) {
> unsigned j;
> diff --git a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
> b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
> index 3b36114..fa13c40 100644
> --- a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
> +++ b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
> @@ -2110,6 +2110,10 @@ setup_output(struct ir3_compile *ctx, nir_variable
> *out)
> so->writes_pos = true;
> break;
> case TGSI_SEMANTIC_COLOR:
> + if (semantic_index == -1) {
> + semantic_index = 0;
> + so->color0_mrt = 1;
> + }
> break;
> default:
> compile_error(ctx, "unknown FS semantic name: %s\n",
> diff --git a/src/gallium/drivers/vc4/vc4_program.c
> b/src/gallium/drivers/vc4/vc4_program.c
> index 2061631..728ecc6 100644
> --- a/src/gallium/drivers/vc4/vc4_program.c
> +++ b/src/gallium/drivers/vc4/vc4_program.c
> @@ -1783,6 +1783,12 @@ ntq_setup_outputs(struct vc4_compile *c)
>
> assert(array_len == 1);
>
> +/* NIR hack to pass through
> + * TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS */
> +if (semantic_name == TGSI_SEMANTIC_COLOR &&
> +semantic_index == -1)
> +semantic_index = 0;
> +
> for (int i = 0; i < 4; i++) {
> add_output(c,
> loc + i,
> --
> 2.3.6
>
> ___
> 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] gallium/ttn: mark location specially in nir for color0-writes-all
On Sat, Jun 27, 2015 at 7:47 PM, Connor Abbott wrote:
> On Sat, Jun 27, 2015 at 2:54 PM, Rob Clark wrote:
>> Connor, btw, how does glsl_to_nir handle this?
>
> The variable for gl_FragColor a special location (FRAG_RESULT_COLOR),
> whereas normal outputs (i.e. gl_FragData[] or out variables) start at
> FRAG_RESULT_DATA0.
>
>>
>> I guess at some point we want to try to align ttn w/ gtn (ie. cleanup
>> the whole nir with a tgsi accent thing)..
>>
>> not that this would be the worst of the ttn vs gtn diff's in the
>> current state, so it is fine if there isn't a better way to do it
>> right now.. but I would like to start moving towards using nir
>> #define's for semantic names/indexes, etc, rather than tgsi or glsl
>> specific ones.. in the end the driver shouldn't have to care if the
>> nir came from tgsi/glsl/spirv/etc
>
> Indeed, it would be nice to have NIR do it's own, well-documented
> thing that's consistent between all the frontends... I've been looking
> at SPIR-V inputs/outputs, and it has its own way of doing things
> that's a little more flexible than GLSL in some ways (e.g. right now
> you can have arbitrary structs of structs and one of the members can
> be marked as flat or noperspective), although it's not really clear
> how much of this is intentional and how much is because it wasn't
> specified or accidentally allowed. The plan has been to map that onto
> how the existing Mesa infrastructure does things, although the current
> underspecification of SPIR-V combined with the underspecification of
> how it all works in Mesa has been a bit frustrating. I'm not really
> familiar with how it works in Gallium at all, though, so I'm not sure
> I'd be the one for the job, or if there even is a person really
> qualified for it.
the one good thing about tgsi is it is pretty well specified, and in a
way that is independent of what sits upstream of tgsi ;-)
I'd be a fan of specifying things in NIR (w/ it's own
enums/#defines/etc) and mapping glsl/spirv/etc onto that.. current
re-use of glsl specific stuff in NIR is a bit of a pain point for
gallium drivers (since gallium drivers can be used for things other
than gl..)
BR,
-R
>>
>> BR,
>> -R
>>
>>
>> On Sat, Jun 27, 2015 at 5:38 PM, Ilia Mirkin wrote:
>>> We need to distinguish a shader that has separate writes to each MRT
>>> from one which is supposed to write the data from MRT 0 to all the MRTs.
>>> In TGSI this is done with a property. NIR doesn't have that, so encode
>>> it as a funny location and decode on the other end.
>>>
>>> Signed-off-by: Ilia Mirkin
>>> ---
>>>
>>> This fixes bin/fbo-drawbuffers-none gl_FragColor when I additionally
>>> initialize the "default" colors to a register other than r0.x -- as is
>>> this happens to work by luck.
>>>
>>> Also fix up vc4 to ignore this for now.
>>>
>>> src/gallium/auxiliary/nir/tgsi_to_nir.c | 7 ++-
>>> src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c | 4
>>> src/gallium/drivers/vc4/vc4_program.c| 6 ++
>>> 3 files changed, 16 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
>>> b/src/gallium/auxiliary/nir/tgsi_to_nir.c
>>> index bf7eb2f..4130697 100644
>>> --- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
>>> +++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
>>> @@ -253,7 +253,12 @@ ttn_emit_declaration(struct ttn_compile *c)
>>> var->name = ralloc_asprintf(var, "out_%d", idx);
>>>
>>> var->data.location = decl->Semantic.Name;
>>> -var->data.index = decl->Semantic.Index;
>>> +if (decl->Semantic.Name == TGSI_SEMANTIC_COLOR &&
>>> +decl->Semantic.Index == 0 &&
>>> +
>>> c->scan->properties[TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS])
>>> + var->data.index = -1;
>>> +else
>>> + var->data.index = decl->Semantic.Index;
>>>
>>> if (is_array) {
>>> unsigned j;
>>> diff --git a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
>>> b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
>>> index 3b36114..fa13c40 100644
>>> --- a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
>>> +++ b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
>>> @@ -2
[Mesa-dev] [PATCH 1/4] tgsi: update docs for ArrayID usage
From: Rob Clark Signed-off-by: Rob Clark --- src/gallium/docs/source/tgsi.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst index 89ca172..4e869e7 100644 --- a/src/gallium/docs/source/tgsi.rst +++ b/src/gallium/docs/source/tgsi.rst @@ -2603,6 +2603,7 @@ not relative to the specified declaration If no ArrayID is specified with an indirect addressing operand the whole register file might be accessed by this operand. This is strongly discouraged and will prevent packing of scalar/vec2 arrays and effective alias analysis. +This is only legal for TEMP and CONST register files. Declaration Semantic -- 2.4.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] gallium/ttn: mark location specially in nir for color0-writes-all
From: Ilia Mirkin
We need to distinguish a shader that has separate writes to each MRT
from one which is supposed to write the data from MRT 0 to all the MRTs.
In TGSI this is done with a property. NIR doesn't have that, so encode
it as a funny location and decode on the other end.
Signed-off-by: Ilia Mirkin
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 7 ++-
src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c | 4
src/gallium/drivers/vc4/vc4_program.c| 6 ++
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index bf7eb2f..4130697 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -253,7 +253,12 @@ ttn_emit_declaration(struct ttn_compile *c)
var->name = ralloc_asprintf(var, "out_%d", idx);
var->data.location = decl->Semantic.Name;
-var->data.index = decl->Semantic.Index;
+if (decl->Semantic.Name == TGSI_SEMANTIC_COLOR &&
+decl->Semantic.Index == 0 &&
+c->scan->properties[TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS])
+ var->data.index = -1;
+else
+ var->data.index = decl->Semantic.Index;
if (is_array) {
unsigned j;
diff --git a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
index 3b36114..fa13c40 100644
--- a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
+++ b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
@@ -2110,6 +2110,10 @@ setup_output(struct ir3_compile *ctx, nir_variable *out)
so->writes_pos = true;
break;
case TGSI_SEMANTIC_COLOR:
+ if (semantic_index == -1) {
+ semantic_index = 0;
+ so->color0_mrt = 1;
+ }
break;
default:
compile_error(ctx, "unknown FS semantic name: %s\n",
diff --git a/src/gallium/drivers/vc4/vc4_program.c
b/src/gallium/drivers/vc4/vc4_program.c
index 2061631..728ecc6 100644
--- a/src/gallium/drivers/vc4/vc4_program.c
+++ b/src/gallium/drivers/vc4/vc4_program.c
@@ -1783,6 +1783,12 @@ ntq_setup_outputs(struct vc4_compile *c)
assert(array_len == 1);
+/* NIR hack to pass through
+ * TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS */
+if (semantic_name == TGSI_SEMANTIC_COLOR &&
+semantic_index == -1)
+semantic_index = 0;
+
for (int i = 0; i < 4; i++) {
add_output(c,
loc + i,
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] nir/lower_phis_to_scalar: undef is trivially scalarizable
From: Rob Clark Signed-off-by: Rob Clark --- src/glsl/nir/nir_lower_phis_to_scalar.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/glsl/nir/nir_lower_phis_to_scalar.c b/src/glsl/nir/nir_lower_phis_to_scalar.c index a57d253..739170d 100644 --- a/src/glsl/nir/nir_lower_phis_to_scalar.c +++ b/src/glsl/nir/nir_lower_phis_to_scalar.c @@ -75,6 +75,7 @@ is_phi_src_scalarizable(nir_phi_src *src, return should_lower_phi(nir_instr_as_phi(src_instr), state); case nir_instr_type_load_const: + case nir_instr_type_ssa_undef: /* These are trivially scalarizable */ return true; -- 2.4.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/4] smattering of tgsi/ttn/nir fixes (v2)
From: Rob Clark Resend, with the patches that didn't yet get an explicit r-b (hint, hint). No real changes, although did add a bit of info to the commit msg for 2/4. Also picked up a patch from Ilia for fixing MRT. This would be solved differently after we gain some proper nir enums/defines for semantic names, rather than continuing with the TGSI defines. But for a short term fix for the regression when switching to ttn+nir, it seems like the best way. Ilia Mirkin (1): gallium/ttn: mark location specially in nir for color0-writes-all Rob Clark (3): tgsi: update docs for ArrayID usage gallium/ttn: IN/OUT are only array if ArrayID != 0 nir/lower_phis_to_scalar: undef is trivially scalarizable src/gallium/auxiliary/nir/tgsi_to_nir.c| 148 - src/gallium/docs/source/tgsi.rst | 1 + .../drivers/freedreno/ir3/ir3_compiler_nir.c | 4 + src/gallium/drivers/vc4/vc4_program.c | 6 + src/glsl/nir/nir_lower_phis_to_scalar.c| 1 + 5 files changed, 98 insertions(+), 62 deletions(-) -- 2.4.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] gallium/ttn: IN/OUT are only array if ArrayID != 0
From: Rob Clark
Fixes issue with gallium HUD. See this thread for details:
http://lists.freedesktop.org/archives/mesa-dev/2015-June/087140.html
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 143 ++--
1 file changed, 81 insertions(+), 62 deletions(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index e1647d5..bf7eb2f 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -184,7 +184,8 @@ ttn_emit_declaration(struct ttn_compile *c)
c->samp_types[decl->Range.First + i] = type;
}
} else {
- nir_variable *var;
+ bool is_array = (array_size > 1);
+
assert(file == TGSI_FILE_INPUT ||
file == TGSI_FILE_OUTPUT ||
file == TGSI_FILE_CONSTANT);
@@ -193,76 +194,94 @@ ttn_emit_declaration(struct ttn_compile *c)
if ((file == TGSI_FILE_CONSTANT) && decl->Declaration.Dimension)
return;
- var = rzalloc(b->shader, nir_variable);
- var->data.driver_location = decl->Range.First;
-
- var->type = glsl_vec4_type();
- if (array_size > 1)
- var->type = glsl_array_type(var->type, array_size);
+ if ((file == TGSI_FILE_INPUT) || (file == TGSI_FILE_OUTPUT)) {
+ is_array = (is_array && decl->Declaration.Array &&
+ (decl->Array.ArrayID != 0));
+ }
- switch (file) {
- case TGSI_FILE_INPUT:
- var->data.read_only = true;
- var->data.mode = nir_var_shader_in;
- var->name = ralloc_asprintf(var, "in_%d", decl->Range.First);
+ for (i = 0; i < array_size; i++) {
+ unsigned idx = decl->Range.First + i;
+ nir_variable *var = rzalloc(b->shader, nir_variable);
- /* We should probably translate to a VERT_ATTRIB_* or VARYING_SLOT_*
- * instead, but nothing in NIR core is looking at the value
- * currently, and this is less change to drivers.
- */
- var->data.location = decl->Semantic.Name;
- var->data.index = decl->Semantic.Index;
+ var->data.driver_location = idx;
- /* We definitely need to translate the interpolation field, because
- * nir_print will decode it.
- */
- switch (decl->Interp.Interpolate) {
- case TGSI_INTERPOLATE_CONSTANT:
-var->data.interpolation = INTERP_QUALIFIER_FLAT;
-break;
- case TGSI_INTERPOLATE_LINEAR:
-var->data.interpolation = INTERP_QUALIFIER_NOPERSPECTIVE;
-break;
- case TGSI_INTERPOLATE_PERSPECTIVE:
-var->data.interpolation = INTERP_QUALIFIER_SMOOTH;
-break;
- }
-
- exec_list_push_tail(&b->shader->inputs, &var->node);
- break;
- case TGSI_FILE_OUTPUT: {
- /* Since we can't load from outputs in the IR, we make temporaries
- * for the outputs and emit stores to the real outputs at the end of
- * the shader.
- */
- nir_register *reg = nir_local_reg_create(b->impl);
- reg->num_components = 4;
- if (array_size > 1)
-reg->num_array_elems = array_size;
+ var->type = glsl_vec4_type();
+ if (is_array)
+var->type = glsl_array_type(var->type, array_size);
- var->data.mode = nir_var_shader_out;
- var->name = ralloc_asprintf(var, "out_%d", decl->Range.First);
+ switch (file) {
+ case TGSI_FILE_INPUT:
+var->data.read_only = true;
+var->data.mode = nir_var_shader_in;
+var->name = ralloc_asprintf(var, "in_%d", idx);
- var->data.location = decl->Semantic.Name;
- var->data.index = decl->Semantic.Index;
+/* We should probably translate to a VERT_ATTRIB_* or
VARYING_SLOT_*
+ * instead, but nothing in NIR core is looking at the value
+ * currently, and this is less change to drivers.
+ */
+var->data.location = decl->Semantic.Name;
+var->data.index = decl->Semantic.Index;
- for (i = 0; i < array_size; i++) {
-c->output_regs[decl->Range.First + i].offset = i;
-c->output_regs[decl->Range.First + i].reg = reg;
+/* We definitely need to translate the interpolation field, because
+ * nir_print will decode it.
+ */
+switch (decl->Interp.Interpolate) {
+case TGSI_INTERPOLATE_CONSTANT:
+ var->data.interpolation = INTERP_QUALIFIER_FLAT;
+ break;
+case TGSI_INTERPOLATE_LINEAR:
+ var->data.interpolation = INTERP_QUALIFIER_NOPERS
Re: [Mesa-dev] [PATCH 4/4] gallium/ttn: mark location specially in nir for color0-writes-all
On Wed, Jul 1, 2015 at 4:27 PM, Eric Anholt wrote: > Rob Clark writes: > >> From: Ilia Mirkin >> >> We need to distinguish a shader that has separate writes to each MRT >> from one which is supposed to write the data from MRT 0 to all the MRTs. >> In TGSI this is done with a property. NIR doesn't have that, so encode >> it as a funny location and decode on the other end. >> >> Signed-off-by: Ilia Mirkin > > Yeah, seems like an OK patch for now, though we really need to start > using common enums instead. yeah.. I need to spend a bit of time on kernel side of things, but after (if no one beats me to it) I was thinking to start trying to clean up the whole nir with tgsi vs glsl thing.. BR, -R > Reviewed-by: Eric Anholt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] xa: don't leak fences
From: Rob Clark
XA was never unref'ing last_fence in the various call paths to
pipe->flush(). Add this to xa_context_flush() and update the other
open-coded calls to pipe->flush() to use xa_context_flush() instead.
This fixes a memory leak reported with xf86-video-freedreno.
Reported-by: Nicolas Dechesne
Cc: "10.5 10.6"
Signed-off-by: Rob Clark
---
src/gallium/state_trackers/xa/xa_context.c | 6 +-
src/gallium/state_trackers/xa/xa_tracker.c | 2 +-
src/gallium/state_trackers/xa/xa_yuv.c | 2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_context.c
b/src/gallium/state_trackers/xa/xa_context.c
index fd49c82..ebfb290 100644
--- a/src/gallium/state_trackers/xa/xa_context.c
+++ b/src/gallium/state_trackers/xa/xa_context.c
@@ -37,7 +37,11 @@
XA_EXPORT void
xa_context_flush(struct xa_context *ctx)
{
- ctx->pipe->flush(ctx->pipe, &ctx->last_fence, 0);
+if (ctx->last_fence) {
+struct pipe_screen *screen = ctx->xa->screen;
+screen->fence_reference(screen, &ctx->last_fence, NULL);
+}
+ctx->pipe->flush(ctx->pipe, &ctx->last_fence, 0);
}
XA_EXPORT struct xa_context *
diff --git a/src/gallium/state_trackers/xa/xa_tracker.c
b/src/gallium/state_trackers/xa/xa_tracker.c
index a384c1c..1df1da7 100644
--- a/src/gallium/state_trackers/xa/xa_tracker.c
+++ b/src/gallium/state_trackers/xa/xa_tracker.c
@@ -464,7 +464,7 @@ xa_surface_redefine(struct xa_surface *srf,
xa_min(save_height, template->height0), &src_box);
pipe->resource_copy_region(pipe, texture,
0, 0, 0, 0, srf->tex, 0, &src_box);
- pipe->flush(pipe, &xa->default_ctx->last_fence, 0);
+ xa_context_flush(xa->default_ctx);
}
pipe_resource_reference(&srf->tex, texture);
diff --git a/src/gallium/state_trackers/xa/xa_yuv.c
b/src/gallium/state_trackers/xa/xa_yuv.c
index 1519639..97a1833 100644
--- a/src/gallium/state_trackers/xa/xa_yuv.c
+++ b/src/gallium/state_trackers/xa/xa_yuv.c
@@ -154,7 +154,7 @@ xa_yuv_planar_blit(struct xa_context *r,
box++;
}
-r->pipe->flush(r->pipe, &r->last_fence, 0);
+xa_context_flush(r);
xa_ctx_sampler_views_destroy(r);
xa_ctx_srf_destroy(r);
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] gallium: clarify reference counting for fence
From: Rob Clark
No where was it spelled out that the state tracker may expect the pipe
driver to unref the old fence.
Signed-off-by: Rob Clark
---
src/gallium/include/pipe/p_context.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/include/pipe/p_context.h
index c2eedf8..d2c2e4c 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -361,8 +361,14 @@ struct pipe_context {
const void *clear_value,
int clear_value_size);
- /** Flush draw commands
+ /**
+* Flush draw commands
+*
+* NOTE: use screen->fence_reference() (or equivalent) to transfer
+* new fence ref to **fence, to ensure that previous fence is unref'd
*
+* \param fence if not NULL, an old fence to unref and transfer a
+*new fence reference to
* \param flags bitfield of enum pipe_flush_flags values.
*/
void (*flush)(struct pipe_context *pipe,
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] vc4: unref old fence
From: Rob Clark
Some, but not all, state trackers will explicitly unref (and set to
NULL) the previous *fence before calling pipe->flush(). So driver
should use fence_ref() which will unref the old fence if not NULL.
Signed-off-by: Rob Clark
---
src/gallium/drivers/vc4/vc4_context.c | 3 ++-
src/gallium/drivers/vc4/vc4_fence.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/vc4/vc4_context.c
b/src/gallium/drivers/vc4/vc4_context.c
index 630f8e6..7de4fad 100644
--- a/src/gallium/drivers/vc4/vc4_context.c
+++ b/src/gallium/drivers/vc4/vc4_context.c
@@ -103,9 +103,10 @@ vc4_pipe_flush(struct pipe_context *pctx, struct
pipe_fence_handle **fence,
vc4_flush(pctx);
if (fence) {
+struct pipe_screen *screen = pctx->screen;
struct vc4_fence *f = vc4_fence_create(vc4->screen,
vc4->last_emit_seqno);
-*fence = (struct pipe_fence_handle *)f;
+screen->fence_reference(screen, fence, (struct
pipe_fence_handle *)f);
}
}
diff --git a/src/gallium/drivers/vc4/vc4_fence.c
b/src/gallium/drivers/vc4/vc4_fence.c
index f2ee91d..6055ffe 100644
--- a/src/gallium/drivers/vc4/vc4_fence.c
+++ b/src/gallium/drivers/vc4/vc4_fence.c
@@ -88,7 +88,7 @@ vc4_fence_create(struct vc4_screen *screen, uint64_t seqno)
if (!f)
return NULL;
-pipe_reference_init(&f->reference, 1);
+pipe_reference_init(&f->reference, 0);
f->seqno = seqno;
return f;
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/4] fence refcnting fixes
From: Rob Clark This isn't at all clear for pipe driver writers currently, since it is not documented anywhere. But radeon/nouveau/llvmpipe seem to drop the ref on the **fence passed in to pipe->flush() (if *fence!=NULL). Freedreno/ilo/vc4 where not doing this. Some state trackers do call screen->fence_reference(screen, &fence, NULL) before pipe->flush(), but others do not. Add a comment for pipe->flush() to clairify what is expected of the driver, and fixup freedreno/ilo/vc4 to comply. Note: that ilo/vc4 patches are untested Rob Clark (4): gallium: clarify reference counting for fence freedreno: unref old fence ilo: unref old fence vc4: unref old fence src/gallium/drivers/freedreno/freedreno_context.c | 2 +- src/gallium/drivers/freedreno/freedreno_fence.c | 2 +- src/gallium/drivers/ilo/ilo_context.c | 5 - src/gallium/drivers/ilo/ilo_screen.c | 2 +- src/gallium/drivers/vc4/vc4_context.c | 3 ++- src/gallium/drivers/vc4/vc4_fence.c | 2 +- src/gallium/include/pipe/p_context.h | 8 +++- 7 files changed, 17 insertions(+), 7 deletions(-) -- 2.4.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] freedreno: unref old fence
From: Rob Clark Some, but not all, state trackers will explicitly unref (and set to NULL) the previous *fence before calling pipe->flush(). So driver should use fence_ref() which will unref the old fence if not NULL. Signed-off-by: Rob Clark --- src/gallium/drivers/freedreno/freedreno_context.c | 2 +- src/gallium/drivers/freedreno/freedreno_fence.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/freedreno/freedreno_context.c b/src/gallium/drivers/freedreno/freedreno_context.c index 668ef36..42f79d3 100644 --- a/src/gallium/drivers/freedreno/freedreno_context.c +++ b/src/gallium/drivers/freedreno/freedreno_context.c @@ -145,7 +145,7 @@ fd_context_flush(struct pipe_context *pctx, struct pipe_fence_handle **fence, fd_context_render(pctx); if (fence) - *fence = fd_fence_create(pctx); + fd_screen_fence_ref(pctx->screen, fence, fd_fence_create(pctx)); } void diff --git a/src/gallium/drivers/freedreno/freedreno_fence.c b/src/gallium/drivers/freedreno/freedreno_fence.c index 375e58f..c30c3f9 100644 --- a/src/gallium/drivers/freedreno/freedreno_fence.c +++ b/src/gallium/drivers/freedreno/freedreno_fence.c @@ -84,7 +84,7 @@ struct pipe_fence_handle * fd_fence_create(struct pipe_context *pctx) if (!fence) return NULL; - pipe_reference_init(&fence->reference, 1); + pipe_reference_init(&fence->reference, 0); fence->ctx = ctx; fence->screen = ctx->screen; -- 2.4.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] ilo: unref old fence
From: Rob Clark
Some, but not all, state trackers will explicitly unref (and set to
NULL) the previous *fence before calling pipe->flush(). So driver
should use fence_ref() which will unref the old fence if not NULL.
Signed-off-by: Rob Clark
---
src/gallium/drivers/ilo/ilo_context.c | 5 -
src/gallium/drivers/ilo/ilo_screen.c | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/ilo/ilo_context.c
b/src/gallium/drivers/ilo/ilo_context.c
index 3d5c7b6..8d17816 100644
--- a/src/gallium/drivers/ilo/ilo_context.c
+++ b/src/gallium/drivers/ilo/ilo_context.c
@@ -62,7 +62,10 @@ ilo_flush(struct pipe_context *pipe,
(flags & PIPE_FLUSH_END_OF_FRAME) ? "frame end" : "user request");
if (f) {
- *f = ilo_screen_fence_create(pipe->screen, ilo->cp->last_submitted_bo);
+ struct pipe_screen *screen = pipe->screen;
+ struct pipe_fence_handle *fence;
+ fence = ilo_screen_fence_create(pipe->screen,
ilo->cp->last_submitted_bo);
+ screen->fence_reference(screen, f, fence);
}
}
diff --git a/src/gallium/drivers/ilo/ilo_screen.c
b/src/gallium/drivers/ilo/ilo_screen.c
index faebb92..a6abd84 100644
--- a/src/gallium/drivers/ilo/ilo_screen.c
+++ b/src/gallium/drivers/ilo/ilo_screen.c
@@ -693,7 +693,7 @@ ilo_screen_fence_create(struct pipe_screen *screen, struct
intel_bo *bo)
if (!fence)
return NULL;
- pipe_reference_init(&fence->reference, 1);
+ pipe_reference_init(&fence->reference, 0);
fence->seqno_bo = intel_bo_ref(bo);
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] fence refcnting fixes
Bleh, assert(pipe_is_referenced(ptr)) in pipe_reference_described() is non-pleased in debug builds about the trick of starting out the fences w/ refcnt=0 (so that it doesn't end up getting upref'd to 2 in pipe->flush().. so I'll have to re-work the fd/ilo/vc4 patches slightly.. BR, -R On Wed, Jul 8, 2015 at 4:34 PM, Rob Clark wrote: > From: Rob Clark > > This isn't at all clear for pipe driver writers currently, since it > is not documented anywhere. But radeon/nouveau/llvmpipe seem to drop > the ref on the **fence passed in to pipe->flush() (if *fence!=NULL). > Freedreno/ilo/vc4 where not doing this. Some state trackers do call > screen->fence_reference(screen, &fence, NULL) before pipe->flush(), > but others do not. > > Add a comment for pipe->flush() to clairify what is expected of the > driver, and fixup freedreno/ilo/vc4 to comply. > > Note: that ilo/vc4 patches are untested > > Rob Clark (4): > gallium: clarify reference counting for fence > freedreno: unref old fence > ilo: unref old fence > vc4: unref old fence > > src/gallium/drivers/freedreno/freedreno_context.c | 2 +- > src/gallium/drivers/freedreno/freedreno_fence.c | 2 +- > src/gallium/drivers/ilo/ilo_context.c | 5 - > src/gallium/drivers/ilo/ilo_screen.c | 2 +- > src/gallium/drivers/vc4/vc4_context.c | 3 ++- > src/gallium/drivers/vc4/vc4_fence.c | 2 +- > src/gallium/include/pipe/p_context.h | 8 +++- > 7 files changed, 17 insertions(+), 7 deletions(-) > > -- > 2.4.3 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] ilo: unref old fence
From: Rob Clark
Some, but not all, state trackers will explicitly unref (and set to
NULL) the previous *fence before calling pipe->flush(). So driver
should use fence_ref() which will unref the old fence if not NULL.
Signed-off-by: Rob Clark
---
src/gallium/drivers/ilo/ilo_context.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/ilo/ilo_context.c
b/src/gallium/drivers/ilo/ilo_context.c
index 3d5c7b6..b9a16aa 100644
--- a/src/gallium/drivers/ilo/ilo_context.c
+++ b/src/gallium/drivers/ilo/ilo_context.c
@@ -62,6 +62,8 @@ ilo_flush(struct pipe_context *pipe,
(flags & PIPE_FLUSH_END_OF_FRAME) ? "frame end" : "user request");
if (f) {
+ struct pipe_screen *screen = pipe->screen;
+ screen->fence_reference(screen, f, NULL);
*f = ilo_screen_fence_create(pipe->screen, ilo->cp->last_submitted_bo);
}
}
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] freedreno: unref old fence
From: Rob Clark
Some, but not all, state trackers will explicitly unref (and set to
NULL) the previous *fence before calling pipe->flush(). So driver
should use fence_ref() which will unref the old fence if not NULL.
Signed-off-by: Rob Clark
---
src/gallium/drivers/freedreno/freedreno_context.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/freedreno/freedreno_context.c
b/src/gallium/drivers/freedreno/freedreno_context.c
index 668ef36..127fb5f 100644
--- a/src/gallium/drivers/freedreno/freedreno_context.c
+++ b/src/gallium/drivers/freedreno/freedreno_context.c
@@ -144,8 +144,10 @@ fd_context_flush(struct pipe_context *pctx, struct
pipe_fence_handle **fence,
{
fd_context_render(pctx);
- if (fence)
+ if (fence) {
+ fd_screen_fence_ref(pctx->screen, fence, NULL);
*fence = fd_fence_create(pctx);
+ }
}
void
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] vc4: unref old fence
From: Rob Clark
Some, but not all, state trackers will explicitly unref (and set to
NULL) the previous *fence before calling pipe->flush(). So driver
should use fence_ref() which will unref the old fence if not NULL.
Signed-off-by: Rob Clark
---
src/gallium/drivers/vc4/vc4_context.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/vc4/vc4_context.c
b/src/gallium/drivers/vc4/vc4_context.c
index 630f8e6..316598f 100644
--- a/src/gallium/drivers/vc4/vc4_context.c
+++ b/src/gallium/drivers/vc4/vc4_context.c
@@ -103,8 +103,10 @@ vc4_pipe_flush(struct pipe_context *pctx, struct
pipe_fence_handle **fence,
vc4_flush(pctx);
if (fence) {
+struct pipe_screen *screen = pctx->screen;
struct vc4_fence *f = vc4_fence_create(vc4->screen,
vc4->last_emit_seqno);
+screen->fence_reference(screen, fence, NULL);
*fence = (struct pipe_fence_handle *)f;
}
}
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] fence refcnting fixes
On Thu, Jul 9, 2015 at 4:21 AM, Christian König wrote: > On 08.07.2015 22:34, Rob Clark wrote: >> >> From: Rob Clark >> >> This isn't at all clear for pipe driver writers currently, since it >> is not documented anywhere. But radeon/nouveau/llvmpipe seem to drop >> the ref on the **fence passed in to pipe->flush() (if *fence!=NULL). >> Freedreno/ilo/vc4 where not doing this. Some state trackers do call >> screen->fence_reference(screen, &fence, NULL) before pipe->flush(), >> but others do not. >> >> Add a comment for pipe->flush() to clairify what is expected of the >> driver, and fixup freedreno/ilo/vc4 to comply. >> >> Note: that ilo/vc4 patches are untested > > > Oh, yes please. That also annoyed me once or twice while hacking on the > state trackers. > > Since I'm not into the drivers those changes are Acked-by: Christian König > > > Do you want to take care of the state trackers as well or should I look into > the video state trackers to fix this myself? I guess w/ the doc change + fixing drivers, we don't strictly need to change the other state trackers to explicitly unref their last_fence, if that is what you had in mind? It probably wouldn't hurt, but shouldn't be required.. BR, -R > Regards, > Christian. > > >> >> Rob Clark (4): >>gallium: clarify reference counting for fence >>freedreno: unref old fence >>ilo: unref old fence >>vc4: unref old fence >> >> src/gallium/drivers/freedreno/freedreno_context.c | 2 +- >> src/gallium/drivers/freedreno/freedreno_fence.c | 2 +- >> src/gallium/drivers/ilo/ilo_context.c | 5 - >> src/gallium/drivers/ilo/ilo_screen.c | 2 +- >> src/gallium/drivers/vc4/vc4_context.c | 3 ++- >> src/gallium/drivers/vc4/vc4_fence.c | 2 +- >> src/gallium/include/pipe/p_context.h | 8 +++- >> 7 files changed, 17 insertions(+), 7 deletions(-) >> > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] vc4: unref old fence
On Thu, Jul 9, 2015 at 8:36 AM, Emil Velikov wrote:
> On 9 July 2015 at 01:46, Rob Clark wrote:
>> From: Rob Clark
>>
>> Some, but not all, state trackers will explicitly unref (and set to
>> NULL) the previous *fence before calling pipe->flush(). So driver
>> should use fence_ref() which will unref the old fence if not NULL.
>>
>> Signed-off-by: Rob Clark
>> ---
>> src/gallium/drivers/vc4/vc4_context.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/src/gallium/drivers/vc4/vc4_context.c
>> b/src/gallium/drivers/vc4/vc4_context.c
>> index 630f8e6..316598f 100644
>> --- a/src/gallium/drivers/vc4/vc4_context.c
>> +++ b/src/gallium/drivers/vc4/vc4_context.c
>> @@ -103,8 +103,10 @@ vc4_pipe_flush(struct pipe_context *pctx, struct
>> pipe_fence_handle **fence,
>> vc4_flush(pctx);
>>
>> if (fence) {
>> +struct pipe_screen *screen = pctx->screen;
>> struct vc4_fence *f = vc4_fence_create(vc4->screen,
>>
>> vc4->last_emit_seqno);
>> +screen->fence_reference(screen, fence, NULL);
> The order seems to be reversed comparing to the other patches that
> you've sent. Is that intentional ?
it just made the diff smaller to do it in this order... the order
doesn't really matter
BR,
-R
> -Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH shader-db] Add support for shadertoy tests
Attached script grabs shaders from shadertoy, and dumps them out as
.shader_test files which can be run through shader-db for compiler
testing.
shadertoy only gives you a fragment shader (which works based on
gl_FragCoord), so a generic vertex shader is used. And a blurb is
inserted for the pre-defined uniforms and main() function (which just
calls shadertoy mainImage() fxn).
v2: updated w/ python suggestions from Dylan
---
Note: we probably want to pick a couple shadertoy shaders and commit
them (rather than pulling down *all* shadertoy shaders, which may
change over time, etc). I can just pick a couple randomly unless
anyone has some requests. Either way, seems useful to have the script
in git in case anyone else wants to grab new/more shaders.
grab-shadertoy.py | 66 +++
1 file changed, 66 insertions(+)
create mode 100755 grab-shadertoy.py
diff --git a/grab-shadertoy.py b/grab-shadertoy.py
new file mode 100755
index 000..04db411
--- /dev/null
+++ b/grab-shadertoy.py
@@ -0,0 +1,66 @@
+#!/usr/bin/env python3
+
+
+import os, requests, textwrap
+
+url = 'https://www.shadertoy.com/api/v1/shaders'
+key = '?key=NdnKw7'
+
+header = textwrap.dedent("""\
+[require]
+GLSL >= 1.30
+
+[fragment shader]
+#version 130
+uniform vec3 iResolution;
+uniform float iGlobalTime;
+uniform float iChannelTime[4];
+uniform vec4 iMouse;
+uniform vec4 iDate;
+uniform float iSampleRate;
+uniform vec3 iChannelResolution[4];
+uniform sampler2D iChannel0;
+uniform sampler2D iChannel1;
+uniform sampler2D iChannel2;
+uniform sampler2D iChannel3;
+
+""")
+
+footer = textwrap.dedent("""\
+
+void main() { mainImage(gl_FragColor, gl_FragCoord.xy); }
+
+[vertex shader]
+#version 130
+in vec2 position;
+
+void main()
+{
+ gl_Position = vec4(position, 0.0, 1.0);
+}
+""")
+
+# Get the list of shaders
+r = requests.get(url + key)
+j = r.json()
+print('Found {} shaders'.format(j['Shaders']))
+
+shader_ids = j['Results']
+for id in shader_ids:
+print('Fetching shader: {}'.format(id))
+print('url: {}/{}{}'.format(url, id, key))
+r = requests.get(url + '/' + id + key)
+j = r.json()
+s = j['Shader']
+info = s['info']
+print('Name: ' + info['name'])
+print('Description: ' + info['description'])
+if not os.path.exists('shaders/shadertoy'):
+os.makedirs('shaders/shadertoy')
+for i, p in enumerate(s['renderpass']):
+#print('Inputs: {}'.format(p['inputs']))
+#print('Outputs: {}'.format(p['outputs']))
+with open('shaders/shadertoy/{}_{}.shader_test'.format(id, i), 'w') as
fobj:
+fobj.write(header)
+fobj.write(p['code'])
+fobj.write(footer)
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] xa: don't leak fences
well, freedreno and vmware ddx still use XA.. they both could probably
be ported to use glamor instead, but that hasn't been done yet..
At least for freedreno with upstream drm/kms driver, one can just use
-modesetting ddx instead. But that doesn't work w/ android fbdev
driver. I need to check again w/ a more recent -modesetting+glamor,
but when I tried it a few months ago, there were some cases of
rendering corruption (but I didn't have time to debug and see whether
that was a freedreno issue or a glamor issue).
I wouldn't recommend new users of XA at this point, but I don't think
we are quite at the point where we can remove it.
BR,
-R
On Fri, Jul 10, 2015 at 7:12 AM, Marek Olšák wrote:
> I wonder... do we still need XA considering that everybody can just
> use glamor instead?
>
> Marek
>
>
> On Wed, Jul 8, 2015 at 7:39 PM, Rob Clark wrote:
>> From: Rob Clark
>>
>> XA was never unref'ing last_fence in the various call paths to
>> pipe->flush(). Add this to xa_context_flush() and update the other
>> open-coded calls to pipe->flush() to use xa_context_flush() instead.
>>
>> This fixes a memory leak reported with xf86-video-freedreno.
>>
>> Reported-by: Nicolas Dechesne
>> Cc: "10.5 10.6"
>> Signed-off-by: Rob Clark
>> ---
>> src/gallium/state_trackers/xa/xa_context.c | 6 +-
>> src/gallium/state_trackers/xa/xa_tracker.c | 2 +-
>> src/gallium/state_trackers/xa/xa_yuv.c | 2 +-
>> 3 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/xa/xa_context.c
>> b/src/gallium/state_trackers/xa/xa_context.c
>> index fd49c82..ebfb290 100644
>> --- a/src/gallium/state_trackers/xa/xa_context.c
>> +++ b/src/gallium/state_trackers/xa/xa_context.c
>> @@ -37,7 +37,11 @@
>> XA_EXPORT void
>> xa_context_flush(struct xa_context *ctx)
>> {
>> - ctx->pipe->flush(ctx->pipe, &ctx->last_fence, 0);
>> +if (ctx->last_fence) {
>> +struct pipe_screen *screen = ctx->xa->screen;
>> +screen->fence_reference(screen, &ctx->last_fence, NULL);
>> +}
>> +ctx->pipe->flush(ctx->pipe, &ctx->last_fence, 0);
>> }
>>
>> XA_EXPORT struct xa_context *
>> diff --git a/src/gallium/state_trackers/xa/xa_tracker.c
>> b/src/gallium/state_trackers/xa/xa_tracker.c
>> index a384c1c..1df1da7 100644
>> --- a/src/gallium/state_trackers/xa/xa_tracker.c
>> +++ b/src/gallium/state_trackers/xa/xa_tracker.c
>> @@ -464,7 +464,7 @@ xa_surface_redefine(struct xa_surface *srf,
>> xa_min(save_height, template->height0), &src_box);
>> pipe->resource_copy_region(pipe, texture,
>>0, 0, 0, 0, srf->tex, 0, &src_box);
>> - pipe->flush(pipe, &xa->default_ctx->last_fence, 0);
>> + xa_context_flush(xa->default_ctx);
>> }
>>
>> pipe_resource_reference(&srf->tex, texture);
>> diff --git a/src/gallium/state_trackers/xa/xa_yuv.c
>> b/src/gallium/state_trackers/xa/xa_yuv.c
>> index 1519639..97a1833 100644
>> --- a/src/gallium/state_trackers/xa/xa_yuv.c
>> +++ b/src/gallium/state_trackers/xa/xa_yuv.c
>> @@ -154,7 +154,7 @@ xa_yuv_planar_blit(struct xa_context *r,
>> box++;
>> }
>>
>> -r->pipe->flush(r->pipe, &r->last_fence, 0);
>> +xa_context_flush(r);
>>
>> xa_ctx_sampler_views_destroy(r);
>> xa_ctx_srf_destroy(r);
>> --
>> 2.4.3
>>
>> ___
>> 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] xa: don't leak fences
On Fri, Jul 10, 2015 at 6:20 PM, Eric Anholt wrote: > Rob Clark writes: > >> well, freedreno and vmware ddx still use XA.. they both could probably >> be ported to use glamor instead, but that hasn't been done yet.. >> >> At least for freedreno with upstream drm/kms driver, one can just use >> -modesetting ddx instead. But that doesn't work w/ android fbdev >> driver. I need to check again w/ a more recent -modesetting+glamor, >> but when I tried it a few months ago, there were some cases of >> rendering corruption (but I didn't have time to debug and see whether >> that was a freedreno issue or a glamor issue). > > I'm confused what "that doesn't work w/ android fbdev driver" means. > Why would you be using an fbdev driver with X? Also, are you doing X on > Android? huge hacks to kinda/sorta work on top of android fbdev + downstream gpu driver, so people have some approximate chance of getting freedreno/x11 working on $random_android_device.. see: https://github.com/freedreno/freedreno/wiki/Architecture mostly it is to try to (best-effort) support devices with dsi panels, since it was only recently that upstream drm/kms driver grew decent dsi support. I'm planning to write panel drivers for a handful of devices, to give reasonable example for anyone with $random_android_device to start with, so between that and the fact that fbdev support barely works (due to differences between different devices) I'll probably torpedo the fbdev support eventually.. BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] xa: add xa_surface_from_handle2
From: Rob Clark
Like xa_surface_from_handle(), but takes a handle type, rather than
hard-coding 'shared' handle. This is needed to fix bugs seen with
xf86-video-freedreno with xrandr rotation, for example. The root issue
is that doing a GEM_OPEN ioctl on a bo that already has a GEM handle
associated with the drm_file will result in two unique handles for the
same bo. Which causes all sorts of follow-on fail.
Cc: "10.5 10.6"
Signed-off-by: Rob Clark
---
Note: it would be good to get this in stable too, since I have a patch
for xf86-video-freedreno which will depend on this.
src/gallium/state_trackers/xa/xa_tracker.c | 40 +++---
src/gallium/state_trackers/xa/xa_tracker.h | 8 ++
src/gallium/targets/xa/xa.sym | 1 +
3 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_tracker.c
b/src/gallium/state_trackers/xa/xa_tracker.c
index 59e8108..d1d3951 100644
--- a/src/gallium/state_trackers/xa/xa_tracker.c
+++ b/src/gallium/state_trackers/xa/xa_tracker.c
@@ -298,6 +298,18 @@ xa_format_check_supported(struct xa_tracker *xa,
return XA_ERR_NONE;
}
+static unsigned
+handle_type(enum xa_handle_type type)
+{
+switch (type) {
+case xa_handle_type_kms:
+ return DRM_API_HANDLE_TYPE_KMS;
+case xa_handle_type_shared:
+default:
+ return DRM_API_HANDLE_TYPE_SHARED;
+}
+}
+
static struct xa_surface *
surface_create(struct xa_tracker *xa,
int width,
@@ -388,6 +400,24 @@ xa_surface_from_handle(struct xa_tracker *xa,
return surface_create(xa, width, height, depth, stype, xa_format, flags,
&whandle);
}
+XA_EXPORT struct xa_surface *
+xa_surface_from_handle2(struct xa_tracker *xa,
+ int width,
+ int height,
+ int depth,
+ enum xa_surface_type stype,
+ enum xa_formats xa_format, unsigned int flags,
+ enum xa_handle_type type,
+ uint32_t handle, uint32_t stride)
+{
+struct winsys_handle whandle;
+memset(&whandle, 0, sizeof(whandle));
+whandle.type = handle_type(type);
+whandle.handle = handle;
+whandle.stride = stride;
+return surface_create(xa, width, height, depth, stype, xa_format, flags,
&whandle);
+}
+
XA_EXPORT int
xa_surface_redefine(struct xa_surface *srf,
int width,
@@ -511,15 +541,7 @@ xa_surface_handle(struct xa_surface *srf,
boolean res;
memset(&whandle, 0, sizeof(whandle));
-switch (type) {
-case xa_handle_type_kms:
- whandle.type = DRM_API_HANDLE_TYPE_KMS;
- break;
-case xa_handle_type_shared:
-default:
- whandle.type = DRM_API_HANDLE_TYPE_SHARED;
- break;
-}
+whandle.type = handle_type(type);
res = screen->resource_get_handle(screen, srf->tex, &whandle);
if (!res)
return -XA_ERR_INVAL;
diff --git a/src/gallium/state_trackers/xa/xa_tracker.h
b/src/gallium/state_trackers/xa/xa_tracker.h
index 5c6435e..8afebb6 100644
--- a/src/gallium/state_trackers/xa/xa_tracker.h
+++ b/src/gallium/state_trackers/xa/xa_tracker.h
@@ -177,6 +177,14 @@ extern struct xa_surface * xa_surface_from_handle(struct
xa_tracker *xa,
enum xa_formats pform,
unsigned int flags,
uint32_t handle, uint32_t stride);
+extern struct xa_surface * xa_surface_from_handle2(struct xa_tracker *xa,
+ int width,
+ int height,
+ int depth,
+ enum xa_surface_type stype,
+ enum xa_formats xa_format, unsigned
int flags,
+ enum xa_handle_type type,
+ uint32_t handle, uint32_t stride);
enum xa_formats xa_surface_format(const struct xa_surface *srf);
diff --git a/src/gallium/targets/xa/xa.sym b/src/gallium/targets/xa/xa.sym
index 9c7f422..50ccc99 100644
--- a/src/gallium/targets/xa/xa.sym
+++ b/src/gallium/targets/xa/xa.sym
@@ -23,6 +23,7 @@
xa_surface_dma;
xa_surface_format;
xa_surface_from_handle;
+ xa_surface_from_handle2;
xa_surface_handle;
xa_surface_map;
xa_surface_redefine;
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util
On Mon, Oct 12, 2015 at 12:47 AM, Jason Ekstrand wrote:
>> > +/**
>> > + * Convert a 2-byte half float to a 4-byte float.
>> > + * Based on code from:
>> > + * http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008786.html
>> > + */
>> > +static inline float
>> > +_mesa_half_to_float(GLhalfARB val)
>> > +{
>> > + return half_to_float(val);
>> > +}
>
> This is kind of ugly. How hard would it really be to just replace the uses
> with the new name? I don't think its used *that* often.
hmm, ~20-30 call sites.. not impossible to update them all, but I
think it should be a separate patch and then drop the compat shims
rather than one big patch that changes everything..
We could also keep the _mesa_half_to_float() name.. but I really
wanted to drop the GLhalfARB and not drag along GL typedefs. If no
one objects to just replacing GLhalfARB with uint16_t.
I could go either way.
>> > +
>> > +#include
>> > +
>> > +#ifdef __cplusplus
>> > +extern "C" {
>> > +#endif
>> > +
>> > +uint16_t float_to_half(float val);
>> > +float half_to_float(uint16_t val);
>>
>> I think these functions need to be prefixed with something -- util_*
>> or something or just leave them as _mesa_*.
>
> Unfortunately, until is kind of a grab-bag right now. Some stuff has a
> util_ prefix, some has kept its _mesa_ or u_ prefix depending on whether it
> was copied from Mesa or gallium, and some (hash_table for example) isn't
> prefixed at all. Personally, I'd go with either util_ (it is a utility
> library) or just keep _mesa_ (this is still the mesa project after all). I'm
> not going to be too insistent though
the util_ prefix conflicts w/ u_half.h (which appears to implement
basically the same thing in a simpler way, but maybe not compatible
enough to just switch to the gallium implementation? Otherwise the
easier approach would be to just move the gallium implementation to
global util directory and use that instead).. I was going to use
convert_ prefix but that also conflicts..
BR,
-R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util
On Mon, Oct 12, 2015 at 2:22 PM, Matt Turner wrote:
> On Mon, Oct 12, 2015 at 11:12 AM, Rob Clark wrote:
>> On Mon, Oct 12, 2015 at 12:47 AM, Jason Ekstrand
>> wrote:
>>>> > +/**
>>>> > + * Convert a 2-byte half float to a 4-byte float.
>>>> > + * Based on code from:
>>>> > + * http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008786.html
>>>> > + */
>>>> > +static inline float
>>>> > +_mesa_half_to_float(GLhalfARB val)
>>>> > +{
>>>> > + return half_to_float(val);
>>>> > +}
>>>
>>> This is kind of ugly. How hard would it really be to just replace the uses
>>> with the new name? I don't think its used *that* often.
>>
>> hmm, ~20-30 call sites.. not impossible to update them all, but I
>> think it should be a separate patch and then drop the compat shims
>> rather than one big patch that changes everything..
>>
>> We could also keep the _mesa_half_to_float() name.. but I really
>> wanted to drop the GLhalfARB and not drag along GL typedefs. If no
>> one objects to just replacing GLhalfARB with uint16_t.
>>
>> I could go either way.
>
> Replacing GLhalfARB with uint16_t seems like a good plan.
ok, then the most straightforward (least churn) approach seems to be
to keep the _mesa_ prefix but use uint16_t..
>>>> > +
>>>> > +#include
>>>> > +
>>>> > +#ifdef __cplusplus
>>>> > +extern "C" {
>>>> > +#endif
>>>> > +
>>>> > +uint16_t float_to_half(float val);
>>>> > +float half_to_float(uint16_t val);
>>>>
>>>> I think these functions need to be prefixed with something -- util_*
>>>> or something or just leave them as _mesa_*.
>>>
>>> Unfortunately, until is kind of a grab-bag right now. Some stuff has a
>>> util_ prefix, some has kept its _mesa_ or u_ prefix depending on whether it
>>> was copied from Mesa or gallium, and some (hash_table for example) isn't
>>> prefixed at all. Personally, I'd go with either util_ (it is a utility
>>> library) or just keep _mesa_ (this is still the mesa project after all). I'm
>>> not going to be too insistent though
>>
>> the util_ prefix conflicts w/ u_half.h (which appears to implement
>> basically the same thing in a simpler way, but maybe not compatible
>> enough to just switch to the gallium implementation? Otherwise the
>> easier approach would be to just move the gallium implementation to
>> global util directory and use that instead).. I was going to use
>> convert_ prefix but that also conflicts..
>
> Seems valuable to ultimately remove the Gallium implementation as
> well. Chad did some really tedious work to improve the functions
> you're moving to round properly.
hmm, looks like his change was mostly important for compiler (to match
what intel hw does).. otoh I guess it shouldn't hurt for gallum (which
looks to be used mostly for texture/format conversion) and would be
nice to de-duplicate..
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/6] glsl: move builtin types to glsl_types.cpp
On Mon, Oct 12, 2015 at 12:50 AM, Jason Ekstrand wrote:
> Can we tweak the commit message a bit:
>
> glsl: move builtin vector types to glsl_types.cpp
>
> builtin_types.CPP contains a lot more than just vec4_type and friends and
> you're not moving all of them.
ok, updated the commit msg[1] (but I assume no point to resend to list
just for that)
[1] https://github.com/freedreno/mesa/commits/wip-nir-no-glsl
BR,
-R
> On Oct 10, 2015 11:48 AM, "Rob Clark" wrote:
>>
>> From: Rob Clark
>>
>> First step at untangling NIR's dependency on glsl_types without bringing
>> in the dependency on glsl_symbol_table. The builtin types are now in
>> glsl_types (which will end up in NIR), but adding them to the symbol-
>> table stays in builtin_types.cpp (which will not be part of NIR).
>>
>> Signed-off-by: Rob Clark
>> ---
>> src/glsl/builtin_types.cpp | 4 +---
>> src/glsl/glsl_types.cpp| 14 ++
>> 2 files changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/glsl/builtin_types.cpp b/src/glsl/builtin_types.cpp
>> index 0aedbb3..bbdcd19 100644
>> --- a/src/glsl/builtin_types.cpp
>> +++ b/src/glsl/builtin_types.cpp
>> @@ -43,9 +43,7 @@
>> * convenience pointers (glsl_type::foo_type).
>> * @{
>> */
>> -#define DECL_TYPE(NAME, ...)\
>> - const glsl_type glsl_type::_##NAME##_type = glsl_type(__VA_ARGS__,
>> #NAME); \
>> - const glsl_type *const glsl_type::NAME##_type =
>> &glsl_type::_##NAME##_type;
>> +#define DECL_TYPE(NAME, ...)
>>
>> #define STRUCT_TYPE(NAME) \
>> const glsl_type glsl_type::_struct_##NAME##_type = \
>> diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
>> index b9cb97c..b0bb2ff 100644
>> --- a/src/glsl/glsl_types.cpp
>> +++ b/src/glsl/glsl_types.cpp
>> @@ -1713,3 +1713,17 @@ glsl_type::coordinate_components() const
>>
>> return size;
>> }
>> +
>> +/**
>> + * Declarations of type flyweights (glsl_type::_foo_type) and
>> + * convenience pointers (glsl_type::foo_type).
>> + * @{
>> + */
>> +#define DECL_TYPE(NAME, ...)\
>> + const glsl_type glsl_type::_##NAME##_type = glsl_type(__VA_ARGS__,
>> #NAME); \
>> + const glsl_type *const glsl_type::NAME##_type =
>> &glsl_type::_##NAME##_type;
>> +
>> +#define STRUCT_TYPE(NAME)
>> +
>> +#include "builtin_type_macros.h"
>> +/** @} */
>> --
>> 2.4.3
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: move half<->float convertion to util
From: Rob Clark
Needed in NIR too, so move out of mesa/main/imports.c
Signed-off-by: Rob Clark
---
src/glsl/Makefile.am | 1 +
src/glsl/ir_constant_expression.cpp | 1 +
src/glsl/nir/nir_constant_expressions.py | 1 +
src/mesa/drivers/dri/i965/brw_sampler_state.c | 1 +
src/mesa/main/format_utils.h | 1 +
src/mesa/main/imports.c | 148 -
src/mesa/main/imports.h | 7 -
src/mesa/main/mipmap.c| 1 +
src/mesa/main/texcompress_bptc.c | 1 +
src/mesa/tnl/t_draw.c | 1 +
src/util/Makefile.sources | 2 +
src/util/half_float.c | 177 ++
src/util/half_float.h | 41 ++
13 files changed, 228 insertions(+), 155 deletions(-)
create mode 100644 src/util/half_float.c
create mode 100644 src/util/half_float.h
diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
index 3265391..347919b 100644
--- a/src/glsl/Makefile.am
+++ b/src/glsl/Makefile.am
@@ -160,6 +160,7 @@ glsl_compiler_SOURCES = \
glsl_compiler_LDADD = \
libglsl.la \
$(top_builddir)/src/libglsl_util.la \
+ $(top_builddir)/src/util/libmesautil.la \
$(PTHREAD_LIBS)
glsl_test_SOURCES = \
diff --git a/src/glsl/ir_constant_expression.cpp
b/src/glsl/ir_constant_expression.cpp
index 309b6b7..67ed360 100644
--- a/src/glsl/ir_constant_expression.cpp
+++ b/src/glsl/ir_constant_expression.cpp
@@ -36,6 +36,7 @@
#include
#include "main/core.h" /* for MAX2, MIN2, CLAMP */
#include "util/rounding.h" /* for _mesa_roundeven */
+#include "util/half_float.h"
#include "ir.h"
#include "glsl_types.h"
#include "program/hash_table.h"
diff --git a/src/glsl/nir/nir_constant_expressions.py
b/src/glsl/nir/nir_constant_expressions.py
index 8fd9b10..2ba8554 100644
--- a/src/glsl/nir/nir_constant_expressions.py
+++ b/src/glsl/nir/nir_constant_expressions.py
@@ -29,6 +29,7 @@ template = """\
#include
#include "main/core.h"
#include "util/rounding.h" /* for _mesa_roundeven */
+#include "util/half_float.h"
#include "nir_constant_expressions.h"
#if defined(__SUNPRO_CC)
diff --git a/src/mesa/drivers/dri/i965/brw_sampler_state.c
b/src/mesa/drivers/dri/i965/brw_sampler_state.c
index c2db5f6..6d73444 100644
--- a/src/mesa/drivers/dri/i965/brw_sampler_state.c
+++ b/src/mesa/drivers/dri/i965/brw_sampler_state.c
@@ -44,6 +44,7 @@
#include "main/macros.h"
#include "main/samplerobj.h"
+#include "util/half_float.h"
/**
* Emit a 3DSTATE_SAMPLER_STATE_POINTERS_{VS,HS,GS,DS,PS} packet.
diff --git a/src/mesa/main/format_utils.h b/src/mesa/main/format_utils.h
index 618f43d..378997b 100644
--- a/src/mesa/main/format_utils.h
+++ b/src/mesa/main/format_utils.h
@@ -34,6 +34,7 @@
#include "imports.h"
#include "macros.h"
#include "util/rounding.h"
+#include "util/half_float.h"
extern const mesa_array_format RGBA32_FLOAT;
extern const mesa_array_format RGBA8_UBYTE;
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 350e675..230ebbc 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -307,154 +307,6 @@ _mesa_bitcount_64(uint64_t n)
}
#endif
-
-/**
- * Convert a 4-byte float to a 2-byte half float.
- *
- * Not all float32 values can be represented exactly as a float16 value. We
- * round such intermediate float32 values to the nearest float16. When the
- * float32 lies exactly between to float16 values, we round to the one with
- * an even mantissa.
- *
- * This rounding behavior has several benefits:
- * - It has no sign bias.
- *
- * - It reproduces the behavior of real hardware: opcode F32TO16 in Intel's
- * GPU ISA.
- *
- * - By reproducing the behavior of the GPU (at least on Intel hardware),
- * compile-time evaluation of constant packHalf2x16 GLSL expressions will
- * result in the same value as if the expression were executed on the GPU.
- */
-GLhalfARB
-_mesa_float_to_half(float val)
-{
- const fi_type fi = {val};
- const int flt_m = fi.i & 0x7f;
- const int flt_e = (fi.i >> 23) & 0xff;
- const int flt_s = (fi.i >> 31) & 0x1;
- int s, e, m = 0;
- GLhalfARB result;
-
- /* sign bit */
- s = flt_s;
-
- /* handle special cases */
- if ((flt_e == 0) && (flt_m == 0)) {
- /* zero */
- /* m = 0; - already set */
- e = 0;
- }
- else if ((flt_e == 0) && (flt_m != 0)) {
- /* denorm -- denorm float maps to 0 half */
- /* m = 0; - already set */
- e = 0;
- }
- else if ((flt_e == 0xff) && (flt_m == 0)) {
-
Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util
On Mon, Oct 12, 2015 at 3:41 PM, Roland Scheidegger wrote:
> Am 12.10.2015 um 20:33 schrieb Rob Clark:
>> On Mon, Oct 12, 2015 at 2:22 PM, Matt Turner wrote:
>>> On Mon, Oct 12, 2015 at 11:12 AM, Rob Clark wrote:
>>>> On Mon, Oct 12, 2015 at 12:47 AM, Jason Ekstrand
>>>> wrote:
>>>>>>> +/**
>>>>>>> + * Convert a 2-byte half float to a 4-byte float.
>>>>>>> + * Based on code from:
>>>>>>> + * http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008786.html
>>>>>>> + */
>>>>>>> +static inline float
>>>>>>> +_mesa_half_to_float(GLhalfARB val)
>>>>>>> +{
>>>>>>> + return half_to_float(val);
>>>>>>> +}
>>>>>
>>>>> This is kind of ugly. How hard would it really be to just replace the uses
>>>>> with the new name? I don't think its used *that* often.
>>>>
>>>> hmm, ~20-30 call sites.. not impossible to update them all, but I
>>>> think it should be a separate patch and then drop the compat shims
>>>> rather than one big patch that changes everything..
>>>>
>>>> We could also keep the _mesa_half_to_float() name.. but I really
>>>> wanted to drop the GLhalfARB and not drag along GL typedefs. If no
>>>> one objects to just replacing GLhalfARB with uint16_t.
>>>>
>>>> I could go either way.
>>>
>>> Replacing GLhalfARB with uint16_t seems like a good plan.
>>
>> ok, then the most straightforward (least churn) approach seems to be
>> to keep the _mesa_ prefix but use uint16_t..
>>
>>>>>>> +
>>>>>>> +#include
>>>>>>> +
>>>>>>> +#ifdef __cplusplus
>>>>>>> +extern "C" {
>>>>>>> +#endif
>>>>>>> +
>>>>>>> +uint16_t float_to_half(float val);
>>>>>>> +float half_to_float(uint16_t val);
>>>>>>
>>>>>> I think these functions need to be prefixed with something -- util_*
>>>>>> or something or just leave them as _mesa_*.
>>>>>
>>>>> Unfortunately, until is kind of a grab-bag right now. Some stuff has a
>>>>> util_ prefix, some has kept its _mesa_ or u_ prefix depending on whether
>>>>> it
>>>>> was copied from Mesa or gallium, and some (hash_table for example) isn't
>>>>> prefixed at all. Personally, I'd go with either util_ (it is a utility
>>>>> library) or just keep _mesa_ (this is still the mesa project after all).
>>>>> I'm
>>>>> not going to be too insistent though
>>>>
>>>> the util_ prefix conflicts w/ u_half.h (which appears to implement
>>>> basically the same thing in a simpler way, but maybe not compatible
>>>> enough to just switch to the gallium implementation? Otherwise the
>>>> easier approach would be to just move the gallium implementation to
>>>> global util directory and use that instead).. I was going to use
>>>> convert_ prefix but that also conflicts..
>>>
>>> Seems valuable to ultimately remove the Gallium implementation as
>>> well. Chad did some really tedious work to improve the functions
>>> you're moving to round properly.
>>
>> hmm, looks like his change was mostly important for compiler (to match
>> what intel hw does).. otoh I guess it shouldn't hurt for gallum (which
>> looks to be used mostly for texture/format conversion) and would be
>> nice to de-duplicate..
>
> I'd be in favor of dropping this implementation over the gallium one,
> but not vice versa. I've expressed my concerns over this implementation
> before (it also looks more expensive), mainly rounding up float values
> to infinity half floats seems like a bad idea. The gallium
> implementation has a comment why I think is a bug, mostly because d3d10
> mandates such value getting rounded to MAX_HALF_FLOAT instead, gl not
> caring about it but at least recommending the same for converting to
> fp11 floats. I doubt hw in general rounds such values to infinity (due
> to the afromentioned d3d10 requirement, which is actually tested for).
well, I'll leave the gallium version as-is then.. I guess I can
understand where (for the using in compiler const propagation) there
is a desire to match what intel hw does (but otoh not really sure if
it matches what other hw does and if gl doesn't really care, not sure
how much that really matters). But at least for now to clean up the
NIR dependency on GLSL I guess we should keep the current _mesa
version..
BR,
-R
> Roland
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util
On Mon, Oct 12, 2015 at 6:07 PM, Roland Scheidegger wrote:
> Am 12.10.2015 um 22:37 schrieb Rob Clark:
>> On Mon, Oct 12, 2015 at 3:41 PM, Roland Scheidegger
>> wrote:
>>> Am 12.10.2015 um 20:33 schrieb Rob Clark:
>>>> On Mon, Oct 12, 2015 at 2:22 PM, Matt Turner wrote:
>>>>> On Mon, Oct 12, 2015 at 11:12 AM, Rob Clark wrote:
>>>>>> On Mon, Oct 12, 2015 at 12:47 AM, Jason Ekstrand
>>>>>> wrote:
>>>>>>>>> +/**
>>>>>>>>> + * Convert a 2-byte half float to a 4-byte float.
>>>>>>>>> + * Based on code from:
>>>>>>>>> + *
>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.opengl.org_discussion-5Fboards_ubb_Forum3_HTML_008786.html&d=BQIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=2SV7p2GaUU6_-p4UXWRZ9hppJQ1vlbvvFipu3TmlI7s&s=B2vMgNT8F0lMSh_aJLIvB2ErGZNaLSKmlOgEdZq7z9Y&e=
>>>>>>>>> + */
>>>>>>>>> +static inline float
>>>>>>>>> +_mesa_half_to_float(GLhalfARB val)
>>>>>>>>> +{
>>>>>>>>> + return half_to_float(val);
>>>>>>>>> +}
>>>>>>>
>>>>>>> This is kind of ugly. How hard would it really be to just replace the
>>>>>>> uses
>>>>>>> with the new name? I don't think its used *that* often.
>>>>>>
>>>>>> hmm, ~20-30 call sites.. not impossible to update them all, but I
>>>>>> think it should be a separate patch and then drop the compat shims
>>>>>> rather than one big patch that changes everything..
>>>>>>
>>>>>> We could also keep the _mesa_half_to_float() name.. but I really
>>>>>> wanted to drop the GLhalfARB and not drag along GL typedefs. If no
>>>>>> one objects to just replacing GLhalfARB with uint16_t.
>>>>>>
>>>>>> I could go either way.
>>>>>
>>>>> Replacing GLhalfARB with uint16_t seems like a good plan.
>>>>
>>>> ok, then the most straightforward (least churn) approach seems to be
>>>> to keep the _mesa_ prefix but use uint16_t..
>>>>
>>>>>>>>> +
>>>>>>>>> +#include
>>>>>>>>> +
>>>>>>>>> +#ifdef __cplusplus
>>>>>>>>> +extern "C" {
>>>>>>>>> +#endif
>>>>>>>>> +
>>>>>>>>> +uint16_t float_to_half(float val);
>>>>>>>>> +float half_to_float(uint16_t val);
>>>>>>>>
>>>>>>>> I think these functions need to be prefixed with something -- util_*
>>>>>>>> or something or just leave them as _mesa_*.
>>>>>>>
>>>>>>> Unfortunately, until is kind of a grab-bag right now. Some stuff has a
>>>>>>> util_ prefix, some has kept its _mesa_ or u_ prefix depending on
>>>>>>> whether it
>>>>>>> was copied from Mesa or gallium, and some (hash_table for example) isn't
>>>>>>> prefixed at all. Personally, I'd go with either util_ (it is a utility
>>>>>>> library) or just keep _mesa_ (this is still the mesa project after
>>>>>>> all). I'm
>>>>>>> not going to be too insistent though
>>>>>>
>>>>>> the util_ prefix conflicts w/ u_half.h (which appears to implement
>>>>>> basically the same thing in a simpler way, but maybe not compatible
>>>>>> enough to just switch to the gallium implementation? Otherwise the
>>>>>> easier approach would be to just move the gallium implementation to
>>>>>> global util directory and use that instead).. I was going to use
>>>>>> convert_ prefix but that also conflicts..
>>>>>
>>>>> Seems valuable to ultimately remove the Gallium implementation as
>>>>> well. Chad did some really tedious work to improve the functions
>>>>> you're moving to round properly.
>>>>
>>>> hmm, looks like his change was mostly important for compiler (to match
>>>> what intel hw does).. otoh I guess it shouldn't hurt for gallum (which
>>>> looks
Re: [Mesa-dev] [PATCH 03/17] mesa: Move gl_frag_depth_layout from mtypes.h to shader_enums.h
and bonus points for adding a gl_frag_depth_layout_name() ;-)
On Fri, Oct 9, 2015 at 5:04 AM, Michael Schellenberger Costa
wrote:
> Hi,
>
> as this conflicts directly with Robs patch
> http://lists.freedesktop.org/archives/mesa-dev/2015-October/096670.html
> you might want to update it
>
> Michael
>
> Am 09.10.2015 um 02:22 schrieb Jason Ekstrand:
>> --- src/glsl/shader_enums.h | 17 +
>> src/mesa/main/mtypes.h | 18 -- 2 files changed, 17
>> insertions(+), 18 deletions(-)
>>
>> diff --git a/src/glsl/shader_enums.h b/src/glsl/shader_enums.h
>> index 2a5d2c5..1c2f5dc 100644 --- a/src/glsl/shader_enums.h +++
>> b/src/glsl/shader_enums.h @@ -473,4 +473,21 @@ typedef enum
>>
>> const char * gl_frag_result_name(gl_frag_result result);
>>
>> +/** + * \brief Layout qualifiers for gl_FragDepth. + * + *
>> Extension AMD_conservative_depth allows gl_FragDepth to be
>> redeclared with + * a layout qualifier. + * + * \see enum
>> ir_depth_layout + */ +enum gl_frag_depth_layout +{ +
>> FRAG_DEPTH_LAYOUT_NONE, /**< No layout is specified. */ +
>> FRAG_DEPTH_LAYOUT_ANY, + FRAG_DEPTH_LAYOUT_GREATER, +
>> FRAG_DEPTH_LAYOUT_LESS, + FRAG_DEPTH_LAYOUT_UNCHANGED +}; +
>> #endif /* SHADER_ENUMS_H */ diff --git a/src/mesa/main/mtypes.h
>> b/src/mesa/main/mtypes.h index 288d757..6a2f323 100644 ---
>> a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -1866,24
>> +1866,6 @@ typedef enum
>>
>>
>> /** - * \brief Layout qualifiers for gl_FragDepth. - * - *
>> Extension AMD_conservative_depth allows gl_FragDepth to be
>> redeclared with - * a layout qualifier. - * - * \see enum
>> ir_depth_layout - */ -enum gl_frag_depth_layout -{ -
>> FRAG_DEPTH_LAYOUT_NONE, /**< No layout is specified. */ -
>> FRAG_DEPTH_LAYOUT_ANY, - FRAG_DEPTH_LAYOUT_GREATER, -
>> FRAG_DEPTH_LAYOUT_LESS, - FRAG_DEPTH_LAYOUT_UNCHANGED -}; - -
>> -/** * Base class for any kind of program object */ struct
>> gl_program
>>
>
> ___
> 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 5/6] nir: remove dependency on glsl
On Tue, Oct 13, 2015 at 11:22 AM, Emil Velikov wrote: > Hi Rob, > > On 10 October 2015 at 19:47, Rob Clark wrote: >> From: Rob Clark >> >> Move glsl_types into NIR, now that the dependency on glsl_symbol_table >> has been split out. >> >> Possibly makes sense to rename things at this point, but if we do that >> I'd like to keep it split out into a separate patch to make git history >> easier to follow (IMHO). >> >> Signed-off-by: Rob Clark >> --- >> src/glsl/Makefile.am |3 - >> src/glsl/Makefile.sources |4 +- >> src/glsl/builtin_type_macros.h | 172 -- >> src/glsl/glsl_types.cpp| 1729 >> >> src/glsl/glsl_types.h | 867 -- >> src/glsl/nir/builtin_type_macros.h | 172 ++ >> src/glsl/nir/glsl_types.cpp| 1729 >> >> src/glsl/nir/glsl_types.h | 867 ++ >> src/glsl/nir/nir_types.h |2 +- >> .../drivers/dri/i965/brw_cubemap_normalize.cpp |2 +- >> src/mesa/drivers/dri/i965/brw_fs.cpp |2 +- >> src/mesa/drivers/dri/i965/brw_fs.h |2 +- >> .../dri/i965/brw_fs_channel_expressions.cpp|2 +- >> src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp |2 +- >> .../drivers/dri/i965/brw_fs_vector_splitting.cpp |2 +- >> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |2 +- >> .../dri/i965/brw_lower_unnormalized_offset.cpp |2 +- >> .../drivers/dri/i965/brw_schedule_instructions.cpp |2 +- >> src/mesa/main/ff_fragment_shader.cpp |2 +- >> src/mesa/main/uniforms.h |2 +- >> src/mesa/program/ir_to_mesa.cpp|2 +- >> src/mesa/program/sampler.cpp |2 +- >> 22 files changed, 2784 insertions(+), 2787 deletions(-) >> delete mode 100644 src/glsl/builtin_type_macros.h >> delete mode 100644 src/glsl/glsl_types.cpp >> delete mode 100644 src/glsl/glsl_types.h >> create mode 100644 src/glsl/nir/builtin_type_macros.h >> create mode 100644 src/glsl/nir/glsl_types.cpp >> create mode 100644 src/glsl/nir/glsl_types.h >> >> diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am >> index 347919b..437c6a5 100644 >> --- a/src/glsl/Makefile.am >> +++ b/src/glsl/Makefile.am >> @@ -148,9 +148,6 @@ libglsl_la_SOURCES = >>\ >> >> >> libnir_la_SOURCES =\ >> - glsl_types.cpp \ >> - builtin_types.cpp \ >> - glsl_symbol_table.cpp \ >> $(NIR_FILES)\ >> $(NIR_GENERATED_FILES) >> >> diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources >> index 436949c..6e61f23 100644 >> --- a/src/glsl/Makefile.sources >> +++ b/src/glsl/Makefile.sources >> @@ -20,6 +20,8 @@ NIR_GENERATED_FILES = \ >> NIR_FILES = \ >> nir/glsl_to_nir.cpp \ >> nir/glsl_to_nir.h \ >> + nir/glsl_types.cpp \ >> + nir/glsl_types.h \ >> nir/nir.c \ >> nir/nir.h \ >> nir/nir_array.h \ >> @@ -103,8 +105,6 @@ LIBGLSL_FILES = \ >> glsl_parser_extras.h \ >> glsl_symbol_table.cpp \ >> glsl_symbol_table.h \ >> - glsl_types.cpp \ >> - glsl_types.h \ >> hir_field_selection.cpp \ >> ir_basic_block.cpp \ >> ir_basic_block.h \ > Can we split this into two (or more) patches. > - move the files from glsl to glsl/nir, updating scons/android. note > scons is missing everything NIR related. > - fold/nuke the additional glsl requirements, from NIR. It is already split up this way.. this patch is primarily the move (plus header path tweaks, etc, to keep things compiling). I don't see how it could be split up any finer while keeping bisectability (ie. not breaking compile in the middle). That said, I did completely ignore scons/android. I don't know the first thing about scons or how to do a scons build, so I think I'll ignore that and let someone else fix it up. I suppose I could fix android build, although I can't build android on my laptop (and I guess I'd have to rebase some of the other android related stuff that isn't upstream yet), so maybe I'll just fix that in a follow-on patch this weekend. BR, -R > From autotools side alone the patch looks great. > > Thank you > Emil > > P.S. Please use -M for git to detect code movement when generating the patch. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/util: fix debug_get_flags_option on 32-bit harder
From: Rob Clark
I noticed the FD_MESA_DEBUG=help numeric flags output was looking kinda
funny.
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/util/u_debug.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_debug.c
b/src/gallium/auxiliary/util/u_debug.c
index 5fe9e33..7388a49 100644
--- a/src/gallium/auxiliary/util/u_debug.c
+++ b/src/gallium/auxiliary/util/u_debug.c
@@ -276,7 +276,7 @@ debug_get_flags_option(const char *name,
for (; flags->name; ++flags)
namealign = MAX2(namealign, strlen(flags->name));
for (flags = orig; flags->name; ++flags)
- _debug_printf("| %*s [0x%0*"PRIu64"]%s%s\n", namealign, flags->name,
+ _debug_printf("| %*s [0x%0*"PRIx64"]%s%s\n", namealign, flags->name,
(int)sizeof(uint64_t)*CHAR_BIT/4, flags->value,
flags->desc ? " " : "", flags->desc ? flags->desc : "");
}
@@ -291,9 +291,9 @@ debug_get_flags_option(const char *name,
if (debug_get_option_should_print()) {
if (str) {
- debug_printf("%s: %s = 0x%"PRIu64" (%s)\n", __FUNCTION__, name,
result, str);
+ debug_printf("%s: %s = 0x%"PRIx64" (%s)\n", __FUNCTION__, name,
result, str);
} else {
- debug_printf("%s: %s = 0x%"PRIu64"\n", __FUNCTION__, name, result);
+ debug_printf("%s: %s = 0x%"PRIx64"\n", __FUNCTION__, name, result);
}
}
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] nir: remove dependency on glsl
On Tue, Oct 13, 2015 at 12:15 PM, Emil Velikov wrote: > On 13 October 2015 at 16:37, Rob Clark wrote: >> On Tue, Oct 13, 2015 at 11:22 AM, Emil Velikov >> wrote: >>> Hi Rob, >>> >>> On 10 October 2015 at 19:47, Rob Clark wrote: >>>> From: Rob Clark >>>> >>>> Move glsl_types into NIR, now that the dependency on glsl_symbol_table >>>> has been split out. >>>> >>>> Possibly makes sense to rename things at this point, but if we do that >>>> I'd like to keep it split out into a separate patch to make git history >>>> easier to follow (IMHO). >>>> >>>> Signed-off-by: Rob Clark >>>> --- >>>> src/glsl/Makefile.am |3 - >>>> src/glsl/Makefile.sources |4 +- >>>> src/glsl/builtin_type_macros.h | 172 -- >>>> src/glsl/glsl_types.cpp| 1729 >>>> >>>> src/glsl/glsl_types.h | 867 -- >>>> src/glsl/nir/builtin_type_macros.h | 172 ++ >>>> src/glsl/nir/glsl_types.cpp| 1729 >>>> >>>> src/glsl/nir/glsl_types.h | 867 ++ >>>> src/glsl/nir/nir_types.h |2 +- >>>> .../drivers/dri/i965/brw_cubemap_normalize.cpp |2 +- >>>> src/mesa/drivers/dri/i965/brw_fs.cpp |2 +- >>>> src/mesa/drivers/dri/i965/brw_fs.h |2 +- >>>> .../dri/i965/brw_fs_channel_expressions.cpp|2 +- >>>> src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp |2 +- >>>> .../drivers/dri/i965/brw_fs_vector_splitting.cpp |2 +- >>>> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |2 +- >>>> .../dri/i965/brw_lower_unnormalized_offset.cpp |2 +- >>>> .../drivers/dri/i965/brw_schedule_instructions.cpp |2 +- >>>> src/mesa/main/ff_fragment_shader.cpp |2 +- >>>> src/mesa/main/uniforms.h |2 +- >>>> src/mesa/program/ir_to_mesa.cpp|2 +- >>>> src/mesa/program/sampler.cpp |2 +- >>>> 22 files changed, 2784 insertions(+), 2787 deletions(-) >>>> delete mode 100644 src/glsl/builtin_type_macros.h >>>> delete mode 100644 src/glsl/glsl_types.cpp >>>> delete mode 100644 src/glsl/glsl_types.h >>>> create mode 100644 src/glsl/nir/builtin_type_macros.h >>>> create mode 100644 src/glsl/nir/glsl_types.cpp >>>> create mode 100644 src/glsl/nir/glsl_types.h >>>> >>>> diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am >>>> index 347919b..437c6a5 100644 >>>> --- a/src/glsl/Makefile.am >>>> +++ b/src/glsl/Makefile.am >>>> @@ -148,9 +148,6 @@ libglsl_la_SOURCES = >>>> \ >>>> >>>> >>>> libnir_la_SOURCES =\ >>>> - glsl_types.cpp \ >>>> - builtin_types.cpp \ >>>> - glsl_symbol_table.cpp \ >>>> $(NIR_FILES)\ >>>> $(NIR_GENERATED_FILES) >>>> >>>> diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources >>>> index 436949c..6e61f23 100644 >>>> --- a/src/glsl/Makefile.sources >>>> +++ b/src/glsl/Makefile.sources >>>> @@ -20,6 +20,8 @@ NIR_GENERATED_FILES = \ >>>> NIR_FILES = \ >>>> nir/glsl_to_nir.cpp \ >>>> nir/glsl_to_nir.h \ >>>> + nir/glsl_types.cpp \ >>>> + nir/glsl_types.h \ >>>> nir/nir.c \ >>>> nir/nir.h \ >>>> nir/nir_array.h \ >>>> @@ -103,8 +105,6 @@ LIBGLSL_FILES = \ >>>> glsl_parser_extras.h \ >>>> glsl_symbol_table.cpp \ >>>> glsl_symbol_table.h \ >>>> - glsl_types.cpp \ >>>> - glsl_types.h \ >>>> hir_field_selection.cpp \ >>>> ir_basic_block.cpp \ >>>> ir_basic_block.h \ >>> Can we split this into two (or more) patches. >>> - mo
Re: [Mesa-dev] [RFC 1/2] gallium: add renderonly driver
On Thu, Oct 15, 2015 at 7:09 PM, Emil Velikov wrote:
> Hi Christian,
>
> I'm glad to see Thierry's work revived. Hopefully this will soon be
> the basis of many more drivers.
>
> On 11 October 2015 at 16:09, Christian Gmeiner
> wrote:
>> This commit adds a generic renderonly driver library, which fullfille
>> the requirements for tegra and etnaviv. As a result it is possible to
>> run unmodified egl software directly (without any compositor) on
>> supported devices.
>>
>> In every use case we import a dumb buffer from scanout gpu into
>> the renderonly gpu.
>>
>> If the scanout hardware does support the used tiling format from the
>> renderonly gpu, a driver can define a function which is used to 'setup'
>> the needed tiling on that imported buffer. This functions gets called
>> during rendertarget resource creation.
>>
>> If the scanout hardware does not support the used tiling format we need
>> to create an extra rendertarget resource for the renderonly gpu.
>> During XXX we blit the renderonly rendertarget onto the imported dumb
>> buffer.
>>
> I'd assume you meant to add something over the XXX here :-P
>
> But seriously some people might not be too happy with the blit onto
> dumb buffer. Personally I ok, esp. since we don't have anything better
> atm.
imho, it is ok if driver specific (or maybe in this case we should
call it "semi driver-specific") code is blitting (or otherwise using
gpu) on dumb buffers.. the main point about dumb buffers is some
particular gpu may not support operating on dumb buffers, so truly
generic code outside of drivers should not make assumptions..
I guess this code counts as "helper" code, so some hw that could not
support dumb buffer access simply doesn't use it and implements their
own version instead..
BR,
-R
> That aside, there are a few minor nitpicks below. With those sorted I
> believe the patch is good to land.
>
>> We assume that the renderonly driver provides a blit function that is
>> capable of resolving the tilied into untiled one.
>>
>> Signed-off-by: Christian Gmeiner
>> ---
>> configure.ac | 1 +
>> src/gallium/drivers/renderonly/Makefile.am | 11 +
>> src/gallium/drivers/renderonly/Makefile.sources| 4 +
>> .../drivers/renderonly/renderonly_context.c| 721
>> +
>> .../drivers/renderonly/renderonly_context.h| 80 +++
>> .../drivers/renderonly/renderonly_resource.c | 296 +
>> .../drivers/renderonly/renderonly_resource.h | 101 +++
>> src/gallium/drivers/renderonly/renderonly_screen.c | 178 +
>> src/gallium/drivers/renderonly/renderonly_screen.h | 55 ++
>> 9 files changed, 1447 insertions(+)
>> create mode 100644 src/gallium/drivers/renderonly/Makefile.am
>> create mode 100644 src/gallium/drivers/renderonly/Makefile.sources
>> create mode 100644 src/gallium/drivers/renderonly/renderonly_context.c
>> create mode 100644 src/gallium/drivers/renderonly/renderonly_context.h
>> create mode 100644 src/gallium/drivers/renderonly/renderonly_resource.c
>> create mode 100644 src/gallium/drivers/renderonly/renderonly_resource.h
>> create mode 100644 src/gallium/drivers/renderonly/renderonly_screen.c
>> create mode 100644 src/gallium/drivers/renderonly/renderonly_screen.h
>>
>> diff --git a/configure.ac b/configure.ac
>> index 217281f..ea485b1 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -2361,6 +2361,7 @@ AC_CONFIG_FILES([Makefile
>> src/gallium/drivers/radeon/Makefile
>> src/gallium/drivers/radeonsi/Makefile
>> src/gallium/drivers/rbug/Makefile
>> + src/gallium/drivers/renderonly/Makefile
>> src/gallium/drivers/softpipe/Makefile
>> src/gallium/drivers/svga/Makefile
>> src/gallium/drivers/trace/Makefile
>
> Don't recall of the top of my head but we might need the following
> hunk. Otherwise the files won't end up in the tarball and configure
> will scream at us.
>
> --- a/src/gallium/Makefile.am
> +++ b/src/gallium/Makefile.am
> @@ -109,6 +109,7 @@ EXTRA_DIST = \
>docs \
>README.portability \
>SConscript \
> + drivers/renderonly \
>winsys/sw/gdi \
>winsys/sw/hgl
>
>> --- /dev/null
>> +++ b/src/gallium/drivers/renderonly/Makefile.sources
>> @@ -0,0 +1,4 @@
>> +C_SOURCES := \
>> + renderonly_context.c \
>> + renderonly_resource.c \
>> + renderonly_screen.c
> Please list all the sources (including the headers) in here, sorted
> alphabetically.
>
>> --- /dev/null
>> +++ b/src/gallium/drivers/renderonly/renderonly_context.c
> [snip]
>> +static void
>> +renderonly_draw_vbo(struct pipe_context *pcontext,
>> + const struct pipe_draw_info *pinfo)
>> +{
>> + struct renderonly_context *context = to_renderonly_context(pcontext);
>> + struct pipe_draw_info info;
>> +
>> + if (pinfo && pinfo->indirect) {
> Can pinfo really be null here ?
Re: [Mesa-dev] MSVC, MinGW build break
On Fri, Oct 16, 2015 at 11:11 PM, Brian Paul wrote: > Hi Rob, > > Your recent commit "nir: remove dependency on glsl" broke the build for MSVC > and MinGW. > > For MSVC: > > [...] > Linking build\windows-x86-debug\gallium\tests\graw\occlusion-query.exe ... > Linking build\windows-x86-debug\gallium\tests\graw\quad-sample.exe ... > glsl.lib(loop_controls.obj) : error LNK2001: unresolved external symbol > "public: static struct glsl_type const * const glsl_type::bool_type" > (?bool_type@glsl_type@@2QBU1@B) > glsl.lib(lower_discard_flow.obj) : error LNK2001: unresolved external symbol > "public: static struct glsl_type const * const glsl_type::bool_type" > (?bool_type@glsl_type@@2QBU1@B) > [...] > glsl.lib(builtin_functions.obj) : error LNK2001: unresolved external symbol > "public: static struct glsl_type const * const glsl_type::float_type" > (?float_type@glsl_type@@2QBU1@B) > [...] > mesa.lib(ff_fragment_shader.obj) : error LNK2001: unresolved external symbol > "public: static struct glsl_type const * const > glsl_type::sampler2DShadow_type" (?sampler2DShadow_type@glsl_type@@2QBU1@B) > [etc. for hundreds more] > > > > For MinGW: > [...] > Linking build/windows-x86-debug/gallium/tests/graw/fs-write-z.exe ... > Linking build/windows-x86-debug/gallium/targets/osmesa/osmesa.dll ... > Linking build/windows-x86-debug/gallium/targets/libgl-gdi/opengl32.dll ... > build/windows-x86-debug/mesa/libmesa.a(ir_to_mesa.o): In function > `reladdr_to_temp': > /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:793: > undefined reference to `glsl_type::vec4_type' > build/windows-x86-debug/mesa/libmesa.a(ir_to_mesa.o): In function `visit': > /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1092: > undefined reference to `glsl_type::vec4_type' > /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1115: > undefined reference to `glsl_type::vec4_type' > /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1487: > undefined reference to `glsl_type::float_type' > /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1497: > undefined reference to `glsl_type::float_type' > /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1871: > undefined reference to `glsl_type::vec4_type' > /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1883: > undefined reference to `glsl_type::vec4_type' > > > Hopefully it's something simple to fix. these types should all be coming from glsl_types.cpp which moved into NIR.. I've no idea about MSVC or MinGW builds.. (I did at least fix up the scons build, although in not a very pretty way..). I guess the best thing I could suggest is to: git show -M b9b40ef9b7644ea24768bc8b7464b1719efe99bf and make equivalent changes in whatever build files MSVC/MinGW uses?? BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] MSVC, MinGW build break
On Sat, Oct 17, 2015 at 12:07 PM, Brian Paul wrote: > On 10/17/2015 07:04 AM, Rob Clark wrote: >> >> On Fri, Oct 16, 2015 at 11:11 PM, Brian Paul wrote: >>> >>> Hi Rob, >>> >>> Your recent commit "nir: remove dependency on glsl" broke the build for >>> MSVC >>> and MinGW. >>> >>> For MSVC: >>> >>> [...] >>>Linking build\windows-x86-debug\gallium\tests\graw\occlusion-query.exe >>> ... >>>Linking build\windows-x86-debug\gallium\tests\graw\quad-sample.exe ... >>> glsl.lib(loop_controls.obj) : error LNK2001: unresolved external symbol >>> "public: static struct glsl_type const * const glsl_type::bool_type" >>> (?bool_type@glsl_type@@2QBU1@B) >>> glsl.lib(lower_discard_flow.obj) : error LNK2001: unresolved external >>> symbol >>> "public: static struct glsl_type const * const glsl_type::bool_type" >>> (?bool_type@glsl_type@@2QBU1@B) >>> [...] >>> glsl.lib(builtin_functions.obj) : error LNK2001: unresolved external >>> symbol >>> "public: static struct glsl_type const * const glsl_type::float_type" >>> (?float_type@glsl_type@@2QBU1@B) >>> [...] >>> mesa.lib(ff_fragment_shader.obj) : error LNK2001: unresolved external >>> symbol >>> "public: static struct glsl_type const * const >>> glsl_type::sampler2DShadow_type" >>> (?sampler2DShadow_type@glsl_type@@2QBU1@B) >>> [etc. for hundreds more] >>> >>> >>> >>> For MinGW: >>> [...] >>>Linking build/windows-x86-debug/gallium/tests/graw/fs-write-z.exe ... >>>Linking build/windows-x86-debug/gallium/targets/osmesa/osmesa.dll ... >>>Linking build/windows-x86-debug/gallium/targets/libgl-gdi/opengl32.dll >>> ... >>> build/windows-x86-debug/mesa/libmesa.a(ir_to_mesa.o): In function >>> `reladdr_to_temp': >>> >>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:793: >>> undefined reference to `glsl_type::vec4_type' >>> build/windows-x86-debug/mesa/libmesa.a(ir_to_mesa.o): In function >>> `visit': >>> >>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1092: >>> undefined reference to `glsl_type::vec4_type' >>> >>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1115: >>> undefined reference to `glsl_type::vec4_type' >>> >>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1487: >>> undefined reference to `glsl_type::float_type' >>> >>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1497: >>> undefined reference to `glsl_type::float_type' >>> >>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1871: >>> undefined reference to `glsl_type::vec4_type' >>> >>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1883: >>> undefined reference to `glsl_type::vec4_type' >>> >>> >>> Hopefully it's something simple to fix. >> >> >> these types should all be coming from glsl_types.cpp which moved into >> NIR.. >> >> I've no idea about MSVC or MinGW builds.. (I did at least fix up the >> scons build, although in not a very pretty way..). I guess the best >> thing I could suggest is to: >> >>git show -M b9b40ef9b7644ea24768bc8b7464b1719efe99bf >> >> and make equivalent changes in whatever build files MSVC/MinGW uses?? > > > Yeah, that's what I did. > ahh, I just saw you pushed a patch.. thanks :-) I'm glad you managed to figure it out.. I actually don't have any windows machine (at home or work) so would have been difficult for me to debug. Sorry about breaking things. BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] MSVC, MinGW build break
On Sat, Oct 17, 2015 at 12:17 PM, Brian Paul wrote: > On 10/17/2015 10:13 AM, Rob Clark wrote: >> >> On Sat, Oct 17, 2015 at 12:07 PM, Brian Paul wrote: >>> >>> On 10/17/2015 07:04 AM, Rob Clark wrote: >>>> >>>> >>>> On Fri, Oct 16, 2015 at 11:11 PM, Brian Paul wrote: >>>>> >>>>> >>>>> Hi Rob, >>>>> >>>>> Your recent commit "nir: remove dependency on glsl" broke the build for >>>>> MSVC >>>>> and MinGW. >>>>> >>>>> For MSVC: >>>>> >>>>> [...] >>>>> Linking >>>>> build\windows-x86-debug\gallium\tests\graw\occlusion-query.exe >>>>> ... >>>>> Linking build\windows-x86-debug\gallium\tests\graw\quad-sample.exe >>>>> ... >>>>> glsl.lib(loop_controls.obj) : error LNK2001: unresolved external symbol >>>>> "public: static struct glsl_type const * const glsl_type::bool_type" >>>>> (?bool_type@glsl_type@@2QBU1@B) >>>>> glsl.lib(lower_discard_flow.obj) : error LNK2001: unresolved external >>>>> symbol >>>>> "public: static struct glsl_type const * const glsl_type::bool_type" >>>>> (?bool_type@glsl_type@@2QBU1@B) >>>>> [...] >>>>> glsl.lib(builtin_functions.obj) : error LNK2001: unresolved external >>>>> symbol >>>>> "public: static struct glsl_type const * const glsl_type::float_type" >>>>> (?float_type@glsl_type@@2QBU1@B) >>>>> [...] >>>>> mesa.lib(ff_fragment_shader.obj) : error LNK2001: unresolved external >>>>> symbol >>>>> "public: static struct glsl_type const * const >>>>> glsl_type::sampler2DShadow_type" >>>>> (?sampler2DShadow_type@glsl_type@@2QBU1@B) >>>>> [etc. for hundreds more] >>>>> >>>>> >>>>> >>>>> For MinGW: >>>>> [...] >>>>> Linking build/windows-x86-debug/gallium/tests/graw/fs-write-z.exe >>>>> ... >>>>> Linking build/windows-x86-debug/gallium/targets/osmesa/osmesa.dll >>>>> ... >>>>> Linking >>>>> build/windows-x86-debug/gallium/targets/libgl-gdi/opengl32.dll >>>>> ... >>>>> build/windows-x86-debug/mesa/libmesa.a(ir_to_mesa.o): In function >>>>> `reladdr_to_temp': >>>>> >>>>> >>>>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:793: >>>>> undefined reference to `glsl_type::vec4_type' >>>>> build/windows-x86-debug/mesa/libmesa.a(ir_to_mesa.o): In function >>>>> `visit': >>>>> >>>>> >>>>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1092: >>>>> undefined reference to `glsl_type::vec4_type' >>>>> >>>>> >>>>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1115: >>>>> undefined reference to `glsl_type::vec4_type' >>>>> >>>>> >>>>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1487: >>>>> undefined reference to `glsl_type::float_type' >>>>> >>>>> >>>>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1497: >>>>> undefined reference to `glsl_type::float_type' >>>>> >>>>> >>>>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1871: >>>>> undefined reference to `glsl_type::vec4_type' >>>>> >>>>> >>>>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1883: >>>>> undefined reference to `glsl_type::vec4_type' >>>>> >>>>> >>>>> Hopefully it's something simple to fix. >>>> >>>> >>>> >>>> these types should all be coming from glsl_types.cpp which moved into >>>> NIR.. >>>> >>>> I've no idea about MSVC or MinGW builds.. (I did at least fix up the >>>> scons build, although in not a very pretty way..). I guess the best >>>> thing I could suggest is to: >>>> >>>> git show -M b9b40ef9b7644ea24768bc8b7464b1719efe99bf >>>> >>>> and make equivalent changes in whatever build files MSVC/MinGW uses?? >>> >>> >>> >>> Yeah, that's what I did. >>> >> >> ahh, I just saw you pushed a patch.. thanks :-) >> >> I'm glad you managed to figure it out.. I actually don't have any >> windows machine (at home or work) so would have been difficult for me >> to debug. Sorry about breaking things. > > > It's pretty easy to install MinGW with apt-get or yum, etc. Then, it's just > 'scons platform=windows machine=x86_64 libgl-gdi' or some variation. > oh, so cross-compile for windows from linux? It didn't even occur to me that this was possible. I'll keep that in mind next time I venture into trying to make build changes BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] MSVC, MinGW build break
On Sat, Oct 17, 2015 at 12:36 PM, Brian Paul wrote: > On 10/17/2015 10:07 AM, Brian Paul wrote: >> >> On 10/17/2015 07:04 AM, Rob Clark wrote: >>> >>> On Fri, Oct 16, 2015 at 11:11 PM, Brian Paul wrote: >>>> >>>> Hi Rob, >>>> >>>> Your recent commit "nir: remove dependency on glsl" broke the build >>>> for MSVC >>>> and MinGW. >>>> >>>> For MSVC: >>>> >>>> [...] >>>>Linking >>>> build\windows-x86-debug\gallium\tests\graw\occlusion-query.exe ... >>>>Linking build\windows-x86-debug\gallium\tests\graw\quad-sample.exe >>>> ... >>>> glsl.lib(loop_controls.obj) : error LNK2001: unresolved external symbol >>>> "public: static struct glsl_type const * const glsl_type::bool_type" >>>> (?bool_type@glsl_type@@2QBU1@B) >>>> glsl.lib(lower_discard_flow.obj) : error LNK2001: unresolved external >>>> symbol >>>> "public: static struct glsl_type const * const glsl_type::bool_type" >>>> (?bool_type@glsl_type@@2QBU1@B) >>>> [...] >>>> glsl.lib(builtin_functions.obj) : error LNK2001: unresolved external >>>> symbol >>>> "public: static struct glsl_type const * const glsl_type::float_type" >>>> (?float_type@glsl_type@@2QBU1@B) >>>> [...] >>>> mesa.lib(ff_fragment_shader.obj) : error LNK2001: unresolved external >>>> symbol >>>> "public: static struct glsl_type const * const >>>> glsl_type::sampler2DShadow_type" >>>> (?sampler2DShadow_type@glsl_type@@2QBU1@B) >>>> [etc. for hundreds more] >>>> >>>> >>>> >>>> For MinGW: >>>> [...] >>>>Linking build/windows-x86-debug/gallium/tests/graw/fs-write-z.exe ... >>>>Linking build/windows-x86-debug/gallium/targets/osmesa/osmesa.dll ... >>>>Linking >>>> build/windows-x86-debug/gallium/targets/libgl-gdi/opengl32.dll ... >>>> build/windows-x86-debug/mesa/libmesa.a(ir_to_mesa.o): In function >>>> `reladdr_to_temp': >>>> >>>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:793: >>>> >>>> undefined reference to `glsl_type::vec4_type' >>>> build/windows-x86-debug/mesa/libmesa.a(ir_to_mesa.o): In function >>>> `visit': >>>> >>>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1092: >>>> >>>> undefined reference to `glsl_type::vec4_type' >>>> >>>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1115: >>>> >>>> undefined reference to `glsl_type::vec4_type' >>>> >>>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1487: >>>> >>>> undefined reference to `glsl_type::float_type' >>>> >>>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1497: >>>> >>>> undefined reference to `glsl_type::float_type' >>>> >>>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1871: >>>> >>>> undefined reference to `glsl_type::vec4_type' >>>> >>>> /var/lib/hudson/jobs/mesa-mingw/workspace/src/mesa/program/ir_to_mesa.cpp:1883: >>>> >>>> undefined reference to `glsl_type::vec4_type' >>>> >>>> >>>> Hopefully it's something simple to fix. >>> >>> >>> these types should all be coming from glsl_types.cpp which moved into >>> NIR.. >>> >>> I've no idea about MSVC or MinGW builds.. (I did at least fix up the >>> scons build, although in not a very pretty way..). I guess the best >>> thing I could suggest is to: >>> >>>git show -M b9b40ef9b7644ea24768bc8b7464b1719efe99bf >>> >>> and make equivalent changes in whatever build files MSVC/MinGW uses?? >> >> >> Yeah, that's what I did. > > > Actually, I'm kind of hoping we can find a cleaner fix for scons. Maybe > Jose can take a look when he has time. > yeah, current solution is not pretty.. Emil had suggested introducing a libnir for scons build, but that was well beyond my understanding of scons and the scons build setup. That would be nice if someone who knew what they were doing could have a look. BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] MSVC, MinGW build break
On Mon, Oct 19, 2015 at 10:02 AM, Jose Fonseca wrote: > On 17/10/15 17:44, Rob Clark wrote: >> >> On Sat, Oct 17, 2015 at 12:36 PM, Brian Paul wrote: >>> >>> On 10/17/2015 10:07 AM, Brian Paul wrote: >>>> >>>> >>>> On 10/17/2015 07:04 AM, Rob Clark wrote: >>>>> >>>>> >>>>> On Fri, Oct 16, 2015 at 11:11 PM, Brian Paul wrote: >>>>>> >>>>>> >>>>>> Hi Rob, >>>>>> >>>>>> Your recent commit "nir: remove dependency on glsl" broke the build >>>>>> for MSVC >>>>>> and MinGW. >>>>>> >>>>>> For MSVC: >>>>>> > [...] >>>>>> >>>>>> >>>>>> >>>>>> Hopefully it's something simple to fix. >>>>> >>>>> >>>>> >>>>> these types should all be coming from glsl_types.cpp which moved into >>>>> NIR.. >>>>> >>>>> I've no idea about MSVC or MinGW builds.. (I did at least fix up the >>>>> scons build, although in not a very pretty way..). I guess the best >>>>> thing I could suggest is to: >>>>> >>>>> git show -M b9b40ef9b7644ea24768bc8b7464b1719efe99bf >>>>> >>>>> and make equivalent changes in whatever build files MSVC/MinGW uses?? >>>> >>>> >>>> >>>> Yeah, that's what I did. >>> >>> >>> >>> Actually, I'm kind of hoping we can find a cleaner fix for scons. Maybe >>> Jose can take a look when he has time. >>> >> >> yeah, current solution is not pretty.. Emil had suggested introducing >> a libnir for scons build, but that was well beyond my understanding of >> scons and the scons build setup. >> >> That would be nice if someone who knew what they were doing could have a >> look. > > > > The problem was actually quite simple. > > I'll post a review request now. > > >> v3: I f***ing hate scons.. but at least it builds > > Please CC'me when there are difficulties related to the scons build before > or during code review. > > There's no need for people to be struggling with SCons specific issues all > alone. But there's too much traffic in Mesa for me to keep up with all of > it (specially because lately my focus has been elsewhere), so unless I'm > explicitly CC'ed the odds are that it will go past me as happened here. > (e-mail that CC me won't be automatically moved into a folder -- will stay > on my top inbox folder where's it's bound to catch my attention.) > sorry, now I know who to ask.. Emil knew I was having difficulties.. although his suggestion was 'add libnir' (which I think is probably the right way.. but a bit out of my depth) BR, -R > > BTW, the root cause is not so much SCons' "quirkyness", but merely the fact > that SCons hasn't yet been updated to build NIR, hence adding > nir/glsl_types.cpp to src/glsl/Makefile.sources' NIR_FILES variable had no > effect for scson. All the trouble resulted of that. > > And we are probably likely to run into issues again, until we integrate NIR > into scons. We should make a bit of time for that as soon as we can. > > > Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFCv0 3/8] gallium: add NIR as a possible IR
--- src/gallium/include/pipe/p_defines.h | 1 + src/gallium/include/pipe/p_state.h | 1 + 2 files changed, 2 insertions(+) diff --git a/src/gallium/include/pipe/p_defines.h b/src/gallium/include/pipe/p_defines.h index 29b0bfb..0dbc54c 100644 --- a/src/gallium/include/pipe/p_defines.h +++ b/src/gallium/include/pipe/p_defines.h @@ -715,6 +715,7 @@ enum pipe_shader_ir PIPE_SHADER_IR_TGSI = 0, PIPE_SHADER_IR_LLVM, PIPE_SHADER_IR_NATIVE, + PIPE_SHADER_IR_NIR, }; /** diff --git a/src/gallium/include/pipe/p_state.h b/src/gallium/include/pipe/p_state.h index 50bfc4a..54ca31f 100644 --- a/src/gallium/include/pipe/p_state.h +++ b/src/gallium/include/pipe/p_state.h @@ -230,6 +230,7 @@ struct pipe_shader_state const struct tgsi_token *tokens; void *llvm; void *native; + void *nir; }; struct pipe_stream_output_info stream_output; }; -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFCv0 2/8] gallium: refactor pipe_shader_state to support multiple IR's
The goal is to allow the pipe driver to request something other than
TGSI, but detect whether what is getting is TGSI vs what it requested.
The pipe drivers will always have to support TGSI (and convert that into
whatever it is that they prefer), but in some cases we should be able to
skip the TGSI intermediate step (such as glsl->nir vs glsl->tgsi->nir).
I think pipe_compute_state should get similar treatment. Currently,
afaict, it has one user and one consumer, which has allowed it to be
sloppy wrt. supporting alternative IR's.
---
src/gallium/auxiliary/hud/hud_context.c | 14 +++--
src/gallium/auxiliary/postprocess/pp_run.c| 4 ++-
src/gallium/auxiliary/tgsi/tgsi_ureg.c| 6 ++--
src/gallium/auxiliary/util/u_simple_shaders.c | 42 +++
src/gallium/auxiliary/util/u_tests.c | 7 -
src/gallium/include/pipe/p_defines.h | 12 ++--
src/gallium/include/pipe/p_state.h| 20 +++--
7 files changed, 89 insertions(+), 16 deletions(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 95eed26..9f39abd 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -1179,7 +1179,12 @@ hud_create(struct pipe_context *pipe, struct cso_context
*cso)
};
struct tgsi_token tokens[1000];
- struct pipe_shader_state state = {tokens};
+ struct pipe_shader_state state;
+
+ memset(&state, 0, sizeof(state));
+
+ state.ir = PIPE_SHADER_IR_TGSI;
+ state.tokens = tokens;
if (!tgsi_text_translate(fragment_shader_text, tokens,
Elements(tokens))) {
assert(0);
@@ -1226,7 +1231,12 @@ hud_create(struct pipe_context *pipe, struct cso_context
*cso)
};
struct tgsi_token tokens[1000];
- struct pipe_shader_state state = {tokens};
+ struct pipe_shader_state state;
+
+ memset(&state, 0, sizeof(state));
+
+ state.ir = PIPE_SHADER_IR_TGSI;
+ state.tokens = tokens;
if (!tgsi_text_translate(vertex_shader_text, tokens, Elements(tokens))) {
assert(0);
diff --git a/src/gallium/auxiliary/postprocess/pp_run.c
b/src/gallium/auxiliary/postprocess/pp_run.c
index caa2062..6cd2b70 100644
--- a/src/gallium/auxiliary/postprocess/pp_run.c
+++ b/src/gallium/auxiliary/postprocess/pp_run.c
@@ -272,8 +272,10 @@ pp_tgsi_to_state(struct pipe_context *pipe, const char
*text, bool isvs,
return NULL;
}
+ memset(&state, 0, sizeof(state));
+
+ state.ir = PIPE_SHADER_IR_TGSI;
state.tokens = tokens;
- memset(&state.stream_output, 0, sizeof(state.stream_output));
if (isvs) {
ret_state = pipe->create_vs_state(pipe, &state);
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 3d21319..96a51c4 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -1777,14 +1777,16 @@ void *ureg_create_shader( struct ureg_program *ureg,
{
struct pipe_shader_state state;
+ memset(&state, 0, sizeof(state));
+
+ state.ir = PIPE_SHADER_IR_TGSI;
+
state.tokens = ureg_finalize(ureg);
if(!state.tokens)
return NULL;
if (so)
state.stream_output = *so;
- else
- memset(&state.stream_output, 0, sizeof(state.stream_output));
switch (ureg->processor) {
case TGSI_PROCESSOR_VERTEX:
diff --git a/src/gallium/auxiliary/util/u_simple_shaders.c
b/src/gallium/auxiliary/util/u_simple_shaders.c
index 6eed337..8be0da9 100644
--- a/src/gallium/auxiliary/util/u_simple_shaders.c
+++ b/src/gallium/auxiliary/util/u_simple_shaders.c
@@ -121,7 +121,12 @@ void *util_make_layered_clear_vertex_shader(struct
pipe_context *pipe)
"MOV OUT[2], SV[0]\n"
"END\n";
struct tgsi_token tokens[1000];
- struct pipe_shader_state state = {tokens};
+ struct pipe_shader_state state;
+
+ memset(&state, 0, sizeof(state));
+
+ state.ir = PIPE_SHADER_IR_TGSI;
+ state.tokens = tokens;
if (!tgsi_text_translate(text, tokens, Elements(tokens))) {
assert(0);
@@ -149,7 +154,12 @@ void *util_make_layered_clear_helper_vertex_shader(struct
pipe_context *pipe)
"MOV OUT[2].x, SV[0].\n"
"END\n";
struct tgsi_token tokens[1000];
- struct pipe_shader_state state = {tokens};
+ struct pipe_shader_state state;
+
+ memset(&state, 0, sizeof(state));
+
+ state.ir = PIPE_SHADER_IR_TGSI;
+ state.tokens = tokens;
if (!tgsi_text_translate(text, tokens, Elements(tokens))) {
assert(0);
@@ -192,7 +202,12 @@ void *util_make_layered_clear_geometry_shader(struct
pipe_context *pipe)
"EMIT IMM[0].\n"
"END\n";
struct tgsi_token tokens[1000];
- struct pipe_shader_state state = {tokens};
+ struct pipe_shader_state state;
+
+ memset(&state, 0, sizeof(state));
+
+ state.ir = PIPE_SHADER_IR_TGSI;
+ state.tokens = tokens;
if (!tgsi_text_translate(text, tokens, Elemen
[Mesa-dev] [RFCv0 8/8] freedreno/ir3: hack for mismatch on varying slots for glsl->tgsi->nir vs glsl->nir
Complete hack just for debugging. It isn't intended that mixing and
matching glsl->tgsi->nir vs glsl->nir between shader stages should
actually work.
---
src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
index 2b9a841..317ed79 100644
--- a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
+++ b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
@@ -2232,6 +2232,12 @@ setup_output(struct ir3_compile *ctx, nir_variable *out)
unsigned slot = out->data.location;
unsigned comp = 0;
+ // XXX temporary hack for NIR vs and TGSI fs.. since there is
+ // some disagreement about varying slots..
+ if (ctx->so->shader->nir)
+ if (slot >= VARYING_SLOT_VAR0)
+ slot += 9;
+
DBG("; out: slot=%u, len=%ux%u, drvloc=%u",
slot, array_len, ncomp, n);
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFCv0 6/8] freedreno/ir3: add support for NIR as preferred IR
For now under debug flag, since only suitable for debugging/testing.
---
src/gallium/drivers/freedreno/freedreno_screen.c | 5 +++-
src/gallium/drivers/freedreno/freedreno_util.h | 1 +
.../drivers/freedreno/ir3/ir3_compiler_nir.c | 15 ++-
src/gallium/drivers/freedreno/ir3/ir3_shader.c | 30 +++---
src/gallium/drivers/freedreno/ir3/ir3_shader.h | 3 +++
5 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
b/src/gallium/drivers/freedreno/freedreno_screen.c
index b64f78c..30def8e 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -71,6 +71,7 @@ static const struct debug_named_value debug_options[] = {
{"glsl120", FD_DBG_GLSL120,"Temporary flag to force GLSL 1.20
(rather than 1.30) on a3xx+"},
{"shaderdb", FD_DBG_SHADERDB, "Enable shaderdb output"},
{"flush", FD_DBG_FLUSH, "Force flush after every draw"},
+ {"nir", FD_DBG_NIR,"Prefer NIR as native IR"},
DEBUG_NAMED_VALUE_END
};
@@ -398,7 +399,7 @@ fd_screen_get_shader_param(struct pipe_screen *pscreen,
unsigned shader,
case PIPE_SHADER_CAP_TGSI_DROUND_SUPPORTED:
case PIPE_SHADER_CAP_TGSI_DFRACEXP_DLDEXP_SUPPORTED:
case PIPE_SHADER_CAP_TGSI_FMA_SUPPORTED:
-case PIPE_SHADER_CAP_TGSI_ANY_INOUT_DECL_RANGE:
+ case PIPE_SHADER_CAP_TGSI_ANY_INOUT_DECL_RANGE:
return 0;
case PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED:
return 1;
@@ -410,6 +411,8 @@ fd_screen_get_shader_param(struct pipe_screen *pscreen,
unsigned shader,
case PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS:
return 16;
case PIPE_SHADER_CAP_PREFERRED_IR:
+ if ((fd_mesa_debug & FD_DBG_NIR) && is_ir3(screen))
+ return PIPE_SHADER_IR_NIR;
return PIPE_SHADER_IR_TGSI;
}
debug_printf("unknown shader param %d\n", param);
diff --git a/src/gallium/drivers/freedreno/freedreno_util.h
b/src/gallium/drivers/freedreno/freedreno_util.h
index 0d2418e..56d3235 100644
--- a/src/gallium/drivers/freedreno/freedreno_util.h
+++ b/src/gallium/drivers/freedreno/freedreno_util.h
@@ -73,6 +73,7 @@ enum adreno_stencil_op fd_stencil_op(unsigned op);
#define FD_DBG_GLSL120 0x0400
#define FD_DBG_SHADERDB 0x0800
#define FD_DBG_FLUSH0x1000
+#define FD_DBG_NIR 0x2000
extern int fd_mesa_debug;
extern bool fd_binning_enabled;
diff --git a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
index b4e5483..5a53e32 100644
--- a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
+++ b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
@@ -164,7 +164,14 @@ to_nir(struct ir3_compile *ctx, struct ir3_shader_variant
*so)
tex_options.lower_txp = (1 << GLSL_SAMPLER_DIM_3D);
}
- struct nir_shader *s = tgsi_to_nir(so->shader->tokens, &options);
+ struct nir_shader *s;
+
+ if (so->shader->nir) {
+ // XXX need nir_clone() here..
+ s = so->shader->nir;
+ } else {
+ s = tgsi_to_nir(so->shader->tokens, &options);
+ }
if (fd_mesa_debug & FD_DBG_OPTMSGS) {
debug_printf("--\n");
@@ -292,6 +299,12 @@ compile_error(struct ir3_compile *ctx, const char *format,
...)
static void
compile_free(struct ir3_compile *ctx)
{
+ /* TODO .. probably need a ralloc_free(ctx->s) here, at least
+* for the tgsi_to_nir case.. right now in the case we get
+* NIR directly, we want to skip this since the nir_shader isn't
+* getting cloned.. and/or if it was we might be wanting to
+* free it in ir3_shader_destroy()??
+*/
ralloc_free(ctx);
}
diff --git a/src/gallium/drivers/freedreno/ir3/ir3_shader.c
b/src/gallium/drivers/freedreno/ir3/ir3_shader.c
index 7b56533..0cbf8fe 100644
--- a/src/gallium/drivers/freedreno/ir3/ir3_shader.c
+++ b/src/gallium/drivers/freedreno/ir3/ir3_shader.c
@@ -39,6 +39,7 @@
#include "ir3_shader.h"
#include "ir3_compiler.h"
+#include "ir3_nir.h"
static void
@@ -188,9 +189,15 @@ create_variant(struct ir3_shader *shader, struct
ir3_shader_key key)
v->type = shader->type;
if (fd_mesa_debug & FD_DBG_DISASM) {
- DBG("dump tgsi: type=%d, k={bp=%u,cts=%u,hp=%u}", shader->type,
- key.binning_pass, key.color_two_side,
key.half_precision);
- tgsi_dump(shader->tokens, 0);
+ if (shader->nir) {
+ DBG("dump nir: type=%d, k={bp=%u,cts=%u,hp=%u}",
shader->type,
+ key.binning_pass, key.color_two_side,
key.half_precision);
+ nir_print_shader(shader->nir, stderr);
+ } else {
+
[Mesa-dev] [PATCH 1/8] nir: add nir_var_all enum
Otherwise, passing -1 gets you:
error: invalid conversion from 'int' to 'nir_variable_mode' [-fpermissive]
Signed-off-by: Rob Clark
---
src/glsl/nir/nir.c | 4
src/glsl/nir/nir.h | 1 +
src/glsl/nir/nir_lower_io.c | 2 +-
src/mesa/drivers/dri/i965/brw_nir.c | 3 ++-
4 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
index 793bdaf..caa9ffc 100644
--- a/src/glsl/nir/nir.c
+++ b/src/glsl/nir/nir.c
@@ -107,6 +107,10 @@ void
nir_shader_add_variable(nir_shader *shader, nir_variable *var)
{
switch (var->data.mode) {
+ case nir_var_all:
+ assert(!"invalid mode");
+ break;
+
case nir_var_local:
assert(!"nir_shader_add_variable cannot be used for local variables");
break;
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index c867e6d..2a84cb0 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -82,6 +82,7 @@ typedef struct {
} nir_state_slot;
typedef enum {
+ nir_var_all = -1,
nir_var_shader_in,
nir_var_shader_out,
nir_var_global,
diff --git a/src/glsl/nir/nir_lower_io.c b/src/glsl/nir/nir_lower_io.c
index 688b48f..b4ed857 100644
--- a/src/glsl/nir/nir_lower_io.c
+++ b/src/glsl/nir/nir_lower_io.c
@@ -176,7 +176,7 @@ nir_lower_io_block(nir_block *block, void *void_state)
nir_variable_mode mode = intrin->variables[0]->var->data.mode;
- if (state->mode != -1 && state->mode != mode)
+ if (state->mode != nir_var_all && state->mode != mode)
continue;
switch (intrin->intrinsic) {
diff --git a/src/mesa/drivers/dri/i965/brw_nir.c
b/src/mesa/drivers/dri/i965/brw_nir.c
index af9d041..e22f5fa 100644
--- a/src/mesa/drivers/dri/i965/brw_nir.c
+++ b/src/mesa/drivers/dri/i965/brw_nir.c
@@ -219,7 +219,8 @@ brw_create_nir(struct brw_context *brw,
nir_assign_var_locations(&nir->uniforms,
&nir->num_uniforms,
is_scalar ? type_size_scalar : type_size_vec4);
- nir_lower_io(nir, -1, is_scalar ? type_size_scalar : type_size_vec4);
+ nir_lower_io(nir, nir_var_all,
+is_scalar ? type_size_scalar : type_size_vec4);
nir_validate_shader(nir);
nir_remove_dead_variables(nir);
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFCv0 7/8] freedreno/ir3: fix const_index handling for uniforms
When coming directly from glsl_to_nir (rather than via TGSI where
information about, for example, mat4's is lost), both const_index
fields will be used (vs. tgsi_to_nir where the 2nd is always zero).
For example:
decl_var uniform INTERP_QUALIFIER_NONE mat4 ModelViewProjectionMatrix (0, 0)
decl_var uniform INTERP_QUALIFIER_NONE mat4 NormalMatrix (4, 4)
...
vec4 ssa_54 = intrinsic load_uniform () () (4, 0) /* NormalMatrix
*/
vec4 ssa_56 = intrinsic load_uniform () () (4, 1) /* NormalMatrix
*/
vs:
decl_var uniform INTERP_QUALIFIER_NONE vec4[8] uniform_0 (0, 0)
...
vec4 ssa_54 = intrinsic load_uniform () () (4, 0)
vec4 ssa_56 = intrinsic load_uniform () () (5, 0)
---
src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
index 5a53e32..2b9a841 100644
--- a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
+++ b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
@@ -1377,7 +1377,10 @@ emit_intrinisic(struct ir3_compile *ctx,
nir_intrinsic_instr *intr)
const nir_intrinsic_info *info = &nir_intrinsic_infos[intr->intrinsic];
struct ir3_instruction **dst, **src;
struct ir3_block *b = ctx->block;
- unsigned idx = intr->const_index[0];
+ unsigned idx = 0;
+
+ for (unsigned i = 0; i <
nir_intrinsic_infos[intr->intrinsic].num_indices; i++)
+ idx += intr->const_index[i];
if (info->has_dest) {
dst = get_dst(ctx, &intr->dest, intr->num_components);
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFCv0 5/8] freedreno/ir3: drop tokens arg
We can get the tokens from variant->shader so drop the extra arg. This
will make things easier to support either getting TGSI or NIR as input.
---
src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
index 8c9234b..b4e5483 100644
--- a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
+++ b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
@@ -126,8 +126,8 @@ struct ir3_compile {
static struct ir3_instruction * create_immed(struct ir3_block *block, uint32_t
val);
static struct ir3_block * get_block(struct ir3_compile *ctx, nir_block
*nblock);
-static struct nir_shader *to_nir(struct ir3_compile *ctx,
- const struct tgsi_token *tokens, struct ir3_shader_variant *so)
+static struct nir_shader *
+to_nir(struct ir3_compile *ctx, struct ir3_shader_variant *so)
{
static const nir_shader_compiler_options options = {
.lower_fpow = true,
@@ -164,7 +164,7 @@ static struct nir_shader *to_nir(struct ir3_compile *ctx,
tex_options.lower_txp = (1 << GLSL_SAMPLER_DIM_3D);
}
- struct nir_shader *s = tgsi_to_nir(tokens, &options);
+ struct nir_shader *s = tgsi_to_nir(so->shader->tokens, &options);
if (fd_mesa_debug & FD_DBG_OPTMSGS) {
debug_printf("--\n");
@@ -214,9 +214,7 @@ static struct nir_shader *to_nir(struct ir3_compile *ctx,
}
static struct ir3_compile *
-compile_init(struct ir3_compiler *compiler,
- struct ir3_shader_variant *so,
- const struct tgsi_token *tokens)
+compile_init(struct ir3_compiler *compiler, struct ir3_shader_variant *so)
{
struct ir3_compile *ctx = rzalloc(NULL, struct ir3_compile);
@@ -245,7 +243,7 @@ compile_init(struct ir3_compiler *compiler,
ctx->block_ht = _mesa_hash_table_create(ctx,
_mesa_hash_pointer, _mesa_key_pointer_equal);
- ctx->s = to_nir(ctx, tokens, so);
+ ctx->s = to_nir(ctx, so);
so->first_driver_param = so->first_immediate = ctx->s->num_uniforms;
@@ -2432,7 +2430,7 @@ ir3_compile_shader_nir(struct ir3_compiler *compiler,
assert(!so->ir);
- ctx = compile_init(compiler, so, so->shader->tokens);
+ ctx = compile_init(compiler, so);
if (!ctx) {
DBG("INIT failed!");
ret = -1;
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFCv0 4/8] mesa/st: add support for NIR as possible driver IR
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 223 -
src/mesa/state_tracker/st_program.c| 43 +-
2 files changed, 260 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 06f510d..49f496f 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -35,6 +35,9 @@
#include "glsl_parser_extras.h"
#include "ir_optimization.h"
+#include "nir.h"
+#include "glsl_to_nir.h"
+
#include "main/errors.h"
#include "main/shaderobj.h"
#include "main/uniforms.h"
@@ -5486,9 +5489,9 @@ out:
* generating Mesa IR.
*/
static struct gl_program *
-get_mesa_program(struct gl_context *ctx,
- struct gl_shader_program *shader_program,
- struct gl_shader *shader)
+get_mesa_program_tgsi(struct gl_context *ctx,
+ struct gl_shader_program *shader_program,
+ struct gl_shader *shader)
{
glsl_to_tgsi_visitor* v;
struct gl_program *prog;
@@ -5680,6 +5683,220 @@ get_mesa_program(struct gl_context *ctx,
return prog;
}
+/* TODO dup'd from brw_vec4_vistor.cpp.. what should we do? */
+static int
+type_size_vec4(const struct glsl_type *type)
+{
+ unsigned int i;
+ int size;
+
+ switch (type->base_type) {
+ case GLSL_TYPE_UINT:
+ case GLSL_TYPE_INT:
+ case GLSL_TYPE_FLOAT:
+ case GLSL_TYPE_BOOL:
+ if (type->is_matrix()) {
+return type->matrix_columns;
+ } else {
+/* Regardless of size of vector, it gets a vec4. This is bad
+ * packing for things like floats, but otherwise arrays become a
+ * mess. Hopefully a later pass over the code can pack scalars
+ * down if appropriate.
+ */
+return 1;
+ }
+ case GLSL_TYPE_ARRAY:
+ assert(type->length > 0);
+ return type_size_vec4(type->fields.array) * type->length;
+ case GLSL_TYPE_STRUCT:
+ size = 0;
+ for (i = 0; i < type->length; i++) {
+size += type_size_vec4(type->fields.structure[i].type);
+ }
+ return size;
+ case GLSL_TYPE_SUBROUTINE:
+ return 1;
+
+ case GLSL_TYPE_SAMPLER:
+ /* Samplers take up no register space, since they're baked in at
+ * link time.
+ */
+ return 0;
+ case GLSL_TYPE_ATOMIC_UINT:
+ return 0;
+ case GLSL_TYPE_IMAGE:
+// return DIV_ROUND_UP(BRW_IMAGE_PARAM_SIZE, 4);
+ case GLSL_TYPE_VOID:
+ case GLSL_TYPE_DOUBLE:
+ case GLSL_TYPE_ERROR:
+ case GLSL_TYPE_INTERFACE:
+ unreachable("not reached");
+ }
+
+ return 0;
+}
+
+static struct gl_program *
+get_mesa_program_nir(struct gl_context *ctx,
+ struct gl_shader_program *shader_program,
+ struct gl_shader *shader)
+{
+ struct gl_program *prog;
+ GLenum target = _mesa_shader_stage_to_program(shader->Stage);
+ struct gl_shader_compiler_options *options =
+
&ctx->Const.ShaderCompilerOptions[_mesa_shader_enum_to_shader_stage(shader->Type)];
+ struct pipe_screen *pscreen = ctx->st->pipe->screen;
+ unsigned ptarget = st_shader_stage_to_ptarget(shader->Stage);
+ nir_shader_compiler_options nir_options = {0};
+ nir_shader *nir;
+
+ /* TODO maybe options marked with 'XXX' should be PIPE_SHADER_CAP_x's */
+ nir_options.lower_ffma =
+ !pscreen->get_shader_param(pscreen, ptarget,
PIPE_SHADER_CAP_TGSI_FMA_SUPPORTED);
+ nir_options.lower_flrp = true; // XXX
+ nir_options.lower_fpow = options->EmitNoPow;
+ nir_options.lower_fsat = options->EmitNoSat;
+ nir_options.lower_fsqrt =
+ !pscreen->get_shader_param(pscreen, ptarget,
PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED);
+ nir_options.lower_negate = false; // XXX
+ nir_options.lower_sub = false; // XXX
+ nir_options.lower_scmp = true; // XXX
+ nir_options.fdot_replicates = false;// XXX
+ nir_options.lower_ffract = true;// XXX
+ nir_options.native_integers = ctx->Const.NativeIntegers;
+
+ validate_ir_tree(shader->ir);
+
+ prog = ctx->Driver.NewProgram(ctx, target, shader_program->Name);
+ if (!prog)
+ return NULL;
+ prog->Parameters = _mesa_new_parameter_list();
+
+ _mesa_copy_linked_program_data(shader->Stage, shader_program, prog);
+ _mesa_generate_parameters_list_for_uniforms(shader_program, shader,
+ prog->Parameters);
+
+// /* Remove reads from output registers. */
+// lower_output_reads(shader->Stage, shader->ir);
+
+ /* Make a pass over the IR to add state references for any built-in
+* uniforms that are used. This has to be done now (during linking).
+* Code generation doesn't happen until the first time this shader is
+* used for rendering. Waiting until then to generate the parameters is
+* too late. At that point, the values for the built-in uniforms won't
+* get sent to the shader.
+*/
+ foreach_in_list(ir_instruction, node,
Re: [Mesa-dev] [RFCv0 0/8] gallium: add support for NIR as alternate IR
On Mon, Oct 19, 2015 at 3:51 PM, Ilia Mirkin wrote:
> On Mon, Oct 19, 2015 at 3:47 PM, Rob Clark wrote:
>> Also, there is some trivial shader variant handling in mesa st which
>> would have to be ported to NIR. Or, perhaps, just somehow expose the
>> shader key to the driver. (Currently most drivers are doing much more
>> variant handling within the driver, and having two levels of variants
>> does seem a bit silly.)
>
> With Marek's latest series, the are no more variants in st/mesa (well,
> except for glDrawPixels/glBitmap-related shaders) provided that your
> driver exposes the right caps.
Ok, I guess I should rebase onto that.. I think the
glDrawPixels/glBitmap paths will still be TGSI.. so only having to
deal with variants in the GLSL->whatever path in drivers would be
nice..
(note: I should probably point out some TODO comments I had in the
freedreno/ir3 parts about cso->{tokens/nir/etc} lifetime.. the current
state of having to dup/clone in driver since sometimes cso->tokens
don't exist after the pipe->create_xyz_state() is a bit ugly..)
BR,
-R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFCv0 0/8] gallium: add support for NIR as alternate IR
From: Rob Clark (grr, resend to the right list..) Still quite rough around the edges, but now it's at the point of sorta- kinda-working-sometimes. So I guess time to get wider feedback. The initial goal is to figure out things that glsl_to_nir does differently from tgsi_to_nir, so we can fix them up and have better likelyhood of drivers being able to consume NIR from multiple sources. Eventually I'd like to be able to re-use spriv->nir for compute/ clover support, for example. And at some point I'd like to be able to bypass the conversion from glsl->tgsi for mesa st. But for now, being able to track down and fix differences between glsl_to_nir vs tgsi_to_nir is a good start. With what I've added to pipe_shader_state (which is, I suppose, missing some doc updates), the intention is that drivers can ask for an IR other than TGSI. And what they actually get will be either TGSI or their preferred IR. Drivers will have to always handle the TGSI case, so the intention isn't to port all the different state trackers (or internally generated shaders, etc). I suppose pipe_compute_state needs similar treatment, but I've skipped that for now. Currently only the direct GLSL->NIR path is implemented for vertex shaders, which results in a huge hack at the end of the series. It isn't ever intended for drivers to mix/match glsl->nir vs glsl->tgsi-> nir across shader stages. But this is sufficient for now for me to debug other issues. Shader variant handling will be completely broken at the moment, without having a nir_clone()[1]. (Ian, depending on how far that is from the top of your TODO list, I can take a stab at that, since I might be the first consumer.) Also, there is some trivial shader variant handling in mesa st which would have to be ported to NIR. Or, perhaps, just somehow expose the shader key to the driver. (Currently most drivers are doing much more variant handling within the driver, and having two levels of variants does seem a bit silly.) [1] https://bugs.freedesktop.org/show_bug.cgi?id=89436 (First patch isn't actually RFC.. just an issue that I noticed in the process.) Rob Clark (8): nir: add nir_var_all enum gallium: refactor pipe_shader_state to support multiple IR's gallium: add NIR as a possible IR mesa/st: add support for NIR as possible driver IR freedreno/ir3: drop tokens arg freedreno/ir3: add support for NIR as preferred IR freedreno/ir3: fix const_index handling for uniforms HACK: freedreno/ir3: hack for mismatch on varying slots for glsl->tgsi->nir vs glsl->nir src/gallium/auxiliary/hud/hud_context.c| 14 +- src/gallium/auxiliary/postprocess/pp_run.c | 4 +- src/gallium/auxiliary/tgsi/tgsi_ureg.c | 6 +- src/gallium/auxiliary/util/u_simple_shaders.c | 42 +++- src/gallium/auxiliary/util/u_tests.c | 7 +- src/gallium/drivers/freedreno/freedreno_screen.c | 5 +- src/gallium/drivers/freedreno/freedreno_util.h | 1 + .../drivers/freedreno/ir3/ir3_compiler_nir.c | 38 +++- src/gallium/drivers/freedreno/ir3/ir3_shader.c | 30 ++- src/gallium/drivers/freedreno/ir3/ir3_shader.h | 3 + src/gallium/include/pipe/p_defines.h | 13 +- src/gallium/include/pipe/p_state.h | 21 +- src/glsl/nir/nir.c | 4 + src/glsl/nir/nir.h | 1 + src/glsl/nir/nir_lower_io.c| 2 +- src/mesa/drivers/dri/i965/brw_nir.c| 3 +- src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 223 - src/mesa/state_tracker/st_program.c| 43 +++- 18 files changed, 422 insertions(+), 38 deletions(-) -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
