On Fri, Jul 21, 2017 at 11:00 AM, Emil Velikov
wrote:
> On 20 July 2017 at 06:09, Jason Ekstrand wrote:
> > On Mon, Jul 17, 2017 at 7:54 AM, Emil Velikov
> > wrote:
> >>
> >> On 16 July 2017 at 06:35, Jason Ekstrand wrote:
> >> > n Fri, Jul 7, 2017 at 11:07 AM, Emil Velikov <
> emil.l.veli...@
Build mesa 5000 completed
Commit 6874b953f6 by Jason Ekstrand on 7/11/2017 6:07 PM:
anv/image: zalloc image views\n\nThis allows us to avoid some extra zeroing.\n\nReviewed-by: Lionel Landwerlin
Configure your notification preferences
__
Build mesa 4999 failed
Commit 3e57e9494c by Jason Ekstrand on 6/22/2017 4:35 AM:
i965: Enable regular fast-clears (CCS_D) on gen9+\n\nThe set of formats which supports CCS_E is actually fairly small on\ngen9. However, everything that supports fast-clears on ge
1-26:
Reviewed-by: Timothy Arceri
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 21/07/17 19:44, Samuel Pitoiset wrote:
On 07/21/2017 11:19 AM, Timothy Arceri wrote:
I wasn't too worried about this because more than just no_error gets
in-lined away, for example the dsa conditions and also the dim == 3.
The resulting output shouldn't be overly large. What do you think?
It may technically be possible to enable some sort of fast-clear support
for at least the base slice of a 2D array texture on gen7. However,
it's not documented to work, we've never tried to do it in GL, and we
have no idea what the hardware does if you turn on CCS_D with arrayed
rendering. Let's
On Saturday, July 22, 2017 2:14:28 AM PDT Chris Wilson wrote:
> Quoting Kenneth Graunke (2017-07-22 00:17:47)
> > The non-LLC story was a horror show. We uploaded data via pwrite
> > (drm_intel_bo_subdata), which would stall if the cache BO was in
> > use (being read) by the GPU. Obviously, we wa
On Saturday, July 22, 2017 2:09:43 AM PDT Chris Wilson wrote:
> Quoting Kenneth Graunke (2017-07-22 00:17:43)
> > Suggested by Chris Wilson.
> > ---
> > src/mesa/drivers/dri/i965/brw_bufmgr.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/src/mesa/drivers/dri/i965/b
https://bugs.freedesktop.org/show_bug.cgi?id=101876
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--
You are receivin
On Fri, 2017-07-21 at 23:19 -0500, Aaron Watry wrote:
> Base it on the active language version
>
> Signed-off-by: Aaron Watry
> ---
> src/gallium/state_trackers/clover/llvm/invocation.cpp | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/clove
On Sat, 2017-07-22 at 13:20 +0200, Pierre Moreau wrote:
> Hi Aaron,
>
> On 2017-07-21 — 23:19, Aaron Watry wrote:
> > According to section 5.8.4.5 of the 2.0 spec, the CL C version is chosen by:
> > 1) If you have -cl-std=CL1.1+ use the version specified
> > 2) If not, use the highest 1.x versio
On Fri, 2017-07-21 at 23:19 -0500, Aaron Watry wrote:
> The device version is the maximum CL version that the device supports.
>
> Eventually, this will query the pipe_driver itself, but for now move it
> a bit closer to its eventual destination.
Ideally we'd check supported extensions, but CLC 1
On Fri, 2017-07-21 at 23:19 -0500, Aaron Watry wrote:
> Fixes: OpenCL CTS test/conformance/buffers/buffer_copy
Similar patch was pushed in 2013:
56647c5d8f8e60269f0a3277e3caa7ee57d1fe6a
"clover: Append buffers that use CL_MEM_USE_HOST_PTR."
Grigory(added to cc) reverted the change and implemented
When we forcibly write white to FS outputs (for XOR mode emulation)
we were using a temp register. But that's not really necessary.
This also fixes the case of writing white to multiple color buffers.
Subsequent changes will build on this.
---
src/gallium/drivers/svga/svga_state_fs.c| 11 +++
The device doesn't directly support this feature so we implement it with
additional shader code which sets the color output(s) w component to
1.0 (or max_int or max_uint).
Fixes 16 Piglit ext_framebuffer_multisample/*alpha-to-one* tests.
---
src/gallium/drivers/svga/svga_context.h | 1 +
src
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
This will be a bit more convenient momentarily. It's also more correct
because it makes prepare_texture take sRGB into account.
Cc: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_draw.c | 6 +-
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 17 +++--
src/mesa/driv
Hello,
While looking at the extension list on my Tahiti GPU (SI) I have found
that ARB_draw_parameters is missing. Looking at the code, it requires
ME firmware version >= 87 and PFP firmware version >= 121. While the
first is satisfied, the second is not [1]. I believe I use the newest
TAHITI firm
https://bugs.freedesktop.org/show_bug.cgi?id=101876
--- Comment #1 from Christoph Haag ---
This is at fault:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=5124bf982393114862f44ee62fa361027faa7c29
It's also on the list:
https://lists.freedesktop.org/archives/mesa-dev/2017-July/164038.html
--
https://bugs.freedesktop.org/show_bug.cgi?id=101876
Bug ID: 101876
Summary: SIGSEGV when launching Steam
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority:
Hi Michel,
On 21 July 2017 at 18:32, Michel Dänzer wrote:
> On 20/07/17 01:08 PM, Daniel Stone wrote:
>> DRI3 version 1.1 adds support for explicit format modifiers, including
>> multi-planar buffers.
>
> Adding mesa-dev, Nicolai and Marek.
>
> We just ran into an issue which might mean that ther
With the comments in patch 4 taken care of, this series is
Reviewed-by: Pierre Moreau
On 2017-07-21 — 23:19, Aaron Watry wrote:
> The first patch is one I've been sitting on for a few weeks while
> I've tried to chase down other issues with clover/llvm/libclc. It
> fixes at least one CTS test t
Hi Aaron,
On 2017-07-21 — 23:19, Aaron Watry wrote:
> According to section 5.8.4.5 of the 2.0 spec, the CL C version is chosen by:
> 1) If you have -cl-std=CL1.1+ use the version specified
> 2) If not, use the highest 1.x version that the device supports
According to that same part of the spec,
On Wed, Jul 19, 2017 at 02:01:26PM -0700, Jason Ekstrand wrote:
> Gen9 hardware has this annoying little corner where CCS_E is not allowed
> for any sRGB formats. This is fixed on gen10 but on gen9 there's nothing
> we can do; it just doesn't work. The old approach to working around this
> was to
Quoting Kenneth Graunke (2017-07-22 00:17:47)
> src/mesa/drivers/dri/i965/brw_program_cache.c | 83
> +++
> 1 file changed, 21 insertions(+), 62 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_program_cache.c
> b/src/mesa/drivers/dri/i965/brw_program_cache.c
On Wed, Jul 19, 2017 at 02:01:54PM -0700, Jason Ekstrand wrote:
> ---
> src/intel/isl/gen_format_layout.py | 46
> +-
> src/intel/isl/isl.h| 8 +++
> 2 files changed, 53 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/isl/gen_forma
Quoting Kenneth Graunke (2017-07-22 00:17:47)
> The non-LLC story was a horror show. We uploaded data via pwrite
> (drm_intel_bo_subdata), which would stall if the cache BO was in
> use (being read) by the GPU. Obviously, we wanted to avoid that.
> So, we tried to detect whether the buffer was bu
Quoting Kenneth Graunke (2017-07-22 00:17:43)
> Suggested by Chris Wilson.
> ---
> src/mesa/drivers/dri/i965/brw_bufmgr.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> index 1669d26e990.
Quoting Kenneth Graunke (2017-07-22 00:17:41)
> With the advent of asynchronous maps, domain tracking doesn't make a
> whole lot of sense. Buffers can be in use on both the CPU and GPU at
> the same time. In order to avoid blocking, we stopped using set_domain
> for asynchronous mappings, which m
On Fri, Jul 21, 2017 at 09:35:21AM -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_blorp.c | 25 +++---
> src/mesa/drivers/dri/i965/brw_clear.c | 3 +-
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 107
> +++---
> src/mesa/drivers/dri/
On Fri, Jul 21, 2017 at 09:47:52AM -0700, Jason Ekstrand wrote:
> This commit changes layer_range_length to return locical layers and also
> changes the way we allocate the aux_state field to not allocate extra
> layers for MCS. This will be important as we're about to start doing
> significantly
Hi Emil,
On 21 July 2017 at 15:23, Emil Velikov wrote:
> I think the key issue is that the resource_get_handle() calls lack
> proper error handling.
>
> There's a single case, that was fixed not too long ago, yet everywhere
> else we consider that resource_get_handle() can fail.
> Can we address
This allows us to override contexts to use no_error functionality
even if the applications themselves do not.
---
src/mesa/drivers/dri/i965/brw_context.c | 3 +++
src/mesa/drivers/dri/i965/intel_screen.c | 1 +
2 files changed, 4 insertions(+)
Tested by running mesa_no_error=true ./bin/tex-error
33 matches
Mail list logo
