Hi Matt,
With the small changes agreed with Jason for patches 9 and 10 you can
add my Rb to those two patches as well. I think with that the entire
series is reviewed.
I also left a comment in patch 9 about using f2u instead f2i since it
looks like that would be more correct by the spec, but it i
On Thu, 2016-01-28 at 09:21 -0800, Matt Turner wrote:
> On Thu, Jan 28, 2016 at 12:32 AM, Iago Toral wrote:
> > On Mon, 2016-01-25 at 15:18 -0800, Matt Turner wrote:
(...)
> >> diff --git a/src/glsl/nir/nir_opt_algebraic.py
> >> b/src/glsl/nir/nir_opt_algebraic.py
> >> index b761b54..56b0f5e 1006
On 29.01.2016 12:44, Michel Dänzer wrote:
> On 28.01.2016 20:20, Daniel Stone wrote:
>> On 28 January 2016 at 03:21, Michel Dänzer wrote:
>>> On 27.01.2016 23:54, Daniel Stone wrote:
On 27 January 2016 at 14:16, Axel Davy wrote:
>
> The other thing you mention, ie failing to import n
In GLES 3.1+ and GL 4.4+ there is no guarantee that interpolation
qualifiers will match between stages so we cannot safely pack
varyings using the current packing pass in Mesa.
We also disable packing on outward facing SSO as these too are outside
the rule that guarantees the interpolation qualifi
Following patches will allow packing of varyings with explicit locations
via the component layout qualifier. Adding the rules here will enable
us to call an alternate path for packing tessellation stages with
explicit locations.
V3: Don't remove rules from the varying linking code as we need to
di
On 28.01.2016 20:20, Daniel Stone wrote:
> On 28 January 2016 at 03:21, Michel Dänzer wrote:
>> On 27.01.2016 23:54, Daniel Stone wrote:
>>> On 27 January 2016 at 14:16, Axel Davy wrote:
On 27/01/2016 13:43, Daniel Stone wrote:
> If the compositor wants to scan out directly, it will impo
From: Jordan Justen
After modifying the hiz buffer allocation and qpitch calculation, hiz
appears to work in all cases on gen8.
v2 by Ben: add GEN8_WM_HZ_FULL_SURFACE_DEPTH_CLEAR. From docs:
"If the depth buffer clear operation does clear the entire width and height of
the surface, then the “ful
Am 29.01.2016 um 00:31 schrieb Matt Turner:
> On Sun, Jan 17, 2016 at 1:49 PM, wrote:
>> From: Roland Scheidegger
>>
>> The existing code used ssse3, and because it isn't compiled in a separate
>> file compiled with that, it is usually not used (that, of course, could
>> be fixed...), whereas ss
On Sun, Jan 17, 2016 at 1:49 PM, wrote:
> From: Roland Scheidegger
>
> The existing code used ssse3, and because it isn't compiled in a separate
> file compiled with that, it is usually not used (that, of course, could
> be fixed...), whereas sse2 is always present at least with 64bit builds.
>
Part of brw_try_draw_prims() is a check to validate textures
(brw_validate_textures()). In case of textures that currently have
only level zero but are marked for mipmap generation, i965 driver
will decide to replace the underlying buffer with a larger one
capable of holding also the additional lev
Validation may kick off copies and subsequently color resolves.
Color resolves (and the copies themselves if ending up in meta path)
will overwrite the internal driver state but are not prepared to
restore it. Instead of adding that capability the validation can be
simply performed before the state
fyi, I'm getting rather close to having a v3 of this patchset ready to
send. Since the last version, I've implemented NIR versions of
tgsi_emulate, and bitmap/drawpix lowering, moved a bunch of stuff out
of st_glsl_to_tgsi, etc. Still a few things to clean up, but it is,
IMHO, getting reasonable
I don't understand the need to mark patches trivial. It's trivial to
make that determination from looking at the patch. :)
On Sun, Jan 17, 2016 at 1:49 PM, wrote:
> From: Roland Scheidegger
>
> ---
> src/gallium/auxiliary/util/u_format_parse.py | 2 +-
> src/mesa/main/format_parser.py
On Thu, Jan 28, 2016 at 10:43 AM, Jason Ekstrand wrote:
> That's not quite correct. 1 means exactly one component while a destination
> size of 0 means that it's a vectorizable operation. All 0-sized sources
> automatically take on the size of the destination. This is how most
> standard ALU opc
On Thu, Jan 28, 2016 at 10:35 AM, Jason Ekstrand wrote:
> No, it also has 2 and 3. Are those not working for some reason?
Oh, thanks, I just totally missed them. I'll use vec2 in this patch.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http:
On Jan 28, 2016 09:22, "Matt Turner" wrote:
>
> On Thu, Jan 28, 2016 at 12:32 AM, Iago Toral wrote:
> > On Mon, 2016-01-25 at 15:18 -0800, Matt Turner wrote:
> >> ---
> >> src/glsl/nir/nir.h | 4
> >> src/glsl/nir/nir_lower_alu_to_scalar.c | 32
+
On Jan 28, 2016 09:25, "Matt Turner" wrote:
>
> On Thu, Jan 28, 2016 at 12:38 AM, Iago Toral wrote:
> > On Mon, 2016-01-25 at 15:18 -0800, Matt Turner wrote:
> >> ---
> >> src/glsl/nir/nir.h| 4
> >> src/glsl/nir/nir_opt_algebraic.py | 28
> >>
On Thu, Jan 28, 2016 at 12:38 AM, Iago Toral wrote:
> On Mon, 2016-01-25 at 15:18 -0800, Matt Turner wrote:
>> ---
>> src/glsl/nir/nir.h| 4
>> src/glsl/nir/nir_opt_algebraic.py | 28
>> 2 files changed, 32 insertions(+)
>>
>> diff --git a/src/gl
On Thu, Jan 28, 2016 at 12:32 AM, Iago Toral wrote:
> On Mon, 2016-01-25 at 15:18 -0800, Matt Turner wrote:
>> ---
>> src/glsl/nir/nir.h | 4
>> src/glsl/nir/nir_lower_alu_to_scalar.c | 32
>> src/glsl/nir/nir_opcodes.py| 10 +
Hi Loukas,
To help me reproduce this
1. which application(s) was running?
2. what is the distro and kernel version?
3. can you send me your vmware.log?
Can you file a bug on bugs.freedesktop.org?
thanks,
Sinclair
On Tue, Jan 26, 2016 at 02:06:14AM +0200, Agorgianitis Loukas wrote:
>
On 27/01/16 21:39, Dave Airlie wrote:
On 25 July 2015 at 00:19, Jonny Lamb wrote:
Here is an initial patchset implementing EGL_EXT_device_base (in
practice nothing to do), device_enumeration (for listing devices), and
device_query (for querying information about a device).
I worked on this bec
On 28 January 2016 at 03:21, Michel Dänzer wrote:
> On 27.01.2016 23:54, Daniel Stone wrote:
>> On 27 January 2016 at 14:16, Axel Davy wrote:
>>> On 27/01/2016 13:43, Daniel Stone wrote:
If the compositor wants to scan out directly, it will import via
GBM, which is in a position to reje
https://bugs.freedesktop.org/show_bug.cgi?id=93878
Samuel Iglesias changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Reviewed-by: Iago Toral Quiroga
On Mon, 2016-01-25 at 15:18 -0800, Matt Turner wrote:
> ---
> src/mesa/drivers/dri/i965/brw_compiler.c | 15 +
> .../dri/i965/brw_fs_channel_expressions.cpp| 8 +++
> src/mesa/drivers/dri/i965/brw_link.cpp | 25
> +++
Reviewed-by: Iago Toral Quiroga
On Mon, 2016-01-25 at 15:18 -0800, Matt Turner wrote:
> And mark nir_op_pack_uvec4_to_uint unreachable, since it's only produced
> by lowering pack[SU]norm4x8 which the vec4 backend does not need.
> ---
> src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 18 +++
On Mon, 2016-01-25 at 15:18 -0800, Matt Turner wrote:
> ---
> src/glsl/nir/nir.h| 4
> src/glsl/nir/nir_opt_algebraic.py | 28
> 2 files changed, 32 insertions(+)
>
> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
> index bbd5b1a..3b90b51 1
On Mon, 2016-01-25 at 15:18 -0800, Matt Turner wrote:
> ---
> src/glsl/nir/nir.h | 4
> src/glsl/nir/nir_lower_alu_to_scalar.c | 32
> src/glsl/nir/nir_opcodes.py| 10 ++
> src/glsl/nir/nir_opt_algebraic.py | 20 ++
27 matches
Mail list logo
