Re: [Mesa-dev] Version info in configs/default says 8.0.0
On Sun, May 6, 2012 at 8:47 AM, Dave Witbrodt wrote:
> I was updating my Mesa build setup, having not looked carefully at it for
> about a year, and I became confused about the version of the upstream git
> HEAD. Running 'grep -C 1 VERSION Makefile' gives me:
>
> PACKAGE_VERSION=8.1-devel
> PACKAGE_DIR = Mesa-$(PACKAGE_VERSION)
> PACKAGE_NAME = MesaLib-$(PACKAGE_VERSION)
>
> This looks right, since I know that version 8.0 was released quite some time
> ago. Running 'grep -B 4 MESA_VERSION configs/default' gives me this:
>
> # Version info
> MESA_MAJOR=8
> MESA_MINOR=0
> MESA_TINY=0
> MESA_VERSION = $(MESA_MAJOR).$(MESA_MINOR).$(MESA_TINY)
>
> I am not a developer (yet), so it's not even clear to me that the env.
> variable MESA_VERSION is even used anywhere. The only external consequences
> (that I can find) seem unimportant:
>
> $ for f in /usr/lib/x86_64-linux-gnu/pkgconfig/gl{,u}.pc; do \
> echo " File: $f"; cat "$f" | grep Version; echo; done
> File: /usr/lib/x86_64-linux-gnu/pkgconfig/gl.pc
> Version: 8.0.0
>
> File: /usr/lib/x86_64-linux-gnu/pkgconfig/glu.pc
> Version: 8.0.0
>
> Not exactly earth-shattering. I just thought I would mention it in case
> someone cares.
It's used for the legacy makefile system. I can update the numbers
but we'll probably ditch that stuff before long.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] shader_test for glsl-to-tgsi ceil bug
On 05/05/2012 06:43 AM, Christoph Bumiller wrote: Test case for the "glsl_to_tgsi: use TGSI_OPCODE_CEIL for ir_unop_ceil" patch attached. It seems to me that also testing a fractional value would be a good idea. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gallium/drivers: handle TGSI_OPCODE_CEIL
On 05/05/2012 06:41 AM, Christoph Bumiller wrote: --- src/gallium/drivers/i915/i915_fpc_translate.c | 16 src/gallium/drivers/nv30/nvfx_fragprog.c |4 src/gallium/drivers/nv30/nvfx_vertprog.c |4 3 files changed, 24 insertions(+), 0 deletions(-) Both patches look OK to me. Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Add F2I and I2F TGSI Opcodes to Radeon LLVM backend.
On Sat, May 05, 2012 at 10:19:28AM -0500, Aaron Watry wrote:
> Based on the code from llvmpipe.
> ---
> .../drivers/radeon/radeon_setup_tgsi_llvm.c| 30
>
> 1 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> index d3c493c..9f9b7cd 100644
> --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
> @@ -329,6 +329,34 @@ static void bgnloop_emit(
> ctx->loop[ctx->loop_depth - 1].endloop_block = endloop_block;
> }
>
> +/* TGSI_OPCODE_F2I */
> +static void f2i_emit(
> + const struct lp_build_tgsi_action * action,
> + struct lp_build_tgsi_context * bld_base,
> + struct lp_build_emit_data * emit_data)
> +{
> + struct gallivm_state * gallivm = bld_base->base.gallivm;
> + const struct lp_type type = bld_base->base.type;
> +
> + LLVMTypeRef int_type = lp_build_int_elem_type(gallivm, type);
int_type can be replaced with bld_base->int_bld.elem_type. You will need
to initialize bld_base->int_bld in radeon_llvm_context_init() first, though.
> + LLVMValueRef val = emit_data->args[0];
> +
> + emit_data->output[emit_data->chan] = LLVMBuildFPToSI(gallivm->builder,
> val, int_type, "");
> +}
> +
> +/* TGSI_OPCODE_I2F */
> +static void i2f_emit(
> + const struct lp_build_tgsi_action * action,
> + struct lp_build_tgsi_context * bld_base,
> + struct lp_build_emit_data * emit_data)
> +{
> + struct gallivm_state * gallivm = bld_base->base.gallivm;
> + const struct lp_type type = bld_base->base.type;
> + LLVMTypeRef fp_type = lp_build_elem_type(gallivm, type);
fp_type should be bld_base->base.elem_type instead.
> +
> + emit_data->output[emit_data->chan] = LLVMBuildSIToFP(gallivm->builder,
> emit_data->args[0], fp_type, "");
> +}
> +
> static void brk_emit(
> const struct lp_build_tgsi_action * action,
> struct lp_build_tgsi_context * bld_base,
> @@ -584,11 +612,13 @@ void radeon_llvm_context_init(struct
> radeon_llvm_context * ctx)
> bld_base->op_actions[TGSI_OPCODE_ENDLOOP].emit = endloop_emit;
> bld_base->op_actions[TGSI_OPCODE_EX2].emit = lp_build_tgsi_intrinsic;
> bld_base->op_actions[TGSI_OPCODE_EX2].intr_name = "llvm.AMDIL.exp.";
> + bld_base->op_actions[TGSI_OPCODE_F2I].emit = f2i_emit;
> bld_base->op_actions[TGSI_OPCODE_FLR].emit = lp_build_tgsi_intrinsic;
> bld_base->op_actions[TGSI_OPCODE_FLR].intr_name = "llvm.AMDGPU.floor";
> bld_base->op_actions[TGSI_OPCODE_FRC].emit = lp_build_tgsi_intrinsic;
> bld_base->op_actions[TGSI_OPCODE_FRC].intr_name =
> "llvm.AMDIL.fraction.";
> bld_base->op_actions[TGSI_OPCODE_IF].emit = if_emit;
> + bld_base->op_actions[TGSI_OPCODE_I2F].emit = i2f_emit;
> bld_base->op_actions[TGSI_OPCODE_KIL].emit = kil_emit;
> bld_base->op_actions[TGSI_OPCODE_KIL].intr_name = "llvm.AMDGPU.kill";
> bld_base->op_actions[TGSI_OPCODE_KILP].emit = lp_build_tgsi_intrinsic;
> --
> 1.7.5.4
If you resubmit with these changes, I'll commit (assuming there are no
piglit regressions).
-Tom
>
> ___
> 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: Handle TGSI_OPCODE_CEIL
On Sat, May 05, 2012 at 09:01:42PM +0200, Kai Wasserbäch wrote:
>
> Signed-off-by: Kai Wasserbäch
> ---
> This patch should enable CEIL on r600g for r600 to Evergreen. Not sure if
> Cayman's registers are already covered by the EG definitions.
The opcode for CEIL is the same on Evergreen and Cayman, so you can
enable it in cm_shader_tgsi_instruction as well.
With that change, the patch is:
Reviewed-by: Tom Stellard
>
> As I have never touched any core driver part before, please review carefully.
>
> src/gallium/drivers/r600/r600_shader.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_shader.c
> b/src/gallium/drivers/r600/r600_shader.c
> index fa29b36..4e1f6b6 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -5154,7 +5154,7 @@ static struct r600_shader_tgsi_instruction
> r600_shader_tgsi_instruction[] = {
> {80,0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
> tgsi_unsupported},
> {TGSI_OPCODE_PUSHA, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
> tgsi_unsupported},
> {TGSI_OPCODE_POPA, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
> tgsi_unsupported},
> - {TGSI_OPCODE_CEIL, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
> tgsi_unsupported},
> + {TGSI_OPCODE_CEIL, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_CEIL,
> tgsi_op2},
> {TGSI_OPCODE_I2F, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_INT_TO_FLT,
> tgsi_op2_trans},
> {TGSI_OPCODE_NOT, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOT_INT,
> tgsi_op2},
> {TGSI_OPCODE_TRUNC, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_TRUNC,
> tgsi_op2},
> @@ -5328,7 +5328,7 @@ static struct r600_shader_tgsi_instruction
> eg_shader_tgsi_instruction[] = {
> {80,0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
> tgsi_unsupported},
> {TGSI_OPCODE_PUSHA, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
> tgsi_unsupported},
> {TGSI_OPCODE_POPA, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
> tgsi_unsupported},
> - {TGSI_OPCODE_CEIL, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
> tgsi_unsupported},
> + {TGSI_OPCODE_CEIL, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_CEIL,
> tgsi_op2},
> {TGSI_OPCODE_I2F, 0,
> EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_INT_TO_FLT, tgsi_op2_trans},
> {TGSI_OPCODE_NOT, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOT_INT,
> tgsi_op2},
> {TGSI_OPCODE_TRUNC, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_TRUNC,
> tgsi_op2},
> --
> 1.7.10
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] vbo: move vbo_draw_method into vbo_context.h
On Mon, May 7, 2012 at 7:11 AM, Mathias Fröhlich
wrote:
>
> Hi Marek,
>
> On Saturday, May 05, 2012 22:12:51 Marek Olšák wrote:
>> could somebody please take a look at this series? It changes a couple
>> of things in gl_context and the vbo module.
>>
>> The other two patches are:
>> [PATCH 2/3] mesa: move gl_client_array*[] from vbo_draw_func into gl_context
>> [PATCH 3/3] mesa: add gl_context::NewDriverState and use it for vertex
>> arrays
>
> I am probably the wrong one to give a architectural ack for the series since I
> am only a part time worker in some corners.
> But I can tell what I had in mind in this area when I did the last changes.
> You are partly heading in the same direction with moving the client array as
> state into mesa.
>
> My plan was:
> Do draws in terms of a gl_array_object that is active for draw. That would
> play the role of your bare client array pointer currently. For the immediate
> mode save and exec context code paths we would use a hidden array object that
> is used on a drivers call code path. For the OpenGL api's draw arrays we would
> use the contexts gl_array_object for draws.
> In my plan the client_array should be located in the gl_array_object.
> Therefore the NewArray bitfield also moved to gl_array_object recently. You
> can
> then there build up a self contained set of methods on the gl_array_object to
> update its state and track the dirty bits in the NewArray bitfield also in
> combination with the Enabled bitfield where we can play a lot of tricks with
> the bitfields to reduce a lot of loops iterating all 33 arrays with loops only
> working on the changed arrays.
>
> For the drivers side I think that we can get rid of the client_array
> completely for the gallium side. To do that, I wanted to derive a
> st_array_object and a classic_array_object from gl_array_object. The
> client_array in its current form could then move into the classic_array_object
> where we can still play intelligent games with the bitfields to cut down the
> length 33 loops int the fast draw path. But the st_array_object would only
> have space for pipe_vertex_{buffer,elements} in addition to the fields from
> the
> base gl_array_object class. These elements could then be incrementally updated
> using the NewArray and Enabled bitfields and applied to the gallium state when
> needed.
As far as the gallium side is concerned, I don't think the array
object can fully encapsulate vertex buffers and vertex elements. Those
two also depend on the vertex shader, because vertex buffer bindings
currently map 1:1 to vertex elements unless the vertex attribs are
interleaved (though that can be changed), and vertex elements always
map 1:1 to vertex shader inputs. Whether it's worth to break the
dependency between those states is questionable. I think that binding
32 vertex buffers and letting vertex elements decide which buffers to
use would be a disaster for our CPU performance. Who knows. All in
all, I've got no idea how to take advantage of array objects in
st/mesa, because it doesn't seem to map to gallium well. Maybe you
guys know better.
>
> Given that I think that I would prefer to have the client_array (not the
> pointer to the first element) itself in the gl_array_object. And the role of
> your gl_client_array** pointer would be replaced by a gl_array_object pointer
> with the same three instances (drawelements api path, vbo_exec, vbo_save)
> around that your patch uses for the *gl_client_array[].
I'd prefer to leave this change to another patch series and keep this
series simple.
> The benefit would be that you could probably encapsulate the the array state
> tracking completely into this subobject, track changes using nifty bitfields
> using ffs based way smaller loops and only track changes to the
> gl_array_object
> draw pointer at the context toplevel.
>
> So, for my interrest, what are your further plans beyond this change?
Concerning core Mesa, I'd like to use gl_context::DriverFlags for more
states than just vertex arrays. I'll probably do blend state next.
I don't have any other plans for core Mesa at the moment.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: Handle TGSI_OPCODE_CEIL (v2)
v2: Enabled CEIL on Cayman too.
Signed-off-by: Kai Wasserbäch
Reviewed-by: Tom Stellard
---
Thanks for the review, Tom!
If this patch is accepted, please apply it to master for me, I don't have
commit access on FDO.
src/gallium/drivers/r600/r600_shader.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index fa29b36..aa17f20 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -5154,7 +5154,7 @@ static struct r600_shader_tgsi_instruction
r600_shader_tgsi_instruction[] = {
{80,0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
{TGSI_OPCODE_PUSHA, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
{TGSI_OPCODE_POPA, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
- {TGSI_OPCODE_CEIL, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
+ {TGSI_OPCODE_CEIL, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_CEIL,
tgsi_op2},
{TGSI_OPCODE_I2F, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_INT_TO_FLT,
tgsi_op2_trans},
{TGSI_OPCODE_NOT, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOT_INT,
tgsi_op2},
{TGSI_OPCODE_TRUNC, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_TRUNC,
tgsi_op2},
@@ -5328,7 +5328,7 @@ static struct r600_shader_tgsi_instruction
eg_shader_tgsi_instruction[] = {
{80,0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
{TGSI_OPCODE_PUSHA, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
{TGSI_OPCODE_POPA, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
- {TGSI_OPCODE_CEIL, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
+ {TGSI_OPCODE_CEIL, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_CEIL,
tgsi_op2},
{TGSI_OPCODE_I2F, 0,
EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_INT_TO_FLT, tgsi_op2_trans},
{TGSI_OPCODE_NOT, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOT_INT,
tgsi_op2},
{TGSI_OPCODE_TRUNC, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_TRUNC,
tgsi_op2},
@@ -5502,7 +5502,7 @@ static struct r600_shader_tgsi_instruction
cm_shader_tgsi_instruction[] = {
{80,0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
{TGSI_OPCODE_PUSHA, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
{TGSI_OPCODE_POPA, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
- {TGSI_OPCODE_CEIL, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
+ {TGSI_OPCODE_CEIL, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_CEIL,
tgsi_op2},
{TGSI_OPCODE_I2F, 0,
EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_INT_TO_FLT, tgsi_op2},
{TGSI_OPCODE_NOT, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOT_INT,
tgsi_op2},
{TGSI_OPCODE_TRUNC, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_TRUNC,
tgsi_op2},
--
1.7.10
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] mesa: add gl_context::NewDriverState and use it for vertex arrays
Looks good, but it took me a while to understand exactly what's going
on. Suggestions for more/improved comments below.
On Tue, Apr 24, 2012 at 4:00 PM, Marek Olšák wrote:
> The vbo module recomputes its states if _NEW_ARRAY is set, so it shouldn't use
> the same flag to notify the driver. Since we've run out of bits in NewState
> and NewState is for core Mesa anyway, we need to find another way.
>
> This patch is the first to start decoupling the state flags meant only
> for core Mesa and those only for drivers.
>
> The idea is to have two flag sets:
> - gl_context::NewState - used by core Mesa only
> - gl_context::NewDriverState - used by drivers only
"used by drivers only. The flags defined by the driver and
opaque/meaningless to core Mesa."
>
> It makes perfect sense to use NewState|=_NEW_ARRAY to notify the vbo module
> that the user changed vertex arrays, and the vbo module in turn sets
> a driver-specific flag to notify the driver that it should update its vertex
> array bindings.
>
> The driver decides which bits of NewDriverState should be set and stores them
> in gl_context::DriverFlags. Then, Core Mesa can do this:
> ctx->NewDriverState |= ctx->DriverFlags.NewArray;
>
> This patch implements this behavior and adapts st/mesa.
> DriverFlags.NewArray is set to ST_NEW_VERTEX_ARRAYS.
>
> Core Mesa only sets NewDriverState. It's the driver's responsibility to read
> it whenever it wants and reset it to 0.
> ---
> src/mesa/main/context.c | 2 ++
> src/mesa/main/mtypes.h | 14 ++
> src/mesa/state_tracker/st_cb_rasterpos.c | 5 -
> src/mesa/state_tracker/st_context.c | 6 ++
> src/mesa/state_tracker/st_context.h | 1 +
> src/mesa/state_tracker/st_draw.c | 12 +---
> src/mesa/vbo/vbo_context.h | 2 +-
> src/mesa/vbo/vbo_exec_array.c | 2 +-
> src/mesa/vbo/vbo_exec_draw.c | 2 +-
> src/mesa/vbo/vbo_rebase.c | 2 ++
> src/mesa/vbo/vbo_save_draw.c | 2 +-
> src/mesa/vbo/vbo_split_copy.c | 2 ++
> src/mesa/vbo/vbo_split_inplace.c | 2 ++
> 13 files changed, 46 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
> index d75351c..7e2ac98 100644
> --- a/src/mesa/main/context.c
> +++ b/src/mesa/main/context.c
> @@ -792,6 +792,7 @@ init_attrib_groups(struct gl_context *ctx)
>
> /* Miscellaneous */
> ctx->NewState = _NEW_ALL;
> + ctx->NewDriverState = ~0;
> ctx->ErrorValue = (GLenum) GL_NO_ERROR;
> ctx->ResetStatus = (GLenum) GL_NO_ERROR;
> ctx->varying_vp_inputs = VERT_BIT_ALL;
> @@ -1290,6 +1291,7 @@ _mesa_copy_context( const struct gl_context *src,
> struct gl_context *dst,
> /* XXX FIXME: Call callbacks?
> */
> dst->NewState = _NEW_ALL;
> + dst->NewDriverState = ~0;
> }
> #endif
>
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index eb103ad..7f01514 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -3255,6 +3255,17 @@ typedef enum
> API_OPENGLES2
> } gl_api;
>
> +/**
> + * Driver-specific state flags.
> + *
> + * These are or'd with gl_context::NewDriverState to notify a driver about
> + * a state change. The driver gets to decide what bits should be set through
> + * this structure.
Just to be clear (and add to the comment), the bits here are set once
by the driver during context creation and never changed, right? Also,
could you make it a bit more clear that the values of the flags are
defined by the driver and opaque to core Mesa?
> + */
> +struct gl_driver_flags
> +{
> + GLbitfield NewArray; /**< Vertex array state */
> +};
>
[...]
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] mesa: move gl_client_array*[] from vbo_draw_func into gl_context
On Tue, Apr 24, 2012 at 4:00 PM, Marek Olšák wrote:
> In the future we'd like to treat vertex arrays as a state and
> not as a parameter to the draw function. This is the first step
> towards that goal.
Part of the goal is to avoid array re-validation for every draw call,
right? Maybe say so in the comment.
More comments below.
>
> This commit adds:
> const struct gl_client_array **gl_context::Array::Arrays.
>
> The pointer is changed in:
> * vbo_draw_method
> * vbo_rebase_prims - unused by gallium
> * vbo_split_prims - unused by gallium
> * st_RasterPos
> ---
> src/mesa/drivers/dri/i965/brw_draw.c | 2 +-
> src/mesa/drivers/dri/i965/brw_draw.h | 1 -
> src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c | 9 -
> src/mesa/main/mtypes.h | 3 +++
> src/mesa/state_tracker/st_cb_rasterpos.c | 5 -
> src/mesa/state_tracker/st_draw.c | 2 +-
> src/mesa/state_tracker/st_draw.h | 2 --
> src/mesa/state_tracker/st_draw_feedback.c | 2 +-
> src/mesa/tnl/t_draw.c | 3 ++-
> src/mesa/tnl/tnl.h | 1 -
> src/mesa/vbo/vbo.h | 1 -
> src/mesa/vbo/vbo_context.h | 15 +++
> src/mesa/vbo/vbo_exec_array.c | 12 ++--
> src/mesa/vbo/vbo_exec_draw.c | 3 +--
> src/mesa/vbo/vbo_rebase.c | 8 ++--
> src/mesa/vbo/vbo_save_draw.c | 3 +--
> src/mesa/vbo/vbo_split_copy.c | 9 +++--
> src/mesa/vbo/vbo_split_inplace.c | 9 +++--
> 18 files changed, 59 insertions(+), 31 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index da37b18..30faa95 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -531,7 +531,6 @@ retry:
> }
>
> void brw_draw_prims( struct gl_context *ctx,
> - const struct gl_client_array *arrays[],
> const struct _mesa_prim *prim,
> GLuint nr_prims,
> const struct _mesa_index_buffer *ib,
> @@ -540,6 +539,7 @@ void brw_draw_prims( struct gl_context *ctx,
> GLuint max_index,
> struct gl_transform_feedback_object *tfb_vertcount )
> {
> + const struct gl_client_array **arrays = ctx->Array.Arrays;
> bool retval;
>
> if (!_mesa_check_conditional_render(ctx))
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.h
> b/src/mesa/drivers/dri/i965/brw_draw.h
> index b910419..2cc4cb3 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.h
> +++ b/src/mesa/drivers/dri/i965/brw_draw.h
> @@ -35,7 +35,6 @@ struct brw_context;
>
>
> void brw_draw_prims( struct gl_context *ctx,
> - const struct gl_client_array *arrays[],
> const struct _mesa_prim *prims,
> GLuint nr_prims,
> const struct _mesa_index_buffer *ib,
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
> b/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
> index 62fee2e..6358b26 100644
> --- a/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
> +++ b/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
> @@ -216,7 +216,7 @@ get_max_client_stride(struct gl_context *ctx, const
> struct gl_client_array **arr
> }
>
> static void
> -TAG(vbo_render_prims)(struct gl_context *ctx, const struct gl_client_array
> **arrays,
> +TAG(vbo_render_prims)(struct gl_context *ctx,
> const struct _mesa_prim *prims, GLuint nr_prims,
> const struct _mesa_index_buffer *ib,
> GLboolean index_bounds_valid,
> @@ -448,7 +448,6 @@ vbo_draw_imm(struct gl_context *ctx, const struct
> gl_client_array **arrays,
>
> static void
> TAG(vbo_render_prims)(struct gl_context *ctx,
> - const struct gl_client_array **arrays,
> const struct _mesa_prim *prims, GLuint nr_prims,
> const struct _mesa_index_buffer *ib,
> GLboolean index_bounds_valid,
> @@ -456,6 +455,7 @@ TAG(vbo_render_prims)(struct gl_context *ctx,
> struct gl_transform_feedback_object *tfb_vertcount)
> {
> struct nouveau_render_state *render = to_render_state(ctx);
> + const struct gl_client_array **arrays = ctx->Array.Arrays;
>
> if (!index_bounds_valid)
> vbo_get_minmax_indices(ctx, prims, ib, &min_index, &max_index,
> @@ -484,7 +484,6 @@ TAG(vbo_render_prims)(struct gl_context *ctx,
>
> static void
> TAG(vbo_check_render_prims)(struct gl_context *ctx,
> - const struct gl_client_array **arrays,
> const struct _mesa_prim *prims, GLuint nr_prims,
> const struct _mesa_index_buffer *ib,
> GLboolean index
Re: [Mesa-dev] [PATCH 1/3] vbo: move vbo_draw_method into vbo_context.h
For the series, Reviewed-by: Brian Paul
but I posted some comments for the other two patches.
-Brian
On 05/05/2012 02:12 PM, Marek Olšák wrote:
Hi,
could somebody please take a look at this series? It changes a couple
of things in gl_context and the vbo module.
The other two patches are:
[PATCH 2/3] mesa: move gl_client_array*[] from vbo_draw_func into gl_context
[PATCH 3/3] mesa: add gl_context::NewDriverState and use it for vertex arrays
Thanks,
Marek
On Wed, Apr 25, 2012 at 12:00 AM, Marek Olšák wrote:
I'll need vbo_context in that function soon.
---
src/mesa/vbo/vbo_context.h| 35 +++
src/mesa/vbo/vbo_exec.h | 36
src/mesa/vbo/vbo_exec_api.c |2 +-
src/mesa/vbo/vbo_exec_array.c |2 +-
src/mesa/vbo/vbo_save_draw.c |3 +--
5 files changed, 38 insertions(+), 40 deletions(-)
diff --git a/src/mesa/vbo/vbo_context.h b/src/mesa/vbo/vbo_context.h
index b9a8aff..a6397ba 100644
--- a/src/mesa/vbo/vbo_context.h
+++ b/src/mesa/vbo/vbo_context.h
@@ -58,6 +58,18 @@
#include "vbo_save.h"
+/** Used to signal when transitioning from one kind of drawing method
+ * to another.
+ */
+enum draw_method
+{
+ DRAW_NONE, /**< Initial value only */
+ DRAW_BEGIN_END,
+ DRAW_DISPLAY_LIST,
+ DRAW_ARRAYS
+};
+
+
struct vbo_context {
struct gl_client_array currval[VBO_ATTRIB_MAX];
@@ -74,6 +86,8 @@ struct vbo_context {
* is responsible for initiating any fallback actions required:
*/
vbo_draw_func draw_prims;
+
+ enum draw_method last_draw_method;
};
@@ -101,4 +115,25 @@ get_program_mode( struct gl_context *ctx )
}
+/**
+ * This is called by glBegin, glDrawArrays and glDrawElements (and
+ * variations of those calls). When we transition from immediate mode
+ * drawing to array drawing we need to invalidate the array state.
+ *
+ * glBegin/End builds vertex arrays. Those arrays may look identical
+ * to glDrawArrays arrays except that the position of the elements may
+ * be different. For example, arrays of (position3v, normal3f) vs. arrays
+ * of (normal3f, position3f). So we need to make sure we notify drivers
+ * that arrays may be changing.
+ */
+static inline void
+vbo_draw_method(struct vbo_context *vbo, enum draw_method method)
+{
+ if (vbo->last_draw_method != method) {
+ struct gl_context *ctx = vbo->exec.ctx;
+ ctx->Driver.UpdateState(ctx, _NEW_ARRAY);
+ vbo->last_draw_method = method;
+ }
+}
+
#endif
diff --git a/src/mesa/vbo/vbo_exec.h b/src/mesa/vbo/vbo_exec.h
index be9f3d7..4ac7d16 100644
--- a/src/mesa/vbo/vbo_exec.h
+++ b/src/mesa/vbo/vbo_exec.h
@@ -78,26 +78,12 @@ struct vbo_exec_copied_vtx {
};
-/** Used to signal when transitioning from one kind of drawing method
- * to another.
- */
-enum draw_method
-{
- DRAW_NONE, /**< Initial value only */
- DRAW_BEGIN_END,
- DRAW_DISPLAY_LIST,
- DRAW_ARRAYS
-};
-
-
struct vbo_exec_context
{
struct gl_context *ctx;
GLvertexformat vtxfmt;
GLvertexformat vtxfmt_noop;
- enum draw_method last_draw_method;
-
struct {
struct gl_buffer_object *bufferobj;
@@ -174,28 +160,6 @@ void vbo_exec_vtx_init( struct vbo_exec_context *exec );
void vbo_exec_vtx_destroy( struct vbo_exec_context *exec );
-/**
- * This is called by glBegin, glDrawArrays and glDrawElements (and
- * variations of those calls). When we transition from immediate mode
- * drawing to array drawing we need to invalidate the array state.
- *
- * glBegin/End builds vertex arrays. Those arrays may look identical
- * to glDrawArrays arrays except that the position of the elements may
- * be different. For example, arrays of (position3v, normal3f) vs. arrays
- * of (normal3f, position3f). So we need to make sure we notify drivers
- * that arrays may be changing.
- */
-static inline void
-vbo_draw_method(struct vbo_exec_context *exec, enum draw_method method)
-{
- if (exec->last_draw_method != method) {
- struct gl_context *ctx = exec->ctx;
- ctx->Driver.UpdateState(ctx, _NEW_ARRAY);
- exec->last_draw_method = method;
- }
-}
-
-
#if FEATURE_beginend
void vbo_exec_vtx_flush( struct vbo_exec_context *exec, GLboolean unmap );
diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
index 3f95410..b87da18 100644
--- a/src/mesa/vbo/vbo_exec_api.c
+++ b/src/mesa/vbo/vbo_exec_api.c
@@ -700,7 +700,7 @@ static void GLAPIENTRY vbo_exec_Begin( GLenum mode )
return;
}
- vbo_draw_method(exec, DRAW_BEGIN_END);
+ vbo_draw_method(vbo_context(ctx), DRAW_BEGIN_END);
if (ctx->Driver.PrepareExecBegin)
ctx->Driver.PrepareExecBegin(ctx);
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 2dcfb8e..6c8a32e 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -523,7 +523,7 @@ vbo_bind_arrays(struct gl_context *ctx)
struct vbo_context *vbo = vbo_context(ctx);
Re: [Mesa-dev] [PATCH 1/3] vbo: move vbo_draw_method into vbo_context.h
On 05/07/2012 09:27 AM, Marek Olšák wrote:
On Mon, May 7, 2012 at 7:11 AM, Mathias Fröhlich
wrote:
Hi Marek,
On Saturday, May 05, 2012 22:12:51 Marek Olšák wrote:
could somebody please take a look at this series? It changes a couple
of things in gl_context and the vbo module.
The other two patches are:
[PATCH 2/3] mesa: move gl_client_array*[] from vbo_draw_func into gl_context
[PATCH 3/3] mesa: add gl_context::NewDriverState and use it for vertex
arrays
I am probably the wrong one to give a architectural ack for the series since I
am only a part time worker in some corners.
But I can tell what I had in mind in this area when I did the last changes.
You are partly heading in the same direction with moving the client array as
state into mesa.
My plan was:
Do draws in terms of a gl_array_object that is active for draw. That would
play the role of your bare client array pointer currently. For the immediate
mode save and exec context code paths we would use a hidden array object that
is used on a drivers call code path. For the OpenGL api's draw arrays we would
use the contexts gl_array_object for draws.
In my plan the client_array should be located in the gl_array_object.
Therefore the NewArray bitfield also moved to gl_array_object recently. You can
then there build up a self contained set of methods on the gl_array_object to
update its state and track the dirty bits in the NewArray bitfield also in
combination with the Enabled bitfield where we can play a lot of tricks with
the bitfields to reduce a lot of loops iterating all 33 arrays with loops only
working on the changed arrays.
For the drivers side I think that we can get rid of the client_array
completely for the gallium side. To do that, I wanted to derive a
st_array_object and a classic_array_object from gl_array_object. The
client_array in its current form could then move into the classic_array_object
where we can still play intelligent games with the bitfields to cut down the
length 33 loops int the fast draw path. But the st_array_object would only
have space for pipe_vertex_{buffer,elements} in addition to the fields from the
base gl_array_object class. These elements could then be incrementally updated
using the NewArray and Enabled bitfields and applied to the gallium state when
needed.
As far as the gallium side is concerned, I don't think the array
object can fully encapsulate vertex buffers and vertex elements. Those
two also depend on the vertex shader, because vertex buffer bindings
currently map 1:1 to vertex elements unless the vertex attribs are
interleaved (though that can be changed), and vertex elements always
map 1:1 to vertex shader inputs. Whether it's worth to break the
dependency between those states is questionable. I think that binding
32 vertex buffers and letting vertex elements decide which buffers to
use would be a disaster for our CPU performance. Who knows. All in
all, I've got no idea how to take advantage of array objects in
st/mesa, because it doesn't seem to map to gallium well. Maybe you
guys know better.
I mentioned the idea before and Mathias is interested in it as well.
The basic idea is:
1. OpenGL's vertex array objects (gl_array_object) basically
encapsulates the state of a bunch of glVertexPointer,
glTexCoordPointer, etc. arrays.
2. In gallium we have a set of pipe_vertex_element that basically
encodes the same state.
3. Hopefully we could avoid re-deriving the later state from the
former if we do the encapsulation that Mathias describes.
But as you said, the derived array state that we pass to draw calls
also depends on the currently bound vertex program and its inputs.
It seems to me though, that a given gl_array_object state would almost
always be used with a vertex shader (or set of vertex shaders) that
use precisely the enabled arrays. So there could be a quick check if
the set of enabled arrays matched the set of vertex shader inputs and
we could quickly re-use the pipe_vertex_element state.
Given that I think that I would prefer to have the client_array (not the
pointer to the first element) itself in the gl_array_object. And the role of
your gl_client_array** pointer would be replaced by a gl_array_object pointer
with the same three instances (drawelements api path, vbo_exec, vbo_save)
around that your patch uses for the *gl_client_array[].
I'd prefer to leave this change to another patch series and keep this
series simple.
I agree.
The benefit would be that you could probably encapsulate the the array state
tracking completely into this subobject, track changes using nifty bitfields
using ffs based way smaller loops and only track changes to the gl_array_object
draw pointer at the context toplevel.
So, for my interrest, what are your further plans beyond this change?
Concerning core Mesa, I'd like to use gl_context::DriverFlags for more
states than just vertex arrays. I'll probably do blend state next.
Sounds good.
I don't have any other plans fo
[Mesa-dev] [PATCH 00/12] radeon/llvm: fixes and some missing features
Some fixes, missing instructions, etc for llvm backend. Comparing to non-llvm backend, it still fails 9 tests for me on evergreen. Also you can find these patches in my github mesa repo, r600_llvm branch: https://github.com/VadimGirlin/mesa.git radeon/llvm: use bitcasts for integers radeon/llvm: use integer comparison for IF radeon/llvm: fix ABS_i32 instruction lowering radeon/llvm: add support for v4i32 radeon/llvm: fix live-in handling for inputs radeon/llvm: add support for VertexID, InstanceID radeon/llvm: add support for TXQ/TXF/DDX/DDY instructions radeon/llvm: add support for AHSR/LSHR/LSHL instructions radeon/llvm: add missing cases for BREAK/CONTINUE radeon/llvm: add support for some ALU instructions radeon/llvm: add support for CUBE ALU instruction radeon/llvm: add suport for cube textures src/gallium/auxiliary/gallivm/lp_bld_tgsi.c|2 - src/gallium/drivers/r600/r600_llvm.c | 64 +-- src/gallium/drivers/radeon/AMDGPUGenInstrEnums.pl |2 +- src/gallium/drivers/radeon/AMDGPUIntrinsics.td | 11 +- .../drivers/radeon/AMDGPULowerInstructions.cpp |9 +- .../radeon/AMDGPULowerShaderInstructions.cpp |3 + src/gallium/drivers/radeon/AMDGPUUtil.cpp | 16 + src/gallium/drivers/radeon/AMDGPUUtil.h|1 + src/gallium/drivers/radeon/R600CodeEmitter.cpp | 60 ++- src/gallium/drivers/radeon/R600GenRegisterInfo.pl |2 +- src/gallium/drivers/radeon/R600ISelLowering.cpp|4 + src/gallium/drivers/radeon/R600InstrInfo.cpp | 12 + src/gallium/drivers/radeon/R600InstrInfo.h |1 + src/gallium/drivers/radeon/R600Instructions.td | 113 - .../drivers/radeon/R600LowerInstructions.cpp |4 +- src/gallium/drivers/radeon/radeon_llvm.h | 38 ++ .../drivers/radeon/radeon_setup_tgsi_llvm.c| 433 +++- 17 files changed, 698 insertions(+), 77 deletions(-) -- 1.7.10.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/12] radeon/llvm: use integer comparison for IF
Replacing "float equal to 1.0f" with "int not equal to 0". This should help for further optimization of boolean computations. Signed-off-by: Vadim Girlin --- src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c index 06af134..c9b4365 100644 --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c @@ -465,8 +465,10 @@ static void if_emit( struct gallivm_state * gallivm = bld_base->base.gallivm; LLVMValueRef cond; LLVMBasicBlockRef if_block, else_block, endif_block; - cond = LLVMBuildFCmp(gallivm->builder, LLVMRealOEQ, emit_data->args[0], - bld_base->base.one, ""); + + cond = LLVMBuildICmp(gallivm->builder, LLVMIntNE, + bitcast(bld_base, TGSI_TYPE_UNSIGNED, emit_data->args[0]), + bld_base->int_bld.zero, ""); endif_block = LLVMAppendBasicBlockInContext(gallivm->context, ctx->main_fn, "ENDIF"); -- 1.7.10.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/12] radeon/llvm: use bitcasts for integers
We're using float as default type, so basically for every instruction that
wants other types for dst/src operands we need to perform the bitcast
to/from default float. Currently bitcast produces no-op MOV instruction,
will be eliminated later.
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_llvm.c |4 +-
src/gallium/drivers/radeon/radeon_llvm.h | 31 ++
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 43 ++--
3 files changed, 73 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index d467baf..a36760c 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -21,10 +21,12 @@ static LLVMValueRef llvm_fetch_const(
enum tgsi_opcode_type type,
unsigned swizzle)
{
- return lp_build_intrinsic_unary(bld_base->base.gallivm->builder,
+ LLVMValueRef cval =
lp_build_intrinsic_unary(bld_base->base.gallivm->builder,
"llvm.AMDGPU.load.const", bld_base->base.elem_type,
lp_build_const_int32(bld_base->base.gallivm,
radeon_llvm_reg_index_soa(reg->Register.Index, swizzle)));
+
+ return bitcast(bld_base, type, cval);
}
static void llvm_load_input(
diff --git a/src/gallium/drivers/radeon/radeon_llvm.h
b/src/gallium/drivers/radeon/radeon_llvm.h
index 9be7f90..39b1214 100644
--- a/src/gallium/drivers/radeon/radeon_llvm.h
+++ b/src/gallium/drivers/radeon/radeon_llvm.h
@@ -105,6 +105,37 @@ struct radeon_llvm_context {
struct gallivm_state gallivm;
};
+static inline LLVMValueRef bitcast(
+ struct lp_build_tgsi_context * bld_base,
+ enum tgsi_opcode_type type,
+ LLVMValueRef value
+)
+{
+ LLVMBuilderRef builder = bld_base->base.gallivm->builder;
+ LLVMContextRef ctx = bld_base->base.gallivm->context;
+ LLVMTypeRef dst_type;
+
+ switch (type) {
+ case TGSI_TYPE_UNSIGNED:
+ case TGSI_TYPE_SIGNED:
+ dst_type = LLVMInt32TypeInContext(ctx);
+ break;
+ case TGSI_TYPE_UNTYPED:
+ case TGSI_TYPE_FLOAT:
+ dst_type = LLVMFloatTypeInContext(ctx);
+ break;
+ default:
+ dst_type = 0;
+ break;
+ }
+
+ if (dst_type)
+ return LLVMBuildBitCast(builder, value, dst_type, "");
+ else
+ return value;
+}
+
+
void radeon_llvm_context_init(struct radeon_llvm_context * ctx);
void radeon_llvm_dispose(struct radeon_llvm_context * ctx);
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index d3c493c..06af134 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -113,8 +113,25 @@ emit_fetch_immediate(
enum tgsi_opcode_type type,
unsigned swizzle)
{
+ LLVMTypeRef ctype;
+ LLVMContextRef ctx = bld_base->base.gallivm->context;
+
+ switch (type) {
+ case TGSI_TYPE_UNSIGNED:
+ case TGSI_TYPE_SIGNED:
+ ctype = LLVMInt32TypeInContext(ctx);
+ break;
+ case TGSI_TYPE_UNTYPED:
+ case TGSI_TYPE_FLOAT:
+ ctype = LLVMFloatTypeInContext(ctx);
+ break;
+ default:
+ ctype = 0;
+ break;
+ }
+
struct lp_build_tgsi_soa_context *bld = lp_soa_context(bld_base);
- return bld->immediates[reg->Register.Index][swizzle];
+ return LLVMConstBitCast(bld->immediates[reg->Register.Index][swizzle],
ctype);
}
static LLVMValueRef
@@ -135,7 +152,7 @@ emit_fetch_input(
return lp_build_gather_values(bld_base->base.gallivm, values,
TGSI_NUM_CHANNELS);
} else {
- return
ctx->inputs[radeon_llvm_reg_index_soa(reg->Register.Index, swizzle)];
+ return bitcast(bld_base, type,
ctx->inputs[radeon_llvm_reg_index_soa(reg->Register.Index, swizzle)]);
}
}
@@ -156,7 +173,7 @@ emit_fetch_temporary(
} else {
LLVMValueRef temp_ptr;
temp_ptr = lp_get_temp_ptr_soa(bld, reg->Register.Index,
swizzle);
- return LLVMBuildLoad(builder, temp_ptr, "");
+ return bitcast(bld_base,type,LLVMBuildLoad(builder, temp_ptr,
""));
}
}
@@ -305,6 +322,9 @@ emit_store(
default:
return;
}
+
+ value = bitcast(bld_base, TGSI_TYPE_FLOAT, value);
+
LLVMBuildStore(builder, value, temp_ptr);
}
}
@@ -502,6 +522,20 @@ static void tex_fetch_args(
emit_data->dst_type = LLVMVectorType(bld_base->base.elem_type, 4);
}
+static void emit_immediate(struct lp_build_tgsi_context * bld_base,
+ const struct tgsi_full_immedi
[Mesa-dev] [PATCH 03/12] radeon/llvm: fix ABS_i32 instruction lowering
Swap source operands for SETGE_INT. Signed-off-by: Vadim Girlin --- src/gallium/drivers/radeon/R600LowerInstructions.cpp |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/radeon/R600LowerInstructions.cpp b/src/gallium/drivers/radeon/R600LowerInstructions.cpp index 181c606..b54778d 100644 --- a/src/gallium/drivers/radeon/R600LowerInstructions.cpp +++ b/src/gallium/drivers/radeon/R600LowerInstructions.cpp @@ -93,8 +93,8 @@ bool R600LowerInstructionsPass::runOnMachineFunction(MachineFunction &MF) &AMDIL::R600_TReg32RegClass); BuildMI(MBB, I, MBB.findDebugLoc(I), TII->get(AMDIL::SETGE_INT), setgt) - .addOperand(MI.getOperand(1)) - .addReg(AMDIL::ZERO); + .addReg(AMDIL::ZERO) + .addOperand(MI.getOperand(1)); unsigned add_int = MRI->createVirtualRegister( &AMDIL::R600_TReg32RegClass); -- 1.7.10.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/12] radeon/llvm: add support for v4i32
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/radeon/AMDGPULowerInstructions.cpp |9 +
src/gallium/drivers/radeon/R600GenRegisterInfo.pl |2 +-
src/gallium/drivers/radeon/R600ISelLowering.cpp|4
src/gallium/drivers/radeon/R600Instructions.td | 10 ++
4 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/radeon/AMDGPULowerInstructions.cpp
b/src/gallium/drivers/radeon/AMDGPULowerInstructions.cpp
index b49d0dd..b138e2b 100644
--- a/src/gallium/drivers/radeon/AMDGPULowerInstructions.cpp
+++ b/src/gallium/drivers/radeon/AMDGPULowerInstructions.cpp
@@ -27,7 +27,7 @@ namespace {
private:
static char ID;
TargetMachine &TM;
-void lowerVCREATE_v4f32(MachineInstr &MI, MachineBasicBlock::iterator I,
+void lowerVCREATE_v4(MachineInstr &MI, MachineBasicBlock::iterator I,
MachineBasicBlock &MBB, MachineFunction &MF);
public:
@@ -56,8 +56,9 @@ bool
AMDGPULowerInstructionsPass::runOnMachineFunction(MachineFunction &MF)
switch (MI.getOpcode()) {
default: continue;
- case AMDIL::VCREATE_v4f32: lowerVCREATE_v4f32(MI, I, MBB, MF); break;
-
+ case AMDIL::VCREATE_v4f32:
+ case AMDIL::VCREATE_v4i32:
+lowerVCREATE_v4(MI, I, MBB, MF); break;
}
MI.eraseFromParent();
}
@@ -65,7 +66,7 @@ bool
AMDGPULowerInstructionsPass::runOnMachineFunction(MachineFunction &MF)
return false;
}
-void AMDGPULowerInstructionsPass::lowerVCREATE_v4f32(MachineInstr &MI,
+void AMDGPULowerInstructionsPass::lowerVCREATE_v4(MachineInstr &MI,
MachineBasicBlock::iterator I, MachineBasicBlock &MBB, MachineFunction &MF)
{
MachineRegisterInfo & MRI = MF.getRegInfo();
diff --git a/src/gallium/drivers/radeon/R600GenRegisterInfo.pl
b/src/gallium/drivers/radeon/R600GenRegisterInfo.pl
index cbded11..409e345 100644
--- a/src/gallium/drivers/radeon/R600GenRegisterInfo.pl
+++ b/src/gallium/drivers/radeon/R600GenRegisterInfo.pl
@@ -81,7 +81,7 @@ def R600_Reg32 : RegisterClass <"AMDIL", [f32, i32], 32, (add
R600_CReg32,
ZERO, HALF, ONE, ONE_INT, PV_X, ALU_LITERAL_X, NEG_ONE, NEG_HALF)>;
-def R600_Reg128 : RegisterClass<"AMDIL", [v4f32], 128, (add
+def R600_Reg128 : RegisterClass<"AMDIL", [v4f32, v4i32], 128, (add
$t128_string)>
{
let SubRegClasses = [(R600_TReg32 sel_x, sel_y, sel_z, sel_w)];
diff --git a/src/gallium/drivers/radeon/R600ISelLowering.cpp
b/src/gallium/drivers/radeon/R600ISelLowering.cpp
index f92fe26..9e3b6b5 100644
--- a/src/gallium/drivers/radeon/R600ISelLowering.cpp
+++ b/src/gallium/drivers/radeon/R600ISelLowering.cpp
@@ -25,9 +25,13 @@ R600TargetLowering::R600TargetLowering(TargetMachine &TM) :
// setSchedulingPreference(Sched::VLIW);
addRegisterClass(MVT::v4f32, &AMDIL::R600_Reg128RegClass);
addRegisterClass(MVT::f32, &AMDIL::R600_Reg32RegClass);
+ addRegisterClass(MVT::v4i32, &AMDIL::R600_Reg128RegClass);
+ addRegisterClass(MVT::i32, &AMDIL::R600_Reg32RegClass);
setOperationAction(ISD::EXTRACT_VECTOR_ELT, MVT::v4f32, Legal);
setOperationAction(ISD::INSERT_VECTOR_ELT, MVT::v4f32, Legal);
+ setOperationAction(ISD::EXTRACT_VECTOR_ELT, MVT::v4i32, Legal);
+ setOperationAction(ISD::INSERT_VECTOR_ELT, MVT::v4i32, Legal);
}
MachineBasicBlock * R600TargetLowering::EmitInstrWithCustomInserter(
diff --git a/src/gallium/drivers/radeon/R600Instructions.td
b/src/gallium/drivers/radeon/R600Instructions.td
index 3b8513c..16ed4fb 100644
--- a/src/gallium/drivers/radeon/R600Instructions.td
+++ b/src/gallium/drivers/radeon/R600Instructions.td
@@ -938,6 +938,16 @@ def : Insert_Element ;
def : Insert_Element ;
def : Insert_Element ;
+def : Extract_Element ;
+def : Extract_Element ;
+def : Extract_Element ;
+def : Extract_Element ;
+
+def : Insert_Element ;
+def : Insert_Element ;
+def : Insert_Element ;
+def : Insert_Element ;
+
include "R600ShaderPatterns.td"
--
1.7.10.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/12] radeon/llvm: fix live-in handling for inputs
Set the input registers as live-in for entry basic block.
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/radeon/AMDGPULowerShaderInstructions.cpp |3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/radeon/AMDGPULowerShaderInstructions.cpp
b/src/gallium/drivers/radeon/AMDGPULowerShaderInstructions.cpp
index d33055c..89e18f0 100644
--- a/src/gallium/drivers/radeon/AMDGPULowerShaderInstructions.cpp
+++ b/src/gallium/drivers/radeon/AMDGPULowerShaderInstructions.cpp
@@ -26,6 +26,9 @@ void
AMDGPULowerShaderInstructionsPass::preloadRegister(MachineFunction * MF,
if (!MRI->isLiveIn(physReg)) {
MRI->addLiveIn(physReg, virtReg);
MachineBasicBlock &EntryMBB = MF->front();
+
+// XXX use EmitLiveInCopies instead?
+EntryMBB.addLiveIn(physReg);
BuildMI(MF->front(), EntryMBB.begin(), DebugLoc(),
TII->get(TargetOpcode::COPY),
virtReg)
.addReg(physReg);
--
1.7.10.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/12] radeon/llvm: add support for VertexID, InstanceID
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_llvm.c | 34
src/gallium/drivers/radeon/radeon_llvm.h |7
.../drivers/radeon/radeon_setup_tgsi_llvm.c|9 ++
3 files changed, 50 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index a36760c..0079800 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -29,6 +29,38 @@ static LLVMValueRef llvm_fetch_const(
return bitcast(bld_base, type, cval);
}
+static void llvm_load_system_value(
+ struct radeon_llvm_context * ctx,
+ unsigned index,
+ const struct tgsi_full_declaration *decl)
+{
+ unsigned chan;
+
+ switch (decl->Semantic.Name) {
+ case TGSI_SEMANTIC_INSTANCEID: chan = 3; break;
+ case TGSI_SEMANTIC_VERTEXID: chan = 0; break;
+ default: assert(!"unknown system value");
+ }
+
+ LLVMValueRef reg = lp_build_const_int32(
+ ctx->soa.bld_base.base.gallivm, chan);
+ ctx->system_values[index] = lp_build_intrinsic_unary(
+ ctx->soa.bld_base.base.gallivm->builder,
+ "llvm.R600.load.input",
+ ctx->soa.bld_base.base.elem_type, reg);
+}
+
+static LLVMValueRef llvm_fetch_system_value(
+ struct lp_build_tgsi_context * bld_base,
+ const struct tgsi_full_src_register *reg,
+ enum tgsi_opcode_type type,
+ unsigned swizzle)
+{
+ struct radeon_llvm_context * ctx = radeon_llvm_context(bld_base);
+ LLVMValueRef cval = ctx->system_values[reg->Register.Index];
+ return bitcast(bld_base, type, cval);
+}
+
static void llvm_load_input(
struct radeon_llvm_context * ctx,
unsigned input_index,
@@ -206,10 +238,12 @@ LLVMModuleRef r600_tgsi_llvm(
bld_base->info = &shader_info;
bld_base->userdata = ctx;
bld_base->emit_fetch_funcs[TGSI_FILE_CONSTANT] = llvm_fetch_const;
+ bld_base->emit_fetch_funcs[TGSI_FILE_SYSTEM_VALUE] =
llvm_fetch_system_value;
bld_base->emit_prologue = llvm_emit_prologue;
bld_base->emit_epilogue = llvm_emit_epilogue;
ctx->userdata = ctx;
ctx->load_input = llvm_load_input;
+ ctx->load_system_value = llvm_load_system_value;
bld_base->op_actions[TGSI_OPCODE_DP2] = dot_action;
bld_base->op_actions[TGSI_OPCODE_DP3] = dot_action;
diff --git a/src/gallium/drivers/radeon/radeon_llvm.h
b/src/gallium/drivers/radeon/radeon_llvm.h
index 39b1214..4a70639 100644
--- a/src/gallium/drivers/radeon/radeon_llvm.h
+++ b/src/gallium/drivers/radeon/radeon_llvm.h
@@ -36,6 +36,8 @@
#define RADEON_LLVM_MAX_BRANCH_DEPTH 16
#define RADEON_LLVM_MAX_LOOP_DEPTH 16
+#define RADEON_LLVM_MAX_SYSTEM_VALUES 4
+
struct radeon_llvm_branch {
LLVMBasicBlockRef endif_block;
LLVMBasicBlockRef if_block;
@@ -78,6 +80,9 @@ struct radeon_llvm_context {
unsigned input_index,
const struct tgsi_full_declaration *decl);
+ void (*load_system_value)(struct radeon_llvm_context *,
+ unsigned index,
+ const struct tgsi_full_declaration *decl);
/** User data to use with the callbacks */
void * userdata;
@@ -90,6 +95,8 @@ struct radeon_llvm_context {
LLVMValueRef outputs[RADEON_LLVM_MAX_OUTPUTS][TGSI_NUM_CHANNELS];
unsigned output_reg_count;
+ LLVMValueRef system_values[RADEON_LLVM_MAX_SYSTEM_VALUES];
+
unsigned reserved_reg_count;
/*=== Private Members ===*/
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index c9b4365..4c437d5 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -231,6 +231,15 @@ static void emit_declaration(
}
break;
+ case TGSI_FILE_SYSTEM_VALUE:
+ {
+ unsigned idx;
+ for (idx = decl->Range.First; idx <= decl->Range.Last; idx++) {
+ ctx->load_system_value(ctx, idx, decl);
+ }
+ }
+ break;
+
case TGSI_FILE_OUTPUT:
{
unsigned idx;
--
1.7.10.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/12] radeon/llvm: add support for TXQ/TXF/DDX/DDY instructions
Signed-off-by: Vadim Girlin
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.c|2 --
src/gallium/drivers/r600/r600_llvm.c |4
src/gallium/drivers/radeon/AMDGPUIntrinsics.td |4
src/gallium/drivers/radeon/AMDGPUUtil.cpp |4
src/gallium/drivers/radeon/R600Instructions.td | 21
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 14 +
6 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.c
index 45bbf81..680c85f 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi.c
@@ -215,8 +215,6 @@ lp_build_tgsi_inst_llvm(
case TGSI_OPCODE_PUSHA:
case TGSI_OPCODE_POPA:
case TGSI_OPCODE_SAD:
- case TGSI_OPCODE_TXF:
- case TGSI_OPCODE_TXQ:
/* deprecated? */
assert(0);
return FALSE;
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index 0079800..b2cdbd0 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -249,10 +249,14 @@ LLVMModuleRef r600_tgsi_llvm(
bld_base->op_actions[TGSI_OPCODE_DP3] = dot_action;
bld_base->op_actions[TGSI_OPCODE_DP4] = dot_action;
bld_base->op_actions[TGSI_OPCODE_DPH] = dot_action;
+ bld_base->op_actions[TGSI_OPCODE_DDX].emit = llvm_emit_tex;
+ bld_base->op_actions[TGSI_OPCODE_DDY].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TEX].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TXB].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TXD].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TXL].emit = llvm_emit_tex;
+ bld_base->op_actions[TGSI_OPCODE_TXF].emit = llvm_emit_tex;
+ bld_base->op_actions[TGSI_OPCODE_TXQ].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TXP].fetch_args = txp_fetch_args;
bld_base->op_actions[TGSI_OPCODE_TXP].emit = llvm_emit_tex;
diff --git a/src/gallium/drivers/radeon/AMDGPUIntrinsics.td
b/src/gallium/drivers/radeon/AMDGPUIntrinsics.td
index bcd61b4..41f9ca2 100644
--- a/src/gallium/drivers/radeon/AMDGPUIntrinsics.td
+++ b/src/gallium/drivers/radeon/AMDGPUIntrinsics.td
@@ -43,9 +43,13 @@ let TargetPrefix = "AMDGPU", isTarget = 1 in {
def int_AMDGPU_mullit : Intrinsic<[llvm_v4f32_ty], [llvm_float_ty,
llvm_float_ty, llvm_float_ty], []>;
def int_AMDGPU_tex : Intrinsic<[llvm_v4f32_ty], [llvm_v4f32_ty, llvm_i32_ty,
llvm_i32_ty], []>;
def int_AMDGPU_txb : Intrinsic<[llvm_v4f32_ty], [llvm_v4f32_ty, llvm_i32_ty,
llvm_i32_ty], []>;
+ def int_AMDGPU_txf : Intrinsic<[llvm_v4f32_ty], [llvm_v4f32_ty, llvm_i32_ty,
llvm_i32_ty], []>;
+ def int_AMDGPU_txq : Intrinsic<[llvm_v4f32_ty], [llvm_v4f32_ty, llvm_i32_ty,
llvm_i32_ty], []>;
def int_AMDGPU_txd : Intrinsic<[llvm_v4f32_ty], [llvm_v4f32_ty, llvm_i32_ty,
llvm_i32_ty], []>;
def int_AMDGPU_txl : Intrinsic<[llvm_v4f32_ty], [llvm_v4f32_ty, llvm_i32_ty,
llvm_i32_ty], []>;
def int_AMDGPU_trunc : Intrinsic<[llvm_float_ty], [llvm_float_ty], []>;
+ def int_AMDGPU_ddx : Intrinsic<[llvm_v4f32_ty], [llvm_v4f32_ty, llvm_i32_ty,
llvm_i32_ty], []>;
+ def int_AMDGPU_ddy : Intrinsic<[llvm_v4f32_ty], [llvm_v4f32_ty, llvm_i32_ty,
llvm_i32_ty], []>;
}
let TargetPrefix = "TGSI", isTarget = 1 in {
diff --git a/src/gallium/drivers/radeon/AMDGPUUtil.cpp
b/src/gallium/drivers/radeon/AMDGPUUtil.cpp
index 6fb01b6..78e1c4b 100644
--- a/src/gallium/drivers/radeon/AMDGPUUtil.cpp
+++ b/src/gallium/drivers/radeon/AMDGPUUtil.cpp
@@ -72,6 +72,8 @@ bool llvm::isTexOp(unsigned opcode)
{
switch(opcode) {
default: return false;
+ case AMDIL::TEX_LD:
+ case AMDIL::TEX_GET_TEXTURE_RESINFO:
case AMDIL::TEX_SAMPLE:
case AMDIL::TEX_SAMPLE_C:
case AMDIL::TEX_SAMPLE_L:
@@ -80,6 +82,8 @@ bool llvm::isTexOp(unsigned opcode)
case AMDIL::TEX_SAMPLE_C_LB:
case AMDIL::TEX_SAMPLE_G:
case AMDIL::TEX_SAMPLE_C_G:
+ case AMDIL::TEX_GET_GRADIENTS_H:
+ case AMDIL::TEX_GET_GRADIENTS_V:
return true;
}
}
diff --git a/src/gallium/drivers/radeon/R600Instructions.td
b/src/gallium/drivers/radeon/R600Instructions.td
index 16ed4fb..0a73b5c 100644
--- a/src/gallium/drivers/radeon/R600Instructions.td
+++ b/src/gallium/drivers/radeon/R600Instructions.td
@@ -387,6 +387,27 @@ def CNDE_INT : R600_3OP <
/* Texture instructions */
+
+def TEX_LD : R600_TEX <
+ 0x03, "TEX_LD",
+ [(set R600_Reg128:$dst, (int_AMDGPU_txf R600_Reg128:$src0, imm:$src1,
imm:$src2))]
+>;
+
+def TEX_GET_TEXTURE_RESINFO : R600_TEX <
+ 0x04, "TEX_GET_TEXTURE_RESINFO",
+ [(set R600_Reg128:$dst, (int_AMDGPU_txq R600_Reg128:$src0, imm:$src1,
imm:$src2))]
+>;
+
+def TEX_GET_GRADIENTS_H : R600_TEX <
+ 0x07, "TEX_GET_GRADIENTS_H",
+ [(set R600_Reg128:$dst, (int_AMDGPU_ddx R600_Reg128:$src0, imm:$src1,
imm:$src2))]
+>;
+
+def TEX_GET_GRADIENTS_V : R600_TEX <
+
[Mesa-dev] [PATCH 08/12] radeon/llvm: add support for AHSR/LSHR/LSHL instructions
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/radeon/R600InstrInfo.cpp | 12
src/gallium/drivers/radeon/R600InstrInfo.h |1 +
src/gallium/drivers/radeon/R600Instructions.td |8 +
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 32
4 files changed, 53 insertions(+)
diff --git a/src/gallium/drivers/radeon/R600InstrInfo.cpp
b/src/gallium/drivers/radeon/R600InstrInfo.cpp
index 0c7ffc4..ed4fcc9 100644
--- a/src/gallium/drivers/radeon/R600InstrInfo.cpp
+++ b/src/gallium/drivers/radeon/R600InstrInfo.cpp
@@ -73,10 +73,22 @@ unsigned R600InstrInfo::getISAOpcode(unsigned opcode) const
case AMDIL::MOVE_i32:
return AMDIL::MOV;
case AMDIL::SHR_i32:
+ return getASHRop();
+case AMDIL::USHR_i32:
return getLSHRop();
}
}
+unsigned R600InstrInfo::getASHRop() const
+{
+ unsigned gen =
TM.getSubtarget().device()->getGeneration();
+ if (gen < AMDILDeviceInfo::HD5XXX) {
+ return AMDIL::ASHR_r600;
+ } else {
+ return AMDIL::ASHR_eg;
+ }
+}
+
unsigned R600InstrInfo::getLSHRop() const
{
unsigned gen = TM.getSubtarget().device()->getGeneration();
diff --git a/src/gallium/drivers/radeon/R600InstrInfo.h
b/src/gallium/drivers/radeon/R600InstrInfo.h
index aedaa9f..701cf7f 100644
--- a/src/gallium/drivers/radeon/R600InstrInfo.h
+++ b/src/gallium/drivers/radeon/R600InstrInfo.h
@@ -52,6 +52,7 @@ namespace llvm {
bool isTrig(const MachineInstr &MI) const;
unsigned getLSHRop() const;
+ unsigned getASHRop() const;
unsigned getMULHI_UINT() const;
unsigned getMULLO_UINT() const;
unsigned getRECIP_UINT() const;
diff --git a/src/gallium/drivers/radeon/R600Instructions.td
b/src/gallium/drivers/radeon/R600Instructions.td
index 0a73b5c..9df0570 100644
--- a/src/gallium/drivers/radeon/R600Instructions.td
+++ b/src/gallium/drivers/radeon/R600Instructions.td
@@ -535,6 +535,12 @@ class LSHR_Common inst> : R600_2OP <
let AMDILOp = AMDILInst.USHR_i32;
}
+class ASHR_Common inst> : R600_2OP <
+ inst, "ASHR $dst, $src0, $src1",
+ [] >{
+ let AMDILOp = AMDILInst.SHR_i32;
+}
+
class MULHI_INT_Common inst> : R600_2OP <
inst, "MULHI_INT $dst, $src0, $src1",
[] >{
@@ -645,6 +651,7 @@ let Gen = AMDGPUGen.R600 in {
def INT_TO_FLT_r600 : INT_TO_FLT_Common<0x6c>;
def SIN_r600 : SIN_Common<0x6E>;
def COS_r600 : COS_Common<0x6F>;
+ def ASHR_r600 : ASHR_Common<0x70>;
def LSHR_r600 : LSHR_Common<0x71>;
def LSHL_r600 : LSHL_Common<0x72>;
def MULLO_INT_r600 : MULLO_INT_Common<0x73>;
@@ -815,6 +822,7 @@ class TRIG_eg : Pat<
let Gen = AMDGPUGen.EG_CAYMAN in {
def MULADD_eg : MULADD_Common<0x14>;
+ def ASHR_eg : ASHR_Common<0x15>;
def LSHR_eg : LSHR_Common<0x16>;
def LSHL_eg : LSHL_Common<0x17>;
def CNDE_eg : CNDE_Common<0x19>;
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index fe5d1b8..2932bdd 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -533,6 +533,35 @@ static void tex_fetch_args(
emit_data->dst_type = LLVMVectorType(bld_base->base.elem_type, 4);
}
+static void emit_shl(
+ const struct lp_build_tgsi_action * action,
+ struct lp_build_tgsi_context * bld_base,
+ struct lp_build_emit_data * emit_data)
+{
+ LLVMBuilderRef builder = bld_base->base.gallivm->builder;
+ emit_data->output[emit_data->chan] = LLVMBuildShl(builder,
+ emit_data->args[0], emit_data->args[1], "");
+}
+
+static void emit_ushr(
+ const struct lp_build_tgsi_action * action,
+ struct lp_build_tgsi_context * bld_base,
+ struct lp_build_emit_data * emit_data)
+{
+ LLVMBuilderRef builder = bld_base->base.gallivm->builder;
+ emit_data->output[emit_data->chan] = LLVMBuildLShr(builder,
+ emit_data->args[0], emit_data->args[1], "");
+}
+static void emit_ishr(
+ const struct lp_build_tgsi_action * action,
+ struct lp_build_tgsi_context * bld_base,
+ struct lp_build_emit_data * emit_data)
+{
+ LLVMBuilderRef builder = bld_base->base.gallivm->builder;
+ emit_data->output[emit_data->chan] = LLVMBuildAShr(builder,
+ emit_data->args[0], emit_data->args[1], "");
+}
+
static void emit_immediate(struct lp_build_tgsi_context * bld_base,
const struct tgsi_full_immediate *imm)
{
@@ -606,6 +635,9 @@ void radeon_llvm_context_init(struct radeon_llvm_context *
ctx)
lp_set_default_actions(bld_base);
+ bld_base->op_actions[TGSI_OPCODE_SHL].emit = emit_shl;
+ bld_base->op_actions[TGSI_OPCODE_ISHR].emit = emit_ishr;
+ bld_base->op_actions[TGSI_OPCODE_USHR].emit = emit_ushr;
bld_base->op_actions[TGSI_OPCODE_DDX].intr_name = "llvm.AMDGPU.ddx";
[Mesa-dev] [PATCH 09/12] radeon/llvm: add missing cases for BREAK/CONTINUE
Signed-off-by: Vadim Girlin --- src/gallium/drivers/radeon/AMDGPUUtil.cpp |1 + src/gallium/drivers/radeon/R600CodeEmitter.cpp |2 ++ 2 files changed, 3 insertions(+) diff --git a/src/gallium/drivers/radeon/AMDGPUUtil.cpp b/src/gallium/drivers/radeon/AMDGPUUtil.cpp index 78e1c4b..f4e60aa 100644 --- a/src/gallium/drivers/radeon/AMDGPUUtil.cpp +++ b/src/gallium/drivers/radeon/AMDGPUUtil.cpp @@ -105,6 +105,7 @@ bool llvm::isFCOp(unsigned opcode) case AMDIL::BREAK_LOGICALZ_f32: case AMDIL::BREAK_LOGICALNZ_i32: case AMDIL::BREAK_LOGICALZ_i32: + case AMDIL::BREAK_LOGICALNZ_f32: case AMDIL::CONTINUE_LOGICALNZ_f32: case AMDIL::IF_LOGICALNZ_i32: case AMDIL::IF_LOGICALZ_f32: diff --git a/src/gallium/drivers/radeon/R600CodeEmitter.cpp b/src/gallium/drivers/radeon/R600CodeEmitter.cpp index 53fdd15..e0bc95b 100644 --- a/src/gallium/drivers/radeon/R600CodeEmitter.cpp +++ b/src/gallium/drivers/radeon/R600CodeEmitter.cpp @@ -568,6 +568,7 @@ void R600CodeEmitter::emitFCInstr(MachineInstr &MI) case AMDIL::BREAK_LOGICALZ_f32: instr = FC_BREAK; break; + case AMDIL::BREAK_LOGICALNZ_f32: case AMDIL::BREAK_LOGICALNZ_i32: instr = FC_BREAK_NZ_INT; break; @@ -575,6 +576,7 @@ void R600CodeEmitter::emitFCInstr(MachineInstr &MI) instr = FC_BREAK_Z_INT; break; case AMDIL::CONTINUE_LOGICALNZ_f32: + case AMDIL::CONTINUE_LOGICALNZ_i32: instr = FC_CONTINUE; break; /* XXX: This assumes that all IFs will be if (x != 0). If we add -- 1.7.10.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/12] radeon/llvm: add support for some ALU instructions
Add support for IABS, NOT, AND, XOR, OR, UADD, UDIV, IDIV, MOD, UMOD, INEG,
I2F, U2F, F2U, F2I, USEQ, USGE, USLT, USNE, ISGE, ISLT, ROUND, MIN, MAX,
IMIN, IMAX, UMIN, UMAX
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/radeon/AMDGPUGenInstrEnums.pl |2 +-
src/gallium/drivers/radeon/AMDGPUIntrinsics.td |6 +-
src/gallium/drivers/radeon/R600Instructions.td | 61 -
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 237 +++-
4 files changed, 293 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/radeon/AMDGPUGenInstrEnums.pl
b/src/gallium/drivers/radeon/AMDGPUGenInstrEnums.pl
index 1fd4fb0..c6d4387 100644
--- a/src/gallium/drivers/radeon/AMDGPUGenInstrEnums.pl
+++ b/src/gallium/drivers/radeon/AMDGPUGenInstrEnums.pl
@@ -41,7 +41,7 @@ my $FILE_TYPE = $ARGV[0];
open AMDIL, '<', 'AMDILInstructions.td';
-my @INST_ENUMS = ('NONE', 'FEQ', 'FGE', 'FLT', 'FNE', 'MOVE_f32', 'MOVE_i32',
'FTOI', 'ITOF', 'CMOVLOG_f32', 'UGT', 'IGE', 'INE', 'UGE', 'IEQ');
+my @INST_ENUMS = ('NONE', 'FEQ', 'FGE', 'FLT', 'FNE', 'MOVE_f32', 'MOVE_i32',
'FTOI', 'ITOF', 'CMOVLOG_f32', 'UGT', 'IGE', 'INE', 'UGE', 'IEQ',
'BINARY_OR_i32', 'BINARY_NOT_i32');
while () {
if ($_ =~ /defm\s+([A-Z_]+)\s+:\s+([A-Za-z0-9]+);
def int_AMDGPU_seq : Intrinsic<[llvm_float_ty], [llvm_float_ty,
llvm_float_ty], []>;
def int_AMDGPU_sgt : Intrinsic<[llvm_float_ty], [llvm_float_ty,
llvm_float_ty], []>;
- def int_AMDGPU_sge : BinaryIntFloat;
+ def int_AMDGPU_sge : Intrinsic<[llvm_float_ty], [llvm_float_ty,
llvm_float_ty], []>;
def int_AMDGPU_sin : Intrinsic<[llvm_float_ty], [llvm_float_ty], []>;
def int_AMDGPU_sle : Intrinsic<[llvm_float_ty], [llvm_float_ty,
llvm_float_ty], []>;
def int_AMDGPU_sne : Intrinsic<[llvm_float_ty], [llvm_float_ty,
llvm_float_ty], []>;
@@ -50,6 +50,10 @@ let TargetPrefix = "AMDGPU", isTarget = 1 in {
def int_AMDGPU_trunc : Intrinsic<[llvm_float_ty], [llvm_float_ty], []>;
def int_AMDGPU_ddx : Intrinsic<[llvm_v4f32_ty], [llvm_v4f32_ty, llvm_i32_ty,
llvm_i32_ty], []>;
def int_AMDGPU_ddy : Intrinsic<[llvm_v4f32_ty], [llvm_v4f32_ty, llvm_i32_ty,
llvm_i32_ty], []>;
+ def int_AMDGPU_imax : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty],
[]>;
+ def int_AMDGPU_imin : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty],
[]>;
+ def int_AMDGPU_umax : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty],
[]>;
+ def int_AMDGPU_umin : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty],
[]>;
}
let TargetPrefix = "TGSI", isTarget = 1 in {
diff --git a/src/gallium/drivers/radeon/R600Instructions.td
b/src/gallium/drivers/radeon/R600Instructions.td
index 9df0570..edbade7 100644
--- a/src/gallium/drivers/radeon/R600Instructions.td
+++ b/src/gallium/drivers/radeon/R600Instructions.td
@@ -84,7 +84,7 @@ class R600_3OP inst, string opName, list
pattern,
InstR600 {
@@ -311,6 +311,18 @@ def TRUNC : R600_1OP <
[(set R600_Reg32:$dst, (int_AMDGPU_trunc R600_Reg32:$src))]
>;
+def CEIL : R600_1OP <
+ 0x12, "CEIL",
+ [(set R600_Reg32:$dst, (int_AMDIL_round_neginf R600_Reg32:$src))]> {
+ let AMDILOp = AMDILInst.ROUND_NEGINF_f32;
+}
+
+def RNDNE : R600_1OP <
+ 0x13, "RNDNE",
+ [(set R600_Reg32:$dst, (int_AMDIL_round_nearest R600_Reg32:$src))]> {
+ let AMDILOp = AMDILInst.ROUND_NEAREST_f32;
+}
+
def FLOOR : R600_1OP <
0x14, "FLOOR",
[(set R600_Reg32:$dst, (int_AMDGPU_floor R600_Reg32:$src))]
@@ -329,59 +341,88 @@ def AND_INT : R600_2OP <
let AMDILOp = AMDILInst.AND_i32;
}
+def OR_INT : R600_2OP <
+ 0x31, "OR_INT",
+ []>{
+ let AMDILOp = AMDILInst.BINARY_OR_i32;
+}
+
def XOR_INT : R600_2OP <
0x32, "XOR_INT",
[]
>;
+def NOT_INT : R600_1OP <
+ 0x33, "NOT_INT",
+ []>{
+ let AMDILOp = AMDILInst.BINARY_NOT_i32;
+}
+
def ADD_INT : R600_2OP <
- 0x34, "ADD_INT $dst, $src0, $src1",
+ 0x34, "ADD_INT",
[]>{
let AMDILOp = AMDILInst.ADD_i32;
}
def SUB_INT : R600_2OP <
- 0x35, "SUB_INT $dst, $src0, $src1",
+ 0x35, "SUB_INT",
[]
>;
+def MAX_INT : R600_2OP <
+ 0x36, "MAX_INT",
+ [(set R600_Reg32:$dst, (int_AMDGPU_imax R600_Reg32:$src0,
R600_Reg32:$src1))]>;
+
+def MIN_INT : R600_2OP <
+ 0x37, "MIN_INT",
+ [(set R600_Reg32:$dst, (int_AMDGPU_imin R600_Reg32:$src0,
R600_Reg32:$src1))]>;
+
+def MAX_UINT : R600_2OP <
+ 0x38, "MAX_UINT",
+ [(set R600_Reg32:$dst, (int_AMDGPU_umax R600_Reg32:$src0,
R600_Reg32:$src1))]>;
+
+def MIN_UINT : R600_2OP <
+ 0x39, "MIN_UINT",
+ [(set R600_Reg32:$dst, (int_AMDGPU_umin R600_Reg32:$src0,
R600_Reg32:$src1))]>;
+
+
def SETE_INT : R600_2OP <
- 0x3A, "SETE_INT $dst, $src0, $src1",
+ 0x3A, "SETE_INT",
[]>{
let AMDILOp = AMDILInst.IEQ;
}
def SETGT_INT : R600_2OP <
- 0x3B, "SGT_INT $dst, $src0, $src1",
+ 0x3B, "SGT_INT",
[]
>;
def SETGE_INT : R600_2OP <
- 0x3C, "SETGE_INT $dst, $src0, $src1",
+ 0x3C, "SETGE_INT",
[]>{
let AMDILOp = AMDILInst.IGE;
}
def SETNE_INT : R600_2OP <
- 0x3D, "SETNE_INT $ds
[Mesa-dev] [PATCH 11/12] radeon/llvm: add support for CUBE ALU instruction
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/radeon/AMDGPUIntrinsics.td |1 +
src/gallium/drivers/radeon/AMDGPUUtil.cpp | 11 +
src/gallium/drivers/radeon/AMDGPUUtil.h|1 +
src/gallium/drivers/radeon/R600CodeEmitter.cpp | 58
src/gallium/drivers/radeon/R600Instructions.td | 13 +-
5 files changed, 63 insertions(+), 21 deletions(-)
diff --git a/src/gallium/drivers/radeon/AMDGPUIntrinsics.td
b/src/gallium/drivers/radeon/AMDGPUIntrinsics.td
index d8ea452..089d3b6 100644
--- a/src/gallium/drivers/radeon/AMDGPUIntrinsics.td
+++ b/src/gallium/drivers/radeon/AMDGPUIntrinsics.td
@@ -54,6 +54,7 @@ let TargetPrefix = "AMDGPU", isTarget = 1 in {
def int_AMDGPU_imin : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty],
[]>;
def int_AMDGPU_umax : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty],
[]>;
def int_AMDGPU_umin : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty],
[]>;
+ def int_AMDGPU_cube : Intrinsic<[llvm_v4f32_ty], [llvm_v4f32_ty], []>;
}
let TargetPrefix = "TGSI", isTarget = 1 in {
diff --git a/src/gallium/drivers/radeon/AMDGPUUtil.cpp
b/src/gallium/drivers/radeon/AMDGPUUtil.cpp
index f4e60aa..8563b9d 100644
--- a/src/gallium/drivers/radeon/AMDGPUUtil.cpp
+++ b/src/gallium/drivers/radeon/AMDGPUUtil.cpp
@@ -98,6 +98,17 @@ bool llvm::isReductionOp(unsigned opcode)
}
}
+bool llvm::isCubeOp(unsigned opcode)
+{
+ switch(opcode) {
+ default: return false;
+ case AMDIL::CUBE_r600:
+ case AMDIL::CUBE_eg:
+ return true;
+ }
+}
+
+
bool llvm::isFCOp(unsigned opcode)
{
switch(opcode) {
diff --git a/src/gallium/drivers/radeon/AMDGPUUtil.h
b/src/gallium/drivers/radeon/AMDGPUUtil.h
index 299146e..38a7ebc 100644
--- a/src/gallium/drivers/radeon/AMDGPUUtil.h
+++ b/src/gallium/drivers/radeon/AMDGPUUtil.h
@@ -29,6 +29,7 @@ bool isPlaceHolderOpcode(unsigned opcode);
bool isTransOp(unsigned opcode);
bool isTexOp(unsigned opcode);
bool isReductionOp(unsigned opcode);
+bool isCubeOp(unsigned opcode);
bool isFCOp(unsigned opcode);
/* XXX: Move these to AMDGPUInstrInfo.h */
diff --git a/src/gallium/drivers/radeon/R600CodeEmitter.cpp
b/src/gallium/drivers/radeon/R600CodeEmitter.cpp
index e0bc95b..eed53a4 100644
--- a/src/gallium/drivers/radeon/R600CodeEmitter.cpp
+++ b/src/gallium/drivers/radeon/R600CodeEmitter.cpp
@@ -44,8 +44,9 @@ namespace {
const R600RegisterInfo * TRI;
bool evergreenEncoding;
+ bool isCube;
bool isReduction;
- unsigned reductionElement;
+ unsigned currentElement;
bool isLast;
unsigned section_start;
@@ -53,7 +54,7 @@ namespace {
public:
R600CodeEmitter(formatted_raw_ostream &OS) : MachineFunctionPass(ID),
- _OS(OS), TM(NULL), evergreenEncoding(false), isReduction(false),
+ _OS(OS), TM(NULL), evergreenEncoding(false), isCube(false),
isReduction(false),
isLast(true) { }
const char *getPassName() const { return "AMDGPU Machine Code Emitter"; }
@@ -65,7 +66,7 @@ namespace {
private:
void emitALUInstr(MachineInstr &MI);
- void emitSrc(const MachineOperand & MO);
+ void emitSrc(const MachineOperand & MO, int chan_override = -1);
void emitDst(const MachineOperand & MO);
void emitALU(MachineInstr &MI, unsigned numSrc);
void emitTexInstr(MachineInstr &MI);
@@ -176,11 +177,19 @@ bool
R600CodeEmitter::runOnMachineFunction(MachineFunction &MF) {
} else if (isReductionOp(MI.getOpcode())) {
isReduction = true;
isLast = false;
-for (reductionElement = 0; reductionElement < 4;
reductionElement++) {
- isLast = (reductionElement == 3);
+for (currentElement = 0; currentElement < 4; currentElement++) {
+ isLast = (currentElement == 3);
emitALUInstr(MI);
}
isReduction = false;
+ } else if (isCubeOp(MI.getOpcode())) {
+ isCube = true;
+ isLast = false;
+ for (currentElement = 0; currentElement < 4; currentElement++) {
+isLast = (currentElement == 3);
+emitALUInstr(MI);
+ }
+ isCube = false;
} else if (MI.getOpcode() == AMDIL::RETURN ||
MI.getOpcode() == AMDIL::BUNDLE ||
MI.getOpcode() == AMDIL::KILL) {
@@ -307,18 +316,25 @@ void R600CodeEmitter::emitALUInstr(MachineInstr &MI)
/* Emit instruction type */
emitByte(0);
- unsigned int opIndex;
- for (opIndex = 1; opIndex < numOperands; opIndex++) {
-/* Literal constants are always stored as the last operand. */
-if (MI.getOperand(opIndex).isImm() || MI.getOperand(opIndex).isFPImm()) {
- break;
+ if (isCube) {
+static const int cube_src_swz[] = {2, 2, 0, 1};
+emitSrc(MI.getOperand(1), cube_src_swz[currentElement]);
+emitSrc(MI.getOperand(1), cube_src_swz[3-currentElement]);
+emitNullBytes(SRC_BYTE_COUNT);
+ } else {
+
[Mesa-dev] [PATCH 12/12] radeon/llvm: add suport for cube textures
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_llvm.c | 22 -
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 92 +++-
2 files changed, 91 insertions(+), 23 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index b2cdbd0..2f83009 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -203,28 +203,7 @@ static struct lp_build_tgsi_action dot_action = {
.intr_name = "llvm.AMDGPU.dp4"
};
-static void txp_fetch_args(
- struct lp_build_tgsi_context * bld_base,
- struct lp_build_emit_data * emit_data)
-{
- LLVMValueRef src_w;
- unsigned chan;
- LLVMValueRef coords[4];
-
- emit_data->dst_type = LLVMVectorType(bld_base->base.elem_type, 4);
- src_w = lp_build_emit_fetch(bld_base, emit_data->inst, 0, TGSI_CHAN_W);
- for (chan = 0; chan < 3; chan++ ) {
- LLVMValueRef arg = lp_build_emit_fetch(bld_base,
- emit_data->inst, 0, chan);
- coords[chan] = lp_build_emit_llvm_binary(bld_base,
- TGSI_OPCODE_DIV, arg, src_w);
- }
- coords[3] = bld_base->base.one;
- emit_data->args[0] = lp_build_gather_values(bld_base->base.gallivm,
- coords, 4);
- emit_data->arg_count = 1;
-}
LLVMModuleRef r600_tgsi_llvm(
struct radeon_llvm_context * ctx,
@@ -257,7 +236,6 @@ LLVMModuleRef r600_tgsi_llvm(
bld_base->op_actions[TGSI_OPCODE_TXL].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TXF].emit = llvm_emit_tex;
bld_base->op_actions[TGSI_OPCODE_TXQ].emit = llvm_emit_tex;
- bld_base->op_actions[TGSI_OPCODE_TXP].fetch_args = txp_fetch_args;
bld_base->op_actions[TGSI_OPCODE_TXP].emit = llvm_emit_tex;
lp_build_tgsi_llvm(bld_base, tokens);
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 502d551..6e6fc3d 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -509,6 +509,87 @@ static void kil_emit(
}
}
+
+static void emit_prepare_cube_coords(
+ struct lp_build_tgsi_context * bld_base,
+ struct lp_build_emit_data * emit_data)
+{
+ boolean shadowcube = (emit_data->inst->Texture.Texture ==
TGSI_TEXTURE_SHADOWCUBE);
+ struct gallivm_state * gallivm = bld_base->base.gallivm;
+ LLVMBuilderRef builder = gallivm->builder;
+ LLVMTypeRef type = bld_base->base.elem_type;
+ LLVMValueRef coords[4];
+ LLVMValueRef mad_args[3];
+ unsigned i, cnt;
+
+ LLVMValueRef v = lp_build_intrinsic(builder, "llvm.AMDGPU.cube",
+ LLVMVectorType(type, 4),
+ &emit_data->args[0],1);
+
+ /* save src.w for shadow cube */
+ cnt = shadowcube ? 3 : 4;
+
+ for (i = 0; i < cnt; ++i) {
+ LLVMValueRef idx = lp_build_const_int32(gallivm, i);
+ coords[i] = LLVMBuildExtractElement(builder, v, idx, "");
+ }
+
+ coords[2] = lp_build_intrinsic(builder, "llvm.AMDIL.fabs.",
+ type, &coords[2], 1);
+ coords[2] = lp_build_intrinsic(builder, "llvm.AMDGPU.rcp",
+ type, &coords[2], 1);
+
+ mad_args[1] = coords[2];
+ mad_args[2] = LLVMConstReal(type, 1.5);
+
+ mad_args[0] = coords[0];
+ coords[0] = lp_build_intrinsic(builder, "llvm.AMDIL.mad.",
+ type, mad_args, 3);
+
+ mad_args[0] = coords[1];
+ coords[1] = lp_build_intrinsic(builder, "llvm.AMDIL.mad.",
+ type, mad_args, 3);
+
+ /* apply yxwy swizzle to cooords */
+ coords[2] = coords[3];
+ coords[3] = coords[1];
+ coords[1] = coords[0];
+ coords[0] = coords[3];
+
+ emit_data->args[0] = lp_build_gather_values(bld_base->base.gallivm,
+ coords, 4);
+}
+
+static void txp_fetch_args(
+ struct lp_build_tgsi_context * bld_base,
+ struct lp_build_emit_data * emit_data)
+{
+ const struct tgsi_full_instruction * inst = emit_data->inst;
+ LLVMValueRef src_w;
+ unsigned chan;
+ LLVMValueRef coords[4];
+
+ emit_data->dst_type = LLVMVectorType(bld_base->base.elem_type, 4);
+ src_w = lp_build_emit_fetch(bld_base, emit_data->inst, 0, TGSI_CHAN_W);
+
+ for (chan = 0; chan < 3; chan++ ) {
+ LLVMValueRef arg = lp_build_emit_fetch(bld_base,
+ emit_data->inst, 0, chan);
+ coords[chan] = lp_build_emit_llvm_binary(bld_base,
+ TGSI_OPCODE_DIV, arg, src_w);
+ }
+ coords[3] = bld_base->base.one;
+ emit
Re: [Mesa-dev] [PATCH 06/10] i965: Parameterize HiZ code to prepare for adding blitting.
On 2 May 2012 14:20, Chris Forbes wrote:
> +void
> +brw_blorp_params::exec(struct intel_context *intel) const
> +{
> + switch (intel->gen) {
> + case 6:
> + gen6_blorp_exec(intel, this);
> + break;
> + case 7:
> + gen7_blorp_exec(intel, this);
> + break;
> + default:
> + /* BLORP is not supported before Gen7. */
> + assert(false);
> + break;
> + }
> +}
>
> Presumably the comment in the default case should be Gen6 ?
>
> -- Chris
>
Whoops, yes. Fixed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): fbo: Only reuse depth/ stencil attachments if the parameters match.
On 05/07/2012 11:53 AM, Paul Berry wrote:
Module: Mesa
Branch: master
Commit: b9819a027d08b38abb380526bed9f2908ffeb507
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=b9819a027d08b38abb380526bed9f2908ffeb507
Author: Paul Berry
Date: Fri Apr 13 21:50:08 2012 -0700
fbo: Only reuse depth/stencil attachments if the parameters match.
When the user attaches a texture to one of the depth/stencil
attachment points (GL_STENCIL_ATTACHMENT or GL_DEPTH_ATTACHMENT), we
check to see if the same texture is also attached to the other
attachment point, and if so, we re-use the existing texture
attachment. This is necessary to ensure that if the user later
queries what is attached to GL_DEPTH_STENCIL_ATTACHMENT, they will not
receive an error.
If, however, the user attaches buffers to the two different attachment
points using different parameters (e.g. a different miplevel), then we
can't re-use the existing texture attachment, because it is pointing
to the wrong part of the texture. This might occur as a transitory
condition if, for example, if the user attached miplevel zero of a
texture to GL_STENCIL_ATTACHMENT and GL_DEPTH_ATTACHMENT, rendered to
it, and then later attempted to attach miplevel one of the same
texture to GL_STENCIL_ATTACHMENT and GL_DEPTH_ATTACHMENT.
This patch causes Mesa to check that GL_STENCIL_ATTACHMENT and
GL_DEPTH_ATTACHMENT use the same attachment parameters before
attempting to share the texture attachment.
On i965 Gen6, fixes piglit tests
"texturing/depthstencil-render-miplevels 1024 depth_stencil_shared"
and "texturing/depthstencil-render-miplevels 1024
stencil_depth_shared".
Reviewed-by: Chad Versace
---
src/mesa/main/fbobject.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 26ae108..f563694 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2023,7 +2023,11 @@ framebuffer_texture(struct gl_context *ctx, const char
*caller, GLenum target,
_glthread_LOCK_MUTEX(fb->Mutex);
if (texObj) {
if (attachment == GL_DEPTH_ATTACHMENT&&
- texObj == fb->Attachment[BUFFER_STENCIL].Texture) {
+ texObj == fb->Attachment[BUFFER_STENCIL].Texture&&
+ level == fb->Attachment[BUFFER_STENCIL].TextureLevel&&
+ _mesa_tex_target_to_face(textarget) ==
+ fb->Attachment[BUFFER_STENCIL].CubeMapFace&&
+ zoffset == fb->Attachment[BUFFER_STENCIL].Zoffset) {
/* The texture object is already attached to the stencil attachment
* point. Don't create a new renderbuffer; just reuse the stencil
* attachment's. This is required to prevent a GL error in
@@ -2032,8 +2036,12 @@ framebuffer_texture(struct gl_context *ctx, const char
*caller, GLenum target,
reuse_framebuffer_texture_attachment(fb, BUFFER_DEPTH,
BUFFER_STENCIL);
} else if (attachment == GL_STENCIL_ATTACHMENT&&
-texObj == fb->Attachment[BUFFER_DEPTH].Texture) {
-/* As above, but with depth and stencil juxtaposed. */
+texObj == fb->Attachment[BUFFER_DEPTH].Texture&&
+ level == fb->Attachment[BUFFER_DEPTH].TextureLevel&&
+ _mesa_tex_target_to_face(textarget) ==
+ fb->Attachment[BUFFER_DEPTH].CubeMapFace&&
+ zoffset == fb->Attachment[BUFFER_DEPTH].Zoffset) {
+/* As above, but with depth and stencil transposed. */
reuse_framebuffer_texture_attachment(fb, BUFFER_STENCIL,
BUFFER_DEPTH);
} else {
It looks like there's some common code there that could be put into a
utility function and shared. Something like:
/**
* Check if the frambuffer attachment point matches the given texture
* image info.
*/
GLboolean
attachment_matches_texture(const struct gl_renderbuffer_attachment *att,
const gl_texture_object *texObj,
GLuint texTarget, GLuint level, GLuint
zoffset)
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] mesa: move gl_client_array*[] from vbo_draw_func into gl_context
On Mon, May 7, 2012 at 6:24 PM, Brian Paul wrote:
> On Tue, Apr 24, 2012 at 4:00 PM, Marek Olšák wrote:
>> In the future we'd like to treat vertex arrays as a state and
>> not as a parameter to the draw function. This is the first step
>> towards that goal.
>
> Part of the goal is to avoid array re-validation for every draw call,
> right? Maybe say so in the comment.
Will do.
>
> More comments below.
>
>
>>
>> This commit adds:
>> const struct gl_client_array **gl_context::Array::Arrays.
>>
>> The pointer is changed in:
>> * vbo_draw_method
>> * vbo_rebase_prims - unused by gallium
>> * vbo_split_prims - unused by gallium
>> * st_RasterPos
>> ---
>> src/mesa/drivers/dri/i965/brw_draw.c | 2 +-
>> src/mesa/drivers/dri/i965/brw_draw.h | 1 -
>> src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c | 9 -
>> src/mesa/main/mtypes.h | 3 +++
>> src/mesa/state_tracker/st_cb_rasterpos.c | 5 -
>> src/mesa/state_tracker/st_draw.c | 2 +-
>> src/mesa/state_tracker/st_draw.h | 2 --
>> src/mesa/state_tracker/st_draw_feedback.c | 2 +-
>> src/mesa/tnl/t_draw.c | 3 ++-
>> src/mesa/tnl/tnl.h | 1 -
>> src/mesa/vbo/vbo.h | 1 -
>> src/mesa/vbo/vbo_context.h | 15 +++
>> src/mesa/vbo/vbo_exec_array.c | 12 ++--
>> src/mesa/vbo/vbo_exec_draw.c | 3 +--
>> src/mesa/vbo/vbo_rebase.c | 8 ++--
>> src/mesa/vbo/vbo_save_draw.c | 3 +--
>> src/mesa/vbo/vbo_split_copy.c | 9 +++--
>> src/mesa/vbo/vbo_split_inplace.c | 9 +++--
>> 18 files changed, 59 insertions(+), 31 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
>> b/src/mesa/drivers/dri/i965/brw_draw.c
>> index da37b18..30faa95 100644
>> --- a/src/mesa/drivers/dri/i965/brw_draw.c
>> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
>> @@ -531,7 +531,6 @@ retry:
>> }
>>
>> void brw_draw_prims( struct gl_context *ctx,
>> - const struct gl_client_array *arrays[],
>> const struct _mesa_prim *prim,
>> GLuint nr_prims,
>> const struct _mesa_index_buffer *ib,
>> @@ -540,6 +539,7 @@ void brw_draw_prims( struct gl_context *ctx,
>> GLuint max_index,
>> struct gl_transform_feedback_object *tfb_vertcount )
>> {
>> + const struct gl_client_array **arrays = ctx->Array.Arrays;
>> bool retval;
>>
>> if (!_mesa_check_conditional_render(ctx))
>> diff --git a/src/mesa/drivers/dri/i965/brw_draw.h
>> b/src/mesa/drivers/dri/i965/brw_draw.h
>> index b910419..2cc4cb3 100644
>> --- a/src/mesa/drivers/dri/i965/brw_draw.h
>> +++ b/src/mesa/drivers/dri/i965/brw_draw.h
>> @@ -35,7 +35,6 @@ struct brw_context;
>>
>>
>> void brw_draw_prims( struct gl_context *ctx,
>> - const struct gl_client_array *arrays[],
>> const struct _mesa_prim *prims,
>> GLuint nr_prims,
>> const struct _mesa_index_buffer *ib,
>> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
>> b/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
>> index 62fee2e..6358b26 100644
>> --- a/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
>> +++ b/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
>> @@ -216,7 +216,7 @@ get_max_client_stride(struct gl_context *ctx, const
>> struct gl_client_array **arr
>> }
>>
>> static void
>> -TAG(vbo_render_prims)(struct gl_context *ctx, const struct gl_client_array
>> **arrays,
>> +TAG(vbo_render_prims)(struct gl_context *ctx,
>> const struct _mesa_prim *prims, GLuint nr_prims,
>> const struct _mesa_index_buffer *ib,
>> GLboolean index_bounds_valid,
>> @@ -448,7 +448,6 @@ vbo_draw_imm(struct gl_context *ctx, const struct
>> gl_client_array **arrays,
>>
>> static void
>> TAG(vbo_render_prims)(struct gl_context *ctx,
>> - const struct gl_client_array **arrays,
>> const struct _mesa_prim *prims, GLuint nr_prims,
>> const struct _mesa_index_buffer *ib,
>> GLboolean index_bounds_valid,
>> @@ -456,6 +455,7 @@ TAG(vbo_render_prims)(struct gl_context *ctx,
>> struct gl_transform_feedback_object *tfb_vertcount)
>> {
>> struct nouveau_render_state *render = to_render_state(ctx);
>> + const struct gl_client_array **arrays = ctx->Array.Arrays;
>>
>> if (!index_bounds_valid)
>> vbo_get_minmax_indices(ctx, prims, ib, &min_index, &max_index,
>> @@ -484,7 +484,6 @@ TAG(vbo_render_prims)(struct gl_context *ctx,
>>
>> static void
>> TAG(vbo_check_render_prims)(struct gl_context *ctx,
>> - const struct gl_client_array **arrays,
>>
Re: [Mesa-dev] [PATCH] meta: do fallback when texture is enabled for DrawPixels
On Sat, 5 May 2012 09:39:31 +0800, Liu Aleaxander wrote: > On Sat, May 5, 2012 at 2:56 AM, Eric Anholt wrote: > > So > > you can't rely on it being correct here -- you'd need to > > _mesa_update_state(ctx) first. I think it should go at the very top of > > the function, due to the _ImageTransferState check also relying on that. > > But we already did _mesa_update_state at _mesa_DrawPixels() ---> > _mesa_valid_to_render(). Thus I guess we don't need do that again, right? Ah, I hadn't found that _mesa_update_state(). Looks good to me, then. pgp8kJDvIr3Q6.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] shader_test for glsl-to-tgsi ceil bug
On Sat, 05 May 2012 14:43:44 +0200, Christoph Bumiller wrote: > Test case for the "glsl_to_tgsi: use TGSI_OPCODE_CEIL for ir_unop_ceil" > patch attached. This wasn't caught by the generated test for ceil()? That seems strange. pgpRyU9FSoKhk.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: initialize samplers mapping with 0
On 04/29/2012 12:54 AM, Vadim Girlin wrote: On Sat, 2012-04-28 at 13:02 -0700, Kenneth Graunke wrote: On 04/28/2012 12:24 PM, Vadim Girlin wrote: On Sat, 2012-04-28 at 11:42 -0700, Kenneth Graunke wrote: On 04/28/2012 11:20 AM, Vadim Girlin wrote: According to GLSL 1.30 specification, initial value for all uniforms without initializer is 0. Some applications rely on this behaviour, e.g. google's MapGL doesn't set all sampler uniforms. (see https://bugs.freedesktop.org/show_bug.cgi?id=49088 ) Signed-off-by: Vadim Girlin --- Tested with r600g only - no regressions. Awesome find! I was at a complete loss here. :) It turns out this is in the 1.20 spec too; it looks like 1.10 doesn't say (but that isn't too surprising). I might add a comment: /* From the GLSL 1.20 specification, page 24, section 4.3.5 "Uniform": * "The link time initial value is either the value of the variable's * initializer, or 0 if no initializer present. Sampler types cannot * have initializers." */ Also, do you really need the memsets in ir_to_mesa and st_glsl_to_tgsi? Everything should go through the linker, so that seems somewhat redundant. I tested with just the link_uniforms change and that was enough to fix MapsGL on i965/Sandybridge. Without the memset in the st_glsl_to_tgsi firefox crashed with MapGL. Probably some code in the state tracker relies on the synchronized values of the SamplerUnits arrays in the gl_program and gl_shader_program. Also, _mesa_uniform function compares these arrays to check for update, and some piglit test failed due to the following problem: First array is initialized: 0, 0, 0, ... Second (without memset) : 0, 1, 2, ... The app calls Uniform1i to set sampler[1] to 1, so we do first[1]=1, but then it's equal with second[1] and update is not detected. Vadim Ah, okay...I missed that one was operating on the gl_shader_program while the other was setting the parallel structure in the gl_program. I can believe that you'd need that, then. BTW, it seems there is a patch from Ian for this issue on the list: http://lists.freedesktop.org/archives/mesa-dev/2012-April/020767.html Right. Without the first patch in that series, the patch you reference probably isn't sufficient (due to ir_to_mesa and st_glsl_to_tgsi not being modified). Eric had a couple concerns about the first patch in the series, and I haven't had a chance to put together a test case for those issues. Maybe we could combine my patch with the ir_to_mesa and st_glsl_to_tgsi parts from yours? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] libGL.so.* are not installed when configured with "--enable-xlib-glx"
On 05/05/2012 10:17 AM, Sven Joachim wrote: > On 2012-05-03 11:34 +0200, Sven Joachim wrote: > >> When configuring mesa git master with "--enable-xlib-glx", the GL >> library does not get installed. > > Bisection showed that this has been broken by commit 8ffb098234: > > commit 8ffb098234fbc3d2e3c8b3db6912dec9ea7a65eb > Author: Eric Anholt > Date: Sun Feb 5 06:10:56 2012 +0100 > > glx: Convert to automake. > > Reviewed-by: Kenneth Graunke > >> I configured mesa like this: >> >> , >> | % ./configure --enable-xlib-glx --without-gallium-drivers \ >> | --without-dri-drivers --disable-egl --prefix=/tmp/mesa >> ` >> >> and after running make, have the following files in lib: >> >> , >> | % ls -1 lib >> | libGL.so >> | libGL.so.1 >> | libGL.so.1.5.08000 >> | libGLU.so >> | libGLU.so.1 >> | libGLU.so.1.3.08000 >> | libdricore.so >> | libglsl.so >> ` >> >> However, the libGL.so* files do not get installed: >> >> , >> | % ls -1R /tmp/mesa/lib >> | /tmp/mesa/lib: >> | dri >> | libGLU.so >> | libGLU.so.1 >> | libGLU.so.1.3.08000 >> | pkgconfig >> | >> | /tmp/mesa/lib/dri: >> | libdricore.so >> | libglsl.so >> | >> | /tmp/mesa/lib/pkgconfig: >> | dri.pc >> | gl.pc >> | glu.pc >> ` >> >> What went wrong? Perhaps the problem is that you are not building any drivers. Does the problem persist if you configure Mesa like this? ./configure --enable-xlib-glx --without-gallium-drivers --with-dri-drivers=swrast --disable-egl --prefix=/tmp/mesa: Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: initialize samplers mapping with 0
On Mon, 2012-05-07 at 11:37 -0700, Ian Romanick wrote: > On 04/29/2012 12:54 AM, Vadim Girlin wrote: > > On Sat, 2012-04-28 at 13:02 -0700, Kenneth Graunke wrote: > >> On 04/28/2012 12:24 PM, Vadim Girlin wrote: > >>> On Sat, 2012-04-28 at 11:42 -0700, Kenneth Graunke wrote: > On 04/28/2012 11:20 AM, Vadim Girlin wrote: > > According to GLSL 1.30 specification, initial value for all uniforms > > without initializer is 0. Some applications rely on this behaviour, > > e.g. google's MapGL doesn't set all sampler uniforms. > > > > (see https://bugs.freedesktop.org/show_bug.cgi?id=49088 ) > > > > Signed-off-by: Vadim Girlin > > --- > > > > Tested with r600g only - no regressions. > > Awesome find! I was at a complete loss here. :) > > It turns out this is in the 1.20 spec too; it looks like 1.10 doesn't > say (but that isn't too surprising). I might add a comment: > > /* From the GLSL 1.20 specification, page 24, section 4.3.5 "Uniform": > * "The link time initial value is either the value of the variable's > * initializer, or 0 if no initializer present. Sampler types cannot > * have initializers." > */ > > Also, do you really need the memsets in ir_to_mesa and st_glsl_to_tgsi? > Everything should go through the linker, so that seems somewhat > redundant. I tested with just the link_uniforms change and that was > enough to fix MapsGL on i965/Sandybridge. > >>> > >>> Without the memset in the st_glsl_to_tgsi firefox crashed with MapGL. > >>> Probably some code in the state tracker relies on the synchronized > >>> values of the SamplerUnits arrays in the gl_program and > >>> gl_shader_program. Also, _mesa_uniform function compares these arrays to > >>> check for update, and some piglit test failed due to the following > >>> problem: > >>> > >>> First array is initialized: 0, 0, 0, ... > >>> Second (without memset) : 0, 1, 2, ... > >>> > >>> The app calls Uniform1i to set sampler[1] to 1, so we do first[1]=1, but > >>> then it's equal with second[1] and update is not detected. > >>> > >>> Vadim > >> > >> Ah, okay...I missed that one was operating on the gl_shader_program > >> while the other was setting the parallel structure in the gl_program. > >> > >> I can believe that you'd need that, then. > >> > > > > BTW, it seems there is a patch from Ian for this issue on the list: > > > > http://lists.freedesktop.org/archives/mesa-dev/2012-April/020767.html > > Right. Without the first patch in that series, the patch you reference > probably isn't sufficient (due to ir_to_mesa and st_glsl_to_tgsi not > being modified). Eric had a couple concerns about the first patch in > the series, and I haven't had a chance to put together a test case for > those issues. > > Maybe we could combine my patch with the ir_to_mesa and st_glsl_to_tgsi > parts from yours? Of course, feel free to use any parts of this patch if you need. Vadim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/12] radeon/llvm: fix live-in handling for inputs
On Mon, May 07, 2012 at 09:08:47PM +0400, Vadim Girlin wrote:
> Set the input registers as live-in for entry basic block.
>
> Signed-off-by: Vadim Girlin
> ---
> src/gallium/drivers/radeon/AMDGPULowerShaderInstructions.cpp |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/gallium/drivers/radeon/AMDGPULowerShaderInstructions.cpp
> b/src/gallium/drivers/radeon/AMDGPULowerShaderInstructions.cpp
> index d33055c..89e18f0 100644
> --- a/src/gallium/drivers/radeon/AMDGPULowerShaderInstructions.cpp
> +++ b/src/gallium/drivers/radeon/AMDGPULowerShaderInstructions.cpp
> @@ -26,6 +26,9 @@ void
> AMDGPULowerShaderInstructionsPass::preloadRegister(MachineFunction * MF,
>if (!MRI->isLiveIn(physReg)) {
> MRI->addLiveIn(physReg, virtReg);
> MachineBasicBlock &EntryMBB = MF->front();
> +
> +// XXX use EmitLiveInCopies instead?
EmitLiveInCopies() isn't meant to be used by the backends, it is only
supposed to be called by the LLVM Instruction Selection passes.
> +EntryMBB.addLiveIn(physReg);
The preloadRegister() function is duplicated in AMDGPUUtil.cpp as
utilAddLiveIn(). I think this change should go in that function and
then all callers of preloadRegister() should use utilAddLiveIn()
instead.
> BuildMI(MF->front(), EntryMBB.begin(), DebugLoc(),
> TII->get(TargetOpcode::COPY),
> virtReg)
> .addReg(physReg);
-Tom
> --
> 1.7.10.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] libGL.so.* are not installed when configured with "--enable-xlib-glx"
On 2012-05-07 20:48 +0200, Chad Versace wrote: > On 05/05/2012 10:17 AM, Sven Joachim wrote: >> On 2012-05-03 11:34 +0200, Sven Joachim wrote: >> >>> When configuring mesa git master with "--enable-xlib-glx", the GL >>> library does not get installed. >> >> Bisection showed that this has been broken by commit 8ffb098234: >> >> commit 8ffb098234fbc3d2e3c8b3db6912dec9ea7a65eb >> Author: Eric Anholt >> Date: Sun Feb 5 06:10:56 2012 +0100 >> >> glx: Convert to automake. >> >> Reviewed-by: Kenneth Graunke >> >>> I configured mesa like this: >>> >>> , >>> | % ./configure --enable-xlib-glx --without-gallium-drivers \ >>> | --without-dri-drivers --disable-egl --prefix=/tmp/mesa >>> ` >>> >>> and after running make, have the following files in lib: >>> >>> , >>> | % ls -1 lib >>> | libGL.so >>> | libGL.so.1 >>> | libGL.so.1.5.08000 >>> | libGLU.so >>> | libGLU.so.1 >>> | libGLU.so.1.3.08000 >>> | libdricore.so >>> | libglsl.so >>> ` >>> >>> However, the libGL.so* files do not get installed: >>> >>> , >>> | % ls -1R /tmp/mesa/lib >>> | /tmp/mesa/lib: >>> | dri >>> | libGLU.so >>> | libGLU.so.1 >>> | libGLU.so.1.3.08000 >>> | pkgconfig >>> | >>> | /tmp/mesa/lib/dri: >>> | libdricore.so >>> | libglsl.so >>> | >>> | /tmp/mesa/lib/pkgconfig: >>> | dri.pc >>> | gl.pc >>> | glu.pc >>> ` >>> >>> What went wrong? > > Perhaps the problem is that you are not building any drivers. No, and building dri drivers does not seem to make sense here anyway since the xlib-based library will not load them, AFAIK. > Does the problem persist if you configure Mesa like this? > > ./configure --enable-xlib-glx --without-gallium-drivers > --with-dri-drivers=swrast --disable-egl --prefix=/tmp/mesa: Yes. Cheers, Sven ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/12] radeon/llvm: fix live-in handling for inputs
Set the input registers as live-in for entry basic block.
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/radeon/AMDGPUUtil.cpp |1 +
src/gallium/drivers/radeon/R600LowerShaderInstructions.cpp |4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/AMDGPUUtil.cpp
b/src/gallium/drivers/radeon/AMDGPUUtil.cpp
index 6fb01b6..663a77f 100644
--- a/src/gallium/drivers/radeon/AMDGPUUtil.cpp
+++ b/src/gallium/drivers/radeon/AMDGPUUtil.cpp
@@ -118,6 +118,7 @@ void AMDGPU::utilAddLiveIn(MachineFunction * MF,
MachineRegisterInfo & MRI,
{
if (!MRI.isLiveIn(physReg)) {
MRI.addLiveIn(physReg, virtReg);
+ MF->front().addLiveIn(physReg);
BuildMI(MF->front(), MF->front().begin(), DebugLoc(),
TII->get(TargetOpcode::COPY), virtReg)
.addReg(physReg);
diff --git a/src/gallium/drivers/radeon/R600LowerShaderInstructions.cpp
b/src/gallium/drivers/radeon/R600LowerShaderInstructions.cpp
index 394ee70..742b50f 100644
--- a/src/gallium/drivers/radeon/R600LowerShaderInstructions.cpp
+++ b/src/gallium/drivers/radeon/R600LowerShaderInstructions.cpp
@@ -13,6 +13,7 @@
#include "AMDGPU.h"
#include "AMDGPULowerShaderInstructions.h"
+#include "AMDGPUUtil.h"
#include "AMDIL.h"
#include "AMDILInstrInfo.h"
#include "llvm/CodeGen/MachineFunctionPass.h"
@@ -117,8 +118,7 @@ void
R600LowerShaderInstructionsPass::lowerLOAD_INPUT(MachineInstr &MI)
unsigned newRegister = inputClass->getRegister(inputIndex);
unsigned dstReg = dst.getReg();
- preloadRegister(MI.getParent()->getParent(), TM.getInstrInfo(), newRegister,
- dstReg);
+ AMDGPU::utilAddLiveIn(MI.getParent()->getParent(), *MRI, TM.getInstrInfo(),
newRegister, dstReg);
}
bool R600LowerShaderInstructionsPass::lowerSTORE_OUTPUT(MachineInstr &MI,
--
1.7.10.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/12] radeon/llvm: fixes and some missing features
On Mon, May 07, 2012 at 09:08:42PM +0400, Vadim Girlin wrote: > Some fixes, missing instructions, etc for llvm backend. Comparing to > non-llvm backend, it still fails 9 tests for me on evergreen. > > Also you can find these patches in my github mesa repo, r600_llvm branch: > https://github.com/VadimGirlin/mesa.git Just a small comment on patch 5, but with that change, the whole series is: Reviewed-by: Tom Stellard > > radeon/llvm: use bitcasts for integers > radeon/llvm: use integer comparison for IF > radeon/llvm: fix ABS_i32 instruction lowering > radeon/llvm: add support for v4i32 > radeon/llvm: fix live-in handling for inputs > radeon/llvm: add support for VertexID, InstanceID > radeon/llvm: add support for TXQ/TXF/DDX/DDY instructions > radeon/llvm: add support for AHSR/LSHR/LSHL instructions > radeon/llvm: add missing cases for BREAK/CONTINUE > radeon/llvm: add support for some ALU instructions > radeon/llvm: add support for CUBE ALU instruction > radeon/llvm: add suport for cube textures > > src/gallium/auxiliary/gallivm/lp_bld_tgsi.c|2 - > src/gallium/drivers/r600/r600_llvm.c | 64 +-- > src/gallium/drivers/radeon/AMDGPUGenInstrEnums.pl |2 +- > src/gallium/drivers/radeon/AMDGPUIntrinsics.td | 11 +- > .../drivers/radeon/AMDGPULowerInstructions.cpp |9 +- > .../radeon/AMDGPULowerShaderInstructions.cpp |3 + > src/gallium/drivers/radeon/AMDGPUUtil.cpp | 16 + > src/gallium/drivers/radeon/AMDGPUUtil.h|1 + > src/gallium/drivers/radeon/R600CodeEmitter.cpp | 60 ++- > src/gallium/drivers/radeon/R600GenRegisterInfo.pl |2 +- > src/gallium/drivers/radeon/R600ISelLowering.cpp|4 + > src/gallium/drivers/radeon/R600InstrInfo.cpp | 12 + > src/gallium/drivers/radeon/R600InstrInfo.h |1 + > src/gallium/drivers/radeon/R600Instructions.td | 113 - > .../drivers/radeon/R600LowerInstructions.cpp |4 +- > src/gallium/drivers/radeon/radeon_llvm.h | 38 ++ > .../drivers/radeon/radeon_setup_tgsi_llvm.c| 433 > +++- > 17 files changed, 698 insertions(+), 77 deletions(-) > > -- > 1.7.10.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 05/12] radeon/llvm: fix live-in handling for inputs
On Mon, May 07, 2012 at 11:53:46PM +0400, Vadim Girlin wrote:
> Set the input registers as live-in for entry basic block.
Looks good. Thanks.
>
> Signed-off-by: Vadim Girlin
> ---
> src/gallium/drivers/radeon/AMDGPUUtil.cpp |1 +
> src/gallium/drivers/radeon/R600LowerShaderInstructions.cpp |4 ++--
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/AMDGPUUtil.cpp
> b/src/gallium/drivers/radeon/AMDGPUUtil.cpp
> index 6fb01b6..663a77f 100644
> --- a/src/gallium/drivers/radeon/AMDGPUUtil.cpp
> +++ b/src/gallium/drivers/radeon/AMDGPUUtil.cpp
> @@ -118,6 +118,7 @@ void AMDGPU::utilAddLiveIn(MachineFunction * MF,
> MachineRegisterInfo & MRI,
> {
> if (!MRI.isLiveIn(physReg)) {
>MRI.addLiveIn(physReg, virtReg);
> + MF->front().addLiveIn(physReg);
>BuildMI(MF->front(), MF->front().begin(), DebugLoc(),
> TII->get(TargetOpcode::COPY), virtReg)
> .addReg(physReg);
> diff --git a/src/gallium/drivers/radeon/R600LowerShaderInstructions.cpp
> b/src/gallium/drivers/radeon/R600LowerShaderInstructions.cpp
> index 394ee70..742b50f 100644
> --- a/src/gallium/drivers/radeon/R600LowerShaderInstructions.cpp
> +++ b/src/gallium/drivers/radeon/R600LowerShaderInstructions.cpp
> @@ -13,6 +13,7 @@
>
> #include "AMDGPU.h"
> #include "AMDGPULowerShaderInstructions.h"
> +#include "AMDGPUUtil.h"
> #include "AMDIL.h"
> #include "AMDILInstrInfo.h"
> #include "llvm/CodeGen/MachineFunctionPass.h"
> @@ -117,8 +118,7 @@ void
> R600LowerShaderInstructionsPass::lowerLOAD_INPUT(MachineInstr &MI)
>unsigned newRegister = inputClass->getRegister(inputIndex);
>unsigned dstReg = dst.getReg();
>
> - preloadRegister(MI.getParent()->getParent(), TM.getInstrInfo(),
> newRegister,
> - dstReg);
> + AMDGPU::utilAddLiveIn(MI.getParent()->getParent(), *MRI,
> TM.getInstrInfo(), newRegister, dstReg);
> }
>
> bool R600LowerShaderInstructionsPass::lowerSTORE_OUTPUT(MachineInstr &MI,
> --
> 1.7.10.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 48441] gnome-control-center crashes
https://bugs.freedesktop.org/show_bug.cgi?id=48441 --- Comment #19 from raphael.roc...@gmail.com 2012-05-07 14:15:01 PDT --- It is fixed for me in last update. ( ArchLinux 64bits / gnome-control-center 3.4.1-2 ) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/10] intel: Work around differences between C and C++ scoping rules.
On 05/02/2012 01:52 PM, Paul Berry wrote: In C++, if a struct is defined inside another struct, or its name is first seen inside a struct or function, the struct is nested inside the namespace of the struct or function it appears in. In C, all structs are visible from toplevel. This patch explicitly moves the decalartions of intel_batchbuffer to toplevel, so that it does not get nested inside a namespace when header files are included from C++. --- src/mesa/drivers/dri/intel/intel_batchbuffer.h |2 + src/mesa/drivers/dri/intel/intel_context.h | 52 --- 2 files changed, 29 insertions(+), 25 deletions(-) Splitting out this struct seems reasonable enough. For this patch only: Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] intel: When AUB dumping, flush before emitting final bitmap command.
When we are generating an AUB dump, we make a final call to
aub_dump_bmp() as the context is being destroyed, to ensure that any
rendering performed before the application exits can be seen during a
simulation run. However, we were doing this before flushing the batch
buffer; as a result simulation runs would not always see the effect of
all rendering commands.
This patch flushes the batch buffer just before making the final call
to aub_dump_bmp(), to ensure that all rendering is properly captured
in the final bitmap.
---
src/mesa/drivers/dri/intel/intel_context.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index f572f38..b770aa25 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -794,8 +794,10 @@ intelDestroyContext(__DRIcontext * driContextPriv)
INTEL_FIREVERTICES(intel);
/* Dump a final BMP in case the application doesn't call SwapBuffers */
- if (INTEL_DEBUG & DEBUG_AUB)
+ if (INTEL_DEBUG & DEBUG_AUB) {
+ intel_batchbuffer_flush(intel);
aub_dump_bmp(&intel->ctx);
+ }
_mesa_meta_free(&intel->ctx);
--
1.7.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] intel: Bump libdrm requirement to 2.4.34.
From: Eric Anholt We'll need this for annotating AUB dumps. --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 3bc59ca..d0fe397 100644 --- a/configure.ac +++ b/configure.ac @@ -37,7 +37,7 @@ USER_CXXFLAGS="$CXXFLAGS" dnl Versions for external dependencies LIBDRM_REQUIRED=2.4.24 LIBDRM_RADEON_REQUIRED=2.4.31 -LIBDRM_INTEL_REQUIRED=2.4.32 +LIBDRM_INTEL_REQUIRED=2.4.34 LIBDRM_NVVIEUX_REQUIRED=2.4.33 LIBDRM_NOUVEAU_REQUIRED=2.4.33 DRI2PROTO_REQUIRED=2.6 -- 1.7.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] i965: Completely annotate the batch bo when aub dumping.
Previously, when the environment variable INTEL_DEBUG=aub was set,
mesa would simply instruct DRM to start dumping data to an .aub file,
but we would not provide DRM with any information about the format of
the data in various buffers. As a result, a lot of the data in the
generate .aub file would be unannotated, making further data analysis
difficult.
This patch causes the entire contents of each batch buffer to be
annotated using the data in brw->state_batch_list (which was
previously used only to annotate the output of INTEL_DEBUG=bat). This
includes data that was allocated by brw_state_batch, such as binding
tables, surface and sampler states, depth/stencil state, and so on.
The new annotation mechanism requires DRM version 2.4.34.
---
src/mesa/drivers/dri/i965/brw_context.h| 87 +---
src/mesa/drivers/dri/i965/brw_state_batch.c| 48 +-
src/mesa/drivers/dri/i965/brw_vtbl.c |1 +
src/mesa/drivers/dri/i965/gen6_blorp.cpp |2 +-
src/mesa/drivers/dri/intel/intel_batchbuffer.c |5 +-
src/mesa/drivers/dri/intel/intel_context.h |1 +
6 files changed, 117 insertions(+), 27 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index a768416..251893f 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -193,33 +193,71 @@ struct brw_state_flags {
GLuint cache;
};
+#define AUB_TRACE_TYPE_MASK0xff00
+#define AUB_TRACE_TYPE_NOTYPE (0 << 8)
+#define AUB_TRACE_TYPE_BATCH (1 << 8)
+#define AUB_TRACE_TYPE_VERTEX_BUFFER (5 << 8)
+#define AUB_TRACE_TYPE_2D_MAP (6 << 8)
+#define AUB_TRACE_TYPE_CUBE_MAP(7 << 8)
+#define AUB_TRACE_TYPE_VOLUME_MAP (9 << 8)
+#define AUB_TRACE_TYPE_1D_MAP (10 << 8)
+#define AUB_TRACE_TYPE_CONSTANT_BUFFER (11 << 8)
+#define AUB_TRACE_TYPE_CONSTANT_URB(12 << 8)
+#define AUB_TRACE_TYPE_INDEX_BUFFER(13 << 8)
+#define AUB_TRACE_TYPE_GENERAL (14 << 8)
+#define AUB_TRACE_TYPE_SURFACE (15 << 8)
+
+/**
+ * state_struct_type enum values are encoded with the top 16 bits representing
+ * the type to be delivered to the .aub file, and the bottom 16 bits
+ * representing the subtype. This macro performs the encoding.
+ */
+#define ENCODE_SS_TYPE(type, subtype) (((type) << 16) | (subtype))
+
enum state_struct_type {
- AUB_TRACE_VS_STATE =1,
- AUB_TRACE_GS_STATE =2,
- AUB_TRACE_CLIP_STATE = 3,
- AUB_TRACE_SF_STATE =4,
- AUB_TRACE_WM_STATE =5,
- AUB_TRACE_CC_STATE =6,
- AUB_TRACE_CLIP_VP_STATE = 7,
- AUB_TRACE_SF_VP_STATE = 8,
- AUB_TRACE_CC_VP_STATE = 0x9,
- AUB_TRACE_SAMPLER_STATE = 0xa,
- AUB_TRACE_KERNEL_INSTRUCTIONS = 0xb,
- AUB_TRACE_SCRATCH_SPACE = 0xc,
- AUB_TRACE_SAMPLER_DEFAULT_COLOR =0xd,
-
- AUB_TRACE_SCISSOR_STATE = 0x15,
- AUB_TRACE_BLEND_STATE = 0x16,
- AUB_TRACE_DEPTH_STENCIL_STATE = 0x17,
-
- /* Not written to .aub files the same way the structures above are. */
- AUB_TRACE_NO_TYPE = 0x100,
- AUB_TRACE_BINDING_TABLE = 0x101,
- AUB_TRACE_SURFACE_STATE = 0x102,
- AUB_TRACE_VS_CONSTANTS =0x103,
- AUB_TRACE_WM_CONSTANTS =0x104,
+ AUB_TRACE_VS_STATE =
ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL, 1),
+ AUB_TRACE_GS_STATE =
ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL, 2),
+ AUB_TRACE_CLIP_STATE = ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL,
3),
+ AUB_TRACE_SF_STATE =
ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL, 4),
+ AUB_TRACE_WM_STATE =
ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL, 5),
+ AUB_TRACE_CC_STATE =
ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL, 6),
+ AUB_TRACE_CLIP_VP_STATE = ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL,
7),
+ AUB_TRACE_SF_VP_STATE = ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL,
8),
+ AUB_TRACE_CC_VP_STATE = ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL,
0x9),
+ AUB_TRACE_SAMPLER_STATE = ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL,
0xa),
+ AUB_TRACE_KERNEL_INSTRUCTIONS = ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL,
0xb),
+ AUB_TRACE_SCRATCH_SPACE = ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL,
0xc),
+ AUB_TRACE_SAMPLER_DEFAULT_COLOR =ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL,
0xd),
+
+ AUB_TRACE_SCISSOR_STATE = ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL,
0x15),
+ AUB_TRACE_BLEND_STATE = ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL,
0x16),
+ AUB_TRACE_DEPTH_STENCIL_STATE = ENCODE_SS_TYPE(AUB_TRACE_TYPE_GENERAL,
0x17),
+
+ AUB_TRACE_VERTEX_BUFFER =
ENCODE_SS_TYPE(AUB_TRACE_TYPE_VERTE
Re: [Mesa-dev] [PATCH 2/3] intel: Bump libdrm requirement to 2.4.34.
On 7 May 2012 14:32, Paul Berry wrote: > From: Eric Anholt > Whoops, I cribbed this patch from Eric and forgot to reset the author to me. Sorry about that, Eric. I'll fix before pushing. > > We'll need this for annotating AUB dumps. > --- > configure.ac |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 3bc59ca..d0fe397 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -37,7 +37,7 @@ USER_CXXFLAGS="$CXXFLAGS" > dnl Versions for external dependencies > LIBDRM_REQUIRED=2.4.24 > LIBDRM_RADEON_REQUIRED=2.4.31 > -LIBDRM_INTEL_REQUIRED=2.4.32 > +LIBDRM_INTEL_REQUIRED=2.4.34 > LIBDRM_NVVIEUX_REQUIRED=2.4.33 > LIBDRM_NOUVEAU_REQUIRED=2.4.33 > DRI2PROTO_REQUIRED=2.6 > -- > 1.7.7.6 > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/10] i965/hiz: Convert gen{6, 7}_hiz.h to gen{6, 7}_blorp.h
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For patches 1-5, Reviewed-by: Chad Versace -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPqEbnAAoJEAIvNt057x8i4dIP/i0bNIIPXFk/4lv4dZhvdkL5 XNz/jB7CYuVqrcwWO7+4xDV2hZByJ/evYwlMrwqxWyewnF/tbyzgS5HZ0HL7CXBn wFuXMmWeanhbDY9eKVQt5j5IDkJLMA1HvOLMuh6TlRZPtwAjQZrBOYHeie1xJn8L l5iRUWOtMCNlbaREPM3ABBz4A6uTdQGDbKSlUfxHq1iy3bpvBRKodxVt1Va1TE8w WojvqkEpb2vSAo1Xw9tbzmgxyN8nY4wFWPQFT8/oZQU2atd2Sf32AS7MmoiO1tmf ct/aThAoXF+3H44exxjbQYBd8OYFz2q0r51Za+yLIKaOtAaUzyqk5Z3KgQnEkPWN b62cDmLV8wv6ijVH+II5G0wzJTm5kCsx3FdLilYG9bgxZFpqy0XQpumm6wUV1Vs9 qGDLXJIL/3bDbvLy/kKTWHUhg85P2Rs67SyALqSZExOfGDuPE0ov8oqJ+rO+dThv MUcnhykUwcwqDxySDhFat95o1XuMMocH4+IdLeYyq2wQAG4JZisJ+XDBjEeCZjFL 0WPKg8gz0WRTWleDe+Y9/mcmy0/rmlRwF0uADjy5EUGgs1v5y5FtjNEhi7+eLFr6 zb/U0hxUyOwwcoDfL7+oMPUuQxRvMh6EMcSYBezYigvGGpGTM4LS+FSDaMBiU0FV BaUUcbbC0F33A9tS6Zbn =alTf -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/10] i965: Parameterize HiZ code to prepare for adding blitting.
On 05/02/2012 01:52 PM, Paul Berry wrote:
> This patch groups together the parameters used by the HiZ functions
> into a new data structure, brw_hiz_resolve_params, rather than passing
> each parameter individually between the HiZ functions. This data
> structure is a subclass of brw_blorp_params, which represents the
> parameters of a general-purpose blit or resolve operation. A future
> patch will add another subclass for blits.
>
> In addition, this patch generalizes the (width, height) parameters to
> a full rect (x0, y0, x1, y1), since blitting operations will need to
> be able to operate on arbitrary rectangles. Also, it renames several
> of the HiZ functions to reflect the expanded role they will serve.
> ---
> src/mesa/drivers/dri/i965/Makefile.sources |1 +
> src/mesa/drivers/dri/i965/brw_blorp.cpp| 106
> src/mesa/drivers/dri/i965/brw_blorp.h | 130 +
> src/mesa/drivers/dri/i965/gen6_blorp.cpp | 146
> +++-
> src/mesa/drivers/dri/i965/gen6_blorp.h | 38 ---
> src/mesa/drivers/dri/i965/gen7_blorp.cpp | 87 +++--
> 6 files changed, 331 insertions(+), 177 deletions(-)
> create mode 100644 src/mesa/drivers/dri/i965/brw_blorp.cpp
> create mode 100644 src/mesa/drivers/dri/i965/brw_blorp.h
[snip]
> +class brw_blorp_params
> +{
> +public:
> + brw_blorp_params();
> +
> + void exec(struct intel_context *intel) const;
Params can "exec" themselves? This feels like an abuse of the method concept.
The method does one thing: it inspects the gen and dispatches to gen6_blorp_exec
gen7_blorp_exec. I think it's sensible to replace the method with brw_blorp_exec
that does the same thing.
> +
> + uint32_t x0;
> + uint32_t y0;
> + uint32_t x1;
> + uint32_t y1;
> + brw_blorp_mip_info depth;
> + uint32_t depth_format;
> + enum gen6_hiz_op hiz_op;
> +};
> +
> +/**
> + * Parameters for a HiZ or depth resolve operation.
> + *
> + * For an overview of HiZ ops, see the following sections of the Sandy Bridge
> + * PRM, Volume 1, Part 2:
> + * - 7.5.3.1 Depth Buffer Clear
> + * - 7.5.3.2 Depth Buffer Resolve
> + * - 7.5.3.3 Hierarchical Depth Buffer Resolve
> + */
> +class brw_hiz_resolve_params : public brw_blorp_params
> +{
> +public:
> + brw_hiz_resolve_params(struct intel_mipmap_tree *mt,
> + unsigned int level, unsigned int layer,
> + gen6_hiz_op op);
> +};
Why is the 'hiz_op' field in brw_blorp_params, not in brw_hiz_resolve_params?
named brw_hiz_resolve_params? The latter seems like the appropriate place for
it.
A remark about naming. The brw_hiz_resolve_params struct is the parameter
list not only for hiz resolves, but also for depth resolves and depth clears.
I think the class should be renamed to the more generic brw_hiz_op_params.
The term "hiz_op" is consistent with hiz-related code elsewhere in the driver,
and is the operation's actual name according to some hw docs.
[snip]
> +
> +/**
> + * \name BLORP internals
> + * \{
> + *
> + * Used internally by gen6_blorp_exec() and gen7_blorp_exec().
> + */
> +
> +void
> +gen6_blorp_init(struct brw_context *brw);
> +
> +void
> +gen6_blorp_emit_batch_head(struct brw_context *brw,
> + const brw_blorp_params *params);
> +
> +void
> +gen6_blorp_emit_vertices(struct brw_context *brw,
> + const brw_blorp_params *params);
> +
> +void
> +gen6_blorp_emit_depth_stencil_state(struct brw_context *brw,
> +const brw_blorp_params *params,
> +uint32_t *out_offset);
> +/** \} */
> +void
> +gen6_blorp_exec(struct intel_context *intel,
> +const brw_blorp_params *params);
> +
Is there a reason you moved the gen6 prototypes into brw_blorp.h? Since
the functions are implemented in gen6_blorp.cpp, I think the prototypes
should remain in their original location, gen6_blorp.h.
Any other organizational scheme feels ad-hoc and makes it more difficult
to guess, at encountering a prototype, where its implemention lives.
> +void
> +gen7_blorp_exec(struct intel_context *intel,
> +const brw_blorp_params *params);
Ditto for this gen7 function.
> +void
> +gen6_blorp_exec(struct intel_context *intel,
> +const brw_blorp_params *params)
> {
> struct gl_context *ctx = &intel->ctx;
> struct brw_context *brw = brw_context(ctx);
> uint32_t draw_x, draw_y;
> uint32_t tile_mask_x, tile_mask_y;
>
> - assert(op != GEN6_HIZ_OP_DEPTH_CLEAR); /* Not implemented yet. */
> - assert(mt->hiz_mt != NULL);
> - intel_miptree_check_level_layer(mt, level, layer);
> -
> - {
> - /* Construct a dummy renderbuffer just to extract tile offsets. */
> - struct intel_renderbuffer rb;
> - rb.mt = mt;
> - rb.mt_level = level;
> - rb.mt_layer = layer;
> - intel_renderbuffer_set_draw_offset(&rb);
> - draw
Re: [Mesa-dev] [PATCH 07/10] i965: split gen{6, 7}_blorp_exec functions into manageable chunks.
On 05/02/2012 01:52 PM, Paul Berry wrote:
> This patch splits up the gen6_blorp_exec and gen7_blorp_exec
> functions, which were very long, into simple component functions.
> With a few exceptions, there is one function per state packet.
>
> This will allow blit functionality to be added without significantly
> complicating the code.
> ---
> src/mesa/drivers/dri/i965/brw_blorp.h| 23 +-
> src/mesa/drivers/dri/i965/gen6_blorp.cpp | 596
> +-
> src/mesa/drivers/dri/i965/gen7_blorp.cpp | 448 ---
> 3 files changed, 595 insertions(+), 472 deletions(-)
[snip]
> +/**
> + * Disable thread dispatch (dw5.19) and enable the HiZ op.
> + */
> +static void
> +gen6_blorp_emit_wm_disable(struct brw_context *brw,
> + const brw_blorp_params *params)
/begin bikeshedding
I think the name of this function is misleading. In the other
gen6_blorp_emit_UNIT_disable functions, we *really* disable the unit
and don't care much about the contents of the 3DSTATE_UNIT packet,
because the packet doesn't instruct the gpu to do anything.
However, that's not the case for 3DSTATE_WM. The content of this packet
is paramount; it tells the gpu which hiz op to execute. Technically,
this function *does disable* the WM. But, on the other hand, it does
much more than that.
Ditto for gen7.
But, I see that I'm bikeshedding now. I need to continue on and do actual,
*useful* review now :)
/end bikeshedding
[snip]
> /**
> - * \param out_offset is relative to
> - *CMD_STATE_BASE_ADDRESS.DynamicStateBaseAddress.
> + * \brief Execute a blit or render pass operation.
> + *
> + * To execute the operation, this function manually constructs and emits a
> + * batch to draw a rectangle primitive. The batchbuffer is flushed before
> + * constructing and after emitting the batch.
> + *
> + * This function alters no GL state.
> */
> void
> -gen6_blorp_emit_depth_stencil_state(struct brw_context *brw,
> -const brw_blorp_params *params,
> -uint32_t *out_offset)
> +gen6_blorp_exec(struct intel_context *intel,
> +const brw_blorp_params *params)
> {
> - struct gen6_depth_stencil_state *state;
> - state = (struct gen6_depth_stencil_state *)
> - brw_state_batch(brw, AUB_TRACE_DEPTH_STENCIL_STATE,
> - sizeof(*state), 64,
> - out_offset);
> - memset(state, 0, sizeof(*state));
> + struct gl_context *ctx = &intel->ctx;
> + struct brw_context *brw = brw_context(ctx);
> + uint32_t depthstencil_offset;
>
> - /* See the following sections of the Sandy Bridge PRM, Volume 1, Part2:
> -* - 7.5.3.1 Depth Buffer Clear
> -* - 7.5.3.2 Depth Buffer Resolve
> -* - 7.5.3.3 Hierarchical Depth Buffer Resolve
> + gen6_blorp_emit_batch_head(brw, params);
> + gen6_blorp_emit_vertices(brw, params);
> + gen6_blorp_emit_urb_config(brw, params);
> + depthstencil_offset = gen6_blorp_emit_depth_stencil_state(brw, params);
> + gen6_blorp_emit_cc_state_pointers(brw, params, depthstencil_offset);
> + gen6_blorp_emit_vs_disable(brw, params);
> + gen6_blorp_emit_gs_disable(brw, params);
> + gen6_blorp_emit_clip_disable(brw, params);
> + gen6_blorp_emit_sf_config(brw, params);
> + gen6_blorp_emit_wm_disable(brw, params);
> +
> + gen6_blorp_emit_depth_stencil_config(brw, params);
> + gen6_blorp_emit_clear_params(brw, params);
> + gen6_blorp_emit_drawing_rectangle(brw, params);
> + gen6_blorp_emit_primitive(brw, params);
> +
> + /* See comments above at first invocation of intel_flush() in
> +* gen6_blorp_emit_batch_head().
> */
> - state->ds2.depth_write_enable = 1;
> - if (params->hiz_op == GEN6_HIZ_OP_DEPTH_RESOLVE) {
> - state->ds2.depth_test_enable = 1;
> - state->ds2.depth_test_func = COMPAREFUNC_NEVER;
> - }
> + intel_flush(ctx);
> +
> + /* Be safe. */
> + brw->state.dirty.brw = ~0;
> + brw->state.dirty.cache = ~0;
> }
I like the new form of gen6_blorp_exec. I look forward to discover how,
in later patches, you integrate msaa into it.
Many of the functions introduced by this patch contain a cast
struct intel_context *intel = &brw->intel;
but do not use the 'intel' variable. After cleaning up the
unused variables, this patch is
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] vbo: move vbo_draw_method into vbo_context.h
On Mon, May 7, 2012 at 6:34 PM, Brian Paul wrote: > On 05/07/2012 09:27 AM, Marek Olšák wrote: >> As far as the gallium side is concerned, I don't think the array >> object can fully encapsulate vertex buffers and vertex elements. Those >> two also depend on the vertex shader, because vertex buffer bindings >> currently map 1:1 to vertex elements unless the vertex attribs are >> interleaved (though that can be changed), and vertex elements always >> map 1:1 to vertex shader inputs. Whether it's worth to break the >> dependency between those states is questionable. I think that binding >> 32 vertex buffers and letting vertex elements decide which buffers to >> use would be a disaster for our CPU performance. Who knows. All in >> all, I've got no idea how to take advantage of array objects in >> st/mesa, because it doesn't seem to map to gallium well. Maybe you >> guys know better. > > > I mentioned the idea before and Mathias is interested in it as well. > > The basic idea is: > > 1. OpenGL's vertex array objects (gl_array_object) basically encapsulates > the state of a bunch of glVertexPointer, glTexCoordPointer, etc. arrays. > > 2. In gallium we have a set of pipe_vertex_element that basically encodes > the same state. > > 3. Hopefully we could avoid re-deriving the later state from the former if > we do the encapsulation that Mathias describes. > > But as you said, the derived array state that we pass to draw calls also > depends on the currently bound vertex program and its inputs. > > It seems to me though, that a given gl_array_object state would almost > always be used with a vertex shader (or set of vertex shaders) that use > precisely the enabled arrays. So there could be a quick check if the set of > enabled arrays matched the set of vertex shader inputs and we could quickly > re-use the pipe_vertex_element state. AFAIK the "Enabled" flags aren't very useful in determining the final number of vertex elements, because if an array is not enabled, the corresponding zero-stride "current" attrib is used instead. So the quick check would depend solely on vertex shader inputs. If your definition of "enabled array" is that it's just used by the vertex shader, then sorry for stating the obvious. ;) Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] shader_test for glsl-to-tgsi ceil bug
On 05/07/2012 08:34 PM, Eric Anholt wrote: > On Sat, 05 May 2012 14:43:44 +0200, Christoph Bumiller > wrote: >> Test case for the "glsl_to_tgsi: use TGSI_OPCODE_CEIL for >> ir_unop_ceil" patch attached. > > This wasn't caught by the generated test for ceil()? That seems > strange. It's not, because it's not really meant to test the functionality of ceil() itself, but rather a bug in glsl-to-tgsi, which implemented it as -floor(-x), that causes the second negation to be lost if the result was used in a certain way, like the reciprocal here. I just sent the test along to illustrate the bug my patch was supposed to fix, although including those kinds of failures in piglit would probably be a good idea, too. Of course testing multiple values, including fractional ones, won't harm either, even if it doesn't make a difference for that specific bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] mesa: add gl_context::NewDriverState and use it for vertex arrays
On Mon, May 7, 2012 at 6:19 PM, Brian Paul wrote: > Looks good, but it took me a while to understand exactly what's going > on. Suggestions for more/improved comments below. > > On Tue, Apr 24, 2012 at 4:00 PM, Marek Olšák wrote: >> The vbo module recomputes its states if _NEW_ARRAY is set, so it shouldn't >> use >> the same flag to notify the driver. Since we've run out of bits in NewState >> and NewState is for core Mesa anyway, we need to find another way. >> >> This patch is the first to start decoupling the state flags meant only >> for core Mesa and those only for drivers. >> >> The idea is to have two flag sets: >> - gl_context::NewState - used by core Mesa only >> - gl_context::NewDriverState - used by drivers only > > "used by drivers only. The flags defined by the driver and > opaque/meaningless to core Mesa." > > >> >> It makes perfect sense to use NewState|=_NEW_ARRAY to notify the vbo module >> that the user changed vertex arrays, and the vbo module in turn sets >> a driver-specific flag to notify the driver that it should update its vertex >> array bindings. >> >> The driver decides which bits of NewDriverState should be set and stores them >> in gl_context::DriverFlags. Then, Core Mesa can do this: >> ctx->NewDriverState |= ctx->DriverFlags.NewArray; >> >> This patch implements this behavior and adapts st/mesa. >> DriverFlags.NewArray is set to ST_NEW_VERTEX_ARRAYS. >> >> Core Mesa only sets NewDriverState. It's the driver's responsibility to read >> it whenever it wants and reset it to 0. >> --- >> src/mesa/main/context.c | 2 ++ >> src/mesa/main/mtypes.h | 14 ++ >> src/mesa/state_tracker/st_cb_rasterpos.c | 5 - >> src/mesa/state_tracker/st_context.c | 6 ++ >> src/mesa/state_tracker/st_context.h | 1 + >> src/mesa/state_tracker/st_draw.c | 12 +--- >> src/mesa/vbo/vbo_context.h | 2 +- >> src/mesa/vbo/vbo_exec_array.c | 2 +- >> src/mesa/vbo/vbo_exec_draw.c | 2 +- >> src/mesa/vbo/vbo_rebase.c | 2 ++ >> src/mesa/vbo/vbo_save_draw.c | 2 +- >> src/mesa/vbo/vbo_split_copy.c | 2 ++ >> src/mesa/vbo/vbo_split_inplace.c | 2 ++ >> 13 files changed, 46 insertions(+), 8 deletions(-) >> >> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c >> index d75351c..7e2ac98 100644 >> --- a/src/mesa/main/context.c >> +++ b/src/mesa/main/context.c >> @@ -792,6 +792,7 @@ init_attrib_groups(struct gl_context *ctx) >> >> /* Miscellaneous */ >> ctx->NewState = _NEW_ALL; >> + ctx->NewDriverState = ~0; >> ctx->ErrorValue = (GLenum) GL_NO_ERROR; >> ctx->ResetStatus = (GLenum) GL_NO_ERROR; >> ctx->varying_vp_inputs = VERT_BIT_ALL; >> @@ -1290,6 +1291,7 @@ _mesa_copy_context( const struct gl_context *src, >> struct gl_context *dst, >> /* XXX FIXME: Call callbacks? >> */ >> dst->NewState = _NEW_ALL; >> + dst->NewDriverState = ~0; >> } >> #endif >> >> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h >> index eb103ad..7f01514 100644 >> --- a/src/mesa/main/mtypes.h >> +++ b/src/mesa/main/mtypes.h >> @@ -3255,6 +3255,17 @@ typedef enum >> API_OPENGLES2 >> } gl_api; >> >> +/** >> + * Driver-specific state flags. >> + * >> + * These are or'd with gl_context::NewDriverState to notify a driver about >> + * a state change. The driver gets to decide what bits should be set through >> + * this structure. > > Just to be clear (and add to the comment), the bits here are set once > by the driver during context creation and never changed, right? Also, Yes, that's right. > could you make it a bit more clear that the values of the flags are > defined by the driver and opaque to core Mesa? Okay I will do that. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 48441] gnome-control-center crashes
https://bugs.freedesktop.org/show_bug.cgi?id=48441 m13...@hotmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #20 from m13...@hotmail.com 2012-05-07 21:36:02 PDT --- (In reply to comment #19) > It is fixed for me in last update. > ( ArchLinux 64bits / gnome-control-center 3.4.1-2 ) 32bits also worked fine. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] vbo: move vbo_draw_method into vbo_context.h
Hi, On Tuesday, May 08, 2012 01:12:51 Marek Olšák wrote: > AFAIK the "Enabled" flags aren't very useful in determining the final > number of vertex elements, because if an array is not enabled, the > corresponding zero-stride "current" attrib is used instead. So the > quick check would depend solely on vertex shader inputs. If your > definition of "enabled array" is that it's just used by the vertex > shader, then sorry for stating the obvious. ;) May be not in the current code, but the _mesa_array_object_get_enabled_* bitmask tricks show how you can immediatly (with an O(1) bitmask operation - no O(33) loop) see even for different aliasing situations which arrays are enabled. If you combine this by bit operations with the enabled shader inputs bitmask you can update the array state incrementally using ffs based loops only doing work on very few of the 33 client arrays. Sigh, I hope to find some time to distil the proof of concept stuff into something usable ... Greetings Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
