ping!
On 11/27/18 12:53 PM, Tapani Pälli wrote:
Hi;
Series was rebased and fixes applied from review, also some changes
applied to support HAL_PIXEL_FORMAT_NV12_Y_TILED_INTEL. With these
changes android.graphics.cts.MediaVulkanGpuTest starts to pass, now
all tests utilizing AHardwareBuffer
https://bugs.freedesktop.org/show_bug.cgi?id=108742
coolo...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 12/10/18 5:52 PM, Timothy Arceri wrote:
> On 11/12/18 11:35 am, Ian Romanick wrote:
>> It seems like someone already sent out patches to implement this, and we
>> decided to not take it for some reason. Maybe it was Rob?
>
> I discovered a thread from the beginning of 2017 titled "feature.txt
On Mon, Dec 10, 2018 at 5:48 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> On Mon, Dec 10, 2018 at 04:56:40PM -0600, Jason Ekstrand wrote:
> > On Fri, Dec 7, 2018 at 6:06 PM Rafael Antognolli <
> rafael.antogno...@intel.com>
> > wrote:
> >
> > This commit tries to rework the
The following patches will add support for an addition
optimisation so this function will no longer just optimise varying
constants.
---
src/amd/vulkan/radv_pipeline.c| 4 ++--
src/compiler/nir/nir.h| 2 +-
src/compiler/nir/nir_linking_helpers.c| 2 +-
This will be reused by the following patch.
---
src/compiler/nir/nir_linking_helpers.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/src/compiler/nir/nir_linking_helpers.c
b/src/compiler/nir/nir_linking_helpers.c
index b447729c60..37644d339f 100644
---
This will help the new opt introduced in the following patches
allowing us to remove extra duplicate varyings.
---
src/gallium/drivers/radeonsi/si_shader_nir.c | 2 --
src/mesa/state_tracker/st_glsl_to_nir.cpp| 4 +++-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git
If we are outputting the same value to more than one output
component rewrite the inputs to read from a single component.
This will allow the duplicate varying components to be optimised
away by the existing opts.
shader-db results i965 (SKL):
total instructions in shared programs: 12869230 ->
On 11/12/18 11:35 am, Ian Romanick wrote:
It seems like someone already sent out patches to implement this, and we
decided to not take it for some reason. Maybe it was Rob?
I discovered a thread from the beginning of 2017 titled "feature.txt &
EXT_debug_label extension". But couldn't find
It seems like someone already sent out patches to implement this, and we
decided to not take it for some reason. Maybe it was Rob?
On 12/10/18 4:08 PM, Timothy Arceri wrote:
> KHR_debug already provides superior functionality but this
> extension is still in use and adding support for it seems
https://bugs.freedesktop.org/show_bug.cgi?id=109004
Vinson Lee changed:
What|Removed |Added
Keywords||bisected
--- Comment #1 from Vinson Lee
KHR_debug already provides superior functionality but this
extension is still in use and adding support for it seems fairly
harmless. For example it seems to be used by Unity as seen in the
Parkitect trace attached to Mesa bug #108919.
---
src/mapi/glapi/gen/gl_API.xml| 17 +
On Mon, Dec 10, 2018 at 04:56:40PM -0600, Jason Ekstrand wrote:
> On Fri, Dec 7, 2018 at 6:06 PM Rafael Antognolli
> wrote:
>
> This commit tries to rework the code that split and returns chunks back
> to the state pool, while still keeping the same logic.
>
> The original code
https://bugs.freedesktop.org/show_bug.cgi?id=108974
Kristian Høgsberg changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Meson 0.49.0 has been out for a couple of days now, and I'd like to make the
final call for autotools. My patch is so massive that it's a huge pain to send
to the list, the latest versions is here:
https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
Dylan
signature.asc
On Mon, Dec 10, 2018 at 2:12 PM Ian Romanick wrote:
>
> Reviewed-by: Ian Romanick
Thanks Ian. I went ahead and pushed this to appease the CI bots.
Kristian
> On 12/10/18 10:14 AM, Emil Velikov wrote:
> > From: "Kristian H. Kristensen"
> >
> > There's a few missing and convoluted bits:
> >
>
On Fri, Dec 7, 2018 at 6:06 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> This commit tries to rework the code that split and returns chunks back
> to the state pool, while still keeping the same logic.
>
> The original code would get a chunk larger than we need and split it
> into
https://bugs.freedesktop.org/show_bug.cgi?id=109002
Dylan Baker changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=108974
Dylan Baker changed:
What|Removed |Added
CC||clayton.a.cr...@intel.com
--- Comment #1
Acked-by: Dylan Baker
Quoting Juan A. Suarez Romero (2018-12-10 04:25:36)
> As 18.3 was published with some delay, let's extend 18.2 life for
> another extra release.
>
> CC: Andres Gomez
> CC: Dylan Baker
> CC: Emil Velikov
> ---
> docs/release-calendar.html | 8 +++-
> 1 file changed,
Reviewed-by: Ian Romanick
On 12/10/18 10:14 AM, Emil Velikov wrote:
> From: "Kristian H. Kristensen"
>
> There's a few missing and convoluted bits:
>
> - FramebufferTexture2DMultisampleEXT
> Missing sanity check, should be desktop="false"
>
> - RenderbufferStorageMultisampleEXT
> Missing
In GLES2 - if extensions are present, float and half-float textures can
be used for rendering. This change enables the svga driver to handle
rendering these types.
---
src/gallium/drivers/svga/svga_screen.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
On Mon, Dec 10, 2018 at 4:28 PM Nick Kreeger wrote:
>
> This change enables GLES2 chagnes to render
>
> This change enables GLES2 to render float/half-float textures to a
> framebuffer when the appropriate OES extensions are available.
>
> This commit regressed OES GLES2 float texture rendering:
This change enables GLES2 chagnes to render
This change enables GLES2 to render float/half-float textures to a
framebuffer when the appropriate OES extensions are available.
This commit regressed OES GLES2 float texture rendering:
The OES_texture* extensions for float and half-float are valid when
GLES2 is present w/ the matching
OES_texture_float/OES_texture_half_float extensions. This fix ensures
that these formats are valid for this configuration.
---
src/mesa/main/glformats.c | 11 ---
1 file changed, 8
https://bugs.freedesktop.org/show_bug.cgi?id=109004
Bug ID: 109004
Summary: blob.c:114: multiple definition of `blob_init'
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
On Fri, Dec 7, 2018 at 6:06 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> They won't be true anymore once we add support for multiple BOs with
> non-userptr.
>
Why not? I guess in the highly restricted case of state streams, you can
safely copy out-of-range of one BO because you
This seems very much over-the-top. It would be better to either find the
specific bug or else just allocate the BOs we use for states as snooped.
See also the anv_gem_set_caching call in genX_query.c.
On Fri, Dec 7, 2018 at 6:06 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> TODO:
On Fri, Dec 7, 2018 at 6:06 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> We now have multiple BOs in the block pool, but sometimes we still
> reference only the first one in some instructions, and use relative
> offsets in others. So we must be sure to add all the BOs from the
fixed
On Mon, Dec 10, 2018 at 12:58 PM Erik Faye-Lund <
erik.faye-l...@collabora.com> wrote:
> On Mon, 2018-12-10 at 11:04 -0600, Jason Ekstrand wrote:
> > The Vulkan working group recently discovered that we made a mistake
> > in
> > assuming that PCI domains are 16-bit even though they can
On Mon, Dec 10, 2018 at 12:45:00PM -0600, Jason Ekstrand wrote:
> On Fri, Dec 7, 2018 at 6:06 PM Rafael Antognolli
> wrote:
>
> We will need specially the anv_block_pool_map, to find the
> map relative to some BO that is not at the start of the block pool.
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=108594
--- Comment #3 from Ahmed Elsayed ---
I have the same bug with AMD HD 8750M.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev
On Mon, Dec 10, 2018 at 10:17 AM Emil Velikov wrote:
>
> From: "Kristian H. Kristensen"
>
> There's a few missing and convoluted bits:
>
> - FramebufferTexture2DMultisampleEXT
> Missing sanity check, should be desktop="false"
>
> - RenderbufferStorageMultisampleEXT
> Missing sanity check, is
On Mon, 2018-12-10 at 11:04 -0600, Jason Ekstrand wrote:
> The Vulkan working group recently discovered that we made a mistake
> in
> assuming that PCI domains are 16-bit even though they can potentially
> be
> 32-bit values. To fix this, the next spec update will chang the
chang -> change
>
On Mon, Dec 10, 2018 at 7:38 AM Emil Velikov wrote:
>
> On Fri, 7 Dec 2018 at 23:48, Kristian H. Kristensen
> wrote:
> >
> > ---
> > src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml | 2 +-
> > src/mapi/glapi/gen/es_EXT.xml | 2 ++
> >
On Mon, Dec 10, 2018 at 7:05 AM Erik Faye-Lund
wrote:
> When I made sure that half-float texture-filtering was required for ES3,
> I didn't realize that virgl doesn't report support for this correctly.
> This regressed the GLES version available on top of several drivers,
> including i965 from
On Fri, Dec 7, 2018 at 6:06 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> We will need specially the anv_block_pool_map, to find the
> map relative to some BO that is not at the start of the block pool.
> ---
> src/intel/vulkan/anv_allocator.c | 23 ---
>
On Sat, Dec 8, 2018 at 9:51 PM Sagar Ghuge wrote:
>
> When RepCtrl is set, the swizzle field is ignored by the hardware. In
> order to ensure a 1-to-1 correspondence between the human-readable
> disassembly and the binary instruction encoding always set the swizzle
> to (all zeros) when it
On Sat, Dec 8, 2018 at 11:08 PM Sagar Ghuge wrote:
>
> While disassembling the predicate always print flag subregister number
> to keep grammar same across the generation for assembler tool.
>
> v2: Club consecutive format calls (Matt Turner)
>
> Signed-off-by: Sagar Ghuge
Reviewed-by: Matt
https://bugs.freedesktop.org/show_bug.cgi?id=109002
Bug ID: 109002
Summary: [bisected] meson build test 'main-test' fails
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Previously, we ignored the the glUnmap(..) operation and
flushed before we flush the cbuf. Now, let's just flush
the data when we unmap.
Neither method is optimal, for example:
glMapBufferRange(.., 0, 100, GL_MAP_FLUSH_EXPLICIT_BIT)
glFlushMappedBufferRange(.., 25, 30)
From: "Kristian H. Kristensen"
There's a few missing and convoluted bits:
- FramebufferTexture2DMultisampleEXT
Missing sanity check, should be desktop="false"
- RenderbufferStorageMultisampleEXT
Missing sanity check, is aliased to RenderbufferStorageMultisample.
Thus it's set only when
On Mon, Dec 10, 2018 at 7:35 AM Elie Tournier
wrote:
> On Thu, Dec 06, 2018 at 05:20:42PM -0800, Gurchetan Singh wrote:
> > Previously, we ignored the the glUnmap(..) operation and
> > flushed before we flush the cbuf. Now, let's just flush
> > the data when we unmap.
> >
> > Neither method is
On Fri, Dec 7, 2018 at 6:06 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> The test was checking whether -1 was smaller than an unsigned int, which
> is always false. So it was exiting early and never running until the
> end, since it would reach the condition (thread_max == -1).
>
Quoting Dylan Baker (2018-12-10 09:13:59)
> Quoting Matt Turner (2018-12-08 12:49:06)
> > On Thu, Nov 22, 2018 at 1:05 PM Matt Turner wrote:
> > >
> > > On Wed, Nov 21, 2018 at 10:48 AM Matt Turner wrote:
> > > >
> > > > Thanks Arfrever and Dylan.
> > > >
> > > > Acked-by: Matt Turner
> > >
> >
Hi Erik,
Not sure if this is our problem as I think that I only saw simple
bindings with a zero instance divisor while debugging supertux kart.
But at least I think that this is a problem in virglrenderer. The
glVertexBindingDivisor is per binding and not per vertex attribute
in OpenGL.
... you
Quoting Matt Turner (2018-12-08 12:49:06)
> On Thu, Nov 22, 2018 at 1:05 PM Matt Turner wrote:
> >
> > On Wed, Nov 21, 2018 at 10:48 AM Matt Turner wrote:
> > >
> > > Thanks Arfrever and Dylan.
> > >
> > > Acked-by: Matt Turner
> >
> > Hmm, actually this doesn't seem to work for me. With it
Acked-by: Samuel Pitoiset
On 12/10/18 6:04 PM, Jason Ekstrand wrote:
The Vulkan working group recently discovered that we made a mistake in
assuming that PCI domains are 16-bit even though they can potentially be
32-bit values. To fix this, the next spec update will chang the types
in the
On 10/12/2018 17:04, Jason Ekstrand wrote:
The Vulkan working group recently discovered that we made a mistake in
assuming that PCI domains are 16-bit even though they can potentially be
32-bit values. To fix this, the next spec update will chang the types
in the VK_EXT_pci_bus_info struct to
The Vulkan working group recently discovered that we made a mistake in
assuming that PCI domains are 16-bit even though they can potentially be
32-bit values. To fix this, the next spec update will chang the types
in the VK_EXT_pci_bus_info struct to be 32 bits which will be a
On Mon, 10 Dec 2018 at 12:25, Juan A. Suarez Romero wrote:
>
> As 18.3 was published with some delay, let's extend 18.2 life for
> another extra release.
>
> CC: Andres Gomez
> CC: Dylan Baker
> CC: Emil Velikov
> ---
> docs/release-calendar.html | 8 +++-
> 1 file changed, 7
On Mon, Dec 10, 2018 at 6:21 AM Samuel Iglesias Gonsálvez
wrote:
>
> Hello Matt,
>
> On 07/12/2018 03:20, Matt Turner wrote:
> > Since this is for an extension that will be BDW+ can we use the
> > _cvtss_sh() intrinsic instead? It corresponds to an IVB+ instruction
> > and even takes the rounding
Trying to reduce the discussion to one e-mail thread and I picked this one.
:-)
TBH, I'm not sure what the right solution is. What I do know is that the
special cases are starting to get nuts. I see a three possible options:
1. Unify the current brw_fs_nir code. This could happen a couple of
On Mon, 10 Dec 2018 at 09:29, Samuel Pitoiset wrote:
>
> Acked-by: Samuel Pitoiset
>
Reviewed-by: Emil Velikov
and pushed to master.
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On 07/12/2018 03:03, Matt Turner wrote:
> On Wed, Dec 5, 2018 at 7:56 AM Samuel Iglesias Gonsálvez
> wrote:
>>
>> Signed-off-by: Samuel Iglesias Gonsálvez
>> ---
>> src/util/Makefile.sources | 2 +
>> src/util/double.c | 197 ++
>> src/util/double.h
I don't care too much when in the series it happens. Disallowing it
temporarily is probably fine.
On Mon, Dec 10, 2018 at 2:44 AM Iago Toral wrote:
> Yes, they are at the bottom of the series since I only worked on that more
> recently. I kept this here because at this point in the series we
On Fri, 7 Dec 2018 at 23:48, Kristian H. Kristensen wrote:
>
> ---
> src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml | 2 +-
> src/mapi/glapi/gen/es_EXT.xml | 2 ++
> src/mapi/glapi/gen/gl_API.xml | 2 --
>
On Thu, Dec 06, 2018 at 05:20:42PM -0800, Gurchetan Singh wrote:
> Previously, we ignored the the glUnmap(..) operation and
> flushed before we flush the cbuf. Now, let's just flush
> the data when we unmap.
>
> Neither method is optimal, for example:
>
> glMapBufferRange(.., 0, 100,
When I made sure that half-float texture-filtering was required for ES3,
I didn't realize that virgl doesn't report support for this correctly.
This regressed the GLES version available on top of several drivers,
including i965 from 3.2 to 2.0.
This is going to need protocol changes to fix
FWIW you can't rely on things being packed. With something like SSO,
or enhanced layouts, you can get some funky stuff.
On Mon, Dec 10, 2018 at 9:22 AM Rob Clark wrote:
>
> That is fine by me. I've come up with a workaround for now (just
> adding some dummy output components to handle the .x__w
That is fine by me. I've come up with a workaround for now (just
adding some dummy output components to handle the .x__w case) so at
least he .w varying doesn't get lost with that shader.
BR,
-R
On Sun, Dec 9, 2018 at 8:20 PM Timothy Arceri wrote:
>
> I'd much rather land the first 3 patches
Hello Matt,
On 07/12/2018 03:20, Matt Turner wrote:
> Since this is for an extension that will be BDW+ can we use the
> _cvtss_sh() intrinsic instead? It corresponds to an IVB+ instruction
> and even takes the rounding mode directly as an immediate argument.
>
If I understand currently this
On Mon, Dec 10, 2018 at 12:32 PM Emil Velikov wrote:
>
> Hi Karol,
>
> On Sat, 8 Dec 2018 at 17:10, Karol Herbst wrote:
> >
> > multiple threads can write to those at the same time
> >
> > Signed-off-by: Karol Herbst
> Should we pick and the other two fixes for stable?
>
> a28ff222951 nv50/ir:
On Mon, Dec 10, 2018 at 2:20 PM Samuel Iglesias Gonsálvez
wrote:
>
> On 05/12/2018 19:22, Connor Abbott wrote:
> > Why is this needed? In general, we shouldn't be relying on
> > optimization ordering for correctness. It probably just means one of
> > the optimizations is wrong, and you're working
On 05/12/2018 19:22, Connor Abbott wrote:
> Why is this needed? In general, we shouldn't be relying on
> optimization ordering for correctness. It probably just means one of
> the optimizations is wrong, and you're working around that.
There is an issue when the shader tries to generate a NaN
This is:
Reviewed-by: Andres Gomez
On Mon, 2018-12-10 at 13:25 +0100, Juan A. Suarez Romero wrote:
> As 18.3 was published with some delay, let's extend 18.2 life for
> another extra release.
>
> CC: Andres Gomez
> CC: Dylan Baker
> CC: Emil Velikov
> ---
> docs/release-calendar.html | 8
https://bugs.freedesktop.org/show_bug.cgi?id=108977
--- Comment #4 from Tapani Pälli ---
Hmm yep, I'm able to reproduce this after all.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
On 05/12/2018 19:35, Connor Abbott wrote:
> All the current lowerings produce their result using a floating-point
> multiply or add, so denorms should already be flushed (e.g.
> nir_op_frcp), or they never produce a denorm (e.g. nir_op_ftrunc), so
> I don't think this is necessary.
This fix is
As 18.3 was published with some delay, let's extend 18.2 life for
another extra release.
CC: Andres Gomez
CC: Dylan Baker
CC: Emil Velikov
---
docs/release-calendar.html | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/docs/release-calendar.html
On Mon, 2018-12-10 at 11:52 +, Haehnle, Nicolai wrote:
> On 10.12.18 12:36, Emil Velikov wrote:
> > Hi Nicolai,
> >
> > On Thu, 6 Dec 2018 at 13:49, Nicolai Hähnle wrote:
> > > From: Nicolai Hähnle
> > >
> > > Linking against LLVM built with BUILD_SHARED_LIBS fails otherwise,
> > > as the
On 10.12.18 12:36, Emil Velikov wrote:
> Hi Nicolai,
>
> On Thu, 6 Dec 2018 at 13:49, Nicolai Hähnle wrote:
>>
>> From: Nicolai Hähnle
>>
>> Linking against LLVM built with BUILD_SHARED_LIBS fails otherwise,
>> as the component is required for the draw module.
>
> I'd imagine we'd want this
On Tue, 2018-06-26 at 23:49 +0200, Fredrik Höglund wrote:
> These are not automatically performed during a render pass instance.
>
> Cc:
> Signed-off-by: Fredrik Höglund
A similar patch like this, 457ac6ce1e2 ("radv: ignore subpass self-
dependencies"), is on master, but without the @stable
Hi Nicolai,
On Thu, 6 Dec 2018 at 13:49, Nicolai Hähnle wrote:
>
> From: Nicolai Hähnle
>
> Linking against LLVM built with BUILD_SHARED_LIBS fails otherwise,
> as the component is required for the draw module.
I'd imagine we'd want this for stable, since the "native" module has
been used for
Hi Karol,
On Sat, 8 Dec 2018 at 17:10, Karol Herbst wrote:
>
> multiple threads can write to those at the same time
>
> Signed-off-by: Karol Herbst
Should we pick and the other two fixes for stable?
a28ff222951 nv50/ir: initialize relDegree staticly
d63a1330822 nouveau: use atomic operations
Calculating the scissor rectangle fields with the y flipped (0 on top)
can generate negative values that will cause assertion failure later on
as the scissor fields are all unsigned. We must clamp the bbox values
again to make sure they don't exceed the fb_height. Also fixed a
calculation error.
On 12/7/18 2:35 AM, Mark Janes wrote:
---
src/mesa/main/errors.c | 27 +++
src/mesa/main/errors.h | 8
2 files changed, 35 insertions(+)
diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index fad8cb59cae..995b0510575 100644
---
On 05/12/2018 19:35, Connor Abbott wrote:
> All the current lowerings produce their result using a floating-point
> multiply or add, so denorms should already be flushed (e.g.
> nir_op_frcp), or they never produce a denorm (e.g. nir_op_ftrunc), so
> I don't think this is necessary.
Right,
On 06/12/2018 08:40, apinheiro wrote:
>
> On 6/12/18 8:37, apinheiro wrote:
>> On 5/12/18 16:55, Samuel Iglesias Gonsálvez wrote:
>>> The remove_extra_rounding_modes() optimization will remove duplicated
>>> rounding mode changes.
>>>
>>> Signed-off-by: Samuel Iglesias Gonsálvez
>>> ---
>>>
On 05/12/2018 18:32, Connor Abbott wrote:
> Given that other places call nir_eval_const_opcode(), and they'll be
> broken unless they also flush denorms, it's probably a good idea to
> move all this into nir_eval_const_opcode() itself.
>
Thanks for the feedback. I will do this and fix the rest
https://bugs.freedesktop.org/show_bug.cgi?id=108977
--- Comment #3 from Matthieu Bouron ---
Using Mesa 18.2.6, the frame is black instead of garbled (0xff00 instead of
0xffff for all pixels).
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA
Acked-by: Samuel Pitoiset
On 12/10/18 6:21 AM, Rhys Kidd wrote:
Fixes: 3fbdcd942fe ("amd: remove support for LLVM 6.0")
Cc: Samuel Pitoiset
Cc: Marek Olšák
Cc: Emil Velikov
Cc: Jan Vesely
Cc: Andres Gomez
Cc: Dylan Baker
Signed-off-by: Rhys Kidd
---
.travis.yml | 29
On 12/8/18 7:03 PM, Rhys Perry wrote:
A small number of questions/concerns:
- sampleLocationCoordinateRange[1] should probably be set to 0.9375,
because of how the sample locations are encoded
That doesn't matter much but we can update it yeah.
- gl_SamplePosition doesn't seem like it
https://bugs.freedesktop.org/show_bug.cgi?id=108578
--- Comment #6 from Samuel Pitoiset ---
Yes, exactly.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=108977
--- Comment #2 from Tapani Pälli ---
FWIW I couldn't reproduce this with Haswell or Skylake machines (using mesa
19.0.0-devel).
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
On Fri, 2018-12-07 at 14:25 -0600, Jason Ekstrand wrote:
> On Tue, Dec 4, 2018 at 1:18 AM Iago Toral Quiroga
> wrote:
> > There are no 8-bit immediates, so assert in that case.
> >
> > 16-bit immediates are replicated in each word of a 32-bit
> > immediate, so
> >
> > we only need to check the
Sure, will do that.
On Fri, 2018-12-07 at 14:11 -0600, Jason Ekstrand wrote:
> 51 and 52 should probably be rolled together. For that matter, I
> don't think we need 6 patches just to add two SPIR-V capabilities and
> advertise one extension. Maybe roll the two SPIR-V patches together,
> add
Yes, I mentioned this in another of my replies. I think we probably
want a combination of these things. For some restrictions like the
cases where we need to split a conversion in two instructions going
through an intermediate type I think a NIR lowering would be good, but
then I think we might
On Fri, 2018-12-07 at 13:13 -0600, Jason Ekstrand wrote:
> On Tue, Dec 4, 2018 at 1:18 AM Iago Toral Quiroga
> wrote:
> > The implementation of these opcodes in the generator assumes that
> > their
> >
> > arguments are packed, and it generates register regions based on
> > that
> >
> >
Yes, they are at the bottom of the series since I only worked on that
more recently. I kept this here because at this point in the series we
need this, but I should be able to esily pull those patches here
instead and remove this one if that is preferred. I don't think they
depend on anything
On Fri, 2018-12-07 at 11:57 -0600, Jason Ekstrand wrote:
> On Tue, Dec 4, 2018 at 1:18 AM Iago Toral Quiroga
> wrote:
> > From the Skylake PRM, Extended Math Function:
> >
> >
> >
> > "The execution size must be no more than 8 when half-floats
> >
> >are used in source or destination
Yeah, maybe. I'll do that.
On Fri, 2018-12-07 at 11:31 -0600, Jason Ekstrand wrote:
> I think it's probably less code to just make a separate 16-bit case.
>
> On Tue, Dec 4, 2018 at 1:18 AM Iago Toral Quiroga
> wrote:
> > ---
> >
> > src/intel/compiler/brw_fs_nir.cpp | 27
Yes that might be a good thing to do. I mean, handling it in the
backend isn't too bad if it was only this, but we now have a lot of
conversion conversion cases and different kinds of restrictions on
different gens and things start getting a bit messy. If we can pull
some of these to NIR I think
92 matches
Mail list logo
