platform_wayland.c includes linux-dmabuf-unstable-v1-client-protocol.h,
which is generated during build. Add the missing dependency to the
Makefile.
I have seen the following build failure due to a race between generation
of linux-dmabuf-unstable-v1-client-protocol.h and compilation of
platform_wa
Hi Rob,
Finally got to review this. Please see my comments inline.
On Fri, May 11, 2018 at 10:48 PM Robert Foss
wrote:
[snip]
> +EGLBoolean
> +droid_load_driver(_EGLDisplay *disp)
Since this is not EGL-facing, I'd personally use bool.
> +{
> + struct dri2_egl_display *dri2_dpy = disp->Driver
Hi Rob,
On Thu, May 24, 2018 at 8:23 PM Robert Foss
wrote:
> Hey,
> I don't think I've received any feedback on this version yet.
> If anyone has some time to spare, it would be nice to get it merged.
Really sorry for taking so long to review. Posted my comments just now.
Best regards,
Tomasz
Hey,
On 2018-05-25 02:17, Rob Herring wrote:
On Thu, May 24, 2018 at 6:23 AM, Robert Foss wrote:
Hey,
I don't think I've received any feedback on this version yet.
If anyone has some time to spare, it would be nice to get it merged.
Just to be clear about the libdrm branch linked in the cove
On Fri, May 25, 2018 at 5:33 PM Robert Foss
wrote:
> Hey,
> On 2018-05-25 02:17, Rob Herring wrote:
> > On Thu, May 24, 2018 at 6:23 AM, Robert Foss
wrote:
> >> Hey,
> >>
> >> I don't think I've received any feedback on this version yet.
> >> If anyone has some time to spare, it would be nice t
On Tue, 2018-05-22 at 10:48 -0700, Dylan Baker wrote:
> This looks good to me. I'm also opened to doing the 18.1.x releases if Emil
> would rather not do them (and I have been updating my 18.1-proposed branch
> either way).
>
I'm fine if you do 18.1.x releases. In fact, I think it would be a good
On 2018-05-25 10:38, Tomasz Figa wrote:
On Fri, May 25, 2018 at 5:33 PM Robert Foss
wrote:
Hey,
On 2018-05-25 02:17, Rob Herring wrote:
On Thu, May 24, 2018 at 6:23 AM, Robert Foss
wrote:
Hey,
I don't think I've received any feedback on this version yet.
If anyone has some time to sp
On 05/25/2018 04:28 AM, Timothy Arceri wrote:
On 25/05/18 11:24, Bas Nieuwenhuizen wrote:
On Fri, May 25, 2018 at 2:25 AM, Timothy Arceri
wrote:
From what I recall with my testing on radeonsi this wasn't really
the ideal
thing to do. Especially when varyings arrays are accessed via and
i
On 25/05/18 19:57, Samuel Pitoiset wrote:
On 05/25/2018 04:28 AM, Timothy Arceri wrote:
On 25/05/18 11:24, Bas Nieuwenhuizen wrote:
On Fri, May 25, 2018 at 2:25 AM, Timothy Arceri
wrote:
From what I recall with my testing on radeonsi this wasn't really
the ideal
thing to do. Especially whe
On 25/05/18 20:40, Timothy Arceri wrote:
On 25/05/18 19:57, Samuel Pitoiset wrote:
On 05/25/2018 04:28 AM, Timothy Arceri wrote:
On 25/05/18 11:24, Bas Nieuwenhuizen wrote:
On Fri, May 25, 2018 at 2:25 AM, Timothy Arceri
wrote:
From what I recall with my testing on radeonsi this wasn't r
On Thursday, 2018-05-24 17:27:04 -0700, Laura Ekstrand wrote:
> For now, all this does is copy our current webpage into a public folder.
> Daniel Stone has the server configured to check this public folder and
> host the index.html as mesa-test.freedesktop.org. When this patch series
> is approved,
https://bugs.freedesktop.org/show_bug.cgi?id=105464
--- Comment #16 from Samuel Pitoiset ---
No CTS regressions, I'm fine with it.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-de
On Thursday, 2018-05-24 17:27:05 -0700, Laura Ekstrand wrote:
> Use Beautiful Soup to fix bad html, then use pandoc for converting to
> rst.
> ---
> docs/rstConverter.py | 23 +++
> 1 file changed, 23 insertions(+)
> create mode 100755 docs/rstConverter.py
>
> diff --git a/do
https://bugs.freedesktop.org/show_bug.cgi?id=105464
--- Comment #17 from Nicolai Hähnle ---
Great, thanks for testing!
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing li
Hi Eric,
On 25 May 2018 at 12:15, Eric Engestrom wrote:
> If I'm misunderstanding gitlab-ci and this is running one the same
> filesystem as the website, then you'll need to `rm -r public` before the
> move, otherwise `mv .public public` will not do what you want :)
It's always run in a fresh co
On Fri, May 25, 2018 at 12:45 PM, Timothy Arceri wrote:
>
>
> On 25/05/18 20:40, Timothy Arceri wrote:
>>
>> On 25/05/18 19:57, Samuel Pitoiset wrote:
>>>
>>> On 05/25/2018 04:28 AM, Timothy Arceri wrote:
On 25/05/18 11:24, Bas Nieuwenhuizen wrote:
>
> On Fri, May 25, 2018 at 2:2
https://bugs.freedesktop.org/show_bug.cgi?id=98581
Samuel Pitoiset changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_private.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index e554fc7acc..708cacf770 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/r
This will allow to emit consecutive shader pointers for
reducing the number of emitted SET_SH_REG packets, which
is recommended.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_private.h | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/src/amd
This reduces the number of SET_SH_REG packets which are emitted
for applications that use more than one descriptor set per stage.
We should be able to emit more SET_SH_REG packets consecutively
(like push constants and vertex buffers for the vertex stage),
but this will be improved later.
Signed-
On Fri, May 25, 2018 at 4:15 AM, Robert Foss wrote:
>
>
> On 2018-05-25 10:38, Tomasz Figa wrote:
>>
>> On Fri, May 25, 2018 at 5:33 PM Robert Foss
>> wrote:
>>
>>> Hey,
>>
>>
>>> On 2018-05-25 02:17, Rob Herring wrote:
On Thu, May 24, 2018 at 6:23 AM, Robert Foss
>>
>> wrote:
>
>>
On Fri, May 25, 2018 at 10:59 PM Rob Herring wrote:
> On Fri, May 25, 2018 at 4:15 AM, Robert Foss
wrote:
> >
> >
> > On 2018-05-25 10:38, Tomasz Figa wrote:
> >>
> >> On Fri, May 25, 2018 at 5:33 PM Robert Foss
> >> wrote:
> >>
> >>> Hey,
> >>
> >>
> >>> On 2018-05-25 02:17, Rob Herring wrote:
On Thursday, 2018-05-24 17:27:15 -0700, Laura Ekstrand wrote:
> This just involves some quick fixes to formatting of the affected pages.
> ---
> docs/autoconf.rst| 1 +
> docs/conf.py | 2 +-
> docs/dispatch.rst| 72
> ++--
On Thursday, 2018-05-24 17:27:18 -0700, Laura Ekstrand wrote:
> There's a lot here. If you're interested, it's mostly whitespace fixes,
> switching variable names and function names to the Sphinx orange variable
> highlight style, and naming code blocks to take advantage of Pygments
> syntax highl
On Thursday, 2018-05-24 17:27:19 -0700, Laura Ekstrand wrote:
> Goodbye old css file. You belong in 1999 from whence you came.
> ---
> docs/mesa.css | 63
> ---
> 1 file changed, 63 deletions(-)
> delete mode 100644 docs/mesa.css
I guess
https://bugs.freedesktop.org/show_bug.cgi?id=106644
--- Comment #9 from Ben Crocker ---
We note that this is a build for a PPC970, which is essentially
a big-endian ~Power4 equivalent to a G5 Mac.
Moreover, it appears to be a 32-bit build.
--
You are receiving this mail because:
You are the QA
On Friday, 2018-05-25 06:52:25 +, Vinson Lee wrote:
> Fix build error without DRI3.
D'uh!
I forgot building dri3 was optional, sorry :/
Reviewed-by: Eric Engestrom
>
> CC drivers/dri2/platform_x11.lo
> drivers/dri2/platform_x11.c:1010:1: error: no previous prototype for function
>
SCATTERPS previously assumed it was being used with an existing basic
block
---
.../drivers/swr/rasterizer/jitter/builder_mem.cpp | 29 +++---
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/swr/rasterizer/jitter/builder_mem.cpp
b/src/gallium/dr
Version 2 makes a small change to swr_loader.cpp to include the new InitMemory
header, which fixes a compile error on single-architecture builds.
Alok Hota (7):
swr/rast: Added in-place building to SCATTERPS
swr/rast: Checking gCoreBuckets and CORE_BUCKETS are equal length at
compile time
---
.../drivers/swr/rasterizer/jitter/builder.h| 28 ++
1 file changed, 28 insertions(+)
diff --git a/src/gallium/drivers/swr/rasterizer/jitter/builder.h
b/src/gallium/drivers/swr/rasterizer/jitter/builder.h
index 6ca128d..08a3a6e 100644
--- a/src/gallium/drivers/swr/
---
src/gallium/drivers/swr/rasterizer/core/rdtsc_core.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/swr/rasterizer/core/rdtsc_core.cpp
b/src/gallium/drivers/swr/rasterizer/core/rdtsc_core.cpp
index f289a31..48ea397 100644
--- a/src/gallium/drivers/swr/rasterizer/cor
---
src/gallium/drivers/swr/rasterizer/jitter/blend_jit.cpp | 2 +-
src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp | 2 +-
.../swr/rasterizer/jitter/functionpasses/lower_x86.cpp | 17 -
.../swr/rasterizer/jitter/functionpasses/passes.h | 2 +-
.../drivers/swr/ras
---
.../drivers/swr/rasterizer/jitter/builder.cpp | 170 ++---
.../drivers/swr/rasterizer/jitter/builder.h| 4 +-
2 files changed, 87 insertions(+), 87 deletions(-)
diff --git a/src/gallium/drivers/swr/rasterizer/jitter/builder.cpp
b/src/gallium/drivers/swr/rasteri
Optimize AVX-512 PA Assemble (PA_STATE_OPT). Reduced generated code by
about 4x, MSVC compiler was going crazy making temporaries and
split-loading inputs onto the stack unless explicit AVX-512 load ops
were added
---
src/gallium/drivers/swr/rasterizer/core/pa_avx.cpp | 139 +
Added two new files for a wrapper function for initialization
v2: added missing include for single architecture builds
---
src/gallium/drivers/swr/Makefile.sources | 4 ++-
src/gallium/drivers/swr/meson.build| 2 ++
src/gallium/drivers/swr/rasterizer/core/api.cpp|
On Fri, May 25, 2018 at 9:25 AM, Tomasz Figa wrote:
> On Fri, May 25, 2018 at 10:59 PM Rob Herring wrote:
>
>> On Fri, May 25, 2018 at 4:15 AM, Robert Foss
> wrote:
>> >
>> >
>> > On 2018-05-25 10:38, Tomasz Figa wrote:
>> >>
>> >> On Fri, May 25, 2018 at 5:33 PM Robert Foss
>> >> wrote:
>> >>
V2: Good catch!
Reviewed-by: Bruce Cherniak
> On May 25, 2018, at 10:19 AM, Alok Hota wrote:
>
> Version 2 makes a small change to swr_loader.cpp to include the new InitMemory
> header, which fixes a compile error on single-architecture builds.
>
> Alok Hota (7):
> swr/rast: Added in-place b
https://bugs.freedesktop.org/show_bug.cgi?id=106644
--- Comment #10 from erhar...@mailbox.org ---
Correct. Should I note (potential?) ppc specific issues in the bug title too,
besides selecting hardware "PowerPC"?
llvmpipe does run on my other G5 (64bit build), however a lot of piglet tests
fail/
On Thursday, 2018-05-24 11:47:52 +0200, Karol Herbst wrote:
> From: Pierre Moreau
>
> v2 (Karol Herbst ):
> * removed unneeded ll
> * ll -> ull
Reviewed-by: Eric Engestrom
>
> Signed-off-by: Karol Herbst
> ---
> src/gallium/auxiliary/util/u_math.h | 55 +
> src/u
On Sat, May 26, 2018 at 12:38 AM Rob Herring wrote:
> On Fri, May 25, 2018 at 9:25 AM, Tomasz Figa wrote:
> > On Fri, May 25, 2018 at 10:59 PM Rob Herring wrote:
> >
> >> On Fri, May 25, 2018 at 4:15 AM, Robert Foss > wrote:
> >> >
> >> >
> >> > On 2018-05-25 10:38, Tomasz Figa wrote:
> >> >>
On Friday, 2018-05-25 16:06:26 +0100, Eric Engestrom wrote:
> On Friday, 2018-05-25 06:52:25 +, Vinson Lee wrote:
> > Fix build error without DRI3.
>
> D'uh!
> I forgot building dri3 was optional, sorry :/
>
> Reviewed-by: Eric Engestrom
Actually, wait no, this doesn't look right, the funct
On Thu, May 24, 2018 at 2:55 PM, Jason Ekstrand wrote:
> From: Francisco Jerez
I think some explanation is required. I'm guessing this is because you
have to write lo fragments out before high, but we should say that in
the commit message.
___
mesa-dev
On Thu, May 24, 2018 at 2:55 PM, Jason Ekstrand wrote:
> It doesn't matter since we don't ever run replicated write shaders
> through the optimizer but it's good to be complete.
Aside: Is there anything that would prevent us from detecting that all
fragments are uniform and using this message?
__
On Thu, May 24, 2018 at 2:55 PM, Jason Ekstrand wrote:
> From: Francisco Jerez
Okay, I think the problem this patch is fixing is that previously we
would unconditionally execute the fire_fb_write() to send the AA data,
and conditionally execute the fire_fb_write() that does not.
But we actually
On Thu, May 24, 2018 at 2:55 PM, Jason Ekstrand wrote:
> Doing instruction header setup in the generator is aweful for a number
Misspelling: awful
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/me
On Thu, May 24, 2018 at 2:55 PM, Jason Ekstrand wrote:
> This patch series adds back-end compiler support for SIMD32 fragment
> shaders. Support is added and everything works but it's currently hidden
> behind INTEL_DEBUG=do32. We know that it improves performance in some
> cases but we do not y
On Friday, February 23, 2018 7:10:55 AM PDT Eleni Maria Stea wrote:
> Gen 7 GPUs store the compressed EAC/ETC2 images in other non-compressed
> formats that can render. When GetCompressed* functions are called, the
> pixels are returned in the non-compressed format that is used for the
> rendering.
On Monday, April 30, 2018 4:38:57 PM PDT Scott D Phillips wrote:
> Kenneth Graunke writes:
>
> > On Monday, April 30, 2018 10:25:49 AM PDT Scott D Phillips wrote:
> >> Rename the (un)map_gtt functions to (un)map_map (map by
> >> returning a map) and add new functions (un)map_tiled_memcpy that
> >
On Fri, May 25, 2018 at 11:27 AM, Matt Turner wrote:
> On Thu, May 24, 2018 at 2:55 PM, Jason Ekstrand
> wrote:
> > From: Francisco Jerez
>
> I think some explanation is required. I'm guessing this is because you
> have to write lo fragments out before high, but we should say that in
> the comm
On Fri, May 25, 2018 at 11:29 AM, Matt Turner wrote:
> On Thu, May 24, 2018 at 2:55 PM, Jason Ekstrand
> wrote:
> > It doesn't matter since we don't ever run replicated write shaders
> > through the optimizer but it's good to be complete.
>
> Aside: Is there anything that would prevent us from d
On Fri, May 25, 2018 at 11:29 AM, Matt Turner wrote:
> On Thu, May 24, 2018 at 2:55 PM, Jason Ekstrand
> wrote:
> > It doesn't matter since we don't ever run replicated write shaders
> > through the optimizer but it's good to be complete.
>
> Aside: Is there anything that would prevent us from d
For certain EGLImage cases, we represent a single slice or LOD of an
image with a byte offset to a tile and X/Y intratile offsets to the
given slice. Most of i965 is fine with this but it breaks blorp. This
is a terrible way to represent slices of a surface in EGL and we should
stop some day but
On Friday, May 25, 2018 12:31:03 PM PDT Jason Ekstrand wrote:
> For certain EGLImage cases, we represent a single slice or LOD of an
> image with a byte offset to a tile and X/Y intratile offsets to the
> given slice. Most of i965 is fine with this but it breaks blorp. This
> is a terrible way to
On Fri, May 25, 2018 at 12:14 PM, Jason Ekstrand wrote:
> On Fri, May 25, 2018 at 11:27 AM, Matt Turner wrote:
>>
>> On Thu, May 24, 2018 at 2:55 PM, Jason Ekstrand
>> wrote:
>> > From: Francisco Jerez
>>
>> I think some explanation is required. I'm guessing this is because you
>> have to write
On Fri, May 25, 2018 at 12:53 PM, Kenneth Graunke
wrote:
> On Friday, May 25, 2018 12:31:03 PM PDT Jason Ekstrand wrote:
> > For certain EGLImage cases, we represent a single slice or LOD of an
> > image with a byte offset to a tile and X/Y intratile offsets to the
> > given slice. Most of i965
From: Marek Olšák
Bindless texture handles can be passed via vertex attribs using this type.
This fixes a bunch of bindless piglit tests on radeonsi.
Cc: 18.0 18.1
---
src/mesa/main/glformats.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glfo
From: Marek Olšák
Bindless texture handles can be passed via vertex attribs using this type.
This fixes a bunch of bindless piglit tests on radeonsi.
Cc: 18.0 18.1
---
src/mesa/state_tracker/st_atom_array.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/state_tracker/st_atom_a
On Thu, May 24, 2018 at 2:56 PM, Jason Ekstrand wrote:
> From: Francisco Jerez
>
> The hardware's control flow logic is 16-wide so we're out of luck
> here. We could, in theory, support SIMD32 if we know the control-flow
> is uniform but we don't have that information at this point.
This is wha
On Thu, May 24, 2018 at 2:56 PM, Jason Ekstrand wrote:
> From: Francisco Jerez
>
Presumably Jason already reviewed this and just missed attaching his R-b tag.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailma
On Thu, May 24, 2018 at 2:56 PM, Jason Ekstrand wrote:
> We want consistent behavior in the meaning of the flag_subreg field
> between SNB and IVB+.
>
> v2 (Jason Ekstrand):
> - Add some extra commentary
>
> Reviewed-by: Jason Ekstrand
Presumably you did not intend to review your own patch :)
_
On Thu, May 24, 2018 at 2:56 PM, Jason Ekstrand wrote:
> From: Francisco Jerez
>
> ---
> src/intel/compiler/brw_shader.cpp | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/compiler/brw_shader.cpp
> b/src/intel/compiler/brw_shader.cpp
> index 141b64e..61211ef
On Fri, May 25, 2018 at 11:50 AM, Matt Turner wrote:
> On Thu, May 24, 2018 at 2:55 PM, Jason Ekstrand wrote:
>> This patch series adds back-end compiler support for SIMD32 fragment
>> shaders. Support is added and everything works but it's currently hidden
>> behind INTEL_DEBUG=do32. We know t
Quoting Scott D Phillips (2018-04-30 18:25:48)
> +#if defined(USE_SSE41)
> +static ALWAYS_INLINE void *
> +_memcpy_streaming_load(void *dest, const void *src, size_t count)
> +{
> + if (count == 16) {
> + __m128i val = _mm_stream_load_si128((__m128i *)src);
> + _mm_store_si128((__m128i
intel_tiled_memcpy is not restricted to using the same pitch on both the
src/dst buffers, nor requires row alignment on the user buffer. To
support arbitrary using packing modes, all we need to do is use the core
functions to compute the pixel locations.
---
src/mesa/drivers/dri/i965/intel_pixel_r
Now that we have enabled cache-line at a time transfers to and from GPU
memory, we can accelerate access into !llc (WC) memory just as well as
WB memory with llc.
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 2 +-
src/mesa/drivers/dri/i965/intel_pixel_read.c | 5 ++---
src/mesa/drivers
Just a small series to put the new cache-line read back to good use for
ye olde Xorg on bxt (and older/newer with very similar effect).
From
4 trep @ 0.7007 msec ( 1430.0/sec): ShmPutImage 500x500 square
4000 trep @ 9.0367 msec ( 111.0/sec): ShmGetImage 500x500 square
to
Allow the tiled_memcpy backend to determine if it is able to copy
between the source and destination pixel buffer. This allows us to
eliminate some duplication in the callers, and permits us to be more
flexible in checking for compatible formats.
(Hmm, is sRGB handling right?)
---
src/mesa/driver
We stream from a tiled and aligned source into an unaligned user buffer,
so we need to use _mm_storeu_si128.
---
src/mesa/drivers/dri/i965/intel_tiled_memcpy.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
b/src/mesa/
Daniel Stone writes:
> We had a go at using Jenkins for some of this: Intel's been really
> quite successful at doing it internally, but our community efforts
> have been a miserable failure. After a few years I've concluded that
> it's not going to change - even with Jenkins 2.0.
>
> Firstly, Jen
On Friday, May 25, 2018 4:33:56 PM PDT Chris Wilson wrote:
> We stream from a tiled and aligned source into an unaligned user buffer,
> so we need to use _mm_storeu_si128.
> ---
> src/mesa/drivers/dri/i965/intel_tiled_memcpy.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=98581
ros...@gmail.com changed:
What|Removed |Added
Resolution|WORKSFORME |FIXED
--- Comment #2 from ros...@gmail
On May 25, 2018 15:23:21 Matt Turner wrote:
On Thu, May 24, 2018 at 2:56 PM, Jason Ekstrand wrote:
From: Francisco Jerez
Presumably Jason already reviewed this and just missed attaching his R-b tag.
Some of these patches have somewhat confusing authorship. I didn't add my
R-b because I
I specifically tried forcing a rename earlier, but it doesn't work. Git
sees too much change. The only way I could get it to work was manually
renaming the HTML files to rst first, then committing, then converting to
rst.
The problem with that strategy is that then the Pandoc command for
convert
On May 25, 2018 15:24:53 Matt Turner wrote:
On Thu, May 24, 2018 at 2:56 PM, Jason Ekstrand wrote:
We want consistent behavior in the meaning of the flag_subreg field
between SNB and IVB+.
v2 (Jason Ekstrand):
- Add some extra commentary
Reviewed-by: Jason Ekstrand
Presumably you did not
On May 25, 2018 15:19:25 Matt Turner wrote:
On Thu, May 24, 2018 at 2:56 PM, Jason Ekstrand wrote:
From: Francisco Jerez
The hardware's control flow logic is 16-wide so we're out of luck
here. We could, in theory, support SIMD32 if we know the control-flow
is uniform but we don't have that
On May 25, 2018 15:28:22 Matt Turner wrote:
On Thu, May 24, 2018 at 2:56 PM, Jason Ekstrand wrote:
From: Francisco Jerez
---
src/intel/compiler/brw_shader.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_shader.cpp
b/src/intel/compiler/brw_sha
Jason Ekstrand writes:
> On May 25, 2018 15:19:25 Matt Turner wrote:
>
>> On Thu, May 24, 2018 at 2:56 PM, Jason Ekstrand wrote:
>>> From: Francisco Jerez
>>>
>>> The hardware's control flow logic is 16-wide so we're out of luck
>>> here. We could, in theory, support SIMD32 if we know the con
On Fri, May 25, 2018 at 4:47 PM, Mark Janes wrote:
> Daniel Stone writes:
> > GitLab CI fixes all of these things. Pipelines are strongly and
> > directly correlated with commits in repositories, though you can also
> > trigger them manually or on a schedule. Permissions are that of the
> > repo
On Thu, May 17, 2018 at 6:50 AM, Lucas Stach wrote:
> Each time I have to touch the buffer import/export functions in the dri
> state tracker I get lost in the maze of functions converting between
> DRI_IMAGE_FOURCC, DRI_IMAGE_FORMAT, DRI_IMAGE_COMPONENTS and pipe format.
>
> Rip it out and repla
From: Francisco Jerez
When we don't have PLN (gen4 and gen11+), we implement LINTERP as either
LINE+MAC or a pair of MADs. In both cases, the accumulator is written
by the first of the two instructions and read by the second. Even
though the accumulator value isn't actually ever used from a log
On g4x through Sandy Bridge, src1 (the coordinates) of the PLN
instruction is required to be an even register number. When it's odd
(which can happen with SIMD32), we have to emit a LINE+MAC combination
instead. Unfortunately, we can't just fall through to the gen4 case
because the input register
On Thu, May 24, 2018 at 6:46 AM, Daniel Stone wrote:
> Hi all,
> I'm going to attempt to interleave a bunch of replies here.
>
> On 23 May 2018 at 20:34, Jason Ekstrand wrote:
> > The freedesktop.org admins are trying to move as many projects and
> services
> > as possible over to gitlab and som
82 matches
Mail list logo
