On Tuesday, April 11, 2017 9:11:56 AM PDT Chris Wilson wrote:
> Decode the EGL/DRI priority enum into the [-1023, 1023] range as
> interpreted by the kernel and call DRM_I915_GEM_CONTEXT_SETPARAM to
> adjust the priority. We use 0 as the default medium priority (also the
> kernel default) and so on
On Wednesday, April 12, 2017 3:11:53 AM PDT Chris Wilson wrote:
> IMG_context_priority
> https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt
>
> "This extension allows an EGLContext to be created with a priority
> hint. It is possible that an implementation wil
On Thu, 2017-09-28 at 21:19 -0700, Kenneth Graunke wrote:
> On Thursday, September 28, 2017 1:24:21 AM PDT Iago Toral Quiroga
> wrote:
> > Triggering the push model when 64-bit inputs are involved is not
> > easy due to
> > the constrains on the maximum number of registers that we allow for
> > thi
Replaced by the assembly validator, and in fact gets in the way of
writing tests for the assembly validator.
---
src/intel/compiler/brw_eu_emit.c | 80
1 file changed, 80 deletions(-)
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_e
There can be no violation of the restriction that source offsets are
aligned if there is only one source offset.
---
src/intel/compiler/brw_eu_validate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
I seem to have forgotten I still had work to do.
---
src/intel/compiler/test_eu_validate.cpp | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/src/intel/compiler/test_eu_validate.cpp
b/src/intel/compiler/test_eu_validate.cpp
index 3dd560074f..4e
I did not implement:
CNL's restriction on 64-bit int + align16, because I don't think
we'll ever use this combination regardless of hardware generation.
The restriction on immediate DF -> F conversions, because there's no
reason to ever generate that, and I don't even know how DF -> F
---
src/intel/compiler/test_eu_validate.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/intel/compiler/test_eu_validate.cpp
b/src/intel/compiler/test_eu_validate.cpp
index 46d2b83e34..3dd560074f 100644
--- a/src/intel/compiler/test_eu_validate.cpp
+++ b/src/intel/compiler/test_
---
src/mesa/drivers/dri/i965/intel_screen.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index bd1365f232..10253eb5a4 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i96
... without the float -> double conversion. Low power parts have
additional restrictions when it comes to operating on 64-bit types, and
the instruction used to do the conversion violates one of them:
specifically, the restriction that "Source and Destination horizontal
stride must be aligned to th
The type suffixes were wrong, and the 16 was missing the 0 prefix.
Fixes: 92f787ff86ab ("i965: Add support for disassembling 64-bit integer
immediates")
---
src/intel/compiler/brw_disasm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel/compiler/brw_disasm.c b/s
Otherwise I cannot use this macro in test_eu_validate.cpp
---
src/intel/common/gen_device_info.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/common/gen_device_info.h
b/src/intel/common/gen_device_info.h
index ede4915e28..59b345e949 100644
--- a/src/intel/common/g
Some restrictions require something like strides to match between src
and dest. For multi-source instructions, I'd rather encapsulate the
logic for not inserting already present errors in ERROR_IF than
open-coding it multiple places.
---
src/intel/compiler/brw_eu_validate.c | 18 +-
64-bit operations on Atom parts have additional restrictions over their
big-core counterparts (validated by later patches).
Specifically, the restriction that "Source and Destination horizontal
stride must be aligned to the same qword" is violated by most shift
operations since NIR uses a 32-bit v
You'll notice there were bugs in some of the code being replaced.
---
src/intel/compiler/brw_eu_validate.c | 33 +++--
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index 7453
On Thu, 2017-09-28 at 21:55 -0700, Kenneth Graunke wrote:
> On Thursday, September 28, 2017 3:33:12 AM PDT Iago Toral Quiroga
> wrote:
> > we can skip these slots when they are not read in the fragment
> > shader
> > and they are positioned right after a VUE header that we are
> > already
> > skipp
On Thursday, September 28, 2017 3:33:12 AM PDT Iago Toral Quiroga wrote:
> we can skip these slots when they are not read in the fragment shader
> and they are positioned right after a VUE header that we are already
> skipping. We also need to ensure that we are passing at least one other
> varying
On Thursday, September 28, 2017 1:24:21 AM PDT Iago Toral Quiroga wrote:
> Triggering the push model when 64-bit inputs are involved is not easy due to
> the constrains on the maximum number of registers that we allow for this mode,
> however, for GS with 'points' primitive type and just a couple o
On Fri, Sep 15, 2017 at 9:01 AM, Jason Ekstrand wrote:
> ---
> src/intel/blorp/blorp_clear.c | 24 +---
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c
> index 0feebef..e8b1e32 100644
> --- a/src
On 2017-09-28 06:12 PM, Mark Thompson wrote:
This is a new interface in libva2 to support wider use-cases of passing
surfaces to external APIs. In particular, this allows export of NV12 and
P010 surfaces.
Signed-off-by: Mark Thompson
---
On 22/09/17 10:17, Christian König wrote:
Am 21.09.20
For 1080p video transcode, the height will be scaled to 1088 when deint
to progressive buffer. Set dst rect to make sure no scale.
Fixes: 3ad8687 "st/va: use new vl_compositor_yuv_deint_full() to deint"
Signed-off-by: Leo Liu
---
src/gallium/state_trackers/va/picture.c | 12 ++--
1 file
Please ignore, ran wrong script :-)
Dave.
On 29 September 2017 at 10:08, Dave Airlie wrote:
> From: Dave Airlie
>
> These don't seem to change at runtime, and the initialisers
> are constant data. This could be improved by not selecting
> the apu/non-apu path on each pcie read/write access.
>
>
On 29/09/17 01:05, Lionel Landwerlin wrote:
Valgrind stats on
dEQP-VK.pipeline.push_constant.graphics_pipeline.range_size_128 :
I obviously inverted before & after...
Before:
HEAP SUMMARY:
in use at exit: 2,467,381 bytes in 1,304 blocks
total heap usage: 697,853 allocs, 696,531 frees,
From: Dave Airlie
These don't seem to change at runtime, and the initialisers
are constant data. This could be improved by not selecting
the apu/non-apu path on each pcie read/write access.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/nbio_v6_1.c | 8
drivers/gpu/drm/amd/
When writing to set > 0, we were just wrongly writing to set 0. This
commit fixes this by lazily allocating each set as we write to them.
We didn't go for having them directly into the command buffer as this
would require an additional ~45Kb per command buffer.
v2: Allocate push descriptors from
Valgrind stats on
dEQP-VK.pipeline.push_constant.graphics_pipeline.range_size_128 :
Before:
HEAP SUMMARY:
in use at exit: 2,467,381 bytes in 1,304 blocks
total heap usage: 697,853 allocs, 696,531 frees, 138,466,600 bytes allocated
LEAK SUMMARY:
definitely lost: 936 bytes in 10 blocks
Mark Thompson wrote:
This reverts commit f70f6baaa3bb0f8b280ac2eaea69bbffaf7de840.
I just bisected to this as it also breaks
mpv --hwdec=vdpau --vo=opengl
amdgpu: The CS has been rejected, see dmesg for more information (-22).
amdgpu: The CS has been cancelled because the context is lost.
[d
On Sat, Sep 16, 2017 at 4:23 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> GLSL ES requires both, and while GLSL explicitly doesn't require correct
> overflow handling, it does appear to require handling input inf/denorms
> correctly.
>
> Fixes dEQP-GLES31.functional.shaders.builtin_functi
On Thu, Sep 28, 2017 at 3:42 PM, Matt Turner wrote:
> On Sat, Sep 16, 2017 at 4:23 AM, Nicolai Hähnle wrote:
>> Hi all,
>>
>> This series was motivated by radeonsi failing some ldexp tests due to
>> not handling denorms correctly and not handling overflows (which GLSL
>> doesn't require, but GLSL
On Sat, Sep 16, 2017 at 4:23 AM, Nicolai Hähnle wrote:
> Hi all,
>
> This series was motivated by radeonsi failing some ldexp tests due to
> not handling denorms correctly and not handling overflows (which GLSL
> doesn't require, but GLSL ES does).
>
> The first patch fixes the GLSL IR lowering of
This reverts commit f70f6baaa3bb0f8b280ac2eaea69bbffaf7de840.
---
This commit broke VAAPI surface export (found by bisection). I think the
observed behaviour with playback is consistent with surfaces not being updated
some of the time, so something to do with sharing? I tried setting
PIPE_BIND
This is a new interface in libva2 to support wider use-cases of passing
surfaces to external APIs. In particular, this allows export of NV12 and
P010 surfaces.
Signed-off-by: Mark Thompson
---
On 22/09/17 10:17, Christian König wrote:
> Am 21.09.2017 um 21:00 schrieb Mark Thompson:
>> On 20/09/1
Necessary to support P010/P016 surfaces for video.
Signed-off-by: Mark Thompson
---
src/gallium/state_trackers/dri/dri2.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/gallium/state_trackers/dri/dri2.c
b/src/gallium/state_trackers/dri/dri2.c
index 8672174787..2aa3ba52f
I don't have access to my Intel email except when physically at work, I'd prefer
to use dy...@pnwbakers.com
Otherwise I probably am the guy to look at meson,
Reviewed-by: Dylan Baker
Quoting Eric Engestrom (2017-09-28 05:37:02)
> Cc: Dylan Baker
> Signed-off-by: Eric Engestrom
> ---
> REVIEWE
Sorry if I insist on this again, but can someone who knows the internals
of Mesa better than me please tell me which files implement pbuffers in
gallium llvmpipe? Specifically, the parts that are involved in creating
a pbuffer, its texture, framebuffer, and (I think) copying the screen to it.
I
For the series:
Reviewed-by: Marek Olšák
Marek
On Thu, Sep 28, 2017 at 9:55 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This fixes a warning caused by the fork (note the change in the function
> signature):
>
> ../../../../../mesa-src/src/gallium/drivers/r600/r600_state_common.c: In
From: Nicolai Hähnle
---
src/gallium/drivers/r300/r300_screen.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/r300/r300_screen.c
b/src/gallium/drivers/r300/r300_screen.c
index f41d09d263f..0c3e097535d 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/galliu
From: Nicolai Hähnle
This fixes a warning caused by the fork (note the change in the function
signature):
../../../../../mesa-src/src/gallium/drivers/r600/r600_state_common.c: In
function ‘r600_init_common_state_functions’:
../../../../../mesa-src/src/gallium/drivers/r600/r600_state_common.c:29
Am 28.09.2017 um 20:09 schrieb Ben Crocker:
> In gallivm_compile_module, fix a typo in the
> debug_printf("Invoke as \"llc ..." message.
>
> Cc: "17.2"
>
> Signed-off-by: Ben Crocker
> ---
> src/gallium/auxiliary/gallivm/lp_bld_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
https://bugs.freedesktop.org/show_bug.cgi?id=103031
--- Comment #1 from Roland Scheidegger ---
Created attachment 134554
--> https://bugs.freedesktop.org/attachment.cgi?id=134554&action=edit
patch accounting for llvm nuked pabs intrinsics
Does this patch work?
I'm also changing the non-intrins
On 28.09.2017 20:28, Marek Olšák wrote:
This breaks GL45-CTS.texture_gather.plain-gather-int-cube-array, but
my CTS is very old.
Did you test your CTS?
You're right, this regressed. I was looking only at the Raven results,
where there's no regression. I'll look into it.
Cheers,
Nicolai
2017-09-28 20:21 GMT+02:00 Nicolai Hähnle :
> On 28.09.2017 19:18, Gustaw Smolarczyk wrote:
>>
>> 2017-09-28 18:52 GMT+02:00 Marek Olšák :
>>>
>>> A clearer comment would be: "Don't destroy the fence when it's in the
>>> middle of util_queue_fence_signal (signalled but not unlocked yet
>>> because
This breaks GL45-CTS.texture_gather.plain-gather-int-cube-array, but
my CTS is very old.
Did you test your CTS?
Marek
On Wed, Sep 13, 2017 at 7:04 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This is the same workaround that radv already applied in commit
> 3ece76f03dc0 ("radv/ac: gath
Am 28.09.2017 um 15:43 schrieb Jose Fonseca:
> On 28/09/17 02:46, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> The operation performed is all the same as LODQ, but with the usual
>> differences between dx10 and GL texture opcodes, that is separate
>> resource
>> and sampler indices
https://bugs.freedesktop.org/show_bug.cgi?id=103031
Bug ID: 103031
Summary: [llvmpipe] piglit fs-discard-exit-2 fails with
llvm-6.0
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
On 28.09.2017 18:37, Eric Engestrom wrote:
On Thursday, 2017-09-28 16:10:51 +, Nicolai Hähnle wrote:
From: Nicolai Hähnle
A tempting alternative fix would be adding a lock/unlock pair in
util_queue_fence_is_signalled. However, that wouldn't actually
improve anything in the semantics of uti
On 28.09.2017 19:18, Gustaw Smolarczyk wrote:
2017-09-28 18:52 GMT+02:00 Marek Olšák :
A clearer comment would be: "Don't destroy the fence when it's in the
middle of util_queue_fence_signal (signalled but not unlocked yet
because util_queue_fence_is_signalled doesn't lock). Instead, wait
until
Am 28.09.2017 um 18:19 schrieb Jose Fonseca:
> On 28/09/17 17:16, Roland Scheidegger wrote:
>> Am 28.09.2017 um 17:53 schrieb Jose Fonseca:
>>> On 28/09/17 16:29, Roland Scheidegger wrote:
Am 28.09.2017 um 16:12 schrieb Jose Fonseca:
> On 27/09/17 15:07, Roland Scheidegger wrote:
>> Am
In init_native_targets, allow the passing of additional options to
the LLC compiler via new GALLIVM_LLC_OPTIONS environmental control.
This option is available only #ifdef DEBUG, initially.
At top, add #include for LLVMParseCommandLineOptions()
declaration.
Cc: "17.2"
Signed-off-by: Ben Crocker
In gallivm_compile_module, fix a typo in the
debug_printf("Invoke as \"llc ..." message.
Cc: "17.2"
Signed-off-by: Ben Crocker
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/
In lp_build_create_jit_compiler_for_module(), advance the minimum
version of LLVM for VSX code generation to 4.0; this is the minimum
revision at which several known VSX code generation bugs are fixed:
https://llvm.org/bugs/show_bug.cgi?id=25503 (fixed in 3.8.1)
https://llvm.org/bugs/show_bug.
In check_os_altivec_support(), allow control of Altivec (first PPC vector
instruction set) code generation via a new environmental control,
GALLIVM_ALTIVEC, which is expected to take on a value of 1 or 0.
The default is to enable Altivec code generation.
This environmental control of Altivec code
Advance the minimum LLVM version for VSX code generation to 4.0.
New environmental controls:
GALLIVM_LLC_OPTIONS
GALLIVM_MATTRS
GALLIVM_VSX 0/1, default=1
GALLIVM_ALTIVEC 0/1, default=1
Ben Crocker (4):
gallivm: fix typo in debug_printf message
gallivm: allow additional llc
Hi,
Sorry for the top-post but the Gmail mobile app no longer believes in
inline quoting.
As for installing newer Meson, that's not strictly needed. As you say,
Meson deliberately doesn't have difficult or changing dependencies. It can
also be run straight from a checkout without mangling $PATH or
Quoting Tapani Pälli (2017-09-27 23:34:26)
>
>
> On 09/27/2017 08:57 PM, Rob Herring wrote:
> > On Wed, Sep 27, 2017 at 12:38 PM, Eric Anholt wrote:
> >> Dylan Baker writes:
> >>
> >>> [ Unknown signature status ]
> >>> I've gone ahead and pushed the Vulkan drivers meson builds.
> >>>
> >>> For
2017-09-28 18:52 GMT+02:00 Marek Olšák :
> A clearer comment would be: "Don't destroy the fence when it's in the
> middle of util_queue_fence_signal (signalled but not unlocked yet
> because util_queue_fence_is_signalled doesn't lock). Instead, wait
> until util_queue_fence_signal returns and then
I use my personal email for working with mailing lists (for a host of reasons),
so with the email changed to ,
Reviewed-by: Dylan Baker
I set my signoff's using my Intel address because management feels that that is
sufficient to convey that I'm working on the behalf of Intel and not as an
indep
On Thursday, 2017-09-28 10:04:32 -0700, Dylan Baker wrote:
> I don't have access to my Intel email except when physically at work, I'd
> prefer
> to use dy...@pnwbakers.com
Done and pushed :)
I also added myself as a reviewer, even though I'm not sure I'll be much
help at first; I guess I'll be
On Thu, Sep 28, 2017 at 3:43 PM, Jose Fonseca wrote:
> On 28/09/17 02:46, srol...@vmware.com wrote:
>>
>> From: Roland Scheidegger
>>
>> The operation performed is all the same as LODQ, but with the usual
>> differences between dx10 and GL texture opcodes, that is separate resource
>> and sampler
https://bugs.freedesktop.org/show_bug.cgi?id=102573
--- Comment #8 from Juan A. Suarez ---
(In reply to Andreas Boll from comment #7)
> Yeah, it's fixed [1]. Please cherry-pick commit 2ef7f23820a for 17.2.2.
>
Sure. It's on the queue.
--
You are receiving this mail because:
You are the assig
A clearer comment would be: "Don't destroy the fence when it's in the
middle of util_queue_fence_signal (signalled but not unlocked yet
because util_queue_fence_is_signalled doesn't lock). Instead, wait
until util_queue_fence_signal returns and then destroy it."
Reviewed-by: Marek Olšák
Marek
O
https://bugs.freedesktop.org/show_bug.cgi?id=102573
Andreas Boll changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Thursday, 2017-09-28 16:10:51 +, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> A tempting alternative fix would be adding a lock/unlock pair in
> util_queue_fence_is_signalled. However, that wouldn't actually
> improve anything in the semantics of util_queue_fence_is_signalled,
> while
On 28/09/17 17:16, Roland Scheidegger wrote:
Am 28.09.2017 um 17:53 schrieb Jose Fonseca:
On 28/09/17 16:29, Roland Scheidegger wrote:
Am 28.09.2017 um 16:12 schrieb Jose Fonseca:
On 27/09/17 15:07, Roland Scheidegger wrote:
Am 27.09.2017 um 09:13 schrieb Olivier Lauffenburger:
Software rast
Am 28.09.2017 um 17:53 schrieb Jose Fonseca:
> On 28/09/17 16:29, Roland Scheidegger wrote:
>> Am 28.09.2017 um 16:12 schrieb Jose Fonseca:
>>> On 27/09/17 15:07, Roland Scheidegger wrote:
Am 27.09.2017 um 09:13 schrieb Olivier Lauffenburger:
> Software rasterizer and LLVM contain code to
From: Nicolai Hähnle
A tempting alternative fix would be adding a lock/unlock pair in
util_queue_fence_is_signalled. However, that wouldn't actually
improve anything in the semantics of util_queue_fence_is_signalled,
while making that test much more heavy-weight. So this lock/unlock
pair in util_
Hi Louis-Francis,
On 28 September 2017 at 09:25, Louis-Francis Ratté-Boulianne
wrote:
> This patchset makes use of Jason Ekstrand's recent work on SYNC_FD
> semaphores and DRI3 v1.2 support for DMA fences:
> https://lists.x.org/archives/xorg-devel/2017-September/054770.html
>
> This is the second
On 28/09/17 16:29, Roland Scheidegger wrote:
Am 28.09.2017 um 16:12 schrieb Jose Fonseca:
On 27/09/17 15:07, Roland Scheidegger wrote:
Am 27.09.2017 um 09:13 schrieb Olivier Lauffenburger:
Software rasterizer and LLVM contain code to enable clipping as soon as
a vertex shader writes to gl_Clip
Am 28.09.2017 um 16:12 schrieb Jose Fonseca:
> On 27/09/17 15:07, Roland Scheidegger wrote:
>> Am 27.09.2017 um 09:13 schrieb Olivier Lauffenburger:
>>> Software rasterizer and LLVM contain code to enable clipping as soon as
>>> a vertex shader writes to gl_ClipDistance, even if the corresponding
>
On 19 September 2017 at 15:23, Vedran Miletić wrote:
> On 09/18/2017 06:00 PM, Emil Velikov wrote:
>> Hi all,
>>
>> As you may know, different components in Mesa use LLVM for various purposes.
>>
>> In particular:
>> - 3.3.0 for the aux gallium module, gallivm
>> - 3.6.0 for the opencl state-tra
https://bugs.freedesktop.org/show_bug.cgi?id=102573
--- Comment #6 from Juan A. Suarez ---
Patches landed in master
https://patchwork.freedesktop.org/series/30551/
Is this fixed?
--
You are receiving this mail because:
You are the assignee for the bug.
On 17 September 2017 at 19:01, Gwan-gyeong Mun wrote:
> It adds support of dri_image_loader to egl dri2 tizen backend.
>- referenced a basic buffer flow and management implementation from
> android's.
>
> It adds dri_image_back/dri_image_back member variables to dri_egl_surface for
> a manag
On 17 September 2017 at 19:01, Gwan-gyeong Mun wrote:
> Tizen platform (actually WL_TBM protocol) internally processes similiar
> actions
> such as mesa's
> BindWaylandDisplayWL/UnbindWaylandDisplayWL/QueryWaylandBufferWL.
> So the platform_tizen.c needs to implemment BindWaylandDisplayWL,
> Unb
On 17 September 2017 at 19:01, Gwan-gyeong Mun wrote:
> It adds support of dri2_loader to egl dri2 tizen backend.
> - referenced a basic buffer flow and management implementation from
> android.
>
> And it implements a query buffer age extesion for tizen and turn on
> swap_buffers_with_damage
On 27/09/17 15:07, Roland Scheidegger wrote:
Am 27.09.2017 um 09:13 schrieb Olivier Lauffenburger:
Software rasterizer and LLVM contain code to enable clipping as soon as
a vertex shader writes to gl_ClipDistance, even if the corresponding
clip planes are disabled.
GLSL specification states that
On 28.09.2017 03:46, srol...@vmware.com wrote:
From: Roland Scheidegger
The operation performed is all the same as LODQ, but with the usual
differences between dx10 and GL texture opcodes, that is separate resource
and sampler indices (plus result swizzling, and setting z/w channels
to zero).
On 17 September 2017 at 19:01, Gwan-gyeong Mun wrote:
> @@ -1736,6 +1736,11 @@ for plat in $platforms; do
> DEFINES="$DEFINES -DHAVE_ANDROID_PLATFORM"
> ;;
>
> +tizen)
> +PKG_CHECK_MODULES([TIZEN], [tpl-egl libtbm libtdm])
> +DEFINES="$DEFINES -DHAVE_TIZEN_PL
On 17 September 2017 at 19:01, Gwan-gyeong Mun wrote:
> It implements the egl swrast related features for tizen platform on
> platform_tizen.c
>
> It works with libtpl-egl (Tizen Porting Layer for egl) and libtbm (Tizen
> Buffer Manager)
> where back buffers of windows are backed by GEM objects.
On 28/09/17 02:46, srol...@vmware.com wrote:
From: Roland Scheidegger
The operation performed is all the same as LODQ, but with the usual
differences between dx10 and GL texture opcodes, that is separate resource
and sampler indices (plus result swizzling, and setting z/w channels
to zero).
---
On 17 September 2017 at 19:00, Gwan-gyeong Mun wrote:
> It adds a _EGL_PLATFORM_TIZEN enum value to _EGLPlatformType for tizen
> platform.
>
> It adds a detecting routine of tizen platform to
> _eglNativePlatformDetectNativeDisplay()
> and _eglGetNativePlatform().
> - As tizen platform interna
Hi Gwan-gyeong Mun
On 17 September 2017 at 19:00, Gwan-gyeong Mun wrote:
> Hi,
>
> these commit series modified some items from previous version.
>
> 1. patches are seperated by feature implementation.
> 2. remove unclearly relevant pbuffer surface-creation code.
> 3. refactored for removing dupl
Cc: Dylan Baker
Signed-off-by: Eric Engestrom
---
REVIEWERS | 5 +
1 file changed, 5 insertions(+)
diff --git a/REVIEWERS b/REVIEWERS
index 0b5d9a4fd31bd652cf02..0d97b29309cc98b9a295 100644
--- a/REVIEWERS
+++ b/REVIEWERS
@@ -103,6 +103,11 @@ F: CleanSpec.mk
F: */Android.*mk
F: */Makefile
On 20 September 2017 at 15:06, Daniel Stone wrote:
> Hi Emil,
>
> On 19 September 2017 at 11:25, Emil Velikov wrote:
>> On 15 September 2017 at 16:41, Daniel Stone wrote:
>>> On 15 September 2017 at 16:13, Emil Velikov
>>> wrote:
Right, I'm looking through both functions and I'm strugglin
Hello Jan, hello Emil,
I've found it. It isn't a LLVM but a Mesa clover build problem. After
Jan pointed me to build clover with
--enable-opencl_icd switch in mesa to create an ICD driver
(libMesaOpenCL.so) and the corresponding vendors file (installed as
/etc/OpenCL/vendors/mesa.icd)
libOp
On Fri, Sep 22, 2017 at 11:31:51AM +0200, Lucas Stach wrote:
> Currently we are blitting the whole resource when the RS is used to
> de-/tile a resource. This can be very inefficient for large resources
> where the transfer is only changing a small part of the resource
> (happens a lot with glTexSu
On Fri, Sep 22, 2017 at 11:31:49AM +0200, Lucas Stach wrote:
> The RS can blit abitrary tile aligned subregions of a resource by
> adjusting the buffer offset.
>
> Signed-off-by: Lucas Stach
> ---
> v2:
> - add asserts, so we catch any invalid use of the RS
> - split out tile mask computation, to
Hi Wladimir,
Am Dienstag, den 26.09.2017, 16:20 +0200 schrieb Wladimir J. van der
Laan:
> Hello Lucas,
>
> On Fri, Sep 22, 2017 at 11:27:36AM +0200, Lucas Stach wrote:
> > It seems that newer cores don't use the PA_ATTRIBUTES to decide if
> > the
> > varying should bypass the flat shading, but de
On Thu, 2017-09-28 at 07:24 -0400, Ilia Mirkin wrote:
> On Thu, Sep 28, 2017 at 6:33 AM, Iago Toral Quiroga m> wrote:
> > we can skip these slots when they are not read in the fragment
> > shader
> > and they are positioned right after a VUE header that we are
> > already
> > skipping. We also nee
On Thu, Sep 28, 2017 at 6:33 AM, Iago Toral Quiroga wrote:
> we can skip these slots when they are not read in the fragment shader
> and they are positioned right after a VUE header that we are already
> skipping. We also need to ensure that we are passing at least one other
> varying, since that
we can skip these slots when they are not read in the fragment shader
and they are positioned right after a VUE header that we are already
skipping. We also need to ensure that we are passing at least one other
varying, since that is a hardware requirement.
This helps alleviate a problem introduce
Hi all,
Just a gentle poke.
Even though a serious issue was already found by Chris Wilson on batchbuffer
migration, I would like for folks to look at the series (in particular the
monster patch 16) and give comments. With those comments I will then create a
v2 (indeed I've already implemented
Signed-off-by: Louis-Francis Ratté-Boulianne
---
src/vulkan/wsi/wsi_common.h | 3 +
src/vulkan/wsi/wsi_common_x11.c | 152 +++-
2 files changed, 121 insertions(+), 34 deletions(-)
diff --git a/src/vulkan/wsi/wsi_common.h b/src/vulkan/wsi/wsi_common.h
ind
Signed-off-by: Louis-Francis Ratté-Boulianne
---
src/vulkan/wsi/wsi_common_x11.c | 46 +
1 file changed, 46 insertions(+)
diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c
index 4569c928c8..d9467092d2 100644
--- a/src/vulkan/ws
Signed-off-by: Louis-Francis Ratté-Boulianne
---
src/egl/main/eglapi.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 41a2a1a9d8..ca2e90cdf0 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -1769,9 +1
Allow drivers to add a list of semaphores to wait on
when queuing a image to present.
Signed-off-by: Louis-Francis Ratté-Boulianne
---
src/amd/vulkan/radv_wsi.c | 2 +-
src/intel/vulkan/anv_wsi.c | 2 ++
src/vulkan/wsi/wsi_common.h | 6 +
src/vulkan/wsi/wsi_comm
Signed-off-by: Louis-Francis Ratté-Boulianne
---
src/intel/vulkan/anv_wsi.c | 121 -
1 file changed, 119 insertions(+), 2 deletions(-)
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index 2e05c3b07b..1e8e507d99 100644
--- a/src/in
This patchset makes use of Jason Ekstrand's recent work on SYNC_FD
semaphores and DRI3 v1.2 support for DMA fences:
https://lists.x.org/archives/xorg-devel/2017-September/054770.html
This is the second version of this patchset. For more context, see:
https://lists.freedesktop.org/archives/mesa-dev
Triggering the push model when 64-bit inputs are involved is not easy due to
the constrains on the maximum number of registers that we allow for this mode,
however, for GS with 'points' primitive type and just a couple of double
varyings we can trigger this and it just doesn't work because the
impl
Hi,
On 28 September 2017 at 09:10, Dave Airlie wrote:
> If we get a nouveauv ever we would have to have this, so not really wanting
> this.
Thanks for taking a look. The reason I did this wasn't just to get it
out of the WSI, but because we need it in the driver anyway.
Without modifiers, it's
On Thu, 2017-09-28 at 00:59 -0700, Kenneth Graunke wrote:
> On Thursday, September 28, 2017 12:36:27 AM PDT Iago Toral Quiroga
> wrote:
> > Triggering the push model when 64-bit inputs are involved is not
> > easy due to
> > the constrains on the maximum number of registers that we allow for
> > th
1 - 100 of 132 matches
Mail list logo
