On Friday, August 12, 2016 9:46:59 PM PDT Jason Ekstrand wrote:
> On Aug 12, 2016 8:13 PM, "Kenneth Graunke" wrote:
> >
> > We'll do blending in the shader in this case, so just disable the
> > hardware blending.
> >
> > Signed-off-by: Kenneth Graunke
> > ---
> > src/mesa/drivers/dri/i965/gen8_b
The current logic used to determine the execution size of sampler
messages was based on special-casing several argument and opcode
combinations, which unsurprisingly missed the possibility that some
messages could exceed the payload size limit or not depending on the
number of coordinate components
This makes it easier for the caller to find out how many scalar
components are actually read by the instruction. As a bonus we no
longer need to special-case BAD_FILE in the implementation of
fs_inst::regs_read.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 7 +--
1 file changed, 5 insertions(+)
This simplifies the code slightly and will allow the SIMD lowering
pass to find out easily what the actual texturing opcode is in order
to determine the maximum execution size of texturing instructions.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 10 --
src/mesa/drivers/dri/i965/brw_fs_
On Aug 12, 2016 8:13 PM, "Kenneth Graunke" wrote:
>
> We'll do blending in the shader in this case, so just disable the
> hardware blending.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/gen8_blend_state.c | 5 -
Drive-by comment: why are you only doing this for gen8 w
This series is,
Acked-by: Edward O'Callaghan
On 08/12/2016 06:25 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/drivers/radeon/r600_streamout.c | 4 ++--
> src/gallium/drivers/radeonsi/si_descriptors.c | 6 --
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> dif
We're going to handle output qualifiers here too, and calling it "inout"
seems to be the going convention.
Signed-off-by: Kenneth Graunke
---
src/compiler/glsl/linker.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/link
From: Ilia Mirkin
v2 (Ken): Add a BLEND_NONE enum value (no qualifiers in use).
Signed-off-by: Ilia Mirkin
Reviewed-by: Kenneth Graunke
---
src/compiler/glsl/ast.h | 5
src/compiler/glsl/ast_type.cpp | 2 ++
src/compiler/glsl/glsl_parser.yy | 45 +
We'll do blending in the shader in this case, so just disable the
hardware blending.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen8_blend_state.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_blend_state.c
b/src/mesa/dr
Drivers emulating advanced blending will want to disable hardware
blending. This makes it easy to check whether hardware blending
should be enabled for buffer "i" by doing:
(BlendEnabled & ~_AdvancedBlendEnabled) & (1 << i)
Signed-off-by: Kenneth Graunke
---
src/mesa/main/blend.c | 18
We always use a coherent read, and ignore the "opt out" enable flag.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
in
Prior to revision 9 of the NV extension or revision 16 of the KHR extension,
the rules for HSL conversion was different. dEQP appears to be out of date.
Here's an old copy:
http://developer.download.nvidia.com/opengl/specs/GL_NV_blend_equation_advanced.txt
// Take the base RGB color and o
From: Ilia Mirkin
Signed-off-by: Ilia Mirkin
Reviewed-by: Kenneth Graunke
---
src/compiler/glsl/glsl_parser_extras.cpp | 1 +
src/compiler/glsl/glsl_parser_extras.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/src/compiler/glsl/glsl_parser_extras.cpp
b/src/compiler/glsl/glsl_parse
Since each qualifier represents a blending mode the shader can be used
with, we take the union of all possible modes when linking.
Signed-off-by: Kenneth Graunke
---
src/compiler/glsl/linker.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/gls
This adds the extension enable (so drivers can advertise it) and the
extra boolean state flag, GL_BLEND_ADVANCED_COHERENT_KHR, which can
be set to request coherent blending.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/blend.c| 2 ++
src/mesa/main/enable.c | 12 +++
Many GPUs cannot handle GL_KHR_blend_equation_advanced natively, and
need to emulate it in the pixel shader. This lowering pass implements
all the necessary math for advanced blending. It fetches the existing
framebuffer value using the MESA_shader_framebuffer_fetch built-in
variables, and the pr
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_link.cpp | 2 ++
src/mesa/drivers/dri/i965/intel_extensions.c | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp
b/src/mesa/drivers/dri/i965/brw_link.cpp
index 1ad23
From: Ilia Mirkin
Signed-off-by: Ilia Mirkin
Reviewed-by: Kenneth Graunke
---
src/mesa/main/extensions_table.h | 1 +
src/mesa/main/mtypes.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index ee4f1af..e8c825
Don't allow them in glBlendEquationSeparate[i], though, as required
by the spec.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/blend.c | 64 +++
1 file changed, 54 insertions(+), 10 deletions(-)
diff --git a/src/mesa/main/blend.c b/src/mesa/mai
This will be used for emulating GL_KHR_advanced_blend_equation features
in shader code. We'll pass in the blending mode that's in use, and use
that in (effectively) a switch statement in the shader.
Signed-off-by: Kenneth Graunke
---
src/mesa/program/prog_statevars.c | 53 ++
From: Ilia Mirkin
v2 (Ken): Fix enum values, drop _mesa_BlendBarrierKHR stub as Curro has
already implemented it.
Signed-off-by: Ilia Mirkin
Signed-off-by: Kenneth Graunke
---
src/mapi/glapi/gen/gl_API.xml | 23 +++
src/mesa/main/tests/dispatch_sanity.c
Note that _mesa_BlendBarrierMESA is not currently hooked up in the
glapi XML, so we can just rename it. We'll hook it up for the
KHR_blend_equation_advanced extension shortly.
XXX: sort out exactly what patches Curro plans to push and when.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/barr
https://bugs.freedesktop.org/show_bug.cgi?id=97231
--- Comment #21 from Ilia Mirkin ---
(In reply to Roland Scheidegger from comment #20)
> That said, it doesn't do the abs part. Is that really required?
I think the abs was an attempt to avoid the swap
> And don't you need the zmin/zmax swap pa
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97231
Signed-off-by: Ilia Mirkin
Cc: "11.2 12.0"
---
src/gallium/drivers/nouveau/nv50/nv50_state_validate.c | 18 ++
src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c | 18 ++
2 files changed, 28 insertio
https://bugs.freedesktop.org/show_bug.cgi?id=97231
--- Comment #20 from Roland Scheidegger ---
(In reply to Ilia Mirkin from comment #18)
> FWIW this also fails on nouveau right now... this is a part of the patch I'm
> going to have to apply (still working out the full details, but this should
>
On Aug 12, 2016 5:51 PM, "Kenneth Graunke" wrote:
>
> On Friday, August 12, 2016 5:45:39 PM PDT Jason Ekstrand wrote:
> > This just occurred to me, but why are we generating mipmaps in meta? We
> > could do it in blorp in a half-dozen lines...
>
> It's a few more than that, but the 'genmipmap' br
https://bugs.freedesktop.org/show_bug.cgi?id=97231
--- Comment #19 from Jules Blok ---
Ah, so this is an issue when combining GL_DEPTH_CLAMP and GL_CLIP_CONTROL?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=97231
--- Comment #18 from Ilia Mirkin ---
FWIW this also fails on nouveau right now... this is a part of the patch I'm
going to have to apply (still working out the full details, but this should
have the general idea):
@@ -329,8 +329,21 @@ nvc0_valid
Kenneth Graunke writes:
> On Wednesday, July 20, 2016 9:49:36 PM PDT Francisco Jerez wrote:
>> Both MESA_shader_framebuffer_fetch_non_coherent and the non-coherent
>> variant of KHR_blend_equation_advanced will use this driver hook to
>> request coherency between framebuffer reads and writes. Th
On Friday, August 12, 2016 5:45:39 PM PDT Jason Ekstrand wrote:
> This just occurred to me, but why are we generating mipmaps in meta? We
> could do it in blorp in a half-dozen lines...
It's a few more than that, but the 'genmipmap' branch of my tree
does exactly that. I wrote the patches a whil
This just occurred to me, but why are we generating mipmaps in meta? We
could do it in blorp in a half-dozen lines...
On Fri, Aug 12, 2016 at 3:59 PM, Kenneth Graunke
wrote:
> When generating mipmaps for sRGB textures, force both decode and encode,
> so the filtering is done in linear colorspac
On Wednesday, July 20, 2016 9:49:36 PM PDT Francisco Jerez wrote:
> Both MESA_shader_framebuffer_fetch_non_coherent and the non-coherent
> variant of KHR_blend_equation_advanced will use this driver hook to
> request coherency between framebuffer reads and writes. This
> intentionally doesn't hook
Much better. Thanks!
Reviewed-by: Jason Ekstrand
On Fri, Aug 12, 2016 at 5:00 PM, Lionel Landwerlin
wrote:
> We let the user believe we support some transfer formats which we don't.
> This can lead to crashes when actually trying to use those formats for
> example on dEQP-VK.api.copy_and_blit.
It was holding the jenkins system to run cts on HSW. So I pushed
[PATCH 1/2] upstream.
On Fri, Aug 12, 2016 at 5:02 PM, Anuj Phogat wrote:
> On Thu, Aug 11, 2016 at 10:25 AM, Lionel Landwerlin
> wrote:
>> SampleMask is only 8bits long on gen7.
>>
>> Signed-off-by: Lionel Landwerlin
>> Cc: Jason
On Thu, Aug 11, 2016 at 10:25 AM, Lionel Landwerlin
wrote:
> SampleMask is only 8bits long on gen7.
>
> Signed-off-by: Lionel Landwerlin
> Cc: Jason Ekstrand
> ---
> src/intel/vulkan/genX_pipeline_util.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/intel/vulkan/genX_pipeline
We let the user believe we support some transfer formats which we don't.
This can lead to crashes when actually trying to use those formats for
example on dEQP-VK.api.copy_and_blit.image_to_image.* tests.
Let all formats we can render to or sample from as meta implements transfers
using attachment
On Thu, Aug 11, 2016 at 5:32 PM, Nanley Chery wrote:
> On Tue, Jul 26, 2016 at 10:04:21PM -0700, Jason Ekstrand wrote:
> > The real objective of this series is patch 5 which prevents us from
> > accidentally creating a surface state with a format unsupported by the
> > hardware. This turns some
Looks like it all checks out. Someone refactored a bunch of the code,
and it just had to move a tiny bit, hence the conflicts. Updated patch
here:
https://github.com/imirkin/mesa/commit/56bae8a1c06aaf3b5be408ad76708de48c482909.patch
which is basically identical to the original.
On Thu, Aug 11, 2
When generating mipmaps for sRGB textures, force both decode and encode,
so the filtering is done in linear colorspace, regardless of settings.
Fixes a WebGL conformance test in Chrome:
https://www.khronos.org/registry/webgl/sdk/tests/conformance2/textures/misc/tex-srgb-mipmap.html?webglVersion=2
https://bugs.freedesktop.org/show_bug.cgi?id=97307
Ian Romanick changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from Ian Romanick
On 08/12/2016 03:02 PM, Jason Ekstrand wrote:
Reviewed-by: Jason Ekstrand mailto:ja...@jlekstrand.net>>
I also ran it through our CI system and it didn't find any problems.
On Fri, Aug 12, 2016 at 2:34 PM, Haixia Shi mailto:h...@chromium.org>> wrote:
The GL_BGR and GL_UNSIGNED_SHORT_5_6_5_
Reviewed-by: Jason Ekstrand
I also ran it through our CI system and it didn't find any problems.
On Fri, Aug 12, 2016 at 2:34 PM, Haixia Shi wrote:
> The GL_BGR and GL_UNSIGNED_SHORT_5_6_5_REV are not defined anywhere in
> OpenGL ES 3.2 (or earlier) specification, and there are no known extens
The GL_BGR and GL_UNSIGNED_SHORT_5_6_5_REV are not defined anywhere in
OpenGL ES 3.2 (or earlier) specification, and there are no known extensions
in the Khronos registry that would add these enums as valid responses for
glGetIntegerv(GL_IMPLEMENTATION_COLOR_READ_TYPE) and
glGetIntegerv(GL_IMPLEMEN
Reviewed-by: Jason Ekstrand
I would still like to see a review from Emil. He's on vacation at the
moment, but he should be back next week.
On Fri, Aug 12, 2016 at 2:17 PM, Kevin Strasser
wrote:
> Some applications continue to use the Xlib client library and expect that
> VK_KHR_xlib_surface w
Some applications continue to use the Xlib client library and expect that
VK_KHR_xlib_surface will be available in the driver. Service these
applications by converting the Display pointer to xcb_connection_t and use
the existing xcb code in the driver.
Signed-off-by: Kevin Strasser
Cc: Jason Ekst
On Fri, Aug 12, 2016 at 2:00 PM, Chad Versace wrote:
> +jekstrand
>
> On 08/12/2016 01:36 PM, Haixia Shi wrote:
>
>> The GL_BGR and GL_UNSIGNED_SHORT_5_6_5_REV are not defined anywhere in
>> OpenGL ES 3.2 (or earlier) specification, and there are no known
>> extensions
>> in the Khronos registry
+jekstrand
On 08/12/2016 01:36 PM, Haixia Shi wrote:
The GL_BGR and GL_UNSIGNED_SHORT_5_6_5_REV are not defined anywhere in
OpenGL ES 3.2 (or earlier) specification, and there are no known extensions
in the Khronos registry that would add these enums as valid responses for
glGetIntegerv(GL_IMPLE
The GL_BGR and GL_UNSIGNED_SHORT_5_6_5_REV are not defined anywhere in
OpenGL ES 3.2 (or earlier) specification, and there are no known extensions
in the Khronos registry that would add these enums as valid responses for
glGetIntegerv(GL_IMPLEMENTATION_COLOR_READ_TYPE) and
glGetIntegerv(GL_IMPLEMEN
I can't say I'm a big fan of this.
From an "api cleanness" point of view, defining things in elements makes
more sense imho.
This is due to the GL api though which uses generic buffer api to turn
buffers into textures which can be sampled (somewhat different to what
d3d10 does).
Can't you just say
For the series:
Reviewed-by: Marek Olšák
Marek
On Wed, Aug 10, 2016 at 9:23 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> They can lead to VM faults and worse, which goes against the GL robustness
> promises.
> ---
> src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 15 +++
https://bugs.freedesktop.org/show_bug.cgi?id=97326
Mark Janes changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=97326
Bug ID: 97326
Summary: [llvmpipe] [softpipe] piglit switch-case-duplicated
regression
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
On Fri, Aug 12, 2016 at 7:23 PM, Ilia Mirkin wrote:
> Patches 1 and 2 are
>
> Acked-by: Ilia Mirkin
>
> I skimmed them and your transformations all seemed right, but I'd be
> lying if I said I looked at each and every line of the diff...
OK. I forgot to mention:
There are no piglit regressions
Patches 1 and 2 are
Acked-by: Ilia Mirkin
I skimmed them and your transformations all seemed right, but I'd be
lying if I said I looked at each and every line of the diff...
On Fri, Aug 12, 2016 at 12:46 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> This is required by OpenGL. Our hardware s
From: Marek Olšák
This is required by OpenGL. Our hardware supports this.
Example: Bind RGBA32F with offset = 4 bytes.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97305
---
src/gallium/auxiliary/util/u_dump_state.c| 4 ++--
src/gallium/docs/source/screen.rst |
From: Marek Olšák
This is required by OpenGL. Our hardware supports this.
Example: Bind RGBA32F with offset = 4 bytes.
---
src/gallium/auxiliary/util/u_dump_state.c | 4 ++--
src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 4 ++--
src/gallium/drivers/nouveau/nvc0/nvc0_tex.c | 24 +++
From: Marek Olšák
st/mesa does this too, so we're safe.
---
src/gallium/drivers/radeonsi/si_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 7e63d48..25dfe26 100644
--- a/src/galli
On Thu, Aug 11, 2016 at 10:47 AM, Anuj Phogat wrote:
> On Fri, Jul 29, 2016 at 2:30 PM, Anuj Phogat
> wrote:
> >
> >
> > On Fri, Jul 29, 2016 at 12:32 PM, Anuj Phogat
> wrote:
> >>
> >>
> >>
> >> On Thu, Jul 28, 2016 at 6:31 PM, Jason Ekstrand
> >> wrote:
> >>>
> >>> On Jul 28, 2016 7:37 PM, "
On 12/08/16 02:14, Timothy Arceri wrote:
> On Thu, 2016-08-11 at 17:10 +0200, Alejandro Piñeiro wrote:
>> On 05/08/16 12:20, Alejandro Piñeiro wrote:
>>> On 05/08/16 01:53, Timothy Arceri wrote:
On Thu, 2016-08-04 at 18:36 +0200, Alejandro Piñeiro wrote:
> Hi,
>
> these days I have
Apply the median and matrix filter before the compostioning
we apply the deinterlacing first to avoid the extra overhead
in processing the past and the future surfaces in deinterlacing.
v2: apply the filters on all the surfaces (Christian)
v3: use get_sampler_view_planes() instead of
get_sampl
Am 11.08.2016 um 17:12 schrieb Nayan Deshmukh:
Apply the median and matrix filter before the compostioning
we apply the deinterlacing first to avoid the extra overhead
in processing the past and the future surfaces in deinterlacing.
It is good practice to put a v1,v2 etc... after the commit mes
On 11.08.2016 12:57, Marek Olšák wrote:
On Thu, Aug 11, 2016 at 11:29 AM, Nicolai Hähnle wrote:
On 10.08.2016 23:36, Marek Olšák wrote:
On Wed, Aug 10, 2016 at 9:23 PM, Nicolai Hähnle
wrote:
Hi,
this is a respin of the series which scans the shader's TGSI to determine
which channels of an
On 08/12/2016 01:31 PM, Jeremy Huddleston Sequoia wrote:
On Aug 12, 2016, at 00:41, Tapani Pälli wrote:
On 07/18/2016 07:07 PM, Jeremy Huddleston Sequoia wrote:
Will do. Thanks for pinging me. Early June was very busy and I didn't see
this come through. I'll get back to you within a c
> On Aug 12, 2016, at 00:41, Tapani Pälli wrote:
>
>
> On 07/18/2016 07:07 PM, Jeremy Huddleston Sequoia wrote:
>> Will do. Thanks for pinging me. Early June was very busy and I didn't see
>> this come through. I'll get back to you within a couple days.
>
> a couple days passed, ping! :)
Hi Mathias,
thanks for the input!
On 11.08.2016 06:49, Mathias Fröhlich wrote:
For subtree-merge:
There is a pair of visualisation teams that used to work for the same
company until they both got sold to individual vendors but still wanted
to share their basic framwork code. Those two applicat
Hi,
On 02-08-16 12:46, Tomasz Figa wrote:
Current prime import code in kms-dri Gallium winsys backend has several
issues:
- It leaks imported buffers, because of duplicate reference count
increment at import time.
- It does not check whether an already imported (or local) buffer is not
b
On 11.08.2016 13:12, Enrico Weigelt, metux IT consult wrote:
On 10.08.2016 15:19, Nicolai Hähnle wrote:
It would be nice to have something more concrete to go on, like what are
the problems _really_ :)
Actually, I haven't understood who the other users of addrlib actually
are - is it just AMDs
On Thursday, July 28, 2016 2:50:07 PM PDT Francisco Jerez wrote:
> This series gets coherent render target reads working with the i965
> driver and exposes the EXT_shader_framebuffer_fetch extension on Gen9+
> platforms. It's dependent on the series I sent last week to make the
> driver-independen
On Sunday, July 31, 2016 1:13:52 AM PDT Kenneth Graunke wrote:
> On Thursday, July 28, 2016 12:45:36 AM PDT Kenneth Graunke wrote:
> > On Friday, July 22, 2016 8:58:54 PM PDT Francisco Jerez wrote:
> > > This is an implementation of non-coherent framebuffer fetch as
> > > described here [1] working
On 07/18/2016 07:07 PM, Jeremy Huddleston Sequoia wrote:
Will do. Thanks for pinging me. Early June was very busy and I didn't see
this come through. I'll get back to you within a couple days.
a couple days passed, ping! :)
--Jeremy
On Jul 18, 2016, at 01:12, Tapani Pälli wrote:
Jere
70 matches
Mail list logo
