Reviewed-by: Samuel Iglesias Gonsálvez
On 21/07/16 03:04, Kenneth Graunke wrote:
> We always resort to the pull model for instanced GS inputs. So, we'd
> better include the VUE handles, or else we can't actually pull anything.
>
> Cc: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Kenneth G
On Wed, 2016-07-20 at 20:57 +1000, Timothy Arceri wrote:
> Currently disabling these optimisations causes some major regressions
> mainly
> because cross shader removal of unused varyings is done in the GLSL
> IR linker.
>
> I've spent some time today attempting to insert a glsl->nir
> conversion
On Thu, Jul 21, 2016 at 6:19 AM, Rob Herring wrote:
> On Fri, Jul 15, 2016 at 2:53 AM, Tomasz Figa wrote:
>> From: Nicolas Boichat
>>
>> Existing image loader code supports creating images only for window
>> surfaces. Moreover droid_create_surface() passes wrong surface type to
>> dri2_get_dri_c
On Wed, Jul 20, 2016 at 10:34 PM, Rob Herring wrote:
> On Wed, Jul 20, 2016 at 12:53 AM, Tomasz Figa wrote:
>> On Wed, Jul 20, 2016 at 7:40 AM, Rob Herring wrote:
>>> On Fri, Jul 15, 2016 at 2:53 AM, Tomasz Figa wrote:
If no hardware driver is present, it is possible to fall back to
t
On Wed, Jul 20, 2016 at 10:43 PM, Rob Herring wrote:
> On Mon, Jul 18, 2016 at 11:29 PM, Tomasz Figa wrote:
>> On Tue, Jul 19, 2016 at 12:35 PM, Rob Herring wrote:
>>> On Fri, Jul 15, 2016 at 2:53 AM, Tomasz Figa wrote:
Hi,
This series is a collection of various fixes and extensi
The NIR representation of framebuffer fetch is the same as the GLSL
IR's until interface variables are lowered away, at which point it
will be translated to load output intrinsics. The GLSL-to-NIR pass
just needs to copy the bits over to the NIR program.
---
src/compiler/glsl/glsl_to_nir.cpp | 2
This requires emitting a series of copies at the top of the program
from each output variable to the corresponding temporary. The initial
copy can be skipped for non-framebuffer fetch outputs whose initial
value is undefined, and the final copy needs to be skipped for
read-only outputs (i.e. gl_La
gl_LastFragData overlaps gl_FragData by definition.
---
src/compiler/glsl/linker.cpp | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index 6d45a02..aeaeb9c 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cp
Since they cannot be written. This prevents adding fragment outputs
to the OutputsWritten set that are only read from via the
gl_LastFragData array but never written to.
---
src/compiler/glsl/ir_set_program_inouts.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compile
This is the set of shader outputs whose initial value is provided to
the shader by some external means when the shader is executed, rather
than computed by the shader itself.
---
src/compiler/glsl/ir_set_program_inouts.cpp | 3 +++
src/mesa/main/mtypes.h | 1 +
2 files changed
Apparently this pass can only handle elimination of a single built-in
fragment output array, so the presence of gl_LastFragData (which it
wouldn't split correctly anyway) could prevent it from splitting the
actual gl_FragData array. Just match gl_FragData by name since it's
the only built-in it ca
---
src/compiler/glsl/ast_to_hir.cpp | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index c050a3f..ac651a9 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -3948,6 +3948,1
---
src/mapi/glapi/gen/es_EXT.xml | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
index 6886dab..929e0e7 100644
--- a/src/mapi/glapi/gen/es_EXT.xml
+++ b/src/mapi/glapi/gen/es_EXT.xml
@@ -790,6 +790,11 @@
+
+
+
+
This allows drivers to expose EXT_shader_framebuffer_fetch in GLES2+
contexts if desired. Note that this adds boolean flags for two MESA
extensions, but only the EXT GLES-only extension is exposed for the
moment, see the cover letter of this series [1] for the rationale.
[1] https://lists.freedes
This can currently only give true as result since the only way you can
expose EXT_shader_framebuffer_fetch right now is by flipping the
MESA_shader_framebuffer_fetch bit, but that could potentially change
in the future, see [1] for an explanation.
[1] https://lists.freedesktop.org/archives/mesa-de
---
src/compiler/glsl/glsl_parser_extras.cpp | 3 +++
src/compiler/glsl/glsl_parser_extras.h | 13 +
2 files changed, 16 insertions(+)
diff --git a/src/compiler/glsl/glsl_parser_extras.cpp
b/src/compiler/glsl/glsl_parser_extras.cpp
index 0077434..a2c1afe 100644
--- a/src/compiler/
The EXT_shader_framebuffer_fetch extension defines alternative
language for GLES2 shaders where user-defined fragment outputs are not
allowed. Instead of using inout user-defined fragment outputs the
shader is expected to read from the gl_LastFragData built-in array.
In addition this allows using
According to the EXT_shader_framebuffer_fetch extension the inout
qualifier can be used on ESSL 3.0+ shaders to declare a special kind
of fragment output that gets implicitly initialized with the previous
framebuffer contents at the current fragment coordinates. In addition
we allow using the same
In preparation for collecting all pipeline barrier GL entry points
into a single source file.
---
src/mapi/glapi/gen/gl_genexec.py | 2 +-
src/mesa/Makefile.sources | 4 ++--
src/mesa/drivers/common/driverfuncs.c | 4 ++--
src/mesa/main/{texturebarrier.c
The GLSL IR representation of framebuffer fetch amounts to a single
bit in the ir_variable object applicable to fragment shader outputs.
The flag indicates that the variable will be implicitly initialized to
the previous contents of the render buffer at the same fragment
coordinates and sample inde
---
src/mesa/main/barrier.c | 51 +
src/mesa/main/barrier.h | 6 ++
src/mesa/main/shaderimage.c | 51 -
src/mesa/main/shaderimage.h | 6 --
4 files changed, 57 insertions(+), 57 deletions(-)
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 up glBlendBarrierMESA to the dispatch layer
since the extension isn't exp
On Thursday, July 21, 2016 2:07:01 PM PDT Timothy Arceri wrote:
> From: Timothy Arceri
>
> We do this for all other stages.
> ---
> src/mesa/drivers/dri/i965/brw_gs.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_gs.c
> b/src/mesa/drivers/dri/i965
This series implements the driver-independent part of the
EXT_shader_framebuffer_fetch extension that provides fully
programmable blending to GLES shaders. The GLSL IR and NIR
representation of the framebuffer fetch functionality should be
straightforward, but the way extension tracking works may
From: Timothy Arceri
We do this for all other stages.
---
src/mesa/drivers/dri/i965/brw_gs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_gs.c
b/src/mesa/drivers/dri/i965/brw_gs.c
index d9f18c4..67a2480 100644
--- a/src/mesa/drivers/dri/i965/brw_gs.c
+
On Tuesday, July 19, 2016 4:33:25 PM PDT Timothy Arceri wrote:
> Reviewed-by: Edward O'Callaghan
> ---
> src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp | 17 +
> src/mesa/drivers/dri/i965/brw_vec4_tcs.h | 1 +
> 2 files changed, 14 insertions(+), 4 deletions(-)
Commit title should
On Tuesday, July 19, 2016 4:33:24 PM PDT Timothy Arceri wrote:
> ---
> src/mesa/drivers/dri/i965/brw_vec4_tes.cpp | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_tes.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4_tes.cpp
> i
We always resort to the pull model for instanced GS inputs. So, we'd
better include the VUE handles, or else we can't actually pull anything.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
1 file changed, 1 insertion(+), 1 d
On Wed, 2016-07-20 at 18:43 +0200, Alejandro Piñeiro wrote:
> On 19/07/16 08:33, Timothy Arceri wrote:
> > V5:
> > - rebase on Ken's interpolation clean-ups [1]
> >
> > V4:
> > - add vec4 backend support and enable for Gen6+
> >
> > V3:
> > - Rewrite patch 9 (add support for packing arrays) t
On Wed, 2016-07-20 at 12:15 -0700, Kenneth Graunke wrote:
> On Tuesday, July 19, 2016 4:33:14 PM PDT Timothy Arceri wrote:
> > Rather than trying to work out the total number of components
> > used at a location we simply treat all outputs as vec4s.
> > ---
> > src/mesa/drivers/dri/i965/brw_fs.h
On Wed, Jul 20, 2016 at 11:52 PM, Emil Velikov wrote:
> On 20 July 2016 at 15:42, Emil Velikov wrote:
>> On 20 July 2016 at 09:26, Nicolas Boichat wrote:
>>> android.opengl.cts.WrapperTest#testGetIntegerv1 CTS test calls
>>> eglTerminate, followed by eglReleaseThread. A similar case is
>>> obser
Thanks to the kind folks at Intel, this has been run through their CI
system, which runs against piglit, as well as CTS. This turned up just
a handful of regressions:
(a) GL_OES_texture_storage_multisample_2d_array define test used
#version 300 es in piglit instead of 310, fixed by
https://patchwo
GCC 6.1 -O3
Mesa 12.1.0-devel (git-d2b4b16)
Some line numbers provided below may be off by a few lines.
List of warnings generated AFTER
http://patchwork.freedesktop.org/series/9204/ rev 2 has been applied:
*
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/mesa/state_tracker/st_glsl_
On Wed, 2016-07-20 at 12:14 -0700, Kenneth Graunke wrote:
> On Tuesday, July 19, 2016 4:33:18 PM PDT Timothy Arceri wrote:
> > For example where n=3 first_component=1 this will give us
> > 0xE (WRITEMASK_YZW).
> >
> > Reviewed-by: Edward O'Callaghan
> > ---
> > src/mesa/drivers/dri/i965/brw_reg.
On Tue, Jul 19, 2016 at 6:41 PM, Matt Turner wrote:
> 1-27 are
>
> Reviewed-by: Matt Turner
Python's not my forte, so I'm going to call the rest of the series weakly
Reviewed-by: Matt Turner
Dylan may be interested in having a look.
___
mesa-dev mai
I had no idea what was going on until I did git show -w.
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Rob Herring writes:
> Use the common pipe_screen ref counting and fd hashing functions. The
> mutex can be dropped as the pipe loader protects the create_screen()
> calls.
I think the mutex mention in the commit message is copy-and-paste from
another commit, since there's no mutex present in thi
On Wed, Jul 20, 2016 at 5:32 PM, Ilia Mirkin wrote:
> On Wed, Jul 20, 2016 at 6:29 PM, Ilia Mirkin wrote:
>> On Wed, Jul 20, 2016 at 6:25 PM, Rob Herring wrote:
>>> Use the common pipe_screen ref counting and fd hashing functions. The
>>> mutex can be dropped as the pipe loader protects the crea
On Wed, Jul 20, 2016 at 6:29 PM, Ilia Mirkin wrote:
> On Wed, Jul 20, 2016 at 6:25 PM, Rob Herring wrote:
>> Use the common pipe_screen ref counting and fd hashing functions. The
>> mutex can be dropped as the pipe loader protects the create_screen()
>> calls.
>>
>> Signed-off-by: Rob Herring
>>
On Wed, Jul 20, 2016 at 6:25 PM, Rob Herring wrote:
> Use the common pipe_screen ref counting and fd hashing functions. The
> mutex can be dropped as the pipe loader protects the create_screen()
> calls.
>
> Signed-off-by: Rob Herring
> Cc: Alexandre Courbot
> ---
> src/gallium/drivers/nouveau/
Andy Furniss wrote:
I tried again, and there's a possible further regression - though I have
no idea whether it's ffmpeg or the newer patches here.
Just thought I would mention it, as I haven't had time to look into it
further yet.
I can confirm this is a regression with the current patches,
>We can keep it like this for now, but I would prefer that we clean this up and
>change the radeon_vce so that it matches the begin/encode/end calls from
>VA-API.
>We should probably work on this together with the performance improvements.
>Regards,
>Christian.
Hi Christian,
Sure, I agree, we
Signed-off-by: Jason Ekstrand
---
src/compiler/nir/nir_lower_returns.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/compiler/nir/nir_lower_returns.c
b/src/compiler/nir/nir_lower_returns.c
index 8dbea6e..cf49d5b 100644
--- a/src/compiler/nir/nir_lower_returns.c
All of these are happily set from glsl_to_nir or spirv_to_nir but their
values are never used for anything.
Signed-off-by: Jason Ekstrand
---
src/compiler/glsl/glsl_to_nir.cpp | 5 -
src/compiler/nir/nir.h | 34 --
src/compiler/spirv/vtn_variable
Signed-off-by: Jason Ekstrand
---
src/compiler/Makefile.sources | 1 +
src/compiler/nir/nir.h | 2 +
src/compiler/nir/nir_lower_constant_initializers.c | 102 +
3 files changed, 105 insertions(+)
create mode 100644 src/comp
The pass isn't really control-flow aware and you can get into case where it
tries to combine instructions from different blocks. This can actually
lead to an assertion failure when removing unneeded instructions if part of
the vector is set in one block and part in another. This prevents
regressi
It's only ever called on single-function shaders. At this point, there are
a lot of helpers that can make it all much simpler.
Signed-off-by: Jason Ekstrand
---
src/compiler/nir/nir_lower_gs_intrinsics.c | 37 +-
1 file changed, 16 insertions(+), 21 deletions(-)
dif
Constant initializers have been a constant (ha!) pain for quite some time.
While they're useful from a language perspective, people writing passes or
backends really don't want deal with them most of the time. This commit
removes most of the constant initializer support from NIR. It is expected
t
Signed-off-by: Jason Ekstrand
---
src/compiler/glsl/glsl_to_nir.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/compiler/glsl/glsl_to_nir.cpp
b/src/compiler/glsl/glsl_to_nir.cpp
index 20302e3..e6171d9 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_ni
Signed-off-by: Jason Ekstrand
---
src/intel/vulkan/anv_pipeline.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index 3723423..df57182 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pip
Use the common pipe_screen ref counting and fd hashing functions.
The mutex can be dropped as the pipe loader protects the create_screen()
calls. The fd does not need to be dup'ed as the caller has already done
that.
Signed-off-by: Rob Herring
Cc: Dave Airlie
---
src/gallium/winsys/virgl/drm/vi
Use the common pipe_screen ref counting and fd hashing functions. The
mutex can be dropped as the pipe loader protects the create_screen()
calls.
Cc: Eric Anholt
Signed-off-by: Rob Herring
---
src/gallium/winsys/vc4/drm/vc4_drm_winsys.c | 9 -
1 file changed, 8 insertions(+), 1 deletion
Use the common pipe_screen ref counting and fd hashing functions. The
mutex can be dropped as the pipe loader protects the create_screen()
calls.
Signed-off-by: Rob Herring
---
src/gallium/winsys/svga/drm/vmw_screen.c | 51
src/gallium/winsys/svga/drm/vmw_screen.
In preparation to add reference counting of pipe_screen in the pipe-loader,
pipe_loader_release needs to destroy the pipe_screen instead of state
trackers.
Signed-off-by: Rob Herring
Cc: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader.h | 1 +
src/gallium/auxiliary/pipe-loade
Use pipe_screen_unreference as it will call pipe_screen->destroy() when
the pipe_screen is no longer referenced.
The pipe_screen referencing is done within create_screen() functions
as drivers (like amdgpu) may have special needs for ref counting.
Signed-off-by: Rob Herring
Cc: Emil Velikov
---
Use the common pipe_screen ref count. amdgpu is unique in its hashing
the dev pointer rather than the fd, so the common fd hashing cannot be
used. However, the same reference count can be used instead of the
private one. The mutex can be dropped as the pipe loader protects the
create_screen() calls
Creating a screen needs to be serialized in order to support reusing
existing screen. With this, driver private mutexes in create_screen()
functions can be removed.
Signed-off-by: Rob Herring
Cc: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 5 +
1 file changed, 5 i
In order to prevent multiple pipe_screens being created in the same
process, lookup of the DRM FD and reference counting of the pipe_screen
are needed. Several implementations of this exist in various gallium
drivers/winsys already. This creates a common version which is opt-in
for winsys implement
Use the common pipe_screen ref counting and fd hashing functions. The
mutex can be dropped as the pipe loader protects the create_screen()
calls.
Signed-off-by: Rob Herring
Cc: Rob Clark
---
src/gallium/drivers/freedreno/freedreno_screen.c | 1 -
src/gallium/drivers/freedreno/freedreno_scree
Use the common pipe_screen ref counting and fd hashing functions. The
mutex can be dropped as the pipe loader protects the create_screen()
calls.
Signed-off-by: Rob Herring
Cc: Alexandre Courbot
---
src/gallium/drivers/nouveau/nouveau_screen.c | 6 --
src/gallium/drivers/nouveau/nouveau_
Hi Andy,
Thanks very much for providing all the information.
The I420 U V swapping issue still can't be reproduced from my side, I will try
it again later. CQP issue is fixed in the new patch set I just submitted.
Please use " ... vaapiencodeh264 rate-control=cqp init-qp=x ..." command, where
Use the common pipe_screen ref counting and fd hashing functions. The
mutex can be dropped as the pipe loader protects the create_screen()
calls.
Signed-off-by: Rob Herring
Cc: "Marek Olšák"
Cc: Ilia Mirkin
---
src/gallium/drivers/r300/r300_screen.c| 3 -
src/gallium/drivers/r600/
Another version of common pipe_screen reference counting.
Changes in v3:
- dup() fd and store in pipe_screen as the lifetime of the
pipe_loader_drm_device and pipe_screen are different.
- Fix leaking of pipe_loader_drm_device. Only the last one closed was
getting freed.
- Move mutex for fd hash
We don't tell the hardware whether we're computing depth, so we need
to manage early Z state manually. Fixes piglit early-z.
---
src/gallium/drivers/vc4/vc4_context.h | 2 ++
src/gallium/drivers/vc4/vc4_emit.c| 6 --
src/gallium/drivers/vc4/vc4_program.c | 5 +
3 files changed, 11 ins
We could use the nir_shader_gather_info() pass to update it after the
fact, but this is what glsl_to_nir and prog_to_nir do.
Note that this doesn't update all the fields (num_textures, num_ubos
are still missing, for example).
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 13 +
1 file
VAAPI passes PIPE_VIDEO_ENTRYPOINT_ENCODE as entry point for encoding case. We
will save this encode entry point in config. config_id was used as profile
previously. Now, config has both profile and entrypoint field, and config_id is
used to get the config object. Later on, we pass this entrypoi
Rate control method is passed from app to driver through config attrib list.
That is why we need to store this rate control method to config. And later on,
we will pass this value to context->desc.h264enc.rate_ctrl.rate_ctrl_method.
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/va
Enable H.264 VAAPI encoding through config. Currently only H.264 baseline is
supported. Encode entrypoint is not accepted by driver.
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/va/config.c | 34 ++
1 file changed, 22 insertions(+), 12 deletions(-)
Add some hardcoded values hardware needs mainly for rate control purpose. With
previously hardcoded values for OMX, the rate control result is not correct.
This change fixed the rate control result by setting correct values for Vaapi.
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/
Add environmental variable to disable interlace mode. At VAAPI decoding stage,
driver can not distinguish b/w pure decoding case and transcoding case. And
since interlace encoding is not supported, we have to disable interlace for
transcoding case. The temporary solution is to use enviromental v
Add necessary functions/changes for VAAPI encoding to buffer and picture. These
changes will allow driver to handle all Vaapi encode related operations. This
patch doesn't change the Vaapi decode behaviour.
Signed-off-by: Boyuan Zhang
---
src/gallium/state_trackers/va/buffer.c | 6 +
src
Add function to copy from yv12 image to nv12 surface for VAAPI putimage call.
We need this function in VaPutImage call where copying from yv12 image to nv12
surface for encoding. Existing function can't be used because it only work for
copying from yv12 surface to nv12 image in Vaapi.
Signed-of
For putimage call, if image format is yv12 (or IYUV with U V field swap) and
surface format is nv12, then we need to convert yv12 to nv12 and then copy the
converted data from image to surface. We can't use the existing logic where
surface is destroyed and re-created with yv12 format.
Signed-of
Creating a screen needs to be serialized in order to support reusing
existing screen. With this, driver private mutexes in create_screen()
functions can be removed.
Signed-off-by: Rob Herring
Cc: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 5 +
1 file changed, 5 i
In order to prevent multiple pipe_screens being created in the same
process, lookup of the DRM FD and reference counting of the pipe_screen
are needed. Several implementations of this exist in various gallium
drivers/winsys already. This creates a common version which is opt-in
for winsys implement
In preparation to add reference counting of pipe_screen in the pipe-loader,
pipe_loader_release needs to destroy the pipe_screen instead of state
trackers.
Signed-off-by: Rob Herring
Cc: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader.h | 1 +
src/gallium/auxiliary/pipe-loade
*** BLURB HERE ***
Rob Herring (11):
gallium: move pipe_screen destroy into pipe-loader
pipe-loader-drm: protect create_screen() calls with a mutex
gallium: add common pipe_screen reference counting functions
pipe-loader-drm: use pipe_screen_unreference to destroy screen
nouveau: use com
On Fri, Jul 15, 2016 at 2:53 AM, Tomasz Figa wrote:
> From: Nicolas Boichat
>
> Existing image loader code supports creating images only for window
> surfaces. Moreover droid_create_surface() passes wrong surface type to
> dri2_get_dri_config(), resulting in incorrect configs being returned for
>
On Tuesday, July 19, 2016 4:33:14 PM PDT Timothy Arceri wrote:
> Rather than trying to work out the total number of components
> used at a location we simply treat all outputs as vec4s.
> ---
> src/mesa/drivers/dri/i965/brw_fs.h | 1 -
> src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 22
On Tuesday, July 19, 2016 4:33:18 PM PDT Timothy Arceri wrote:
> For example where n=3 first_component=1 this will give us
> 0xE (WRITEMASK_YZW).
>
> Reviewed-by: Edward O'Callaghan
> ---
> src/mesa/drivers/dri/i965/brw_reg.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/me
Tom Stellard writes:
> There was a patch committed to clang to remove unnecessary includes from
> header files, so we now need to explicitly include
> clang/Lex/PreprocessorOptions.h
>
> v2:
> - Use <> instead of "" for the include path.
> ---
> src/gallium/state_trackers/clover/llvm/invocatio
Tom Stellard writes:
> The build was failing because the official CL headers have a few defines,
> like:
>
> \# define cl_khr_gl_sharing 1
>
> Which have the same name as some class members of clang's OpenCLOptions class.
> If we include the cl headers first, this breaks the build because the me
I followed your suggestions and changed the prototype, although the
implementation only supports basic formats
---
include/vulkan/vulkan_intel.h | 17 +++
src/intel/vulkan/anv_intel.c | 49 +++
2 files changed, 66 insertions(+)
diff --git a/in
On Tuesday, July 19, 2016 4:33:13 PM PDT Timothy Arceri wrote:
> We will use this for output varyings. To make component
> packing simpler we will just treat all varyings as vec4s.
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 13 +
> src/mesa/drivers/dri/i965/brw_shader.h | 1 +
>
>Makes sense, but I suggest that in this case we should add at least a comment
>why this is still disabled.
>And it would look better if we have an "#if 0" or something like this in the
>code which gets explicitly removed with the last patch.
Sure, I agree. I will submit a new patch set to add t
On Friday, July 15, 2016 3:47:39 PM PDT Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
> Cc: "12.0"
> Cc: Connor Abbott
> ---
> src/compiler/nir/nir.c | 107
> +++
> src/compiler/nir/nir.h | 4 ++
> src/compiler/nir/nir_lower
On Friday, July 15, 2016 3:47:40 PM PDT Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
> Cc: "12.0"
> Cc: Connor Abbott
> ---
> src/compiler/nir/nir_inline_functions.c | 41
> +++--
> 1 file changed, 39 insertions(+), 2 deletions(-)
>
> diff --git a/src/comp
On 07/20/2016 12:22 AM, Eero Tamminen wrote:
> Hi,
>
> When you put arrays to headers they get duplicated in every object file
> that includes the header. If they're not static, you get conflict, if
> they're static, you rely on linker being able to de-duplicate them
> (which isn't given with eve
On Wed, Jul 20, 2016 at 3:10 PM, Marek Olšák wrote:
> Did you test this?
> https://cgit.freedesktop.org/~mareko/mesa/commit/?h=si-mid-ib-gfx-fence&id=a993d93a16da86ef1ead4a55aed969752ad3965a
I compiled your git branch and tested some games.
Bioshock Infinite benchmark on Ultra settings goes from
On 19/07/16 08:33, Timothy Arceri wrote:
> V5:
> - rebase on Ken's interpolation clean-ups [1]
>
> V4:
> - add vec4 backend support and enable for Gen6+
>
> V3:
> - Rewrite patch 9 (add support for packing arrays) to not add
> hacks to the type_size() functions.
> - Add packing support for t
Reviewed-by: Alejandro Piñeiro
On 19/07/16 08:33, Timothy Arceri wrote:
> ---
> src/mesa/drivers/dri/i965/brw_vec4_tes.cpp | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_tes.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4_
Reviewed-by: Alejandro Piñeiro
On 19/07/16 08:33, Timothy Arceri wrote:
> Here we create a new output_generic_reg array with the ability to
> store the dst_reg for each component of user defined varyings.
> This is needed as the previous code only stored the dst_reg based
> on the varying locati
On 19/07/16 08:33, Timothy Arceri wrote:
> This makes sure we give the correct driver location
> for doubles when using component packing.
Taking into account that the commit is about give the correct location
for the dvec3 case, probably it is worth to mention on the commit message.
> ---
> src
On 20 July 2016 at 15:42, Emil Velikov wrote:
> On 20 July 2016 at 09:26, Nicolas Boichat wrote:
>> android.opengl.cts.WrapperTest#testGetIntegerv1 CTS test calls
>> eglTerminate, followed by eglReleaseThread. A similar case is
>> observed in this bug: https://bugs.freedesktop.org/show_bug.cgi?id
On 15 July 2016 at 08:53, Tomasz Figa wrote:
> Hi,
>
> This series is a collection of various fixes and extensions we came up
> with during our attempt to use Mesa for Android.
>
> Fixes included in this series:
> - added mandatory EGL_MAX_PBUFFER_WIDTH and _HEIGHT attributes to EGL
>configs,
I miss a little explanation on the commit message (like on commit 8),
but that is just personal preference (and in general I personally tend
to be too verbose on the commit messages).
Either if you add a little explanation or not:
Reviewed-by: Alejandro Piñeiro
On 19/07/16 08:33, Timothy Arcer
On 19/07/16 08:33, Timothy Arceri wrote:
> Rather than trying to work out the total number of components
> used at a location we simply treat all outputs as vec4s.
Probably it would be good to explain a little the why on the commit
message, and not just the what. In either case:
Reviewed-by: Aleja
Reviewed-by: Alejandro Piñeiro
On 19/07/16 08:33, Timothy Arceri wrote:
> We will use this for output varyings. To make component
> packing simpler we will just treat all varyings as vec4s.
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 13 +
> src/mesa/drivers/dri/i965/brw_shader
On 15.07.2016 05:15, Marek =?UNKNOWN?B?T2zFocOhaw==?= wrote:
> Module: Mesa
> Branch: master
> Commit: f84e9d749fbb6da73a60fb70e6725db773c9b8f8
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=f84e9d749fbb6da73a60fb70e6725db773c9b8f8
>
> Author: Marek Olšák
> Date: Thu Jul 14 22:07
On 19 July 2016 at 03:12, Alexander von Gluck IV wrote:
> July 18 2016 1:10 PM, "Emil Velikov" wrote:
>> On 18 July 2016 at 16:28, Alexander von Gluck IV
>> wrote:
>>
>>> July 18 2016 9:20 AM, "Emil Velikov" wrote:
On 18 July 2016 at 14:39, Alexander von Gluck IV
wrote:
>
1 - 100 of 139 matches
Mail list logo
