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, as
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
>>> wrote:
I think two different concepts of ownership are getting confla
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 conflated here:
>>> Right/responsibility to delete and right to modi
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 I understand it, gallium, as it stands, giv
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 back-end using NIR requires
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
> > mat
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 flagging BRW_NEW_VERTICES if prims[i].basever
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 vertex buffer anyway. This is because w
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).
> ---
> src/mesa/drivers/dri/i965/brw_compiler.h | 2
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.
___
mesa-dev mailing list
mesa-de
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
> - GRID Autosport
>
> I have
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
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.
> ---
> src/gallium/state_trackers/osmesa/osmesa.c |
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 1a4cc69..56e5705 100644
--- a/src/glsl/nir/nir_print.c
+++ b/src/
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, for example. This can be useful for debugging a
> deterministicall
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
> > --- a/src/mesa/drivers/dri/i9
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 and align so that the
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
>> does). Albeit this
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
> probl
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"
Bugzilla: https:/
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 prone.
Also sort-of prepar
On 2015-12-22 21:20, Kenneth Graunke wrote:
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-o
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.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/nir/nir_typ
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 insertions(+)
create mode 10064
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 (yes, sometimes there's m
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 his final version of the
> patch (CC'ed
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 let everyone go fix their own
>> e-mail address.
>
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 the patch in the end..
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
ARB_fragment_layer_viewpo
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 doesn't cause
> probl
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 wrote:
>> On Thu,
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.
___
mesa-dev mailing list
mesa-
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
>> --- a/src/gallium/drivers/radeon/r600_buffer_
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
still
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 insertions(+), 12 deletions(-)
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 nee
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 file changed, 1 insertion
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
---
src/mesa/drivers/dri/i965/brw_compiler.h |
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 pu
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 present.
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
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
---
src/mesa/drivers/
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 a/src/glsl/nir/nir_types.cpp b/src/gl
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. E
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 mix-and-m
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 gl_shader_
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 a/src/mesa/drivers/dri/i965/gen6_vs_state.c
b/src/mesa
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
> patch, and computes a new
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 in the commit message: Isn
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 fo
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 l
51 matches
Mail list logo
