Re: [Mesa-dev] [PATCH] mesa: Set ProfileMask properly for core profile.
On 07/08/2013 04:09 PM, Matt Turner wrote: Fixes MESA_GL_VERSION_OVERRIDE=3.2 egl-create-context-verify-gl-flavor. --- src/mesa/main/context.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c index 5ad04cc..d687fb7 100644 --- a/src/mesa/main/context.c +++ b/src/mesa/main/context.c @@ -636,8 +636,10 @@ _mesa_init_constants(struct gl_context *ctx) ctx->Const.MaxTransformFeedbackInterleavedComponents = 4 * MAX_FEEDBACK_ATTRIBS; ctx->Const.MaxVertexStreams = 1; - /* GL 3.2: hard-coded for now: */ - ctx->Const.ProfileMask = GL_CONTEXT_COMPATIBILITY_PROFILE_BIT; + /* GL 3.2 */ + ctx->Const.ProfileMask = ctx->API == API_OPENGL_CORE + ? GL_CONTEXT_CORE_PROFILE_BIT + : GL_CONTEXT_COMPATIBILITY_PROFILE_BIT; /** GL_EXT_gpu_shader4 */ ctx->Const.MinProgramTexelOffset = -8; Ah, I see - this is only used for glGetIntegerv with GL_CONTEXT_PROFILE_MASK. Seems reasonable then. Unless someone is planning on implementing the compatibility profile (which I doubt), this could just be: ctx->Const.ProfileMask = GL_CONTEXT_CORE_PROFILE_BIT; but I think the way you have it is a bit more obvious/self-documenting, so I'm fine with it. Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 60016] After automake merge two different GPU (AMD + NVIDIA) willnot work on same machine
https://bugs.freedesktop.org/show_bug.cgi?id=60016 Chí-Thanh Christopher Nguyễn changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=50594 -- 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] [PULL] i965: Merging intel_context and brw_context
Acked-by: Chris Forbes ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Set ProfileMask properly for core profile.
Reviewed-by: Jordan Justen On Mon, Jul 8, 2013 at 4:09 PM, Matt Turner wrote: > Fixes MESA_GL_VERSION_OVERRIDE=3.2 egl-create-context-verify-gl-flavor. > --- > src/mesa/main/context.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c > index 5ad04cc..d687fb7 100644 > --- a/src/mesa/main/context.c > +++ b/src/mesa/main/context.c > @@ -636,8 +636,10 @@ _mesa_init_constants(struct gl_context *ctx) > ctx->Const.MaxTransformFeedbackInterleavedComponents = 4 * > MAX_FEEDBACK_ATTRIBS; > ctx->Const.MaxVertexStreams = 1; > > - /* GL 3.2: hard-coded for now: */ > - ctx->Const.ProfileMask = GL_CONTEXT_COMPATIBILITY_PROFILE_BIT; > + /* GL 3.2 */ > + ctx->Const.ProfileMask = ctx->API == API_OPENGL_CORE > + ? GL_CONTEXT_CORE_PROFILE_BIT > + : GL_CONTEXT_COMPATIBILITY_PROFILE_BIT; > > /** GL_EXT_gpu_shader4 */ > ctx->Const.MinProgramTexelOffset = -8; > -- > 1.8.1.5 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Set ProfileMask properly for core profile.
Fixes MESA_GL_VERSION_OVERRIDE=3.2 egl-create-context-verify-gl-flavor. --- src/mesa/main/context.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c index 5ad04cc..d687fb7 100644 --- a/src/mesa/main/context.c +++ b/src/mesa/main/context.c @@ -636,8 +636,10 @@ _mesa_init_constants(struct gl_context *ctx) ctx->Const.MaxTransformFeedbackInterleavedComponents = 4 * MAX_FEEDBACK_ATTRIBS; ctx->Const.MaxVertexStreams = 1; - /* GL 3.2: hard-coded for now: */ - ctx->Const.ProfileMask = GL_CONTEXT_COMPATIBILITY_PROFILE_BIT; + /* GL 3.2 */ + ctx->Const.ProfileMask = ctx->API == API_OPENGL_CORE + ? GL_CONTEXT_CORE_PROFILE_BIT + : GL_CONTEXT_COMPATIBILITY_PROFILE_BIT; /** GL_EXT_gpu_shader4 */ ctx->Const.MinProgramTexelOffset = -8; -- 1.8.1.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Mesa 9.2 and release process changes
On Tue, Jul 2, 2013 at 10:02 PM, Ian Romanick wrote: > 3. I'd like to make some adjustments to our process for picking patches back > to the stable branch. The current process is okay, but it has some kinks. > The two big (related) problems are people either under-mark things for the > stable branch or over-mark. We also have the problem that things are > occasionally marked for stable that, in the end, shouldn't go to stable. > > Instead of the current system, I'd like to propose creating a mesa-stable > mailing list where candidate patches will be sent. The release manage will > then have the responsibility to apply patches to the branch. This gives > opportunity for subsystem maintainers to ACK or NAK patches before they > land. It also gives the opportunity to use a build bot to pre-verify that > no patch ever breaks the build on the stable branch. > > Anyone can nominate a patch for stable by sending it to the list. This > provides a means for solving the under-mark problem. It may mean that > developers have to do more work (e.g., waiting awhile after a patch lands on > master to send it to the stable list), so we may need to come up with some > means to mitigate that. > > As part of this, we need to clearly document the criteria for inclusion in > the stable branch. We have some vague criteria now, but we should formalize > and agree on the list. I don't like the idea that *we* have to send patches to the stable mailing list. The marking of candidates for stable has pretty much been the same as in the Linux kernel and worked pretty well. From kernel/Documentation/stable_kernel_rules.txt: "To have the patch automatically included in the stable tree, add the tag Cc: sta...@vger.kernel.org in the sign-off area. Once the patch is merged it will be applied to the stable tree without anything else needing to be done by the author or subsystem maintainer." The major difference between the current Mesa and kernel approaches seems to be that there is a -stable maintainer for kernel who decides which candidates go in and which don't. I think we need such a strict maintainer for our stable branches, but I don't think we need anything else. I also think the under-mark problem is unsolvable no matter what the process of picking patches is. People must either: - mark their patches for stable - go through the git log, find suitable candidates, and make sure they are all picked (I have done this with my patches too), this is the only case where a stable mailing list makes sense I also recommend reading stable_kernel_rules.txt as mentioned by Daniel Vetter, but he linked to an old version. The latest version can be found in the kernel tree. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.
On 8 July 2013 10:40, Paul Berry wrote:
> Previously, we had a separate function for setting up the built-in
> variables for each combination of shader stage and GLSL version
> (e.g. generate_110_vs_variables to generate the built-in variables for
> GLSL 1.10 vertex shaders). The functions called each other in ad-hoc
> ways, leading to unexpected inconsistencies (for example,
> generate_120_fs_variables was called for GLSL versions 1.20 and above,
> but generate_130_fs_variables was called only for GLSL version 1.30).
> In addition, it led to a lot of code duplication, since many varyings
> had to be duplicated in both the FS and VS code paths. With the
> advent of geometry shaders (and later, tessellation control and
> tessellation evaluation shaders), this code duplication was going to
> get a lot worse.
>
> So this patch reworks things so that instead of having a separate
> function for each shader type and GLSL version, we have a function for
> constants, one for uniforms, one for varyings, and one for the special
> variables that are specific to each shader type.
>
> In addition, we use a class, builtin_variable_generator, to keep track
> of the instruction exec_list, the GLSL parse state, commonly-used
> types, and a few other variables, so that we don't have to pass them
> around as function arguments. This makes the code a lot more compact.
>
> Where it was feasible to do so without introducing compilation errors,
> I've also gone ahead and introduced the variables needed for
> {ARB,EXT}_geometry_shader4 style geometry shaders. This patch takes
> care of everything except the GS variable gl_VerticesIn, the FS
> variable gl_PrimitiveID, and GLSL 1.50 style geometry shader inputs
> (using the gl_in interface block). Those remaining features will be
> added later.
>
> I've also made a slight nomenclature change: previously we used the
> word "deprecated" to refer to variables which are marked in GLSL 1.40
> as requiring the ARB_compatibility extension, and are marked in GLSL
> 1.50 onward as requiring the compatibilty profile. This was
> misleading, since not all deprecated variables require the
> compatibility profile (for example gl_FragData and gl_FragColor, which
> have been deprecated since GLSL 1.30, but do not require the
> compatibility profile until GLSL 4.20). We now consistently use the
> word "compatibility" to refer to these variables.
>
> This patch doesn't introduce any functional changes (since geometry
> shaders haven't been enabled yet).
> ---
> src/glsl/builtin_variables.cpp | 1124
> +---
> 1 file changed, 363 insertions(+), 761 deletions(-)
>
Ian wanted to know what the impact of this patch was on executable size.
With I release build, I measured 5742592 bytes before (for libdricore) and
5737376 bytes after. So it's a 0.09% decrease in size.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Add an assertion to brwProgramStringNotify.
On 3 July 2013 21:49, Kenneth Graunke wrote:
> On 07/03/2013 10:50 AM, Paul Berry wrote:
>
>> driver->ProgramStringNotify is only called for ARB programs, fixed
>> function vertex programs, and ir_to_mesa (which isn't used by the i965
>> back-end). Therefore, even after geometry shaders are added,
>> brwProgramStringNotify should only ever be called with a target of
>> GL_VERTEX_PROGRAM_ARB or GL_FRAGMENT_PROGRAM_ARB.
>>
>> This patch adds an assertion to clarify that.
>> ---
>> src/mesa/drivers/dri/i965/brw_**program.c | 11 +--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/**brw_program.c
>> b/src/mesa/drivers/dri/i965/**brw_program.c
>> index 87986a9..4c5acb5 100644
>> --- a/src/mesa/drivers/dri/i965/**brw_program.c
>> +++ b/src/mesa/drivers/dri/i965/**brw_program.c
>> @@ -126,7 +126,8 @@ brwProgramStringNotify(struct gl_context *ctx,
>> {
>> struct brw_context *brw = brw_context(ctx);
>>
>> - if (target == GL_FRAGMENT_PROGRAM_ARB) {
>> + switch (target) {
>> + case GL_FRAGMENT_PROGRAM_ARB: {
>> struct gl_fragment_program *fprog = (struct gl_fragment_program
>> *) prog;
>> struct brw_fragment_program *newFP = brw_fragment_program(fprog);
>> const struct brw_fragment_program *curFP =
>> @@ -135,8 +136,9 @@ brwProgramStringNotify(struct gl_context *ctx,
>> if (newFP == curFP)
>> brw->state.dirty.brw |= BRW_NEW_FRAGMENT_PROGRAM;
>> newFP->id = get_new_program_id(brw->intel.**intelScreen);
>> + break;
>> }
>> - else if (target == GL_VERTEX_PROGRAM_ARB) {
>> + case GL_VERTEX_PROGRAM_ARB: {
>> struct gl_vertex_program *vprog = (struct gl_vertex_program *)
>> prog;
>> struct brw_vertex_program *newVP = brw_vertex_program(vprog);
>> const struct brw_vertex_program *curVP =
>> @@ -152,6 +154,11 @@ brwProgramStringNotify(struct gl_context *ctx,
>> /* Also tell tnl about it:
>> */
>> _tnl_program_string(ctx, target, prog);
>> + break;
>> + }
>> + default:
>> + assert(!"Unexpected target in brwProgramStringNotify");
>> + break;
>> }
>>
>
> I'm really glad to see this. However, I suspect people coming across it
> will perpetually wonder why the other targets aren't present.
>
> Perhaps add a block comment below the "default:" containing your commit
> message?
>
That's a good idea. Thanks for the suggestion.
>
> Either way,
> Reviewed-by: Kenneth Graunke
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/util: use explicily sized types for {un, }pack_rgba_{s, u}int
On 08.07.2013 22:32, Marek Olšák wrote:
> Hi Emil,
>
> What issue does this patch fix? Is there a nonarchaic CPU architecture
> or a compiler where "int" doesn't have 32 bits?
Yes, on x86_128 an int will be 64 bit.
It says "(Un)pack pixel blocks to/from R32G32B32A32_UINT", and not
PIPE_FORMAT_RSIZEOFINT_GSIZEOFINT_BSIZEOFINT_ASIZEOFINT_INT, so pick the
type that doesn't leave you with that uneasy feeling of relying on
sizeof(int) == 4.
So it fixes the issue of the code upsetting people. Unless explicitly
sized types upset you ? You cared enough to reply ... question is, does
anyone care enough to merge the patch.
> Marek
>
> On Mon, Jul 8, 2013 at 8:56 PM, Emil Velikov wrote:
>> Every function but the above four uses explicitly sized types for their
>> src and dst arguments. Even fetch_rgba_{s,u}int follows the convention.
>>
>> Signed-off-by: Emil Velikov
>> ---
>> src/gallium/auxiliary/util/u_format.c | 8
>> src/gallium/auxiliary/util/u_format.h | 8
>> 2 files changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/util/u_format.c
>> b/src/gallium/auxiliary/util/u_format.c
>> index 686ca8a..08ef6ab 100644
>> --- a/src/gallium/auxiliary/util/u_format.c
>> +++ b/src/gallium/auxiliary/util/u_format.c
>> @@ -297,7 +297,7 @@ util_format_read_4ui(enum pipe_format format,
>> {
>> const struct util_format_description *format_desc;
>> const uint8_t *src_row;
>> - unsigned *dst_row;
>> + uint32_t *dst_row;
>>
>> format_desc = util_format_description(format);
>>
>> @@ -318,7 +318,7 @@ util_format_write_4ui(enum pipe_format format,
>> {
>> const struct util_format_description *format_desc;
>> uint8_t *dst_row;
>> - const unsigned *src_row;
>> + const uint32_t *src_row;
>>
>> format_desc = util_format_description(format);
>>
>> @@ -339,7 +339,7 @@ util_format_read_4i(enum pipe_format format,
>> {
>> const struct util_format_description *format_desc;
>> const uint8_t *src_row;
>> - int *dst_row;
>> + int32_t *dst_row;
>>
>> format_desc = util_format_description(format);
>>
>> @@ -360,7 +360,7 @@ util_format_write_4i(enum pipe_format format,
>> {
>> const struct util_format_description *format_desc;
>> uint8_t *dst_row;
>> - const int *src_row;
>> + const int32_t *src_row;
>>
>> format_desc = util_format_description(format);
>>
>> diff --git a/src/gallium/auxiliary/util/u_format.h
>> b/src/gallium/auxiliary/util/u_format.h
>> index bb729c0..28527f5 100644
>> --- a/src/gallium/auxiliary/util/u_format.h
>> +++ b/src/gallium/auxiliary/util/u_format.h
>> @@ -361,13 +361,13 @@ struct util_format_description
>> * Only defined for INT formats.
>> */
>> void
>> - (*unpack_rgba_uint)(unsigned *dst, unsigned dst_stride,
>> + (*unpack_rgba_uint)(uint32_t *dst, unsigned dst_stride,
>> const uint8_t *src, unsigned src_stride,
>> unsigned width, unsigned height);
>>
>> void
>> (*pack_rgba_uint)(uint8_t *dst, unsigned dst_stride,
>> - const unsigned *src, unsigned src_stride,
>> + const uint32_t *src, unsigned src_stride,
>> unsigned width, unsigned height);
>>
>>/**
>> @@ -377,13 +377,13 @@ struct util_format_description
>> * Only defined for INT formats.
>> */
>> void
>> - (*unpack_rgba_sint)(signed *dst, unsigned dst_stride,
>> + (*unpack_rgba_sint)(int32_t *dst, unsigned dst_stride,
>> const uint8_t *src, unsigned src_stride,
>> unsigned width, unsigned height);
>>
>> void
>> (*pack_rgba_sint)(uint8_t *dst, unsigned dst_stride,
>> - const int *src, unsigned src_stride,
>> + const int32_t *src, unsigned src_stride,
>> unsigned width, unsigned height);
>>
>> /**
>> --
>> 1.8.3.2
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/util: use explicily sized types for {un, }pack_rgba_{s, u}int
On 08/07/13 21:32, Marek Olšák wrote:
> Hi Emil,
>
> What issue does this patch fix? Is there a nonarchaic CPU architecture
> or a compiler where "int" doesn't have 32 bits?
>
Hi Marek
To the best of my knowledge, there is no specific issue. It was brought
up as I was looking on a nouveau crash. The crash itself is not related
nor resolved with this patch, but I thought that the consistency would
be appreciated
Emil
> Marek
>
> On Mon, Jul 8, 2013 at 8:56 PM, Emil Velikov wrote:
>> Every function but the above four uses explicitly sized types for their
>> src and dst arguments. Even fetch_rgba_{s,u}int follows the convention.
>>
>> Signed-off-by: Emil Velikov
>> ---
>> src/gallium/auxiliary/util/u_format.c | 8
>> src/gallium/auxiliary/util/u_format.h | 8
>> 2 files changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/util/u_format.c
>> b/src/gallium/auxiliary/util/u_format.c
>> index 686ca8a..08ef6ab 100644
>> --- a/src/gallium/auxiliary/util/u_format.c
>> +++ b/src/gallium/auxiliary/util/u_format.c
>> @@ -297,7 +297,7 @@ util_format_read_4ui(enum pipe_format format,
>> {
>> const struct util_format_description *format_desc;
>> const uint8_t *src_row;
>> - unsigned *dst_row;
>> + uint32_t *dst_row;
>>
>> format_desc = util_format_description(format);
>>
>> @@ -318,7 +318,7 @@ util_format_write_4ui(enum pipe_format format,
>> {
>> const struct util_format_description *format_desc;
>> uint8_t *dst_row;
>> - const unsigned *src_row;
>> + const uint32_t *src_row;
>>
>> format_desc = util_format_description(format);
>>
>> @@ -339,7 +339,7 @@ util_format_read_4i(enum pipe_format format,
>> {
>> const struct util_format_description *format_desc;
>> const uint8_t *src_row;
>> - int *dst_row;
>> + int32_t *dst_row;
>>
>> format_desc = util_format_description(format);
>>
>> @@ -360,7 +360,7 @@ util_format_write_4i(enum pipe_format format,
>> {
>> const struct util_format_description *format_desc;
>> uint8_t *dst_row;
>> - const int *src_row;
>> + const int32_t *src_row;
>>
>> format_desc = util_format_description(format);
>>
>> diff --git a/src/gallium/auxiliary/util/u_format.h
>> b/src/gallium/auxiliary/util/u_format.h
>> index bb729c0..28527f5 100644
>> --- a/src/gallium/auxiliary/util/u_format.h
>> +++ b/src/gallium/auxiliary/util/u_format.h
>> @@ -361,13 +361,13 @@ struct util_format_description
>> * Only defined for INT formats.
>> */
>> void
>> - (*unpack_rgba_uint)(unsigned *dst, unsigned dst_stride,
>> + (*unpack_rgba_uint)(uint32_t *dst, unsigned dst_stride,
>> const uint8_t *src, unsigned src_stride,
>> unsigned width, unsigned height);
>>
>> void
>> (*pack_rgba_uint)(uint8_t *dst, unsigned dst_stride,
>> - const unsigned *src, unsigned src_stride,
>> + const uint32_t *src, unsigned src_stride,
>> unsigned width, unsigned height);
>>
>>/**
>> @@ -377,13 +377,13 @@ struct util_format_description
>> * Only defined for INT formats.
>> */
>> void
>> - (*unpack_rgba_sint)(signed *dst, unsigned dst_stride,
>> + (*unpack_rgba_sint)(int32_t *dst, unsigned dst_stride,
>> const uint8_t *src, unsigned src_stride,
>> unsigned width, unsigned height);
>>
>> void
>> (*pack_rgba_sint)(uint8_t *dst, unsigned dst_stride,
>> - const int *src, unsigned src_stride,
>> + const int32_t *src, unsigned src_stride,
>> unsigned width, unsigned height);
>>
>> /**
>> --
>> 1.8.3.2
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/util: use explicily sized types for {un, }pack_rgba_{s, u}int
Hi Emil,
What issue does this patch fix? Is there a nonarchaic CPU architecture
or a compiler where "int" doesn't have 32 bits?
Marek
On Mon, Jul 8, 2013 at 8:56 PM, Emil Velikov wrote:
> Every function but the above four uses explicitly sized types for their
> src and dst arguments. Even fetch_rgba_{s,u}int follows the convention.
>
> Signed-off-by: Emil Velikov
> ---
> src/gallium/auxiliary/util/u_format.c | 8
> src/gallium/auxiliary/util/u_format.h | 8
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_format.c
> b/src/gallium/auxiliary/util/u_format.c
> index 686ca8a..08ef6ab 100644
> --- a/src/gallium/auxiliary/util/u_format.c
> +++ b/src/gallium/auxiliary/util/u_format.c
> @@ -297,7 +297,7 @@ util_format_read_4ui(enum pipe_format format,
> {
> const struct util_format_description *format_desc;
> const uint8_t *src_row;
> - unsigned *dst_row;
> + uint32_t *dst_row;
>
> format_desc = util_format_description(format);
>
> @@ -318,7 +318,7 @@ util_format_write_4ui(enum pipe_format format,
> {
> const struct util_format_description *format_desc;
> uint8_t *dst_row;
> - const unsigned *src_row;
> + const uint32_t *src_row;
>
> format_desc = util_format_description(format);
>
> @@ -339,7 +339,7 @@ util_format_read_4i(enum pipe_format format,
> {
> const struct util_format_description *format_desc;
> const uint8_t *src_row;
> - int *dst_row;
> + int32_t *dst_row;
>
> format_desc = util_format_description(format);
>
> @@ -360,7 +360,7 @@ util_format_write_4i(enum pipe_format format,
> {
> const struct util_format_description *format_desc;
> uint8_t *dst_row;
> - const int *src_row;
> + const int32_t *src_row;
>
> format_desc = util_format_description(format);
>
> diff --git a/src/gallium/auxiliary/util/u_format.h
> b/src/gallium/auxiliary/util/u_format.h
> index bb729c0..28527f5 100644
> --- a/src/gallium/auxiliary/util/u_format.h
> +++ b/src/gallium/auxiliary/util/u_format.h
> @@ -361,13 +361,13 @@ struct util_format_description
> * Only defined for INT formats.
> */
> void
> - (*unpack_rgba_uint)(unsigned *dst, unsigned dst_stride,
> + (*unpack_rgba_uint)(uint32_t *dst, unsigned dst_stride,
> const uint8_t *src, unsigned src_stride,
> unsigned width, unsigned height);
>
> void
> (*pack_rgba_uint)(uint8_t *dst, unsigned dst_stride,
> - const unsigned *src, unsigned src_stride,
> + const uint32_t *src, unsigned src_stride,
> unsigned width, unsigned height);
>
>/**
> @@ -377,13 +377,13 @@ struct util_format_description
> * Only defined for INT formats.
> */
> void
> - (*unpack_rgba_sint)(signed *dst, unsigned dst_stride,
> + (*unpack_rgba_sint)(int32_t *dst, unsigned dst_stride,
> const uint8_t *src, unsigned src_stride,
> unsigned width, unsigned height);
>
> void
> (*pack_rgba_sint)(uint8_t *dst, unsigned dst_stride,
> - const int *src, unsigned src_stride,
> + const int32_t *src, unsigned src_stride,
> unsigned width, unsigned height);
>
> /**
> --
> 1.8.3.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Mesa 9.2 and release process changes
On Tue, Jul 02, 2013 at 02:37:54PM -0700, Matt Turner wrote: > On Tue, Jul 2, 2013 at 1:02 PM, Ian Romanick wrote: > > 2. Instead of just posting md5sum for the release tarballs, I think we > > should start GPG signing them. I'm not sure what sort of process we want to > > establish for this. Should they just be signed by the release managers key? > > Is this easier than I think it is? > > GPG sign the git tag (git tag -s) and the announce email which > contains the md5/sha sums. That's how X.Org releases are done. I think best practice is: - Sign the released tarball, and distribute that with the tarball. - Distribute SHA1/SHA256 checksums together with the tarball. - In the release announcement include the checksums - Send a signed release announcement - Sign the release in git Please move away from MD5. It's not useful at all to check that it's the real tarball or not. It's helpful if the signature is done by someone that has a good connection to the web of trust, but it's not really a requirement. You could also consider creating a role key for that and have the people that have access to it sign it, but I don't really recommend it. The idea of having the checksums in the release announcement is that those mails ussually end up in several places, and it's unlikely that they all get compromised. The signature is so that at least some people can very if and complain if it's not what they see. Kurt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/util: use explicily sized types for {un, }pack_rgba_{s, u}int
Every function but the above four uses explicitly sized types for their
src and dst arguments. Even fetch_rgba_{s,u}int follows the convention.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/util/u_format.c | 8
src/gallium/auxiliary/util/u_format.h | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format.c
b/src/gallium/auxiliary/util/u_format.c
index 686ca8a..08ef6ab 100644
--- a/src/gallium/auxiliary/util/u_format.c
+++ b/src/gallium/auxiliary/util/u_format.c
@@ -297,7 +297,7 @@ util_format_read_4ui(enum pipe_format format,
{
const struct util_format_description *format_desc;
const uint8_t *src_row;
- unsigned *dst_row;
+ uint32_t *dst_row;
format_desc = util_format_description(format);
@@ -318,7 +318,7 @@ util_format_write_4ui(enum pipe_format format,
{
const struct util_format_description *format_desc;
uint8_t *dst_row;
- const unsigned *src_row;
+ const uint32_t *src_row;
format_desc = util_format_description(format);
@@ -339,7 +339,7 @@ util_format_read_4i(enum pipe_format format,
{
const struct util_format_description *format_desc;
const uint8_t *src_row;
- int *dst_row;
+ int32_t *dst_row;
format_desc = util_format_description(format);
@@ -360,7 +360,7 @@ util_format_write_4i(enum pipe_format format,
{
const struct util_format_description *format_desc;
uint8_t *dst_row;
- const int *src_row;
+ const int32_t *src_row;
format_desc = util_format_description(format);
diff --git a/src/gallium/auxiliary/util/u_format.h
b/src/gallium/auxiliary/util/u_format.h
index bb729c0..28527f5 100644
--- a/src/gallium/auxiliary/util/u_format.h
+++ b/src/gallium/auxiliary/util/u_format.h
@@ -361,13 +361,13 @@ struct util_format_description
* Only defined for INT formats.
*/
void
- (*unpack_rgba_uint)(unsigned *dst, unsigned dst_stride,
+ (*unpack_rgba_uint)(uint32_t *dst, unsigned dst_stride,
const uint8_t *src, unsigned src_stride,
unsigned width, unsigned height);
void
(*pack_rgba_uint)(uint8_t *dst, unsigned dst_stride,
- const unsigned *src, unsigned src_stride,
+ const uint32_t *src, unsigned src_stride,
unsigned width, unsigned height);
/**
@@ -377,13 +377,13 @@ struct util_format_description
* Only defined for INT formats.
*/
void
- (*unpack_rgba_sint)(signed *dst, unsigned dst_stride,
+ (*unpack_rgba_sint)(int32_t *dst, unsigned dst_stride,
const uint8_t *src, unsigned src_stride,
unsigned width, unsigned height);
void
(*pack_rgba_sint)(uint8_t *dst, unsigned dst_stride,
- const int *src, unsigned src_stride,
+ const int32_t *src, unsigned src_stride,
unsigned width, unsigned height);
/**
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/14] glsl: Add copy-constructor for ast_struct_specifier.
---
src/glsl/ast.h | 12
1 file changed, 12 insertions(+)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 3bb33c5..87f9876 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -453,6 +453,18 @@ class ast_declarator_list;
class ast_struct_specifier : public ast_node {
public:
+ /**
+* \brief Make a shallow copy of an ast_struct_specifier.
+*
+* Use only if the objects are allocated from the same context and will not
+* be modified. Zeros the inherited ast_node's fields.
+*/
+ ast_struct_specifier(const ast_struct_specifier& that):
+ ast_node(), name(that.name), declarations(that.declarations)
+ {
+ /* empty */
+ }
+
ast_struct_specifier(const char *identifier,
ast_declarator_list *declarator_list);
virtual void print(void) const;
--
1.8.1.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: x/y coordinates must be divided by block dim in dma blit
Reviewed-by: Marek Olšák
Marek
On Fri, Jul 5, 2013 at 8:55 PM, Christoph Bumiller
wrote:
> From: Christoph Bumiller
>
> ---
> src/gallium/drivers/r600/evergreen_state.c | 10 --
> src/gallium/drivers/r600/r600_state.c | 10 --
> 2 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/evergreen_state.c
> b/src/gallium/drivers/r600/evergreen_state.c
> index 0dc4f15..0267d28 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -3740,6 +3740,7 @@ boolean evergreen_dma_blit(struct pipe_context *ctx,
> struct r600_texture *rdst = (struct r600_texture*)dst;
> unsigned dst_pitch, src_pitch, bpp, dst_mode, src_mode, copy_height;
> unsigned src_w, dst_w;
> + unsigned src_x, src_y;
>
> if (rctx->rings.dma.cs == NULL) {
> return FALSE;
> @@ -3748,6 +3749,11 @@ boolean evergreen_dma_blit(struct pipe_context *ctx,
> return FALSE;
> }
>
> + src_x = util_format_get_nblocksx(src->format, src_box->x);
> + dst_x = util_format_get_nblocksx(src->format, dst_x);
> + src_y = util_format_get_nblocksy(src->format, src_box->y);
> + dst_y = util_format_get_nblocksy(src->format, dst_y);
> +
> bpp = rdst->surface.bpe;
> dst_pitch = rdst->surface.level[dst_level].pitch_bytes;
> src_pitch = rsrc->surface.level[src_level].pitch_bytes;
> @@ -3792,7 +3798,7 @@ boolean evergreen_dma_blit(struct pipe_context *ctx,
> */
> src_offset= rsrc->surface.level[src_level].offset;
> src_offset += rsrc->surface.level[src_level].slice_size *
> src_box->z;
> - src_offset += src_box->y * src_pitch + src_box->x * bpp;
> + src_offset += src_y * src_pitch + src_x * bpp;
> dst_offset = rdst->surface.level[dst_level].offset;
> dst_offset += rdst->surface.level[dst_level].slice_size *
> dst_z;
> dst_offset += dst_y * dst_pitch + dst_x * bpp;
> @@ -3800,7 +3806,7 @@ boolean evergreen_dma_blit(struct pipe_context *ctx,
> src_box->height * src_pitch);
> } else {
> evergreen_dma_copy_tile(rctx, dst, dst_level, dst_x, dst_y,
> dst_z,
> - src, src_level, src_box->x,
> src_box->y, src_box->z,
> + src, src_level, src_x, src_y,
> src_box->z,
> copy_height, dst_pitch, bpp);
> }
> return TRUE;
> diff --git a/src/gallium/drivers/r600/r600_state.c
> b/src/gallium/drivers/r600/r600_state.c
> index 301ca88..ac0e0ce 100644
> --- a/src/gallium/drivers/r600/r600_state.c
> +++ b/src/gallium/drivers/r600/r600_state.c
> @@ -3139,6 +3139,7 @@ boolean r600_dma_blit(struct pipe_context *ctx,
> struct r600_texture *rdst = (struct r600_texture*)dst;
> unsigned dst_pitch, src_pitch, bpp, dst_mode, src_mode, copy_height;
> unsigned src_w, dst_w;
> + unsigned src_x, src_y;
>
> if (rctx->rings.dma.cs == NULL) {
> return FALSE;
> @@ -3147,6 +3148,11 @@ boolean r600_dma_blit(struct pipe_context *ctx,
> return FALSE;
> }
>
> + src_x = util_format_get_nblocksx(src->format, src_box->x);
> + dst_x = util_format_get_nblocksx(src->format, dst_x);
> + src_y = util_format_get_nblocksy(src->format, src_box->y);
> + dst_y = util_format_get_nblocksy(src->format, dst_y);
> +
> bpp = rdst->surface.bpe;
> dst_pitch = rdst->surface.level[dst_level].pitch_bytes;
> src_pitch = rsrc->surface.level[src_level].pitch_bytes;
> @@ -3179,7 +3185,7 @@ boolean r600_dma_blit(struct pipe_context *ctx,
> */
> src_offset= rsrc->surface.level[src_level].offset;
> src_offset += rsrc->surface.level[src_level].slice_size *
> src_box->z;
> - src_offset += src_box->y * src_pitch + src_box->x * bpp;
> + src_offset += src_y * src_pitch + src_x * bpp;
> dst_offset = rdst->surface.level[dst_level].offset;
> dst_offset += rdst->surface.level[dst_level].slice_size *
> dst_z;
> dst_offset += dst_y * dst_pitch + dst_x * bpp;
> @@ -3191,7 +3197,7 @@ boolean r600_dma_blit(struct pipe_context *ctx,
> r600_dma_copy(rctx, dst, src, dst_offset, src_offset, size);
> } else {
> return r600_dma_copy_tile(rctx, dst, dst_level, dst_x, dst_y,
> dst_z,
> - src, src_level, src_box->x,
> src_box->y, src_box->z,
> + src, src_level, src_x, src_y,
> src_box->z,
> copy_height, dst_pitch, bpp);
> }
> return TRUE;
> --
> 1.8.1.5
>
> _
[Mesa-dev] [PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.
Previously, we had a separate function for setting up the built-in
variables for each combination of shader stage and GLSL version
(e.g. generate_110_vs_variables to generate the built-in variables for
GLSL 1.10 vertex shaders). The functions called each other in ad-hoc
ways, leading to unexpected inconsistencies (for example,
generate_120_fs_variables was called for GLSL versions 1.20 and above,
but generate_130_fs_variables was called only for GLSL version 1.30).
In addition, it led to a lot of code duplication, since many varyings
had to be duplicated in both the FS and VS code paths. With the
advent of geometry shaders (and later, tessellation control and
tessellation evaluation shaders), this code duplication was going to
get a lot worse.
So this patch reworks things so that instead of having a separate
function for each shader type and GLSL version, we have a function for
constants, one for uniforms, one for varyings, and one for the special
variables that are specific to each shader type.
In addition, we use a class, builtin_variable_generator, to keep track
of the instruction exec_list, the GLSL parse state, commonly-used
types, and a few other variables, so that we don't have to pass them
around as function arguments. This makes the code a lot more compact.
Where it was feasible to do so without introducing compilation errors,
I've also gone ahead and introduced the variables needed for
{ARB,EXT}_geometry_shader4 style geometry shaders. This patch takes
care of everything except the GS variable gl_VerticesIn, the FS
variable gl_PrimitiveID, and GLSL 1.50 style geometry shader inputs
(using the gl_in interface block). Those remaining features will be
added later.
I've also made a slight nomenclature change: previously we used the
word "deprecated" to refer to variables which are marked in GLSL 1.40
as requiring the ARB_compatibility extension, and are marked in GLSL
1.50 onward as requiring the compatibilty profile. This was
misleading, since not all deprecated variables require the
compatibility profile (for example gl_FragData and gl_FragColor, which
have been deprecated since GLSL 1.30, but do not require the
compatibility profile until GLSL 4.20). We now consistently use the
word "compatibility" to refer to these variables.
This patch doesn't introduce any functional changes (since geometry
shaders haven't been enabled yet).
---
src/glsl/builtin_variables.cpp | 1124 +---
1 file changed, 363 insertions(+), 761 deletions(-)
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index eccd15a..0c74200 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -30,116 +30,6 @@
#include "program/prog_statevars.h"
#include "program/prog_instruction.h"
-static void generate_ARB_draw_buffers_variables(exec_list *,
- struct _mesa_glsl_parse_state *,
- bool,
_mesa_glsl_parser_targets);
-
-static void
-generate_ARB_draw_instanced_variables(exec_list *,
- struct _mesa_glsl_parse_state *,
- bool, _mesa_glsl_parser_targets);
-
-static void
-generate_AMD_vertex_shader_layer_variables(exec_list *instructions,
- struct _mesa_glsl_parse_state
*state,
- bool warn,
- _mesa_glsl_parser_targets target);
-
-struct builtin_variable {
- enum ir_variable_mode mode;
- int slot;
- const char *type;
- const char *name;
-};
-
-static const builtin_variable builtin_core_vs_variables[] = {
- { ir_var_shader_out, VARYING_SLOT_POS, "vec4", "gl_Position" },
- { ir_var_shader_out, VARYING_SLOT_PSIZ, "float", "gl_PointSize" },
-};
-
-static const builtin_variable builtin_core_fs_variables[] = {
- { ir_var_shader_in, VARYING_SLOT_POS, "vec4", "gl_FragCoord" },
- { ir_var_shader_in, VARYING_SLOT_FACE, "bool", "gl_FrontFacing" },
- { ir_var_shader_out, FRAG_RESULT_COLOR, "vec4", "gl_FragColor" },
-};
-
-static const builtin_variable builtin_100ES_fs_variables[] = {
- { ir_var_shader_in, VARYING_SLOT_PNTC, "vec2", "gl_PointCoord" },
-};
-
-static const builtin_variable builtin_300ES_vs_variables[] = {
- { ir_var_system_value, SYSTEM_VALUE_VERTEX_ID, "int", "gl_VertexID" },
-};
-
-static const builtin_variable builtin_300ES_fs_variables[] = {
- { ir_var_shader_in, VARYING_SLOT_POS, "vec4", "gl_FragCoord" },
- { ir_var_shader_in, VARYING_SLOT_FACE, "bool", "gl_FrontFacing" },
- { ir_var_shader_out, FRAG_RESULT_DEPTH, "float", "gl_FragDepth" },
- { ir_var_shader_in, VARYING_SLOT_PNTC, "vec2", "gl_PointCoord" },
-};
-
-static const builtin_variable builtin_110_fs_variables[] = {
- { ir_var_shader_out, FRAG_RESULT_DEPTH, "float", "gl_FragDepth" },
-};
-
-static const builtin_variable builtin_110_d
[Mesa-dev] [PATCH RFC 2/3] glsl: Make gl_TexCoord compatibility-only
gl_TexCoord was deprecated in GLSL 1.30. In GLSL 1.40 it was marked
as ARB_compatibility-only, and in GLSL 1.50 and above it was marked as
only appearing in the compatibility profile. It has never appeared in
GLSL ES.
However, Mesa erroneously included it in all desktop versions of GLSL,
even versions 1.40 and 1.50 (which do not currently support the
compatibility profile). This patch makes gl_TexCoord available in the
compatibility profile (and GLSL versions 1.30 and prior) only.
NOTE: although this is a simple bug fix, it probably isn't sensible to
cherry-pick it to stable release branches, since its only effect is to
cause incorrectly-written shaders to fail to compile.
---
src/glsl/builtin_variables.cpp | 56 ++
1 file changed, 30 insertions(+), 26 deletions(-)
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index 58019c6..eccd15a 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -748,20 +748,22 @@ generate_110_vs_variables(exec_list *instructions,
}
generate_110_uniforms(instructions, state, add_deprecated);
- /* From page 54 (page 60 of the PDF) of the GLSL 1.20 spec:
-*
-* "As with all arrays, indices used to subscript gl_TexCoord must
-* either be an integral constant expressions, or this array must be
-* re-declared by the shader with a size. The size can be at most
-* gl_MaxTextureCoords. Using indexes close to 0 may aid the
-* implementation in preserving varying resources."
-*/
- const glsl_type *const vec4_array_type =
- glsl_type::get_array_instance(glsl_type::vec4_type, 0);
+ if (add_deprecated) {
+ /* From page 54 (page 60 of the PDF) of the GLSL 1.20 spec:
+ *
+ * "As with all arrays, indices used to subscript gl_TexCoord must
+ * either be an integral constant expressions, or this array must be
+ * re-declared by the shader with a size. The size can be at most
+ * gl_MaxTextureCoords. Using indexes close to 0 may aid the
+ * implementation in preserving varying resources."
+ */
+ const glsl_type *const vec4_array_type =
+ glsl_type::get_array_instance(glsl_type::vec4_type, 0);
- add_variable(instructions, state->symbols,
- "gl_TexCoord", vec4_array_type, ir_var_shader_out,
-VARYING_SLOT_TEX0);
+ add_variable(instructions, state->symbols,
+ "gl_TexCoord", vec4_array_type, ir_var_shader_out,
+ VARYING_SLOT_TEX0);
+ }
generate_ARB_draw_buffers_variables(instructions, state, false,
vertex_shader);
@@ -944,20 +946,22 @@ generate_110_fs_variables(exec_list *instructions,
generate_110_uniforms(instructions, state, add_deprecated);
- /* From page 54 (page 60 of the PDF) of the GLSL 1.20 spec:
-*
-* "As with all arrays, indices used to subscript gl_TexCoord must
-* either be an integral constant expressions, or this array must be
-* re-declared by the shader with a size. The size can be at most
-* gl_MaxTextureCoords. Using indexes close to 0 may aid the
-* implementation in preserving varying resources."
-*/
- const glsl_type *const vec4_array_type =
- glsl_type::get_array_instance(glsl_type::vec4_type, 0);
+ if (add_deprecated) {
+ /* From page 54 (page 60 of the PDF) of the GLSL 1.20 spec:
+ *
+ * "As with all arrays, indices used to subscript gl_TexCoord must
+ * either be an integral constant expressions, or this array must be
+ * re-declared by the shader with a size. The size can be at most
+ * gl_MaxTextureCoords. Using indexes close to 0 may aid the
+ * implementation in preserving varying resources."
+ */
+ const glsl_type *const vec4_array_type =
+ glsl_type::get_array_instance(glsl_type::vec4_type, 0);
- add_variable(instructions, state->symbols,
- "gl_TexCoord", vec4_array_type, ir_var_shader_in,
-VARYING_SLOT_TEX0);
+ add_variable(instructions, state->symbols,
+ "gl_TexCoord", vec4_array_type, ir_var_shader_in,
+ VARYING_SLOT_TEX0);
+ }
generate_ARB_draw_buffers_variables(instructions, state, false,
fragment_shader);
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH RFC 1/3] glsl ES: Fix magnitude of gl_MaxVertexUniformVectors.
Previously, we set it equal to MaxVertexUniformComponents. It should be MaxVertexUniformComponents / 4. NOTE: This is a candidate for the stable branches. Cc: mesa-sta...@lists.freedesktop.org --- src/glsl/builtin_variables.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp index f4ac205..58019c6 100644 --- a/src/glsl/builtin_variables.cpp +++ b/src/glsl/builtin_variables.cpp @@ -533,7 +533,7 @@ generate_common_ES_uniforms(exec_list *instructions, add_builtin_constant(instructions, symtab, "gl_MaxVertexAttribs", state->Const.MaxVertexAttribs); add_builtin_constant(instructions, symtab, "gl_MaxVertexUniformVectors", - state->Const.MaxVertexUniformComponents); + state->Const.MaxVertexUniformComponents / 4); add_builtin_constant(instructions, symtab, "gl_MaxVertexTextureImageUnits", state->Const.MaxVertexTextureImageUnits); add_builtin_constant(instructions, symtab, "gl_MaxCombinedTextureImageUnits", -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH RFC 0/3] glsl: Rewrite builtin_variables.cpp.
While hunting down some geometry shader bugs last week, I became
concerned about the organization of src/glsl/builtin_variables.cpp,
which is responsible for setting up all the GLSL built-in variables
accessible by a shader, based on the shader type (VS or FS), GLSL
version, desktop/GLES flag, and what extensions are enabled. I was
concerned about the following things:
- The code contains a separate function to handle each GLSL version
and shader type (e.g. generate_130_vs_variables to generate the
vertex shader variables for GLSL 1.30). Since most GLSL versions
contain a superset of the variables from the previous version, these
functions mostly call each other but not always (for example
generate_130_vs_variables calls generate_120_vs_variables, but
generate_140_fs_variables doesn't call generate_130_fs_variables).
As a result, it can be difficult to tell at a glance which set of
GLSL versions a given function applies to. Also, it isn't obvious
which set of functions need to be called to establish the right set
of variables for a given shader type. As a result, until very
recently on my geometry shader branch, uniforms and constants were
missing from geometry shaders.
- Several variables are declared in multiple places. For example
gl_PointCoord (which appears in the fragment shader for every
version of GLSL except desktop GLSL 1.10) has to be declared in
three places: builtin_100ES_fs_variables (which applies only to GLSL
1.00 ES), builtin_300ES_fs_variables (which applies only to GLSL
3.00 ES), and builtin_120_fs_variables (which applies to all desktop
GLSL versions 1.20 and onward).
- With the advent of geometry shaders, the level of code duplication
is going to get a lot worse, because each "varying" variable has to
be declared once for vertex shaders, twice for geometry shaders (as
input and as output), and once for fragment shaders. That's going
to get worse again in the future when we add tessellation control
and tessellation evaluation shaders.
This patch series reworks builtin_variables.cpp so that:
- Each built-in variable is declared in exactly one place, and it is
clear from the surrounding context when each variable is available.
For example, here's the new declaration of gl_PointCoord:
if (state->is_version(120, 100))
add_input(VARYING_SLOT_PNTC, vec2_t, "gl_PointCoord");
- Each varying is declared exactly once. For example here is the
declaration of gl_ClipDistance (this covers the VS output, the GS
input and output, and the FS input):
if (state->is_version(130, 0)) {
ADD_VARYING(VARYING_SLOT_CLIP_DIST0, array(float_t, 0),
"gl_ClipDistance");
}
- The code paths are nearly identical for all shader types and GLSL
versions.
I also made a number of minor changes to improve the readability of
the file. For example I created a class, builtin_variable_generator,
to keep track of the exec_list of instructions and the
_mesa_glsl_parse_state, so that we don't have to pass those explicitly
around with each function call.
In the process of doing the rewrite, I discovered bugs in gl_TexCoord
and gl_MaxUniformVectors. I've made separate patches to fix those
bugs, so that they can be cherry-picked to stable branches if
necessary.
This series is avaiable at branch "builtin-variables-rework" of
https://github.com/stereotype441/mesa.git.
[PATCH RFC 1/3] glsl ES: Fix magnitude of gl_MaxVertexUniformVectors.
[PATCH RFC 2/3] glsl: Make gl_TexCoord compatibility-only
[PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] gallium-egl: Use native types rather than EGL ones
ping
Does anyone have any objections on this patch? Feel free to commit, it
looks ok
Cheers
Emil
On 22/06/13 16:43, Emil Velikov wrote:
> Change egl_g3d_wl_drm_common_query_buffer() to use boolean/int rather than
> EGLBoolean/EGLint, based on the interface in native_wayland_bufmgr.h,
>
> Resolves type conversion warnings spotted by gcc
>
> x11/native_dri2.c:892:1: warning: initialization from incompatible pointer
> type[enabled by default]
> };
> ^
>
> x11/native_dri2.c:892:1: warning: (near initialization for
> 'dri2_display_wayland_bufmgr.query_buffer') [enabled by default]
>
> wayland/native_drm.c:302:1: warning: initialization from incompatible pointer
> type [enabled by default]
> };
> ^
> wayland/native_drm.c:302:1: warning: (near initialization for
> 'wayland_drm_display_wayland_bufmgr.query_buffer') [enabled by default]
>
> drm/native_drm.c:244:1: warning: initialization from incompatible pointer
> type [enabled by default]
> };
> ^
> drm/native_drm.c:244:1: warning: (near initialization for
> 'drm_display_wayland_bufmgr.query_buffer') [enabled by default]
>
> Signed-off-by: Emil Velikov
> CC: Kristian Høgsberg
> ---
> .../egl/common/native_wayland_drm_bufmgr_helper.c| 16
>
> .../egl/common/native_wayland_drm_bufmgr_helper.h| 4 ++--
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git
> a/src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.c
> b/src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.c
> index a9e7342..0711236 100644
> --- a/src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.c
> +++ b/src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.c
> @@ -69,10 +69,10 @@ egl_g3d_wl_drm_common_wl_buffer_get_resource(struct
> native_display *ndpy,
> return wayland_drm_buffer_get_buffer(buffer);
> }
>
> -EGLBoolean
> +boolean
> egl_g3d_wl_drm_common_query_buffer(struct native_display *ndpy,
> struct wl_buffer *_buffer,
> - EGLint attribute, EGLint *value)
> + int attribute, int *value)
> {
> struct wl_drm_buffer *buffer = (struct wl_drm_buffer *) _buffer;
> struct pipe_resource *resource = buffer->driver_buffer;
> @@ -85,21 +85,21 @@ egl_g3d_wl_drm_common_query_buffer(struct native_display
> *ndpy,
>switch (resource->format) {
>case PIPE_FORMAT_B8G8R8A8_UNORM:
> *value = EGL_TEXTURE_RGBA;
> - return EGL_TRUE;
> + return TRUE;
>case PIPE_FORMAT_B8G8R8X8_UNORM:
> *value = EGL_TEXTURE_RGB;
> - return EGL_TRUE;
> + return TRUE;
>default:
> - return EGL_FALSE;
> + return FALSE;
>}
> case EGL_WIDTH:
>*value = buffer->buffer.width;
> - return EGL_TRUE;
> + return TRUE;
> case EGL_HEIGHT:
>*value = buffer->buffer.height;
> - return EGL_TRUE;
> + return TRUE;
> default:
> - return EGL_FALSE;
> + return FALSE;
> }
> }
>
> diff --git
> a/src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.h
> b/src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.h
> index 543dc6f..cf86b90 100644
> --- a/src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.h
> +++ b/src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.h
> @@ -39,9 +39,9 @@ struct pipe_resource *
> egl_g3d_wl_drm_common_wl_buffer_get_resource(struct native_display *ndpy,
> struct wl_buffer *buffer);
>
> -EGLBoolean
> +boolean
> egl_g3d_wl_drm_common_query_buffer(struct native_display *ndpy,
> struct wl_buffer *buffer,
> - EGLint attribute, EGLint *value);
> + int attribute, int *value);
>
> #endif /* _NATIVE_WAYLAND_DRM_BUFMGR_HELPER_H_ */
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCHv2 4/4] glsl opt_flip_matrices: Silence unused variable warning in the release build
Resolves the following gcc warning
opt_flip_matrices.cpp:84:32: warning: unused variable 'deref'
v2: keep the variable, but wrap it in a ifndef NDEBUG block(suggested by Ian)
Signed-off-by: Emil Velikov
Reviewed-by: Kenneth Graunke
---
Feel free to commit
---
src/glsl/opt_flip_matrices.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glsl/opt_flip_matrices.cpp b/src/glsl/opt_flip_matrices.cpp
index 497513f..2107b1d 100644
--- a/src/glsl/opt_flip_matrices.cpp
+++ b/src/glsl/opt_flip_matrices.cpp
@@ -81,8 +81,10 @@ matrix_flipper::visit_enter(ir_expression *ir)
if (mvp_transpose &&
strcmp(mat_var->name, "gl_ModelViewProjectionMatrix") == 0) {
+#ifndef NDEBUG
ir_dereference_variable *deref =
ir->operands[0]->as_dereference_variable();
assert(deref && deref->var == mat_var);
+#endif
void *mem_ctx = ralloc_parent(ir);
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] glsl ast_to_hir: Silence uninitialized variable warnings in the release build
Resolves the following gcc warnings
warning: 'iface_type_name' may be used uninitialized in this function
warning: 'var_mode' may be used uninitialized in this function
Note: The variables are initialised to UNKNOWN and ir_var_auto
Signed-off-by: Emil Velikov
Reviewed-by: Ian Romanick
---
Feel free to commit
---
src/glsl/ast_to_hir.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index efbd72c..52b562c 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4221,6 +4221,8 @@ ast_interface_block::hir(exec_list *instructions,
var_mode = ir_var_uniform;
iface_type_name = "uniform";
} else {
+ var_mode = ir_var_auto;
+ iface_type_name = "UNKNOWN";
assert(!"interface block layout qualifier not found!");
}
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCHv2 2/4] nvc0: Silence uninitialized variable warning in the release build
Resolves the following gcc warning warning: 'ptr' may be used uninitialized in this function xy[0] = ptr[sample_index][0] * 0.0625f; ^ v2: Bail out when using non-conformant sample_count (spotted by calim) Signed-off-by: Emil Velikov --- src/gallium/drivers/nvc0/nvc0_context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nvc0/nvc0_context.c b/src/gallium/drivers/nvc0/nvc0_context.c index cd86040..2d6d315 100644 --- a/src/gallium/drivers/nvc0/nvc0_context.c +++ b/src/gallium/drivers/nvc0/nvc0_context.c @@ -394,7 +394,7 @@ nvc0_context_get_sample_position(struct pipe_context *pipe, case 8: ptr = ms8; break; default: assert(0); - break; + return; } xy[0] = ptr[sample_index][0] * 0.0625f; xy[1] = ptr[sample_index][1] * 0.0625f; -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] R600/SI: Initial double precision support for Radeon SI
On Tue, Jul 02, 2013 at 10:44:10AM +0200, Niels Ole Salscheider wrote:
> Hi,
>
> the attached patches add initial support for double precision operations on
> Southern Islands cards.
>
> Some expressions containing multiple double precision kernel arguments cause
> llvm to run until all memory is used - but I do not (yet) know why.
> It works fine as long as I pass pointers to double values.
>
I may have an idea about why this is happening. Could you file a bug
report and attach an LLVM IR test case?
All these patches look good to me, but #2 and #6 should have a test case
with them. If you resubmit these patches with test cases, I will push the
entire series.
Nice work!
-Tom
> Regards,
>
> Ole
> From 4224b314cf2d97cdf2ac99564d6155fa04fbb971 Mon Sep 17 00:00:00 2001
> From: Niels Ole Salscheider
> Date: Sat, 1 Jun 2013 16:48:56 +0200
> Subject: [PATCH 1/6] R600/SI: Add initial double precision support for SI
>
> ---
> lib/Target/R600/AMDGPUISelLowering.cpp | 6 ++
> lib/Target/R600/SIISelLowering.cpp | 1 +
> lib/Target/R600/SIInstructions.td | 30 +-
> test/CodeGen/R600/fadd64.ll| 13 +
> test/CodeGen/R600/fdiv64.ll| 14 ++
> test/CodeGen/R600/fmul64.ll| 13 +
> test/CodeGen/R600/load64.ll| 20
> 7 Dateien geändert, 96 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
> create mode 100644 test/CodeGen/R600/fadd64.ll
> create mode 100644 test/CodeGen/R600/fdiv64.ll
> create mode 100644 test/CodeGen/R600/fmul64.ll
> create mode 100644 test/CodeGen/R600/load64.ll
>
> diff --git a/lib/Target/R600/AMDGPUISelLowering.cpp
> b/lib/Target/R600/AMDGPUISelLowering.cpp
> index 4019a1f..5f3d496 100644
> --- a/lib/Target/R600/AMDGPUISelLowering.cpp
> +++ b/lib/Target/R600/AMDGPUISelLowering.cpp
> @@ -60,12 +60,18 @@ AMDGPUTargetLowering::AMDGPUTargetLowering(TargetMachine
> &TM) :
>setOperationAction(ISD::STORE, MVT::v4f32, Promote);
>AddPromotedToType(ISD::STORE, MVT::v4f32, MVT::v4i32);
>
> + setOperationAction(ISD::STORE, MVT::f64, Promote);
> + AddPromotedToType(ISD::STORE, MVT::f64, MVT::i64);
> +
>setOperationAction(ISD::LOAD, MVT::f32, Promote);
>AddPromotedToType(ISD::LOAD, MVT::f32, MVT::i32);
>
>setOperationAction(ISD::LOAD, MVT::v4f32, Promote);
>AddPromotedToType(ISD::LOAD, MVT::v4f32, MVT::v4i32);
>
> + setOperationAction(ISD::LOAD, MVT::f64, Promote);
> + AddPromotedToType(ISD::LOAD, MVT::f64, MVT::i64);
> +
>setOperationAction(ISD::MUL, MVT::i64, Expand);
>
>setOperationAction(ISD::UDIV, MVT::i32, Expand);
> diff --git a/lib/Target/R600/SIISelLowering.cpp
> b/lib/Target/R600/SIISelLowering.cpp
> index 9d4cfef..0d17a12 100644
> --- a/lib/Target/R600/SIISelLowering.cpp
> +++ b/lib/Target/R600/SIISelLowering.cpp
> @@ -45,6 +45,7 @@ SITargetLowering::SITargetLowering(TargetMachine &TM) :
>
>addRegisterClass(MVT::v2i32, &AMDGPU::VReg_64RegClass);
>addRegisterClass(MVT::v2f32, &AMDGPU::VReg_64RegClass);
> + addRegisterClass(MVT::f64, &AMDGPU::VReg_64RegClass);
>
>addRegisterClass(MVT::v4i32, &AMDGPU::VReg_128RegClass);
>addRegisterClass(MVT::v4f32, &AMDGPU::VReg_128RegClass);
> diff --git a/lib/Target/R600/SIInstructions.td
> b/lib/Target/R600/SIInstructions.td
> index 9c96c08..b956387 100644
> --- a/lib/Target/R600/SIInstructions.td
> +++ b/lib/Target/R600/SIInstructions.td
> @@ -660,7 +660,9 @@ defm V_RSQ_LEGACY_F32 : VOP1_32 <
>[(set f32:$dst, (int_AMDGPU_rsq f32:$src0))]
> >;
> defm V_RSQ_F32 : VOP1_32 <0x002e, "V_RSQ_F32", []>;
> -defm V_RCP_F64 : VOP1_64 <0x002f, "V_RCP_F64", []>;
> +defm V_RCP_F64 : VOP1_64 <0x002f, "V_RCP_F64",
> + [(set f64:$dst, (fdiv FP_ONE, f64:$src0))]
> +>;
> defm V_RCP_CLAMP_F64 : VOP1_64 <0x0030, "V_RCP_CLAMP_F64", []>;
> defm V_RSQ_F64 : VOP1_64 <0x0031, "V_RSQ_F64", []>;
> defm V_RSQ_CLAMP_F64 : VOP1_64 <0x0032, "V_RSQ_CLAMP_F64", []>;
> @@ -996,10 +998,25 @@ def V_LSHR_B64 : VOP3_64_Shift <0x0162,
> "V_LSHR_B64",
> >;
> def V_ASHR_I64 : VOP3_64_Shift <0x0163, "V_ASHR_I64", []>;
>
> +let isCommutable = 1 in {
> +
> def V_ADD_F64 : VOP3_64 <0x0164, "V_ADD_F64", []>;
> def V_MUL_F64 : VOP3_64 <0x0165, "V_MUL_F64", []>;
> def V_MIN_F64 : VOP3_64 <0x0166, "V_MIN_F64", []>;
> def V_MAX_F64 : VOP3_64 <0x0167, "V_MAX_F64", []>;
> +
> +} // isCommutable = 1
> +
> +def : Pat <
> + (fadd f64:$src0, f64:$src1),
> + (V_ADD_F64 $src0, $src1, (i64 0))
> +>;
> +
> +def : Pat <
> + (fmul f64:$src0, f64:$src1),
> + (V_MUL_F64 $src0, $src1, (i64 0))
> +>;
> +
> def V_LDEXP_F64 : VOP3_64 <0x0168, "V_LDEXP_F64", []>;
>
> let isCommutable = 1 in {
> @@ -1417,6 +1434,10 @@ def : BitConvert ;
> def : BitConvert ;
> def : BitConvert ;
>
> +def : BitConvert ;
> +
> +def : BitConvert ;
> +
> /** === **/
> /** Src & Dst modifiers **/
> /*
Re: [Mesa-dev] [RFC] Mesa 9.2 and release process changes
On Tue, Jul 02, 2013 at 01:02:06PM -0700, Ian Romanick wrote: > To keep our six-month release cadence, it looks like we'll target > August 22nd for 9.2. That means we'll probably need to make the > release branch on July 18th... that's just over two weeks from now. > > Assuming that works for everyone, I'd like to propose a couple > changes to our post-9.2 release process. > > 1. Carl Worth is taking over stable releases from me, so I'd like to > increase the rate of stable releases from (nominally) monthly to > every two weeks. > > 2. Instead of just posting md5sum for the release tarballs, I think > we should start GPG signing them. I'm not sure what sort of process > we want to establish for this. Should they just be signed by the > release managers key? Is this easier than I think it is? > > 3. I'd like to make some adjustments to our process for picking > patches back to the stable branch. The current process is okay, but > it has some kinks. The two big (related) problems are people either > under-mark things for the stable branch or over-mark. We also have > the problem that things are occasionally marked for stable that, in > the end, shouldn't go to stable. > > Instead of the current system, I'd like to propose creating a > mesa-stable mailing list where candidate patches will be sent. The > release manage will then have the responsibility to apply patches to > the branch. This gives opportunity for subsystem maintainers to ACK > or NAK patches before they land. It also gives the opportunity to > use a build bot to pre-verify that no patch ever breaks the build on > the stable branch. > > Anyone can nominate a patch for stable by sending it to the list. > This provides a means for solving the under-mark problem. It may > mean that developers have to do more work (e.g., waiting awhile > after a patch lands on master to send it to the stable list), so we > may need to come up with some means to mitigate that. > > As part of this, we need to clearly document the criteria for > inclusion in the stable branch. We have some vague criteria now, > but we should formalize and agree on the list. > > 4. With the above changes in the stable releases, I'd like to > increase the rate of major releases from six months to three months. > A lot of good work (new features, performance improvements, etc.) > sit on master for a really long time before getting into a release. > As a result, many distros ship some semi-random point from master. > Given that we allow regressions to pile up on master (to be fixed > during the stabilization period), this is a pretty terrible > situation. > +1 I think this is great especially for drivers / state trackers that use LLVM as it will make it easier to sync up with LLVM releases. -Tom > This would mean that Mesa 9.3 would be mid-November. That sounds > pretty good to me. > ___ > 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] [RFC PATCH 12/12] i965/blorp: Add temporary work-around due to b607d57630daa7d92a84c41abfd45cacbe63f3d2
Address GPU hung due to skipping selection of 3D pipeline in blorp when RS
is switched on. I've yet to figure out the reason for this.
Signed-off-by: Abdiel Janulgue
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
index a88148e..a67bdf5 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -50,11 +50,22 @@ gen6_blorp_emit_batch_head(struct brw_context *brw,
const brw_blorp_params *params)
{
struct gl_context *ctx = &brw->intel.ctx;
+ struct intel_context *intel = &brw->intel;
/* To ensure that the batch contains only the resolve, flush the batch
* before beginning and after finishing emitting the resolve packets.
*/
intel_flush(ctx);
+
+ /* When we have resource streamer enabled. GPU hungs if 3D pipe
+ is not selected even if invariant state is initially selected
+ 3D pipe already.*/
+ if (intel->is_haswell) {
+ /* Select the 3D pipeline (as opposed to media) */
+ BEGIN_BATCH(1);
+ OUT_BATCH(brw->CMD_PIPELINE_SELECT << 16 | 0);
+ ADVANCE_BATCH();
+ }
}
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 11/12] i965/blorp: In blorp, update PS on-chip binding table when new surface state entries are generated
Signed-off-by: Abdiel Janulgue
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 16 +++-
src/mesa/drivers/dri/i965/gen7_blorp.cpp |3 ++-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
index d900734..a88148e 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -459,8 +459,22 @@ gen6_blorp_emit_binding_table(struct brw_context *brw,
uint32_t wm_surf_offset_renderbuffer,
uint32_t wm_surf_offset_texture)
{
+ struct intel_context *intel = &brw->intel;
uint32_t wm_bind_bo_offset;
- uint32_t *bind = (uint32_t *)
+ uint32_t *bind;
+
+ if (intel->is_haswell) {
+ gen7_update_ps_binding_table(brw,
+
BRW_BLORP_RENDERBUFFER_BINDING_TABLE_INDEX,
+ wm_surf_offset_renderbuffer);
+ gen7_update_ps_binding_table(brw,
+ BRW_BLORP_TEXTURE_BINDING_TABLE_INDEX,
+ wm_surf_offset_texture);
+
+ return brw->wm.bind_bo_offset;
+ }
+
+ bind = (uint32_t *)
brw_state_batch(brw, AUB_TRACE_BINDING_TABLE,
sizeof(uint32_t) *
BRW_BLORP_NUM_BINDING_TABLE_ENTRIES,
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index 822f954..4ec95e2 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -156,7 +156,8 @@ gen7_blorp_emit_surface_state(struct brw_context *brw,
? I915_TILING_Y : region->tiling;
uint32_t *surf = (uint32_t *)
- brw_state_batch(brw, AUB_TRACE_SURFACE_STATE, 8 * 4, 32,
&wm_surf_offset);
+ brw_state_batch(brw, AUB_TRACE_SURFACE_STATE, 8 * 4,
+ intel->is_haswell? 64 : 32, &wm_surf_offset);
memset(surf, 0, 8 * 4);
surf[0] = BRW_SURFACE_2D << BRW_SURFACE_TYPE_SHIFT |
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 10/12] i965: Use hw-bt for generated WM UBO surface states.
Update the hardware binding table when uploading a new UBO surface state
Signed-off-by: Abdiel Janulgue
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index f1fb889..8dbf021 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -851,6 +851,7 @@ static void
brw_upload_wm_ubo_surfaces(struct brw_context *brw)
{
struct gl_context *ctx = &brw->intel.ctx;
+ struct intel_context *intel = &brw->intel;
/* _NEW_PROGRAM */
struct gl_shader_program *prog = ctx->Shader._CurrentFragmentProgram;
@@ -859,6 +860,10 @@ brw_upload_wm_ubo_surfaces(struct brw_context *brw)
brw_upload_ubo_surfaces(brw, prog->_LinkedShaders[MESA_SHADER_FRAGMENT],
&brw->wm.surf_offset[SURF_INDEX_WM_UBO(0)]);
+ if (intel->is_haswell) {
+ gen7_update_ps_binding_table(brw, SURF_INDEX_WM_UBO(0),
+
brw->wm.surf_offset[SURF_INDEX_WM_UBO(0)]);
+ }
}
const struct brw_tracked_state brw_wm_ubo_surfaces = {
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 09/12] i965: Flush on-chip binding table to pool
When the resource streamer encounters 3DSTATE_BINDING_TABLE_POINTERS_* command,
it will flush the edited state of our on-chip binding table to the pool.
Previously,
the CS will just normally consume this state. But when RS is enabled, it first
processes
this command before passing it to the CS causing a flush to the location
specified.
We don't want the RS to keep flushing all the time when the state of on-chip
binding tables
is unchanged. So make sure to flush it only when binding table state is dirty.
Signed-off-by: Abdiel Janulgue
---
src/mesa/drivers/dri/i965/gen7_vs_state.c | 10 ++
src/mesa/drivers/dri/i965/gen7_wm_state.c | 10 ++
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c
b/src/mesa/drivers/dri/i965/gen7_vs_state.c
index 1b97e8c..b7956fd 100644
--- a/src/mesa/drivers/dri/i965/gen7_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_vs_state.c
@@ -40,10 +40,12 @@ upload_vs_state(struct brw_context *brw)
gen7_emit_vs_workaround_flush(intel);
/* BRW_NEW_VS_BINDING_TABLE */
- BEGIN_BATCH(2);
- OUT_BATCH(_3DSTATE_BINDING_TABLE_POINTERS_VS << 16 | (2 - 2));
- OUT_BATCH(brw->vs.bind_bo_offset);
- ADVANCE_BATCH();
+ if (brw->state.dirty.brw & BRW_NEW_VS_BINDING_TABLE) {
+ BEGIN_BATCH(2);
+ OUT_BATCH(_3DSTATE_BINDING_TABLE_POINTERS_VS << 16 | (2 - 2));
+ OUT_BATCH(brw->vs.bind_bo_offset & 0xFFC0);
+ ADVANCE_BATCH();
+ }
/* CACHE_NEW_SAMPLER */
BEGIN_BATCH(2);
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_state.c
b/src/mesa/drivers/dri/i965/gen7_wm_state.c
index b025551..faa8bab 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_state.c
@@ -119,10 +119,12 @@ upload_ps_state(struct brw_context *brw)
HSW_PS_MAX_THREADS_SHIFT : IVB_PS_MAX_THREADS_SHIFT;
/* BRW_NEW_PS_BINDING_TABLE */
- BEGIN_BATCH(2);
- OUT_BATCH(_3DSTATE_BINDING_TABLE_POINTERS_PS << 16 | (2 - 2));
- OUT_BATCH(brw->wm.bind_bo_offset);
- ADVANCE_BATCH();
+ if (brw->state.dirty.brw & BRW_NEW_PS_BINDING_TABLE) {
+ BEGIN_BATCH(2);
+ OUT_BATCH(_3DSTATE_BINDING_TABLE_POINTERS_PS << 16 | (2 - 2));
+ OUT_BATCH(brw->wm.bind_bo_offset & 0xFFC0);
+ ADVANCE_BATCH();
+ }
/* CACHE_NEW_SAMPLER */
BEGIN_BATCH(2);
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 08/12] i965: Use hw-bt for renderbuffer, constant, and texture surface states.
Update the on-chip binding table for every generated renderbuffer, constant,
and texture surface_state entries. When hw-generated binding-tables are enabled,
bspec dictates that surface state entries should aligned to a 64-byte boundary.
Signed-off-by: Abdiel Janulgue
---
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 36 ++---
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
index 99b00e3..6a8e1fd 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
@@ -244,7 +244,12 @@ gen7_update_buffer_texture_surface(struct gl_context *ctx,
gl_format format = tObj->_BufferObjectFormat;
uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
-8 * 4, 32, &binding_table[surf_index]);
+8 * 4,
+intel->is_haswell? 64 : 32,
+&binding_table[surf_index]);
+ if (intel->is_haswell) {
+ gen7_update_ps_binding_table(brw, surf_index, binding_table[surf_index]);
+ }
memset(surf, 0, 8 * 4);
uint32_t surface_format = brw_format_for_mesa_format(format);
@@ -303,7 +308,15 @@ gen7_update_texture_surface(struct gl_context *ctx,
}
uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
-8 * 4, 32, &binding_table[surf_index]);
+8 * 4,
+intel->is_haswell? 64 : 32,
+&binding_table[surf_index]);
+ if (intel->is_haswell) {
+ if (binding_table == brw->wm.surf_offset)
+ gen7_update_ps_binding_table(brw, surf_index,
binding_table[surf_index]);
+ if (binding_table == brw->vs.surf_offset)
+ gen7_update_vs_binding_table(brw, surf_index,
binding_table[surf_index]);
+ }
memset(surf, 0, 8 * 4);
uint32_t tex_format = translate_tex_format(intel,
@@ -394,7 +407,9 @@ gen7_create_constant_surface(struct brw_context *brw,
const GLint w = elements - 1;
uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
-8 * 4, 32, out_offset);
+8 * 4,
+intel->is_haswell? 64 : 32,
+out_offset);
memset(surf, 0, 8 * 4);
surf[0] = BRW_SURFACE_BUFFER << BRW_SURFACE_TYPE_SHIFT |
@@ -495,7 +510,13 @@ gen7_update_null_renderbuffer_surface(struct brw_context
*brw, unsigned unit)
const struct gl_framebuffer *fb = ctx->DrawBuffer;
uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
- 8 * 4, 32, &brw->wm.surf_offset[unit]);
+8 * 4,
+intel->is_haswell? 64 : 32,
+&brw->wm.surf_offset[unit]);
+
+ if (intel->is_haswell) {
+ gen7_update_ps_binding_table(brw, unit, brw->wm.surf_offset[unit]);
+ }
memset(surf, 0, 8 * 4);
/* From the Ivybridge PRM, Volume 4, Part 1, page 65,
@@ -538,7 +559,12 @@ gen7_update_renderbuffer_surface(struct brw_context *brw,
rb->TexImage->TexObject->Target : GL_TEXTURE_2D;
uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
-8 * 4, 32, &brw->wm.surf_offset[unit]);
+8 * 4,
+intel->is_haswell? 64 : 32,
+&brw->wm.surf_offset[unit]);
+ if (intel->is_haswell) {
+ gen7_update_ps_binding_table(brw, unit, brw->wm.surf_offset[unit]);
+ }
memset(surf, 0, 8 * 4);
intel_miptree_used_for_rendering(irb->mt);
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 07/12] i965: Use hw-bt for pull constants and VS UBO surface states.
When surface_state pointing to pull constant surfaces are changed, update
on-chip binding table. Same with VS ubo surface states.
Signed-off-by: Abdiel Janulgue
---
src/mesa/drivers/dri/i965/brw_vs_surface_state.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vs_surface_state.c
b/src/mesa/drivers/dri/i965/brw_vs_surface_state.c
index 605d394..1aa5250 100644
--- a/src/mesa/drivers/dri/i965/brw_vs_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_vs_surface_state.c
@@ -34,6 +34,7 @@
#include "brw_context.h"
#include "brw_state.h"
+#include "brw_defines.h"
/* Creates a new VS constant buffer reflecting the current VS program's
* constants, if needed by the VS program.
@@ -94,6 +95,9 @@ brw_upload_vs_pull_constants(struct brw_context *brw)
intel->vtbl.create_constant_surface(brw, brw->vs.const_bo, 0, size,
&brw->vs.surf_offset[surf], false);
+ if (intel->is_haswell)
+ gen7_update_vs_binding_table(brw, surf, brw->vs.surf_offset[surf]);
+
brw->state.dirty.brw |= BRW_NEW_VS_CONSTBUF;
}
@@ -110,6 +114,8 @@ static void
brw_upload_vs_ubo_surfaces(struct brw_context *brw)
{
struct gl_context *ctx = &brw->intel.ctx;
+ struct intel_context *intel = &brw->intel;
+ uint32_t p, surf_offset;
/* _NEW_PROGRAM */
struct gl_shader_program *prog = ctx->Shader.CurrentVertexProgram;
@@ -118,6 +124,10 @@ brw_upload_vs_ubo_surfaces(struct brw_context *brw)
brw_upload_ubo_surfaces(brw, prog->_LinkedShaders[MESA_SHADER_VERTEX],
&brw->vs.surf_offset[SURF_INDEX_VS_UBO(0)]);
+
+ if (intel->is_haswell)
+ gen7_update_vs_binding_table(brw, SURF_INDEX_VS_UBO(0),
+ brw->vs.surf_offset[SURF_INDEX_VS_UBO(0)]);
}
const struct brw_tracked_state brw_vs_ubo_surfaces = {
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 06/12] i965: Implement opcodes for the hw-generated binding table EDIT commands
Signed-off-by: Abdiel Janulgue
---
src/mesa/drivers/dri/i965/brw_defines.h |5 +
src/mesa/drivers/dri/i965/brw_state.h |6 ++
src/mesa/drivers/dri/i965/gen7_misc_state.c | 31 +++
3 files changed, 42 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index c990958..81431d0 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1165,6 +1165,11 @@ enum brw_message_target {
/* Haswell hardware-generated binding tables */
#define _3DSTATE_BINDING_TABLE_POOL_ALLOC 0x7919 /* GEN7.5+ */
# define HSW_BINDING_TABLE_ALLOC_OFFSET 0x860 /* GEN7.5+ */
+#define _3DSTATE_BINDING_TABLE_EDIT_VS 0x7843 /* GEN7.5 */
+#define _3DSTATE_BINDING_TABLE_EDIT_GS 0x7844 /* GEN7.5 */
+#define _3DSTATE_BINDING_TABLE_EDIT_HS 0x7845 /* GEN7.5 */
+#define _3DSTATE_BINDING_TABLE_EDIT_DS 0x7846 /* GEN7.5 */
+#define _3DSTATE_BINDING_TABLE_EDIT_PS 0x7847 /* GEN7.5 */
#define _3DSTATE_SAMPLER_STATE_POINTERS0x7802 /* GEN6+ */
# define PS_SAMPLER_STATE_CHANGE (1 << 12)
diff --git a/src/mesa/drivers/dri/i965/brw_state.h
b/src/mesa/drivers/dri/i965/brw_state.h
index eecc1f2..c8808c8 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -216,6 +216,12 @@ get_attr_override(const struct brw_vue_map *vue_map, int
urb_entry_read_offset,
void gen7_rs_control(struct brw_context *brw, int enable);
void gen7_enable_hw_binding_tables(struct brw_context *brw);
void gen7_update_hw_bt(struct brw_context *brw);
+void gen7_update_vs_binding_table(struct brw_context *brw,
+ uint32_t index,
+ uint32_t surf_offset);
+void gen7_update_ps_binding_table(struct brw_context *brw,
+ uint32_t index,
+ uint32_t surf_offset);
/* gen7_urb.c */
void gen7_allocate_push_constants(struct brw_context *brw);
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index 11464a2..ae9c485 100644
--- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
@@ -150,6 +150,37 @@ gen7_rs_control(struct brw_context *brw, int enable)
}
void
+gen7_update_vs_binding_table(struct brw_context *brw,
+ uint32_t index,
+ uint32_t surf_offset)
+{
+ struct intel_context *intel = &brw->intel;
+
+ BEGIN_BATCH(3);
+ OUT_BATCH(_3DSTATE_BINDING_TABLE_EDIT_VS << 16 | (3 - 2));
+ OUT_BATCH(0x3);
+ OUT_BATCH(index << 16 | (surf_offset & 0xF) >> 5);
+ ADVANCE_BATCH();
+ brw->state.dirty.brw |= BRW_NEW_VS_BINDING_TABLE;
+}
+
+void
+gen7_update_ps_binding_table(struct brw_context *brw,
+ uint32_t index,
+ uint32_t surf_offset)
+{
+ struct intel_context *intel = &brw->intel;
+
+ BEGIN_BATCH(3);
+ OUT_BATCH(_3DSTATE_BINDING_TABLE_EDIT_PS << 16 | (3 - 2));
+ OUT_BATCH(0x3);
+ OUT_BATCH(index << 16 | (surf_offset & 0xF) >> 5);
+ ADVANCE_BATCH();
+
+ brw->state.dirty.brw |= BRW_NEW_PS_BINDING_TABLE;
+}
+
+void
gen7_enable_hw_binding_tables(struct brw_context *brw)
{
struct intel_context *intel = &brw->intel;
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 05/12] i965: Switch on hardware-generated binding tables.
On Haswell hardware with resource streamer enabled, enable the on-chip hardware
binding tables. The hw-bt can be updated directly using EDIT commands.
Skip manual generation of binding tables when this is activated.
Signed-off-by: Abdiel Janulgue
---
src/mesa/drivers/dri/i965/brw_context.c |2 +
src/mesa/drivers/dri/i965/brw_context.h |1 +
src/mesa/drivers/dri/i965/brw_defines.h |4 ++
src/mesa/drivers/dri/i965/brw_state.h|4 ++
src/mesa/drivers/dri/i965/brw_state_upload.c |3 +
src/mesa/drivers/dri/i965/brw_vs_surface_state.c |4 ++
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |4 ++
src/mesa/drivers/dri/i965/gen7_misc_state.c | 68 ++
8 files changed, 90 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 56c42ba..ed13bc4 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -438,6 +438,8 @@ brwCreateContext(int api,
brw_fs_alloc_reg_sets(brw);
+ brw->hw_bt_pool = 0;
+
if (INTEL_DEBUG & DEBUG_SHADER_TIME)
brw_init_shader_time(brw);
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index e250f51..26cc228 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1052,6 +1052,7 @@ struct brw_context
} reg_sets[2];
} wm;
+ drm_intel_bo *hw_bt_pool;
struct {
uint32_t state_offset;
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 04422fe..c990958 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1162,6 +1162,10 @@ enum brw_message_target {
#define _3DSTATE_BINDING_TABLE_POINTERS_GS 0x7829 /* GEN7+ */
#define _3DSTATE_BINDING_TABLE_POINTERS_PS 0x782A /* GEN7+ */
+/* Haswell hardware-generated binding tables */
+#define _3DSTATE_BINDING_TABLE_POOL_ALLOC 0x7919 /* GEN7.5+ */
+# define HSW_BINDING_TABLE_ALLOC_OFFSET 0x860 /* GEN7.5+ */
+
#define _3DSTATE_SAMPLER_STATE_POINTERS0x7802 /* GEN6+ */
# define PS_SAMPLER_STATE_CHANGE (1 << 12)
# define GS_SAMPLER_STATE_CHANGE (1 << 9)
diff --git a/src/mesa/drivers/dri/i965/brw_state.h
b/src/mesa/drivers/dri/i965/brw_state.h
index 43e5b0c..eecc1f2 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -118,6 +118,8 @@ extern const struct brw_tracked_state gen7_sol_state;
extern const struct brw_tracked_state gen7_urb;
extern const struct brw_tracked_state gen7_vs_state;
extern const struct brw_tracked_state gen7_wm_state;
+extern const struct brw_tracked_state gen7_hw_binding_tables;
+extern const struct brw_tracked_state gen7_hw_bt_update;
extern const struct brw_tracked_state haswell_cut_index;
/* brw_misc_state.c */
@@ -212,6 +214,8 @@ get_attr_override(const struct brw_vue_map *vue_map, int
urb_entry_read_offset,
/* Haswell Resource streamer controls */
void gen7_rs_control(struct brw_context *brw, int enable);
+void gen7_enable_hw_binding_tables(struct brw_context *brw);
+void gen7_update_hw_bt(struct brw_context *brw);
/* gen7_urb.c */
void gen7_allocate_push_constants(struct brw_context *brw);
diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index b04f9af..1916979 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -191,6 +191,9 @@ static const struct brw_tracked_state *gen7_atoms[] =
&gen6_vs_push_constants, /* Before vs_state */
&gen6_wm_push_constants, /* Before wm_surfaces and constant_buffer */
+ &gen7_hw_bt_update,
+ &gen7_hw_binding_tables, /* Enable hw-generated binding tables for Haswell
*/
+
/* Surface state setup. Must come before the VS/WM unit. The binding
* table upload must be last.
*/
diff --git a/src/mesa/drivers/dri/i965/brw_vs_surface_state.c
b/src/mesa/drivers/dri/i965/brw_vs_surface_state.c
index cbad071..605d394 100644
--- a/src/mesa/drivers/dri/i965/brw_vs_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_vs_surface_state.c
@@ -138,6 +138,10 @@ brw_vs_upload_binding_table(struct brw_context *brw)
{
uint32_t *bind;
int i;
+ struct intel_context *intel = &brw->intel;
+
+ if (intel->is_haswell)
+ return;
if (INTEL_DEBUG & DEBUG_SHADER_TIME) {
gen7_create_shader_time_surface(brw,
&brw->vs.surf_offset[SURF_INDEX_VS_SHADER_TIME]);
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 27a2651..f1fb889 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -879,6 +879,10 @@ brw_upload_wm_binding_table(struct brw_context *
[Mesa-dev] [RFC PATCH 04/12] i965: Add MI_RS_STORE_DATA_IMM workaround for 3DPRIMITIVE commands
Signed-off-by: Abdiel Janulgue
---
src/mesa/drivers/dri/i965/brw_draw.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index 5730eed..436077b 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -256,6 +256,20 @@ static void gen7_emit_prim(struct brw_context *brw,
intel_batchbuffer_emit_mi_flush(intel);
}
+ /* If resource streamer is enabled, an MI_RS_STORE_DATA_IMM with Resource
+* Streamer Flush set must be programmed prior to a 3DPRIMITIVE command.
+*/
+ if (intel->is_haswell) {
+ BEGIN_BATCH(4);
+ OUT_BATCH(MI_RS_STORE_DATA_IMM |
+(1 << 21) | /* rs flush */
+(4 - 2));
+ OUT_BATCH(0);
+ OUT_BATCH(0);
+ OUT_BATCH(0);
+ ADVANCE_BATCH();
+ }
+
BEGIN_BATCH(7);
OUT_BATCH(CMD_3D_PRIM << 16 | (7 - 2));
OUT_BATCH(hw_prim | vertex_access_type);
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 03/12] i965: Temporarily disable resource streamer when state base address is updated.
Prior to changing the Surface State Base Address, the resouce streamer must be
disabled
within a batch buffer where the RS is enabled. RS is re-enabled again once the
SBA is updated.
Signed-off-by: Abdiel Janulgue
---
src/mesa/drivers/dri/i965/brw_misc_state.c |7 +++
src/mesa/drivers/dri/i965/brw_state.h |3 +++
src/mesa/drivers/dri/i965/gen7_misc_state.c | 10 ++
3 files changed, 20 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 23faee6..f35149d 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -1047,6 +1047,9 @@ static void upload_state_base_address( struct brw_context
*brw )
if (intel->gen == 6)
intel_emit_post_sync_nonzero_flush(intel);
+ if (intel->is_haswell)
+ gen7_rs_control(brw, 0x0);
+
BEGIN_BATCH(10);
OUT_BATCH(CMD_STATE_BASE_ADDRESS << 16 | (10 - 2));
/* General state base address: stateless DP read/write requests */
@@ -1083,6 +1086,10 @@ static void upload_state_base_address( struct
brw_context *brw )
OUT_BATCH(1); /* Indirect object upper bound */
OUT_BATCH(1); /* Instruction access upper bound */
ADVANCE_BATCH();
+
+ if (intel->is_haswell)
+ gen7_rs_control(brw, 0x1);
+
} else if (intel->gen == 5) {
BEGIN_BATCH(8);
OUT_BATCH(CMD_STATE_BASE_ADDRESS << 16 | (8 - 2));
diff --git a/src/mesa/drivers/dri/i965/brw_state.h
b/src/mesa/drivers/dri/i965/brw_state.h
index 3ac65cf..43e5b0c 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -210,6 +210,9 @@ uint32_t
get_attr_override(const struct brw_vue_map *vue_map, int urb_entry_read_offset,
int fs_attr, bool two_side_color, uint32_t *max_source_attr);
+/* Haswell Resource streamer controls */
+void gen7_rs_control(struct brw_context *brw, int enable);
+
/* gen7_urb.c */
void gen7_allocate_push_constants(struct brw_context *brw);
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index 539fc32..0c96681 100644
--- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
@@ -138,3 +138,13 @@ const struct brw_tracked_state gen7_depthbuffer = {
},
.emit = brw_emit_depthbuffer,
};
+
+void
+gen7_rs_control(struct brw_context *brw, int enable)
+{
+ struct intel_context *intel = &brw->intel;
+
+ BEGIN_BATCH(1);
+ OUT_BATCH(MI_RS_CONTROL | enable);
+ ADVANCE_BATCH();
+}
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 02/12] intel: On Haswell hardware, enable the resource streamer on batchbuffer start
Signed-off-by: Abdiel Janulgue
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 409df29..84736a8 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -202,6 +202,9 @@ do_flush_locked(struct intel_context *intel)
if (batch->needs_sol_reset)
flags |= I915_EXEC_GEN7_SOL_RESET;
+ if (intel->is_haswell)
+ flags |= I915_EXEC_RS;
+
if (ret == 0) {
if (unlikely(INTEL_DEBUG & DEBUG_AUB))
brw_annotate_aub(intel);
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH 01/12] intel: Add resource streamer control defines
Signed-off-by: Abdiel Janulgue
---
src/mesa/drivers/dri/i965/intel_reg.h |4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_reg.h
b/src/mesa/drivers/dri/i965/intel_reg.h
index f45a8f3..2cf68dd 100644
--- a/src/mesa/drivers/dri/i965/intel_reg.h
+++ b/src/mesa/drivers/dri/i965/intel_reg.h
@@ -44,6 +44,10 @@
#define MI_STORE_REGISTER_MEM (CMD_MI | (0x24 << 23))
# define MI_STORE_REGISTER_MEM_USE_GGTT(1 << 22)
+/* Haswell RS control */
+#define MI_RS_CONTROL (CMD_MI | (0x6 << 23))
+#define MI_RS_STORE_DATA_IMM(CMD_MI | (0x2b << 23))
+
/** @{
*
* PIPE_CONTROL operation, a combination MI_FLUSH and register write with
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC] Enable Resource Streamer on Haswell
The following RFC patchset initially enables the resource streamer on Haswell. We can think of the resource streamer as a command streamer accelerator: It accelerates certain commands that would normally take time to build-up and submit to the GPU; hence reducing some of the overhead associated with such commands. In Haswell, generating binding tables and constant buffers can be offloaded from being CPU-generated commands to the resource streamer. This is a preparatory patchset that initially enables hardware-generated binding tables - which is primarily required to enable RS-based optimizations e.g.constant buffer generation and other ways to reduce command buffer submissions. This initial patch is closely modeled after the current model of how the i965 driver generates binding tables (see section below for possible future optimization). Though it shaved off a few microseconds off CPU cycles for every command submission, I don't expect it at its current form to produce wide margins in performance gains. The changes improved GLB 2.5 by 0.19% n=14. In hw-generated binding tables case, the RS basically sits in front of the CS watching for the [VS/PS]BINDING_TABLE_POINTERS commands. Once RS encounters it, it flushes the state of the on-die binding table entries to a buffer object, where the CS picks it up afterwards. Each surface state and it's associated index in the on-die binding table state can be edited directly instead of generating the entire binding table array in one go. One optimization idea that we can possibly implement in the future is to use the RS to publish deltas of changed surface states so that we wouldn't have to rebuild entire binding tables for every batch buffer flush. Currently our VS/PS surface states are appended at the end of our batchbuffer in the i965 driver. For every batchbuffer flush, the VS/PS surface states and binding tables are rebuilt everytime for every change. With the RS in mind, it would be possible to use a separate larger batchbuffer for (permanent?) surface state objects so the generated surface state offsets would change less often [1]. With this series, GLB works fine and most piglit tests pass but some random GPU lockups may occur when piglit is run over a period of time. intel_error_decode does not specifically say where in the batch the problem points to. I'll spend some time in nailing down this issue in the next revision. In the intel-gfx list, I'll post the libdrm and kernel portions that enables the RS-bits on MI_BATCH_BUFFER_START. [1] Needs changes in libdrm aperture checks to accomodate multiple levels of relocation See http://lists.freedesktop.org/archives/mesa-dev/2013-May/039088.html Abdiel Janulgue (12): intel: Add resource streamer control defines intel: On Haswell hardware, enable the resource streamer on batchbuffer start i965: Temporarily disable resource streamer when state base address is updated. i965: Add MI_RS_STORE_DATA_IMM workaround for 3DPRIMITIVE commands i965: Switch on hardware-generated binding tables. i965: Implement opcodes for the hw-generated binding table EDIT commands i965: Use hw-bt for pull constants and VS UBO surface states. i965: Use hw-bt for renderbuffer, constant, and texture surface states. i965: Flush on-chip binding table to pool i965: Use hw-bt for generated WM UBO surface states. i965/blorp: In blorp, update PS on-chip binding table when new surface state entries are generated i965/blorp: Add temporary work-around due to b607d57630daa7d92a84c41abfd45cacbe63f3d2 src/mesa/drivers/dri/i965/brw_context.c | 2 ++ src/mesa/drivers/dri/i965/brw_context.h | 1 + src/mesa/drivers/dri/i965/brw_defines.h | 9 ++ src/mesa/drivers/dri/i965/brw_draw.c | 14 + src/mesa/drivers/dri/i965/brw_misc_state.c| 7 + src/mesa/drivers/dri/i965/brw_state.h | 13 + src/mesa/drivers/dri/i965/brw_state_upload.c | 3 ++ src/mesa/drivers/dri/i965/brw_vs_surface_state.c | 14 + src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 9 ++ src/mesa/drivers/dri/i965/gen6_blorp.cpp | 27 - src/mesa/drivers/dri/i965/gen7_blorp.cpp | 3 +- src/mesa/drivers/dri/i965/gen7_misc_state.c | 109 + src/mesa/drivers/dri/i965/gen7_vs_state.c | 10 --- src/mesa/drivers/dri/i965/gen7_wm_state.c | 10 --- src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 36 +++ src/mesa/drivers/dri/i965/intel_batchbuffer.c | 3 ++ src/mesa/drivers/dri/i965/intel_reg.h | 4 +++ 17 files changed, 259 insertions(+), 15 deletions(-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/me
