Re: [Mesa-dev] [PATCH V2 9.1] i965/vs: Fix Gen4/5 VUE map inconsistency with gl_ClipVertex
Reviewed-by: Jordan Justen
Tested-by: Jordan Justen
I tested steam and a few games, and it seems good. On one generally
problematic (non-Valve) TF2 map, I did see some vertex location
issues. I don't suspect these are introduced by this patch.
Since this is for the stable branch, please verify that there are no
piglit regressions. I kind of hope we might get another r-b too.
On Fri, Apr 26, 2013 at 11:56 PM, Chris Forbes wrote:
> This is roughly a backport of Eric's commit 0967c362.
>
> We avoided assigning a slot in the VUE map for gl_ClipVertex, but left
> the bit set in outputs_written, producing horrible confusion further
> down the pipe.
>
> Mostly fixes rendering in source games, and probably in Freespace 2 SCP.
>
> Signed-off-by: Chris Forbes
>
> V2: Mask out the bit, not its index. Strangely, the game still worked
> with that wrong, but rendering of pretty much anything else was
> completely trashed.
> ---
> src/mesa/drivers/dri/i965/brw_vs.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vs.c
> b/src/mesa/drivers/dri/i965/brw_vs.c
> index 0810471..0234ebb 100644
> --- a/src/mesa/drivers/dri/i965/brw_vs.c
> +++ b/src/mesa/drivers/dri/i965/brw_vs.c
> @@ -62,9 +62,13 @@ brw_compute_vue_map(struct brw_context *brw, struct
> brw_vs_compile *c)
> {
> const struct intel_context *intel = &brw->intel;
> struct brw_vue_map *vue_map = &c->prog_data.vue_map;
> - GLbitfield64 outputs_written = c->prog_data.outputs_written;
> + GLbitfield64 outputs_written;
> int i;
>
> + if (intel->gen < 6)
> + c->prog_data.outputs_written &=
> ~BITFIELD64_BIT(VERT_RESULT_CLIP_VERTEX);
> + outputs_written = c->prog_data.outputs_written;
> +
> vue_map->num_slots = 0;
> for (i = 0; i < BRW_VERT_RESULT_MAX; ++i) {
>vue_map->vert_result_to_slot[i] = -1;
> @@ -150,8 +154,6 @@ brw_compute_vue_map(struct brw_context *brw, struct
> brw_vs_compile *c)
> * feedback is enabled or disabled, just go ahead and assign a slot for
> it.
> */
> for (int i = 0; i < VERT_RESULT_MAX; ++i) {
> - if (intel->gen < 6 && i == VERT_RESULT_CLIP_VERTEX)
> - continue;
>if ((outputs_written & BITFIELD64_BIT(i)) &&
>vue_map->vert_result_to_slot[i] == -1) {
> assign_vue_slot(vue_map, i);
> --
> 1.8.2.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/llvm: Use LLVM C API for compiling LLVM IR to ISA.
Jose, On Thursday, April 25, 2013 03:52:44 Jose Fonseca wrote: > There is no paradox. To be clear: Ok, thanks! Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: mask unused source components for SAMPLE
This results in more clean shader code and may improve the quality of
optimized code produced by r600-sb due to eliminated false dependencies
in some cases.
Signed-off-by: Vadim Girlin
---
There are no piglit regressions with this patch on evergreen.
I consider this as a prerequisite for r600-sb branch, it fixes the performance
regression with optimized shaders uncovered by some recent changes to tgsi
and/or r600 codegen.
If there are no objections or new suggestions, is it OK to push the latest
version of r600-sb-2 branch [1] that includes this patch?
The changes in the branch after the recent mail include 3 additional patches
to improve handling of some corner cases (they fix some issues reported on IRC),
also they add switching to unoptimized code in case of possible internal
optimization problems, and new option "sbnofallback" for R600_DEBUG to disable
such fallback.
Vadim
[1] http://cgit.freedesktop.org/~vadimg/mesa/log/?h=r600-sb-2
src/gallium/drivers/r600/r600_shader.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 0204f80..aa88252 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -4739,6 +4739,26 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
/* the array index is read from Z */
tex.coord_type_z = 0;
+ /* mask unused source components */
+ if (opcode == FETCH_OP_SAMPLE) {
+ switch (inst->Texture.Texture) {
+ case TGSI_TEXTURE_2D:
+ case TGSI_TEXTURE_RECT:
+ tex.src_sel_z = 7;
+ tex.src_sel_w = 7;
+ break;
+ case TGSI_TEXTURE_1D_ARRAY:
+ tex.src_sel_y = 7;
+ tex.src_sel_w = 7;
+ break;
+ case TGSI_TEXTURE_1D:
+ tex.src_sel_y = 7;
+ tex.src_sel_z = 7;
+ tex.src_sel_w = 7;
+ break;
+ }
+ }
+
r = r600_bytecode_add_tex(ctx->bc, &tex);
if (r)
return r;
--
1.8.2.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/llvm: Use LLVM C API for compiling LLVM IR to ISA.
Hi, On Thursday, April 25, 2013 10:29:27 Jose Fonseca wrote: > - There are a bunch of options that need to be set via globals, (see > lp_set_target_options), so app/drivers could tamper with each other > options. > > - llvm::cl::ParseCommandLineOptions will complain if called multiple times > -- I think we no longer need to call it these days though > > In short, LLVM was not designed for multiple users in the same process. Yep. Also llvm is still emerging too fast to assume a specific version to be available. At least with r600 we do currently need a somewhat recent version and kind of have this assumption. But due to the api not kept strictly backwards compatible and all the pitfalls that happen while emerging fast its very likely that a potential application that also tries to make use of the driver modules just brings its own probably incompatible llvm version in some way. So shielding this in any way makes sense ... For the Mesa wrappers: I have attached a shell script again as a rapid proof that is able to build a linker script that builds up a wrapper shared library that contains a private llvm copy. That's again non optimal - it contains just all static libs that I have in my current test environment... It's just to sketch how this could work. The MesaLLVM-with-prefix.link script can by used with the command g++ -shared -o libMesaLLVM.so MesaLLVM-with-prefix.link to produce a libMesaLLVM.so that contains all C symbols starting with LLVM from libLLVMCore.a. All of them get prefixed with Mesa and are the only exported symbols then. That's close to Joses suggestion but with less work to be done in sources. The MesaLLVM-with-version.link script can by used with the command g++ -shared -o libMesaLLVM.so MesaLLVM-with-version.link to produce a libMesaLLVM.so shared library that uses symbol versioning to distinguish between the llvm versions. I got this idea yesterday and this might simplify the problem a lot. By this variant we do not even need to prefix all the callers by Mesa. What this does is to explicitly assign a symbol version to all these calls. At static link symbol resolve time with this libMesaLLVM.so, this symbol version (the 'A MesaLLVM_1.0' entry) is then pulled out of this shared object and all users, in libllvmradeon.so for example, are linked against LLVMCreateContext@MesaLLVM_1,0 instead of just LLVMCreateContext. So we should get a private copy of llvm in libMesaLLVM.so with just the same call names than usual source code wise. That's to be tested and verified, but if this works like I think it should, this is the easiest way to get our own LLVM version on linux at least. And sorry for just doing these crude proof of concept stuff ... Greetings Mathias mklinkerscript.sh Description: application/shellscript /* Mesa llvm linker script */ EXTERN( LLVMAddAlias LLVMAddAttribute LLVMAddCase LLVMAddClause LLVMAddDestination LLVMAddFunction LLVMAddFunctionAttr LLVMAddGlobal LLVMAddGlobalInAddressSpace LLVMAddIncoming LLVMAddInstrAttribute LLVMAddNamedMetadataOperand LLVMAddTargetDependentFunctionAttr LLVMAlignOf LLVMAppendBasicBlock LLVMAppendBasicBlockInContext LLVMArrayType LLVMBasicBlockAsValue LLVMBlockAddress LLVMBuildAdd LLVMBuildAggregateRet LLVMBuildAlloca LLVMBuildAnd LLVMBuildArrayAlloca LLVMBuildArrayMalloc LLVMBuildAShr LLVMBuildAtomicRMW LLVMBuildBinOp LLVMBuildBitCast LLVMBuildBr LLVMBuildCall LLVMBuildCast LLVMBuildCondBr LLVMBuildExactSDiv LLVMBuildExtractElement LLVMBuildExtractValue LLVMBuildFAdd LLVMBuildFCmp LLVMBuildFDiv LLVMBuildFMul LLVMBuildFNeg LLVMBuildFPCast LLVMBuildFPExt LLVMBuildFPToSI LLVMBuildFPToUI LLVMBuildFPTrunc LLVMBuildFree LLVMBuildFRem LLVMBuildFSub LLVMBuildGEP LLVMBuildGlobalString LLVMBuildGlobalStringPtr LLVMBuildICmp LLVMBuildInBoundsGEP LLVMBuildIndirectBr LLVMBuildInsertElement LLVMBuildInsertValue LLVMBuildIntCast LLVMBuildIntToPtr LLVMBuildInvoke LLVMBuildIsNotNull LLVMBuildIsNull LLVMBuildLandingPad LLVMBuildLoad LLVMBuildLShr LLVMBuildMalloc LLVMBuildMul LLVMBuildNeg LLVMBuildNot LLVMBuildNSWAdd LLVMBuildNSWMul LLVMBuildNSWNeg LLVMBuildNSWSub LLVMBuildNUWAdd LLVMBuildNUWMul LLVMBuildNUWNeg LLVMBuildNUWSub LLVMBuildOr LLVMBuildPhi LLVMBuildPointerCast LLVMBuildPtrDiff LLVMBuildPtrToInt LLVMBuildResume LLVMBuildRet LLVMBuildRetVoid LLVMBuildSDiv LLVMBuildSelect LLVMBuildSExt LLVMBuildSExtOrBitCast LLVMBuildShl LLVMBuildShuffleVector LLVMBuildSIToFP LLVMBuildSRem LLVMBuildStore LLVMBuildStructGEP LLVMBuildSub LLVMBuildSwitch LLVMBuildTrunc LLVMBuildTruncOrBitCast LLVMBuildUDiv LLVMBuildUIToFP LLVMBuildUnreachable LLVMBuildURem LLVMBuildVAArg LLVMBuildXor LLVMBuildZExt LLVMBuildZExtOrBitCast LLVMClearInsertionPosition LLVMConstAdd LLVMConstAllOnes LLVMConstAnd LLVMConstArray LLVMConstAShr LLVMConstBitCast LLVMConstExactSDiv LLVMConstExtractElement LLVMConstExtractValue LLVMConstFAdd LLVMConstFCmp LLVMConstFDiv LLVMConstFMul LLVMConstFNeg LLVMConstFPCast LLVMConstFPExt LLVMConstFPToSI LLVMConstFPToUI LLVMConstF
Re: [Mesa-dev] [PATCH V2 9.1] i965/vs: Fix Gen4/5 VUE map inconsistency with gl_ClipVertex
With the fixed version of the first patch, plus the second;
- No piglit regressions on Ironlake.
- Fixes 4 piglits: EXT_framebuffer_multisample/interpolation 0 centroid-*
On Sat, Apr 27, 2013 at 7:36 PM, Jordan Justen wrote:
> Reviewed-by: Jordan Justen
> Tested-by: Jordan Justen
>
> I tested steam and a few games, and it seems good. On one generally
> problematic (non-Valve) TF2 map, I did see some vertex location
> issues. I don't suspect these are introduced by this patch.
>
> Since this is for the stable branch, please verify that there are no
> piglit regressions. I kind of hope we might get another r-b too.
>
> On Fri, Apr 26, 2013 at 11:56 PM, Chris Forbes wrote:
>> This is roughly a backport of Eric's commit 0967c362.
>>
>> We avoided assigning a slot in the VUE map for gl_ClipVertex, but left
>> the bit set in outputs_written, producing horrible confusion further
>> down the pipe.
>>
>> Mostly fixes rendering in source games, and probably in Freespace 2 SCP.
>>
>> Signed-off-by: Chris Forbes
>>
>> V2: Mask out the bit, not its index. Strangely, the game still worked
>> with that wrong, but rendering of pretty much anything else was
>> completely trashed.
>> ---
>> src/mesa/drivers/dri/i965/brw_vs.c | 8 +---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_vs.c
>> b/src/mesa/drivers/dri/i965/brw_vs.c
>> index 0810471..0234ebb 100644
>> --- a/src/mesa/drivers/dri/i965/brw_vs.c
>> +++ b/src/mesa/drivers/dri/i965/brw_vs.c
>> @@ -62,9 +62,13 @@ brw_compute_vue_map(struct brw_context *brw, struct
>> brw_vs_compile *c)
>> {
>> const struct intel_context *intel = &brw->intel;
>> struct brw_vue_map *vue_map = &c->prog_data.vue_map;
>> - GLbitfield64 outputs_written = c->prog_data.outputs_written;
>> + GLbitfield64 outputs_written;
>> int i;
>>
>> + if (intel->gen < 6)
>> + c->prog_data.outputs_written &=
>> ~BITFIELD64_BIT(VERT_RESULT_CLIP_VERTEX);
>> + outputs_written = c->prog_data.outputs_written;
>> +
>> vue_map->num_slots = 0;
>> for (i = 0; i < BRW_VERT_RESULT_MAX; ++i) {
>>vue_map->vert_result_to_slot[i] = -1;
>> @@ -150,8 +154,6 @@ brw_compute_vue_map(struct brw_context *brw, struct
>> brw_vs_compile *c)
>> * feedback is enabled or disabled, just go ahead and assign a slot for
>> it.
>> */
>> for (int i = 0; i < VERT_RESULT_MAX; ++i) {
>> - if (intel->gen < 6 && i == VERT_RESULT_CLIP_VERTEX)
>> - continue;
>>if ((outputs_written & BITFIELD64_BIT(i)) &&
>>vue_map->vert_result_to_slot[i] == -1) {
>> assign_vue_slot(vue_map, i);
>> --
>> 1.8.2.1
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] renaming i965g
Hi Chris, On Fri, Apr 26, 2013 at 5:42 PM, Chris Wilson wrote: > On Fri, Apr 26, 2013 at 04:26:05PM +0800, Chia-I Wu wrote: >> I just pushed the driver to master, under the name ilo. The driver is >> still new and has many bugs or known issues, but I will continue >> improving it. > > FYI, you can use: > > Section "Device" > Identifier "Device0" > Driver "Intel" > Option "DRI" "ilo" > EndSection > > to use your new driver without having to rename existing dri.so. Thanks for the tip. It is helpful. > > Hope that helps, > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: mask unused source components for SAMPLE
Reviewed-by: Marek Olšák
This looks incomplete though. There are a lot more texture opcodes and
texture targets which could be handled there as well.
Marek
On Sat, Apr 27, 2013 at 10:29 AM, Vadim Girlin wrote:
> This results in more clean shader code and may improve the quality of
> optimized code produced by r600-sb due to eliminated false dependencies
> in some cases.
>
> Signed-off-by: Vadim Girlin
> ---
>
> There are no piglit regressions with this patch on evergreen.
>
> I consider this as a prerequisite for r600-sb branch, it fixes the performance
> regression with optimized shaders uncovered by some recent changes to tgsi
> and/or r600 codegen.
>
> If there are no objections or new suggestions, is it OK to push the latest
> version of r600-sb-2 branch [1] that includes this patch?
>
> The changes in the branch after the recent mail include 3 additional patches
> to improve handling of some corner cases (they fix some issues reported on
> IRC),
> also they add switching to unoptimized code in case of possible internal
> optimization problems, and new option "sbnofallback" for R600_DEBUG to disable
> such fallback.
>
> Vadim
>
> [1] http://cgit.freedesktop.org/~vadimg/mesa/log/?h=r600-sb-2
>
> src/gallium/drivers/r600/r600_shader.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/src/gallium/drivers/r600/r600_shader.c
> b/src/gallium/drivers/r600/r600_shader.c
> index 0204f80..aa88252 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -4739,6 +4739,26 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
> /* the array index is read from Z */
> tex.coord_type_z = 0;
>
> + /* mask unused source components */
> + if (opcode == FETCH_OP_SAMPLE) {
> + switch (inst->Texture.Texture) {
> + case TGSI_TEXTURE_2D:
> + case TGSI_TEXTURE_RECT:
> + tex.src_sel_z = 7;
> + tex.src_sel_w = 7;
> + break;
> + case TGSI_TEXTURE_1D_ARRAY:
> + tex.src_sel_y = 7;
> + tex.src_sel_w = 7;
> + break;
> + case TGSI_TEXTURE_1D:
> + tex.src_sel_y = 7;
> + tex.src_sel_z = 7;
> + tex.src_sel_w = 7;
> + break;
> + }
> + }
> +
> r = r600_bytecode_add_tex(ctx->bc, &tex);
> if (r)
> return r;
> --
> 1.8.2.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: mask unused source components for SAMPLE
On 04/27/2013 02:53 PM, Marek Olšák wrote:
Reviewed-by: Marek Olšák
This looks incomplete though. There are a lot more texture opcodes and
texture targets which could be handled there as well.
Yes, this patch handles most trivial cases, though I think they are most
frequently used cases as well. Also it covers all known to me cases
where it caused problems for optimization.
I'll look into other cases later - they are more complex, so there is
more chances to break something (I'm not sure about piglit coverage for
this), and IIRC many of them either actually use all components of
source register or modify the swizzles in such a way that there is no
unused components, e.g. xyzz with SHADOW2D/SAMPLE_C.
Vadim
Marek
On Sat, Apr 27, 2013 at 10:29 AM, Vadim Girlin wrote:
This results in more clean shader code and may improve the quality of
optimized code produced by r600-sb due to eliminated false dependencies
in some cases.
Signed-off-by: Vadim Girlin
---
There are no piglit regressions with this patch on evergreen.
I consider this as a prerequisite for r600-sb branch, it fixes the performance
regression with optimized shaders uncovered by some recent changes to tgsi
and/or r600 codegen.
If there are no objections or new suggestions, is it OK to push the latest
version of r600-sb-2 branch [1] that includes this patch?
The changes in the branch after the recent mail include 3 additional patches
to improve handling of some corner cases (they fix some issues reported on IRC),
also they add switching to unoptimized code in case of possible internal
optimization problems, and new option "sbnofallback" for R600_DEBUG to disable
such fallback.
Vadim
[1] http://cgit.freedesktop.org/~vadimg/mesa/log/?h=r600-sb-2
src/gallium/drivers/r600/r600_shader.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 0204f80..aa88252 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -4739,6 +4739,26 @@ static int tgsi_tex(struct r600_shader_ctx *ctx)
/* the array index is read from Z */
tex.coord_type_z = 0;
+ /* mask unused source components */
+ if (opcode == FETCH_OP_SAMPLE) {
+ switch (inst->Texture.Texture) {
+ case TGSI_TEXTURE_2D:
+ case TGSI_TEXTURE_RECT:
+ tex.src_sel_z = 7;
+ tex.src_sel_w = 7;
+ break;
+ case TGSI_TEXTURE_1D_ARRAY:
+ tex.src_sel_y = 7;
+ tex.src_sel_w = 7;
+ break;
+ case TGSI_TEXTURE_1D:
+ tex.src_sel_y = 7;
+ tex.src_sel_z = 7;
+ tex.src_sel_w = 7;
+ break;
+ }
+ }
+
r = r600_bytecode_add_tex(ctx->bc, &tex);
if (r)
return r;
--
1.8.2.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 9.1] i965/vs: Fix Gen4/5 VUE map inconsistency with gl_ClipVertex
On 04/27/2013 12:36 AM, Jordan Justen wrote: Reviewed-by: Jordan Justen Tested-by: Jordan Justen I tested steam and a few games, and it seems good. On one generally problematic (non-Valve) TF2 map, I did see some vertex location issues. I don't suspect these are introduced by this patch. Since this is for the stable branch, please verify that there are no piglit regressions. I kind of hope we might get another r-b too. Here, have another r-b :) Reviewed-by: Kenneth Graunke Looks reasonable to me. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] glsl: Add ir_binop_vector_extract
On 04/08/2013 03:24 PM, Ian Romanick wrote:
From: Ian Romanick
The new opcode is used to get a single field from a vector. The field
index may not be constant. This will eventually replace
ir_dereference_array of vectors. This is similar to the extractelement
instruction in LLVM IR.
http://llvm.org/docs/LangRef.html#extractelement-instruction
Signed-off-by: Ian Romanick
---
src/glsl/ir.cpp | 5 +
src/glsl/ir.h | 10 +-
src/glsl/ir_constant_expression.cpp | 35 ---
src/glsl/ir_validate.cpp| 6 ++
src/mesa/program/ir_to_mesa.cpp | 1 +
5 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index 05b77da..f4596db 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -399,6 +399,10 @@ ir_expression::ir_expression(int op, ir_rvalue *op0,
ir_rvalue *op1)
this->type = op0->type;
break;
+ case ir_binop_vector_extract:
+ this->type = op0->type->get_scalar_type();
+ break;
+
default:
assert(!"not reached: missing automatic type setup for ir_expression");
this->type = glsl_type::float_type;
@@ -505,6 +509,7 @@ static const char *const operator_strs[] = {
"pow",
"packHalf2x16_split",
"ubo_load",
+ "vector_extract",
"lrp",
"vector",
};
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 0c3e399..4da54fc 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -1115,9 +1115,17 @@ enum ir_expression_operation {
ir_binop_ubo_load,
/**
+* Extract a scalar from a vector
+*
+* operand0 is the vector
+* operand1 is the index of the field to read from operand0
+*/
+ ir_binop_vector_extract,
+
+ /**
* A sentinel marking the last of the binary operations.
*/
- ir_last_binop = ir_binop_ubo_load,
+ ir_last_binop = ir_binop_vector_extract,
ir_triop_lrp,
diff --git a/src/glsl/ir_constant_expression.cpp
b/src/glsl/ir_constant_expression.cpp
index c09e56a..e802e6c 100644
--- a/src/glsl/ir_constant_expression.cpp
+++ b/src/glsl/ir_constant_expression.cpp
@@ -391,9 +391,16 @@ ir_expression::constant_expression_value(struct hash_table
*variable_context)
}
if (op[1] != NULL)
- assert(op[0]->type->base_type == op[1]->type->base_type ||
-this->operation == ir_binop_lshift ||
-this->operation == ir_binop_rshift);
+ switch (this->operation) {
+ case ir_binop_lshift:
+ case ir_binop_rshift:
+ case ir_binop_vector_extract:
+break;
+
+ default:
+assert(op[0]->type->base_type == op[1]->type->base_type);
+break;
+ }
bool op0_scalar = op[0]->type->is_scalar();
bool op1_scalar = op[1] != NULL && op[1]->type->is_scalar();
@@ -1230,6 +1237,28 @@ ir_expression::constant_expression_value(struct
hash_table *variable_context)
}
break;
+ case ir_binop_vector_extract: {
+ const int c = op[1]->value.i[0];
Shouldn't we bounds check 'c' here? Otherwise you could walk off the
end of the array and crash. Undefined behavior is fine (pick some
random element), but crashing is bad.
Otherwise patch 1 looks good...
Reviewed-by: Kenneth Graunke
+ switch (op[0]->type->base_type) {
+ case GLSL_TYPE_UINT:
+data.u[0] = op[0]->value.u[c];
+break;
+ case GLSL_TYPE_INT:
+data.i[0] = op[0]->value.i[c];
+break;
+ case GLSL_TYPE_FLOAT:
+data.f[0] = op[0]->value.f[c];
+break;
+ case GLSL_TYPE_BOOL:
+data.b[0] = op[0]->value.b[c];
+break;
+ default:
+assert(0);
+ }
+ break;
+ }
+
case ir_binop_bit_xor:
for (unsigned c = 0, c0 = 0, c1 = 0;
c < components;
diff --git a/src/glsl/ir_validate.cpp b/src/glsl/ir_validate.cpp
index 699c192..83519cf 100644
--- a/src/glsl/ir_validate.cpp
+++ b/src/glsl/ir_validate.cpp
@@ -468,6 +468,12 @@ ir_validate::visit_leave(ir_expression *ir)
assert(ir->operands[1]->type == glsl_type::uint_type);
break;
+ case ir_binop_vector_extract:
+ assert(ir->operands[0]->type->is_vector());
+ assert(ir->operands[1]->type->is_scalar()
+&& ir->operands[1]->type->is_integer());
+ break;
+
case ir_triop_lrp:
assert(ir->operands[0]->type->base_type == GLSL_TYPE_FLOAT);
assert(ir->operands[0]->type == ir->operands[1]->type);
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 14cf5ba..7d351c0 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -1485,6 +1485,7 @@ ir_to_mesa_visitor::visit(ir_expression *ir)
emit(ir, OPCODE_LRP, result_dst, op[2], op[1], op[0]);
break;
+ case ir_binop_vector_extract:
case ir_quadop_vector:
/* This operation should have already been handled.
*/
___
m
Re: [Mesa-dev] [PATCH] mesa: Make Haiku use mmap vs simple malloc for exec memory
Seems fine to me. Though you might also want to update src/gallium/auxiliary/rtasm/rtasm_execmem.c while you're at it. Jose - Original Message - > * Haiku recently got DEP support which can result in the > OS locking down execution in non-exec flagged memory. > --- > src/mesa/main/execmem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/mesa/main/execmem.c b/src/mesa/main/execmem.c > index bb9c70a..5f31966 100644 > --- a/src/mesa/main/execmem.c > +++ b/src/mesa/main/execmem.c > @@ -37,7 +37,7 @@ > > > > -#if defined(__linux__) || defined(__OpenBSD__) || defined(_NetBSD__) || > defined(__sun) > +#if defined(__linux__) || defined(__OpenBSD__) || defined(_NetBSD__) || > defined(__sun) || defined(__HAIKU__) > > /* > * Allocate a large block of memory which can hold code then dole it out > -- > 1.8.2.1 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: Fix altivec intrinsics for 8xi16 add/sub
Looks good to me. Jose - Original Message - > Signed-off-by: Adam Jackson > --- > src/gallium/auxiliary/gallivm/lp_bld_arit.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c > b/src/gallium/auxiliary/gallivm/lp_bld_arit.c > index ec05026..524a8e7 100644 > --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c > +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c > @@ -378,7 +378,7 @@ lp_build_add(struct lp_build_context *bld, > if(type.width == 8) >intrinsic = type.sign ? "llvm.ppc.altivec.vaddsbs" : >"llvm.ppc.altivec.vaddubs"; > if(type.width == 16) > - intrinsic = type.sign ? "llvm.ppc.altivec.vaddsws" : > "llvm.ppc.altivec.vadduws"; > + intrinsic = type.sign ? "llvm.ppc.altivec.vaddshs" : > "llvm.ppc.altivec.vadduhs"; > } >} > > @@ -655,7 +655,7 @@ lp_build_sub(struct lp_build_context *bld, > if(type.width == 8) >intrinsic = type.sign ? "llvm.ppc.altivec.vsubsbs" : >"llvm.ppc.altivec.vsububs"; > if(type.width == 16) > - intrinsic = type.sign ? "llvm.ppc.altivec.vsubsws" : > "llvm.ppc.altivec.vsubuws"; > + intrinsic = type.sign ? "llvm.ppc.altivec.vsubshs" : > "llvm.ppc.altivec.vsubuhs"; > } >} > > -- > 1.8.2 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] llvmpipe: stop crashing when one of the so targets is null
- Original Message -
> Fixes a crash when one of the so targets is null.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/drivers/llvmpipe/lp_draw_arrays.c |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
> b/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
> index e8a5880..fc947b1 100644
> --- a/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
> +++ b/src/gallium/drivers/llvmpipe/lp_draw_arrays.c
> @@ -89,8 +89,11 @@ llvmpipe_draw_vbo(struct pipe_context *pipe, const struct
> pipe_draw_info *info)
> }
>
> for (i = 0; i < lp->num_so_targets; i++) {
> - void *buf = llvmpipe_resource(lp->so_targets[i]->target.buffer)->data;
> - lp->so_targets[i]->mapping = buf;
> + void *buf = 0;
> + if (lp->so_targets[i]) {
> + buf = llvmpipe_resource(lp->so_targets[i]->target.buffer)->data;
> + lp->so_targets[i]->mapping = buf;
> + }
> }
> draw_set_mapped_so_targets(draw, lp->num_so_targets,
>lp->so_targets);
> --
> 1.7.10.4
>
Series is
Reviewed-by: Jose Fonseca
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/3] AMD_vertex_shader_layer extension
This series adds the AMD_vertex_shader_layer extension, and enables intel drivers to set the layer in the VUE if gl_Layer has been written in the vertex shader. Note: there will be more patch series required before the i965 driver will be able to enable the AMD_vertex_shader_layer. In addition, this extension depends on glFramebufferLayer which is added in GL 3.2, or with ARB_geometry_shader4. These patches are available within the amd_vertex_shader_layer branch of git://people.freedesktop.org/~jljusten/mesa. Jordan Justen (3): extensions: add AMD_vertex_shader_layer glsl: add AMD_vertex_shader_layer support i965: write layer if gl_Layer is used in VS src/glsl/builtin_variables.cpp | 31 src/glsl/glsl_parser_extras.cpp|1 + src/glsl/glsl_parser_extras.h |2 ++ src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |4 +++ src/mesa/main/extensions.c |1 + src/mesa/main/mtypes.h |3 ++- 6 files changed, 41 insertions(+), 1 deletion(-) -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] extensions: add AMD_vertex_shader_layer
This extension will require driver support, so it must
be enabled by the driver.
http://www.opengl.org/registry/specs/AMD/vertex_shader_layer.txt
Signed-off-by: Jordan Justen
---
src/mesa/main/extensions.c |1 +
src/mesa/main/mtypes.h |3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 64473b9..c7dfbf9 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -286,6 +286,7 @@ static const struct extension extension_table[] = {
{ "GL_AMD_draw_buffers_blend", o(ARB_draw_buffers_blend),
GL, 2009 },
{ "GL_AMD_seamless_cubemap_per_texture",
o(AMD_seamless_cubemap_per_texture),GL, 2009 },
{ "GL_AMD_shader_stencil_export",
o(ARB_shader_stencil_export), GL, 2009 },
+ { "GL_AMD_vertex_shader_layer", o(AMD_vertex_shader_layer),
GL, 2012 },
{ "GL_APPLE_object_purgeable", o(APPLE_object_purgeable),
GL, 2006 },
{ "GL_APPLE_packed_pixels", o(dummy_true),
GLL,2002 },
{ "GL_APPLE_texture_max_level", o(dummy_true),
ES1 | ES2, 2009 },
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 1d12809..1976e1c 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -230,7 +230,7 @@ typedef enum
VARYING_SLOT_CLIP_DIST0,
VARYING_SLOT_CLIP_DIST1,
VARYING_SLOT_PRIMITIVE_ID, /* Does not appear in VS */
- VARYING_SLOT_LAYER, /* Appears only as GS output */
+ VARYING_SLOT_LAYER, /* Appears as VS or GS output */
VARYING_SLOT_FACE, /* FS only */
VARYING_SLOT_PNTC, /* FS only */
VARYING_SLOT_VAR0, /* First generic varying slot */
@@ -3051,6 +3051,7 @@ struct gl_extensions
GLboolean OES_standard_derivatives;
/* vendor extensions */
GLboolean AMD_seamless_cubemap_per_texture;
+ GLboolean AMD_vertex_shader_layer;
GLboolean APPLE_object_purgeable;
GLboolean ATI_envmap_bumpmap;
GLboolean ATI_texture_compression_3dc;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] glsl: add AMD_vertex_shader_layer support
This GLSL extension requires that AMD_vertex_shader_layer be
enabled by the driver.
Signed-off-by: Jordan Justen
---
src/glsl/builtin_variables.cpp | 31 +++
src/glsl/glsl_parser_extras.cpp |1 +
src/glsl/glsl_parser_extras.h |2 ++
3 files changed, 34 insertions(+)
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index b0c7a20..098c3f1 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -39,6 +39,12 @@ generate_ARB_draw_instanced_variables(exec_list *,
struct _mesa_glsl_parse_state *,
bool, _mesa_glsl_parser_targets);
+static void
+generate_AMD_vertex_shader_layer_variables(exec_list *instructions,
+ struct _mesa_glsl_parse_state
*state,
+ bool warn,
+ _mesa_glsl_parser_targets target);
+
struct builtin_variable {
enum ir_variable_mode mode;
int slot;
@@ -818,6 +824,8 @@ generate_130_vs_variables(exec_list *instructions,
"gl_ClipDistance", clip_distance_array_type, ir_var_shader_out,
VARYING_SLOT_CLIP_DIST0);
+ generate_AMD_vertex_shader_layer_variables(instructions, state, false,
+ vertex_shader);
}
@@ -1020,6 +1028,29 @@ generate_ARB_draw_instanced_variables(exec_list
*instructions,
}
}
+static void
+generate_AMD_vertex_shader_layer_variables(exec_list *instructions,
+ struct _mesa_glsl_parse_state
*state,
+ bool warn,
+ _mesa_glsl_parser_targets target)
+{
+ /* gl_Layer is only available in the vertex shader for the
+* AMD_vertex_shader_layer extension. It will also be available in the
+* geometry shader when GLSL 1.50 is supported.
+*/
+ if (target != vertex_shader)
+ return;
+
+ if (state->AMD_vertex_shader_layer_enable) {
+ ir_variable *inst =
+ add_variable(instructions, state->symbols,
+ "gl_Layer", glsl_type::int_type,
+ ir_var_shader_out, VARYING_SLOT_LAYER);
+
+ if (warn)
+ inst->warn_extension = "GL_AMD_vertex_shader_layer";
+ }
+}
static void
generate_ARB_shader_stencil_export_variables(exec_list *instructions,
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 0992294..e419264 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -468,6 +468,7 @@ static const _mesa_glsl_extension
_mesa_glsl_supported_extensions[] = {
EXT(ARB_shading_language_packing, true, false, true, true, false,
ARB_shading_language_packing),
EXT(ARB_texture_multisample,true, false, true, true, false,
ARB_texture_multisample),
EXT(ARB_texture_query_lod, false, false, true, true, false,
ARB_texture_query_lod),
+ EXT(AMD_vertex_shader_layer,true, false, false, true, false,
AMD_vertex_shader_layer),
};
#undef EXT
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index 95891b5..3386365 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -284,6 +284,8 @@ struct _mesa_glsl_parse_state {
bool ARB_texture_multisample_warn;
bool ARB_texture_query_lod_enable;
bool ARB_texture_query_lod_warn;
+ bool AMD_vertex_shader_layer_enable;
+ bool AMD_vertex_shader_layer_warn;
/*@}*/
/** Extensions supported by the OpenGL implementation. */
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] i965: write layer if gl_Layer is used in VS
This is enabled by the AMD_vertex_shader_layer extension.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 2fb8482..84abffd 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -2487,6 +2487,10 @@ vec4_visitor::emit_psiz_and_flags(struct brw_reg reg)
emit(MOV(brw_writemask(reg, WRITEMASK_W),
src_reg(output_reg[VARYING_SLOT_PSIZ])));
}
+ if (prog_data->vue_map.slots_valid & VARYING_BIT_LAYER) {
+ emit(MOV(retype(brw_writemask(reg, WRITEMASK_Y), BRW_REGISTER_TYPE_D),
+ src_reg(output_reg[VARYING_SLOT_LAYER])));
+ }
}
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/4] Implement glFramebufferTexture
This series adds support for the glFramebufferTexture function, which is required for GL 3.2 / ARB_geometry_shader4. These patches are available within the amd_vertex_shader_layer branch of git://people.freedesktop.org/~jljusten/mesa. Jordan Justen (4): mesa: add renderbuffer Depth field mesa: add renderbuffer attachment Layered field mesa: add Layered field to framebuffers mesa: implement glFramebufferTexture src/mapi/glapi/gen/GL3x.xml |2 +- src/mesa/main/fbobject.c | 53 -- src/mesa/main/fbobject.h |7 +- src/mesa/main/mtypes.h |4 src/mesa/main/renderbuffer.c |1 + 5 files changed, 58 insertions(+), 9 deletions(-) -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] mesa: add renderbuffer Depth field
With glFramebufferTexture, a renderbuffer may support all layers of the texture, so we need the depth of the renderbuffer to check for consistency which is required for framebuffer completeness. Signed-off-by: Jordan Justen --- src/mesa/main/mtypes.h |1 + src/mesa/main/renderbuffer.c |1 + 2 files changed, 2 insertions(+) diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index 1976e1c..3cc4409 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -2565,6 +2565,7 @@ struct gl_renderbuffer GLuint Name; GLint RefCount; GLuint Width, Height; + GLuint Depth; GLboolean Purgeable; /**< Is the buffer purgeable under memory pressure? */ GLboolean AttachedAnytime; /**< TRUE if it was attached to a framebuffer */ GLubyte NumSamples; diff --git a/src/mesa/main/renderbuffer.c b/src/mesa/main/renderbuffer.c index b426162..d458609 100644 --- a/src/mesa/main/renderbuffer.c +++ b/src/mesa/main/renderbuffer.c @@ -52,6 +52,7 @@ _mesa_init_renderbuffer(struct gl_renderbuffer *rb, GLuint name) rb->Width = 0; rb->Height = 0; + rb->Depth = 0; rb->InternalFormat = GL_RGBA; rb->Format = MESA_FORMAT_NONE; } -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] mesa: add renderbuffer attachment Layered field
If glFramebufferTexture is used, then the framebuffer attachment is
layered.
Signed-off-by: Jordan Justen
---
src/mesa/main/fbobject.c | 16 +---
src/mesa/main/fbobject.h |3 ++-
src/mesa/main/mtypes.h |1 +
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 6560408..ce1cb0e 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -350,7 +350,8 @@ _mesa_set_texture_attachment(struct gl_context *ctx,
struct gl_framebuffer *fb,
struct gl_renderbuffer_attachment *att,
struct gl_texture_object *texObj,
- GLenum texTarget, GLuint level, GLuint zoffset)
+ GLenum texTarget, GLuint level, GLuint zoffset,
+ GLboolean layered)
{
if (att->Texture == texObj) {
/* re-attaching same texture */
@@ -372,6 +373,7 @@ _mesa_set_texture_attachment(struct gl_context *ctx,
att->TextureLevel = level;
att->CubeMapFace = _mesa_tex_target_to_face(texTarget);
att->Zoffset = zoffset;
+ att->Layered = layered;
att->Complete = GL_FALSE;
if (_mesa_get_attachment_teximage(att)) {
@@ -2102,7 +2104,7 @@ reuse_framebuffer_texture_attachment(struct
gl_framebuffer *fb,
static void
framebuffer_texture(struct gl_context *ctx, const char *caller, GLenum target,
GLenum attachment, GLenum textarget, GLuint texture,
-GLint level, GLint zoffset)
+GLint level, GLint zoffset, GLboolean layered)
{
struct gl_renderbuffer_attachment *att;
struct gl_texture_object *texObj = NULL;
@@ -2229,7 +2231,7 @@ framebuffer_texture(struct gl_context *ctx, const char
*caller, GLenum target,
BUFFER_DEPTH);
} else {
_mesa_set_texture_attachment(ctx, fb, att, texObj, textarget,
- level, zoffset);
+ level, zoffset, layered);
if (attachment == GL_DEPTH_STENCIL_ATTACHMENT) {
/* Above we created a new renderbuffer and attached it to the
* depth attachment point. Now attach it to the stencil attachment
@@ -2295,7 +2297,7 @@ _mesa_FramebufferTexture1D(GLenum target, GLenum
attachment,
}
framebuffer_texture(ctx, "1D", target, attachment, textarget, texture,
- level, 0);
+ level, 0, GL_FALSE);
}
@@ -2346,7 +2348,7 @@ _mesa_FramebufferTexture2D(GLenum target, GLenum
attachment,
}
framebuffer_texture(ctx, "2D", target, attachment, textarget, texture,
- level, 0);
+ level, 0, GL_FALSE);
}
@@ -2364,7 +2366,7 @@ _mesa_FramebufferTexture3D(GLenum target, GLenum
attachment,
}
framebuffer_texture(ctx, "3D", target, attachment, textarget, texture,
- level, zoffset);
+ level, zoffset, GL_FALSE);
}
@@ -2375,7 +2377,7 @@ _mesa_FramebufferTextureLayer(GLenum target, GLenum
attachment,
GET_CURRENT_CONTEXT(ctx);
framebuffer_texture(ctx, "Layer", target, attachment, 0, texture,
- level, layer);
+ level, layer, GL_FALSE);
}
diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h
index 0358864..ba013fd 100644
--- a/src/mesa/main/fbobject.h
+++ b/src/mesa/main/fbobject.h
@@ -98,7 +98,8 @@ _mesa_set_texture_attachment(struct gl_context *ctx,
struct gl_framebuffer *fb,
struct gl_renderbuffer_attachment *att,
struct gl_texture_object *texObj,
- GLenum texTarget, GLuint level, GLuint zoffset);
+ GLenum texTarget, GLuint level, GLuint zoffset,
+ GLboolean layered);
extern void
_mesa_set_renderbuffer_attachment(struct gl_context *ctx,
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 3cc4409..eb8ec3a 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2609,6 +2609,7 @@ struct gl_renderbuffer_attachment
GLuint CubeMapFace; /**< 0 .. 5, for cube map textures. */
GLuint Zoffset; /**< Slice for 3D textures, or layer for both 1D
* and 2D array textures */
+ GLboolean Layered;
};
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] mesa: add Layered field to framebuffers
When checking framebuffer completeness, we test each attachment.
We verify that all attachments are consistent in terms of layers.
1. They must all be layered, or all non-layered
2. If they are layered, they must match in depth
Signed-off-by: Jordan Justen
---
src/mesa/main/fbobject.c | 20
src/mesa/main/mtypes.h |2 ++
2 files changed, 22 insertions(+)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index ce1cb0e..419e871 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -776,6 +776,8 @@ _mesa_test_framebuffer_completeness(struct gl_context *ctx,
GLint fixedSampleLocations = -1;
GLint i;
GLuint j;
+ bool layer_count_valid = false;
+ GLuint layer_count = 0, att_layer_count;
assert(_mesa_is_user_fbo(fb));
@@ -948,8 +950,26 @@ _mesa_test_framebuffer_completeness(struct gl_context *ctx,
fbo_incomplete("unsupported renderbuffer format", i);
return;
}
+
+ /* Check that layered rendering is consistent. */
+ att_layer_count = att->Layered ? att->Renderbuffer->Depth : 0;
+ if (!layer_count_valid) {
+ layer_count = att_layer_count;
+ layer_count_valid = true;
+ } else if (layer_count != att_layer_count) {
+ if (layer_count == 0 || att_layer_count == 0) {
+fb->_Status = GL_FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS;
+fbo_incomplete("framebuffer attachment layer mode is
inconsistent", i);
+ } else {
+fb->_Status = GL_FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_ARB;
+fbo_incomplete("framebuffer attachment layer count is
inconsistent", i);
+ }
+ return;
+ }
}
+ fb->Layered = layer_count > 0;
+
if (_mesa_is_desktop_gl(ctx) && !ctx->Extensions.ARB_ES2_compatibility) {
/* Check that all DrawBuffers are present */
for (j = 0; j < ctx->Const.MaxDrawBuffers; j++) {
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index eb8ec3a..fd8a7b1 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2682,6 +2682,8 @@ struct gl_framebuffer
struct gl_renderbuffer *_ColorDrawBuffers[MAX_DRAW_BUFFERS];
struct gl_renderbuffer *_ColorReadBuffer;
+ GLboolean Layered;
+
/** Delete this framebuffer */
void (*Delete)(struct gl_framebuffer *fb);
};
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] mesa: implement glFramebufferTexture
Signed-off-by: Jordan Justen
---
src/mapi/glapi/gen/GL3x.xml |2 +-
src/mesa/main/fbobject.c| 17 +
src/mesa/main/fbobject.h|4
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/mapi/glapi/gen/GL3x.xml b/src/mapi/glapi/gen/GL3x.xml
index 9ca3d47..5078f7b 100644
--- a/src/mapi/glapi/gen/GL3x.xml
+++ b/src/mapi/glapi/gen/GL3x.xml
@@ -607,7 +607,7 @@
-
+
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 419e871..32dcc75 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2402,6 +2402,23 @@ _mesa_FramebufferTextureLayer(GLenum target, GLenum
attachment,
void GLAPIENTRY
+_mesa_FramebufferTexture(GLenum target, GLenum attachment,
+ GLuint texture, GLint level)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ if ((_mesa_is_desktop_gl(ctx) && ctx->Version >= 32) ||
+ ctx->Extensions.ARB_geometry_shader4) {
+ framebuffer_texture(ctx, "Layer", target, attachment, 0, texture,
+ level, 0, GL_TRUE);
+ } else {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "unsupported function (glFramebufferTexture) called");
+ }
+}
+
+
+void GLAPIENTRY
_mesa_FramebufferRenderbuffer(GLenum target, GLenum attachment,
GLenum renderbufferTarget,
GLuint renderbuffer)
diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h
index ba013fd..2d88001 100644
--- a/src/mesa/main/fbobject.h
+++ b/src/mesa/main/fbobject.h
@@ -192,6 +192,10 @@ _mesa_FramebufferTextureLayer(GLenum target, GLenum
attachment,
GLuint texture, GLint level, GLint layer);
extern void GLAPIENTRY
+_mesa_FramebufferTexture(GLenum target, GLenum attachment,
+ GLuint texture, GLint level);
+
+extern void GLAPIENTRY
_mesa_FramebufferRenderbuffer(GLenum target, GLenum attachment,
GLenum renderbuffertarget,
GLuint renderbuffer);
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/12] glsl: Lower ir_binop_vector_extract to swizzle
On 04/08/2013 03:24 PM, Ian Romanick wrote:
From: Ian Romanick
Lower ir_binop_vector_extract with a constant index to a swizzle. This
is exactly like ir_dereference_array of a vector with a constant index.
Signed-off-by: Ian Romanick
---
src/glsl/lower_vec_index_to_swizzle.cpp | 45 +
1 file changed, 45 insertions(+)
diff --git a/src/glsl/lower_vec_index_to_swizzle.cpp
b/src/glsl/lower_vec_index_to_swizzle.cpp
index 264d6dc..ad09dd2 100644
--- a/src/glsl/lower_vec_index_to_swizzle.cpp
+++ b/src/glsl/lower_vec_index_to_swizzle.cpp
@@ -47,6 +47,7 @@ public:
}
ir_rvalue *convert_vec_index_to_swizzle(ir_rvalue *val);
+ ir_rvalue *convert_vector_extract_to_swizzle(ir_rvalue *val);
virtual ir_visitor_status visit_enter(ir_expression *);
virtual ir_visitor_status visit_enter(ir_swizzle *);
@@ -98,6 +99,40 @@
ir_vec_index_to_swizzle_visitor::convert_vec_index_to_swizzle(ir_rvalue *ir)
return new(ctx) ir_swizzle(deref->array, i, 0, 0, 0, 1);
}
+ir_rvalue *
+ir_vec_index_to_swizzle_visitor::convert_vector_extract_to_swizzle(ir_rvalue
*ir)
+{
+ ir_expression *const expr = ir->as_expression();
+ if (expr == NULL || expr->operation != ir_binop_vector_extract)
+ return ir;
+
+ ir_constant *const idx = expr->operands[1]->constant_expression_value();
+ if (idx == NULL)
+ return ir;
+
+ void *ctx = ralloc_parent(ir);
+ this->progress = true;
+
+ /* Page 40 of the GLSL 1.20 spec says:
+*
+* "When indexing with non-constant expressions, behavior is undefined
+* if the index is negative, or greater than or equal to the size of
+* the vector."
+*
+* The quoted spec text mentions non-constant expressions, but this code
+* operates on constants. These constants are the result of non-constant
+* expressions that have been optimized to constants. The common case here
+* is a loop counter from an unrolled loop that is used to index a vector.
+*
+* The ir_swizzle constructor gets angry if the index is negative or too
+* large. For simplicity sake, just clamp the index to [0, size-1].
+*/
+ const int i = MIN2(MAX2(idx->value.i[0], 0),
+ ((int) expr->operands[0]->type->vector_elements - 1));
+
+ return new(ctx) ir_swizzle(expr->operands[0], i, 0, 0, 0, 1);
+}
+
ir_visitor_status
ir_vec_index_to_swizzle_visitor::visit_enter(ir_expression *ir)
{
@@ -105,6 +140,7 @@ ir_vec_index_to_swizzle_visitor::visit_enter(ir_expression
*ir)
for (i = 0; i < ir->get_num_operands(); i++) {
ir->operands[i] = convert_vec_index_to_swizzle(ir->operands[i]);
+ ir->operands[i] = convert_vector_extract_to_swizzle(ir->operands[i]);
}
return visit_continue;
@@ -127,6 +163,7 @@ ir_vec_index_to_swizzle_visitor::visit_enter(ir_assignment
*ir)
{
ir->set_lhs(convert_vec_index_to_swizzle(ir->lhs));
ir->rhs = convert_vec_index_to_swizzle(ir->rhs);
+ ir->rhs = convert_vector_extract_to_swizzle(ir->rhs);
return visit_continue;
}
@@ -140,6 +177,12 @@ ir_vec_index_to_swizzle_visitor::visit_enter(ir_call *ir)
if (new_param != param) {
param->replace_with(new_param);
+ } else {
+new_param = convert_vec_index_to_swizzle(param);
This is wrong. You want convert_vector_extract_to_swizzle(param).
Clearly, the intention is to do both, and instead you're calling the old
method twice.
+
+if (new_param != param) {
+ param->replace_with(new_param);
+}
}
}
@@ -151,6 +194,7 @@ ir_vec_index_to_swizzle_visitor::visit_enter(ir_return *ir)
{
if (ir->value) {
ir->value = convert_vec_index_to_swizzle(ir->value);
+ ir->value = convert_vector_extract_to_swizzle(ir->value);
}
return visit_continue;
@@ -160,6 +204,7 @@ ir_visitor_status
ir_vec_index_to_swizzle_visitor::visit_enter(ir_if *ir)
{
ir->condition = convert_vec_index_to_swizzle(ir->condition);
+ ir->condition = convert_vector_extract_to_swizzle(ir->condition);
return visit_continue;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/12] glsl: Refactor part of convert_vec_index_to_cond_assign
On 04/08/2013 03:24 PM, Ian Romanick wrote:
From: Ian Romanick
Use a first function that extract the vector being indexed and the index
from the deref. Call the second function that does the real work.
Coming patches will add a new ir_expression for variable indexing into a
vector. Having the lowering pass split into two functions will make it
much easier to lower the new ir_expression.
Signed-off-by: Ian Romanick
---
src/glsl/lower_vec_index_to_cond_assign.cpp | 47 ++---
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/src/glsl/lower_vec_index_to_cond_assign.cpp
b/src/glsl/lower_vec_index_to_cond_assign.cpp
index f85875f..6572cc4 100644
--- a/src/glsl/lower_vec_index_to_cond_assign.cpp
+++ b/src/glsl/lower_vec_index_to_cond_assign.cpp
@@ -53,6 +53,9 @@ public:
}
ir_rvalue *convert_vec_index_to_cond_assign(ir_rvalue *val);
+ ir_rvalue *convert_vec_index_to_cond_assign(void *mem_ctx,
+ ir_rvalue *orig_vector,
+ ir_rvalue *orig_index);
virtual ir_visitor_status visit_enter(ir_expression *);
virtual ir_visitor_status visit_enter(ir_swizzle *);
@@ -65,24 +68,15 @@ public:
};
ir_rvalue *
-ir_vec_index_to_cond_assign_visitor::convert_vec_index_to_cond_assign(ir_rvalue
*ir)
+ir_vec_index_to_cond_assign_visitor::convert_vec_index_to_cond_assign(void
*mem_ctx,
+ ir_rvalue
*orig_vector,
+ ir_rvalue
*orig_index)
{
- ir_dereference_array *orig_deref = ir->as_dereference_array();
ir_assignment *assign, *value_assign;
ir_variable *index, *var, *value;
ir_dereference *deref, *deref_value;
unsigned i;
- if (!orig_deref)
- return ir;
-
- if (orig_deref->array->type->is_matrix() ||
- orig_deref->array->type->is_array())
- return ir;
-
- void *mem_ctx = ralloc_parent(ir);
-
- assert(orig_deref->array_index->type->base_type == GLSL_TYPE_INT);
exec_list list;
@@ -92,15 +86,15 @@
ir_vec_index_to_cond_assign_visitor::convert_vec_index_to_cond_assign(ir_rvalue
ir_var_temporary);
list.push_tail(index);
deref = new(base_ir) ir_dereference_variable(index);
- assign = new(base_ir) ir_assignment(deref, orig_deref->array_index, NULL);
+ assign = new(base_ir) ir_assignment(deref, orig_index, NULL);
list.push_tail(assign);
/* Store the value inside a temp, thus avoiding matrixes duplication */
- value = new(base_ir) ir_variable(orig_deref->array->type, "vec_value_tmp",
+ value = new(base_ir) ir_variable(orig_vector->type, "vec_value_tmp",
ir_var_temporary);
list.push_tail(value);
deref_value = new(base_ir) ir_dereference_variable(value);
- value_assign = new(base_ir) ir_assignment(deref_value, orig_deref->array);
+ value_assign = new(base_ir) ir_assignment(deref_value, orig_vector);
list.push_tail(value_assign);
/* Temporary where we store whichever value we swizzle out. */
Right below this line, the code reads:
var = new(base_ir) ir_variable(ir->type, "vec_index_tmp_v",
ir_var_temporary);
which fails to compile because you removed the variable called "ir".
Please make this compile. Perhaps you want to introduce your extra
glsl_type parameter in this patch rather than patch 5?
--Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
