Re: [Mesa-dev] [PATCH] r600: fix constant buffer size programming

On 21.12.2015 21:12, Grazvydas Ignotas wrote: When buffer size is less than 16, zero ends up being programmed as size, which prevents the hardware from fetching the correct values. Fix it by combining shift and align so that the value is always rounded up. Cc: "11.1 11.0 10.6"

Re: [Mesa-dev] [PATCH v2] Add .mailmap

On Tue, Dec 22, 2015 at 12:55 PM, Erik Faye-Lund wrote: > On Tue, Dec 22, 2015 at 12:47 PM, Thomas Tanner wrote: >> Hi, >> my primary email address for open source contributions is tan...@gmx.net >> cheers >> > > OK, I think Giuseppe will want this info for

Re: [Mesa-dev] [PATCH v3] Add .mailmap

On Tue, Dec 22, 2015 at 3:36 PM, Alex Deucher wrote: > > Maybe it would make sense to make the personal emails the default for > everyone. I think I'd prefer that too. I've changed yours too for now, but for me it's not always trivial to find which of the private emails

[Mesa-dev] [PATCH v4] Add .mailmap

This adds a first tentative .mailmap file, to canonicize contributor name/emails in shortlogs and other statistical endeavours. Signed-off-by: Giuseppe Bilotta --- .mailmap | 460 +++ 1 file changed, 460

Re: [Mesa-dev] [PATCH 01/13] nir: Add a glsl_vec_type() helper.

I think I've written this patch before... Reviewed-by: Jason Ekstrand On Dec 22, 2015 2:21 AM, "Kenneth Graunke" wrote: > I need access to glsl_type::vec2_type from C. Wrapping vec() also gives > us access to vec3 if we need it. > >

Re: [Mesa-dev] [PATCH 8/8] draw: fix draw pipeline stages wrt changing vertex sizes

On 22/12/15 03:00, srol...@vmware.com wrote: From: Roland Scheidegger The vertex size can change in fetch_pipeline_prepare, if drivers use the draw_prepare_shader_outputs hook (similar to what the llvm path already does). Albeit this is hugely confusing and very error

Re: [Mesa-dev] [PATCH v2 3/3] radeonsi: add RADEON_REPLACE_SHADERS debug option

For the series: Reviewed-by: Marek Olšák On Mon, Dec 21, 2015 at 10:18 PM, Nicolai Hähnle wrote: > From: Nicolai Hähnle > > This option allows replacing a single shader by a pre-compiled ELF object > as generated by LLVM's llc,

[Mesa-dev] [PATCH] nir/print: print variable constant-initializers

From: Rob Clark Signed-off-by: Rob Clark --- src/glsl/nir/nir_print.c | 53 1 file changed, 53 insertions(+) diff --git a/src/glsl/nir/nir_print.c b/src/glsl/nir/nir_print.c index

Re: [Mesa-dev] [PATCH 2/2] st/osmesa: add OSMesaCreateContextAttribs() function

Sorry for being late... Do you need to update the version scripts for this new function? src/gallium/targets/osmesa/osmesa.{sym,def,mingw.def} Andreas 2015-12-16 1:59 GMT+01:00 Brian Paul : > As with the previous commit, except for gallium. > --- >

Re: [Mesa-dev] [RFC] i965: alternative to memctx for cleaning up nir variants

On Mon, Dec 21, 2015 at 1:48 PM, Jason Ekstrand wrote: > > I think two different concepts of ownership are getting conflated here: > Right/responsibility to delete and right to modify. > > The way I understand it, gallium, as it stands, gives neither to the driver. > A

Re: [Mesa-dev] [RFC] i965: alternative to memctx for cleaning up nir variants

On Tue, Dec 22, 2015 at 9:02 PM, Rob Clark wrote: > On Mon, Dec 21, 2015 at 1:48 PM, Jason Ekstrand wrote: >> >> I think two different concepts of ownership are getting conflated here: >> Right/responsibility to delete and right to modify. >> >> The way

Re: [Mesa-dev] [RFC] i965: alternative to memctx for cleaning up nir variants

On Tue, Dec 22, 2015 at 9:47 PM, Connor Abbott wrote: > On Tue, Dec 22, 2015 at 9:02 PM, Rob Clark wrote: >> On Mon, Dec 21, 2015 at 1:48 PM, Jason Ekstrand wrote: >>> >>> I think two different concepts of ownership are getting

Re: [Mesa-dev] [RFC] i965: alternative to memctx for cleaning up nir variants

On Tue, Dec 22, 2015 at 9:55 PM, Rob Clark wrote: > On Tue, Dec 22, 2015 at 9:47 PM, Connor Abbott wrote: >> On Tue, Dec 22, 2015 at 9:02 PM, Rob Clark wrote: >>> On Mon, Dec 21, 2015 at 1:48 PM, Jason Ekstrand

Re: [Mesa-dev] [PATCH 12/13] i965: Handle mix-and-match TCS/TES with separate shader objects.

On 2015-12-22 02:20:57, Kenneth Graunke wrote: > GL_ARB_separate_shader_objects allows the application to mix-and-match > TCS and TES programs separately. This means that the interface between > the two stages isn't known until the final SSO pipeline is in place. > > This isn't a great match for

Re: [Mesa-dev] [PATCH] nir/print: print variable constant-initializers

On Tuesday, December 22, 2015 4:58:23 PM PST Rob Clark wrote: > From: Rob Clark > > Signed-off-by: Rob Clark Thanks! Reviewed-by: Kenneth Graunke signature.asc Description: This is a digitally signed message part.

Re: [Mesa-dev] [PATCH v2 5/7] i965: Add support for gl_DrawIDARB and enable extension

On Wed, Dec 16, 2015 at 3:47 PM, Kristian Høgsberg wrote: > From: Kristian Høgsberg Kristensen > > We have to break open a new vec4 for gl_DrawIDARB. We've used up all > space in the vec4 we use for SGVS and gl_DrawIDARB has to come from its > own separate

Re: [Mesa-dev] [PATCH v2 7/7] i965: Reemit vertex state between indirect multi draws

On Wed, Dec 16, 2015 at 3:47 PM, Kristian Høgsberg wrote: > From: Kristian Høgsberg Kristensen > > If we're doing an indirect draw, prims[i].basevertex is always 0 and the > real base vertex value is in the indirect parameter buffer. We try to > avoid

Re: [Mesa-dev] [PATCH 13/13] i965: Enable ARB_tessellation_shader on Gen8+.

On 2015-12-22 02:20:58, Kenneth Graunke wrote: > Everything is in place and I'm not aware of any further issues. \o/ Minor comment sent on 12, but series Reviewed-by: Jordan Justen > > Tested with: > - Piglit > - Tessmark > - Unigine Heaven > - Shadow of Mordor > -

Re: [Mesa-dev] [PATCH 02/13] i965: Only call brw_upload_tcs/tes_prog when using tessellation.

On Wednesday, December 23, 2015 2:21:49 AM PST eocallag...@alterapraxis.com wrote: > On 2015-12-22 21:20, Kenneth Graunke wrote: [snip] > > diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c > > b/src/mesa/drivers/dri/i965/brw_tcs.c > > index b5eb4cd..037a2da 100644 > > ---

Re: [Mesa-dev] [PATCH 8/8] draw: fix draw pipeline stages wrt changing vertex sizes

Am 22.12.2015 um 16:32 schrieb Jose Fonseca: > On 22/12/15 03:00, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> The vertex size can change in fetch_pipeline_prepare, if drivers use >> the draw_prepare_shader_outputs hook (similar to what the llvm path >> already

Re: [Mesa-dev] [PATCH v2 4/7] i965: Add support for gl_BaseVertexARB and gl_BaseInstanceARB

On Wed, Dec 16, 2015 at 3:47 PM, Kristian Høgsberg wrote: > From: Kristian Høgsberg Kristensen > > We already have gl_BaseVertexARB in the .x component of the SGVS vec4 > and plug gl_BaseInstanceARB into the last free component (.y). > --- >

Re: [Mesa-dev] [PATCH v3] mesa: fix interface matching done in validate_io

On Wed, 2015-12-16 at 19:29 +1100, Timothy Arceri wrote: > On Wed, 2015-12-16 at 08:24 +0200, Tapani Pälli wrote: > > Patch makes following changes for interface matching: > > > >- do not try to match builtin variables > >- handle swizzle in input name, as example 'a.z' should > >

Re: [Mesa-dev] [PATCH v3] mesa: fix interface matching done in validate_io

On 12/23/2015 01:33 AM, Timothy Arceri wrote: On Wed, 2015-12-16 at 19:29 +1100, Timothy Arceri wrote: On Wed, 2015-12-16 at 08:24 +0200, Tapani Pälli wrote: Patch makes following changes for interface matching: - do not try to match builtin variables - handle swizzle in input name,

[Mesa-dev] [PATCH 04/13] i965: Remove unnecessary brw->tess_ctrl_program assertions.

This is trying to enforce the fact that the hardware requires HS, TE, and DS to be enabled or disabled together. But it's kind of an ad-hoc attempt, and not too useful. More importantly, we aren't going to have a gl_shader_program for the TCS which is automatically generated when none is

[Mesa-dev] [PATCH 12/13] i965: Handle mix-and-match TCS/TES with separate shader objects.

GL_ARB_separate_shader_objects allows the application to mix-and-match TCS and TES programs separately. This means that the interface between the two stages isn't known until the final SSO pipeline is in place. This isn't a great match for our hardware: the TCS and TES have to agree on the Patch

[Mesa-dev] [PATCH 03/13] i965: Consolidate BRW_NEW_TESS_{CTRL, EVAL}_PROGRAM flags.

For several reasons, I don't think it's particularly useful to have separate flags: 1. Most of the time, tessellation shaders are paired, so both will be replaced at the same time. 2. The data layout is tightly coupled. Both need to agree on the number of per-patch slots in the VUE map.

[Mesa-dev] [PATCH 00/13] Finish ARB_tessellation_shader on Gen8+.

This patch series resolves the last two known issues with tessellation shader support on Intel Gen8+ hardware. First, it adds support for compiling a TCS on-the-fly when none is supplied (which is required by OpenGL, but not ES). Secondly, it fixes SSO bugs when separate TCS and TES are

[Mesa-dev] [PATCH 05/13] i965: Switch TCS gl_program/gl_shader_program checks over to TES.

Tessellation control shaders are optional, but evaluation shaders will always be present when using tessellation. However, we'll always enable the TCS (HS) hardware stage when using tessellation - we'll just create a program on the fly. That program, however, won't have a gl_program or

[Mesa-dev] [PATCH 06/13] i965: Only call _mesa_load_state_parameters if prog exists.

With the automatic-TCS creation, we won't have a prog, but still need to upload push constants. Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/gen6_vs_state.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[Mesa-dev] [PATCH 02/13] i965: Only call brw_upload_tcs/tes_prog when using tessellation.

If there's no evaluation shader, tessellation is disabled. The upload functions would just bail. Instead, don't bother calling them. This will simplify the optional-TCS case a bit, as brw_upload_tcs can assume that we're doing tessellation. Signed-off-by: Kenneth Graunke

[Mesa-dev] [PATCH 01/13] nir: Add a glsl_vec_type() helper.

I need access to glsl_type::vec2_type from C. Wrapping vec() also gives us access to vec3 if we need it. Signed-off-by: Kenneth Graunke --- src/glsl/nir/nir_types.cpp | 6 ++ src/glsl/nir/nir_types.h | 1 + 2 files changed, 7 insertions(+) diff --git

Re: [Mesa-dev] [PATCH v2 12/13] i965: Add tessellation control shaders.

We discussed all my questions / comments on irc... 12 & 13 Reviewed-by: Jordan Justen On 2015-12-11 13:24:01, Kenneth Graunke wrote: > The TCS is the first tessellation shader stage, and the most > complicated. It has access to each of the control points in the input

[Mesa-dev] [PATCH 08/13] i965: Create and set a new brw_tcs_prog_data::outputs_written field.

When the application hasn't supplied a TCS, and we have to create one, we need to know what VS outputs to copy to TES inputs. To do this, we create a new program key field, and set it to the TES InputsRead bitfield. Signed-off-by: Kenneth Graunke ---

[Mesa-dev] [PATCH 09/13] i965: Start program_string_id from 1, not 0.

This way, I can safely use brw_tcs_prog_key::program_string_id == 0 to mean "not filled out because no program exists", which avoids the need for adding an extra boolean to that struct. Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/intel_screen.c | 1 + 1

[Mesa-dev] [PATCH 07/13] i965: Upload HS push constants whenever default tess. levels change.

When using tessellation on OpenGL without a TCS, default values for gl_TessLevelOuter/gl_TessLevelInner are provided via the API. Core Mesa will flag ctx->DriverFlags.NewDefaultTessLevels whenever those values change. We add a corresponding BRW_NEW_DEFAULT_TESS_LEVELS flag and hook it up to HS

[Mesa-dev] [PATCH 10/13] i965: Automatically create a passthrough TCS when needed.

Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/brw_tcs.c| 62 ++ src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp | 57 +-- src/mesa/drivers/dri/i965/brw_vec4_tcs.h | 6 ++- 3 files changed, 113

[Mesa-dev] [PATCH 11/13] i965: Defer input lowering for tessellation stages until specialization.

With tessellation shaders and SSO, we won't be able to always decide on VUE map layouts at LinkProgram time. Unfortunately, we have to delay it until shader specialization time. However, uniform lowering cannot be deferred - brw_codegen_*_prog() reads nir->num_uniforms. Fortunately, we don't

[Mesa-dev] [PATCH 13/13] i965: Enable ARB_tessellation_shader on Gen8+.

Everything is in place and I'm not aware of any further issues. Tested with: - Piglit - Tessmark - Unigine Heaven - Shadow of Mordor - GRID Autosport I have patches to backport this to Haswell, Ivybridge, and Baytrail as well (the first Intel hardware to support tessellation), but there are

Re: [Mesa-dev] [PATCH 1/9] st/va: make the implementation thread save

On 21 December 2015 at 15:10, Christian König wrote: > On 21.12.2015 11:05, Andy Furniss wrote: > >> Julien Isorce wrote: >> >>> Hi Christian, >>> >>> I have 2 remarks: >>> >>> 1: I am sure you have the clear answer to the following questions, so >>> maybe add a comment

Re: [Mesa-dev] [PATCH v2 1/2] mesa: Add a _mesa_active_fragment_shader_has_side_effects helper

On 12/16/2015 10:59 AM, Iago Toral Quiroga wrote: Some drivers can disable the FS unit if there is nothing in the shader code that writes to an output (i.e. color, depth, etc). Right now, mesa has a function to check for atomic buffers and the i965 driver also checks for images. Refactor this

Re: [Mesa-dev] [PATCH v2 1/2] mesa: Add a _mesa_active_fragment_shader_has_side_effects helper

On Tue, 2015-12-22 at 10:39 +0200, Tapani Pälli wrote: > > On 12/16/2015 10:59 AM, Iago Toral Quiroga wrote: > > Some drivers can disable the FS unit if there is nothing in the > > shader code > > that writes to an output (i.e. color, depth, etc). Right now, mesa > > has > > a function to check

Re: [Mesa-dev] [PATCH] gallium/radeon: add a flag that forces VRAM placement for everything

On Tue, Dec 22, 2015 at 4:57 AM, Michel Dänzer wrote: > On 22.12.2015 07:36, Marek Olšák wrote: >> >> diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c >> b/src/gallium/drivers/radeon/r600_buffer_common.c >> index 484f5c8..21fe498 100644 >> ---

[Mesa-dev] [Bug 92850] Segfault loading War Thunder

https://bugs.freedesktop.org/show_bug.cgi?id=92850 --- Comment #54 from Jose Fonseca --- (In reply to Nicolai Hähnle from comment #53) > The 'FBO incomplete' message is something that is often seen with apitrace. > Not sure where it actually comes from, but in other cases it

[Mesa-dev] [Bug 89018] Civilization: Beyond Earth terrain section not rendered

https://bugs.freedesktop.org/show_bug.cgi?id=89018 --- Comment #25 from Peter Asplund --- Same for me on R290 -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___

Re: [Mesa-dev] [PATCH v2] Add .mailmap

On Tue, Dec 22, 2015 at 12:47 PM, Thomas Tanner wrote: > Hi, > my primary email address for open source contributions is tan...@gmx.net > cheers > OK, I think Giuseppe will want this info for his final version of the patch (CC'ed), thanks :) > On 17.12.15 10:39, Erik Faye-Lund

Re: [Mesa-dev] [PATCH 6/8] llvmpipe: use ints not unsigned for slots

On 22/12/15 03:00, srol...@vmware.com wrote: From: Roland Scheidegger They can't actually be 0 (as position is there) but should avoid confusion. This was supposed to have been done by af7ba989fb5a39925a0a1261ed281fe7f48a16cf but I accidentally pushed an older version of

Re: [Mesa-dev] [PATCH v3] Add .mailmap

On Tue, Dec 22, 2015 at 2:33 AM, Giuseppe Bilotta wrote: > On Tue, Dec 22, 2015 at 3:25 AM, Jason Ekstrand wrote: >> >> As with Michel, I'd rather have my "personal" e-mail as the cannonical one. >> That said, I vote we just merge this as-is and

Re: [Mesa-dev] [PATCH 1/8] draw: rework hanndling of non-existing outputs in emit code

On 22/12/15 03:00, srol...@vmware.com wrote: From: Roland Scheidegger Previously the code would just redirect requests for attributes which don't exist to use output 0. Rework this to output all zeros instead which seems more useful - in particular some extensions like

[Mesa-dev] [Bug 92850] Segfault loading War Thunder

https://bugs.freedesktop.org/show_bug.cgi?id=92850 --- Comment #55 from har...@gmx.de --- (In reply to Nicolai Hähnle from comment #53) > The 'FBO incomplete' message is something that is often seen with apitrace. > Not sure where it actually comes from, but in other cases it doesn't cause >

Re: [Mesa-dev] [PATCH] r600: fix constant buffer size programming

On Tue, Dec 22, 2015 at 5:37 PM, Nicolai Hähnle wrote: > On 21.12.2015 21:12, Grazvydas Ignotas wrote: >> >> When buffer size is less than 16, zero ends up being programmed as >> size, which prevents the hardware from fetching the correct values. >> Fix it by combining shift