On Tue, Nov 6, 2018 at 2:31 PM Kristian H. Kristensen
wrote:
>
> In gallium, we model the attachment sample count as a new nr_samples
> field in pipe_surface. A driver can indicate support for the extension
> using the new pipe cap, PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE.
>
> Signed-off-by: Krist
On Tue, Nov 6, 2018 at 10:27 AM Gert Wollny wrote:
>
> Am Dienstag, den 06.11.2018, 09:29 -0500 schrieb Ilia Mirkin:
> > On Tue, Nov 6, 2018 at 5:59 AM Gert Wollny > > wrote:
> > >
> > >
> > > I'm not so sure that things break, at least we have a
On Tue, Nov 6, 2018 at 5:59 AM Gert Wollny wrote:
>
> Am Montag, den 05.11.2018, 11:17 -0500 schrieb Ilia Mirkin:
> > On Mon, Nov 5, 2018 at 11:02 AM Gert Wollny > m> wrote:
> > >
> > > Am Montag, den 05.11.2018, 08:56 -0500 schrieb Ilia Mirkin:
> > >
I doesn't need ES 3.0, just EXT_occlusion_query_boolean, which mesa
happens to support. Are there any drivers that support conditional
render but not ARB_occlusion_query? (I don't think that's really
possible given that the feature is basically designed for occlusion
queries...)
On Mon, Nov 5, 2018
On Mon, Nov 5, 2018 at 11:02 AM Gert Wollny wrote:
>
> Am Montag, den 05.11.2018, 08:56 -0500 schrieb Ilia Mirkin:
> > At the gallium level, it's a promise that some PIPE_FORMAT_*_SRGB is
> > supported for rendering and that you can use a non-srgb format in the
> >
On Mon, Nov 5, 2018 at 7:12 AM Gert Wollny wrote:
>
> Am Donnerstag, den 01.11.2018, 12:32 -0400 schrieb Ilia Mirkin:
> >
> >
> > EXT_framebuffer_sRGB is a desktop GL ext. EXT_sRGB_write_control is a
> > GLES ext that was meant to provide the same functionality in GL
On Thu, Nov 1, 2018 at 12:17 PM Gert Wollny wrote:
>
> Am Donnerstag, den 01.11.2018, 12:03 -0400 schrieb Ilia Mirkin:
> > On Thu, Nov 1, 2018 at 11:45 AM Gert Wollny > m> wrote:
> > >
> > > Am Donnerstag, den 01.11.2018, 11:19 -0400 schrieb Ilia Mirkin:
>
On Thu, Nov 1, 2018 at 11:45 AM Gert Wollny wrote:
>
> Am Donnerstag, den 01.11.2018, 11:19 -0400 schrieb Ilia Mirkin:
> > On Thu, Nov 1, 2018 at 10:41 AM Gert Wollny > m> wrote:
> > >
> > > Am Donnerstag, den 01.11.2018, 10:34 -0400 schrieb Ilia Mirkin:
>
On Thu, Nov 1, 2018 at 10:41 AM Gert Wollny wrote:
>
> Am Donnerstag, den 01.11.2018, 10:34 -0400 schrieb Ilia Mirkin:
> > On Thu, Nov 1, 2018 at 10:31 AM Gert Wollny > m> wrote:
> > >
> > > Am Donnerstag, den 01.11.2018, 10:15 -0400 schrieb Ilia Mirkin:
On Thu, Nov 1, 2018 at 10:31 AM Gert Wollny wrote:
>
> Am Donnerstag, den 01.11.2018, 10:15 -0400 schrieb Ilia Mirkin:
> > So ... thinking about this a little more ... how is the new enable
> > different from the existing "EXT_framebuffer_sRGB" enable? When would
>
So ... thinking about this a little more ... how is the new enable
different from the existing "EXT_framebuffer_sRGB" enable? When would
one be set but not the other?
On Thu, Nov 1, 2018 at 7:30 AM Gert Wollny wrote:
>
> From: Gert Wollny
>
> Dear all,
>
> yet another update, only to the Gallium
Reviewed-by: Ilia Mirkin
But one very very minor change, no need to re-send, just fix it up locally:
On Thu, Nov 1, 2018 at 8:00 AM Gert Wollny wrote:
>
> From: Gert Wollny
>
> This only adds support on the Gallium core level, for the drivers
> it is likely that additional cha
Reviewed-by: Ilia Mirkin
On Thu, Nov 1, 2018 at 8:00 AM Gert Wollny wrote:
>
> From: Gert Wollny
>
> This format is needed to support EXT_texture_sRGB_R8. THe patch adds a new
> format enum, the format entries in Gallium and and svga, the mapping between
> sRGB and linear
Reviewed-by: Ilia Mirkin
On Thu, Nov 1, 2018 at 8:00 AM Gert Wollny wrote:
>
> From: Gert Wollny
>
> v2: - fix format definition line
> - disable for desktop GL
> - don't add GL_R8_EXT to glext.h since it is already in
> GLES2/gl2ext.h in glext.h and
On Fri, Oct 26, 2018 at 1:24 PM Dylan Baker wrote:
>
> This is bad for a couple of reasons, but the worst is that it gets the
> shell involved. When the shell gets involved we can start running into
> problems with LANG, namely LANG=C. This is particularly obnoxious for
> translation files, since
On Wed, Oct 31, 2018 at 12:37 PM Erik Faye-Lund
wrote:
>
> On Wed, 2018-10-31 at 12:01 -0400, Ilia Mirkin wrote:
> > I had to do a double (or triple) take on this logic as well. Part of
> > the subtlety is that the fallback only applies for ES when there's a
> > match
I had to do a double (or triple) take on this logic as well. Part of
the subtlety is that the fallback only applies for ES when there's a
match but no exact match. Probably good to mention this.
On Wed, Oct 31, 2018 at 11:13 AM Erik Faye-Lund
wrote:
>
> On Wed, 2018-10-31 at 15:46 +0200, Tapani Pä
;>
>>
>> dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_unsupported_enum
>>
>> when extension is manually disabled via MESA_EXTENSION_OVERRIDE
>>
>> v2: - always enable the extension when sRGB is supported (Ilia Mirkin).
>> - Correct
On Tue, Oct 30, 2018 at 7:59 AM Erik Faye-Lund
wrote:
>
> On Tue, 2018-10-30 at 07:44 -0400, Ilia Mirkin wrote:
> > On Thu, Oct 25, 2018 at 6:59 AM Erik Faye-Lund
> > wrote:
> > >
> > > From: Marek Olšák
> > >
> > > The spec was modified
On Thu, Oct 25, 2018 at 6:59 AM Erik Faye-Lund
wrote:
>
> From: Marek Olšák
>
> The spec was modified to support GLES.
>
> Tested-by: Erik Faye-Lund
> ---
> This replaces this patch:
> https://patchwork.freedesktop.org/patch/257423/
>
> docs/relnotes/18.3.0.html| 1 +
> src/mesa/main/e
Aaaactually, just noticed this in 3/4 but it's here as well:
On Tue, Oct 30, 2018 at 7:03 AM Ilia Mirkin wrote:
>
> Reviewed-by: Ilia Mirkin
> On Tue, Oct 30, 2018 at 6:46 AM Gert Wollny wrote:
> >
> > v2: - fix format definition line
> > - disable fo
Reviewed-by: Ilia Mirkin
On Tue, Oct 30, 2018 at 6:46 AM Gert Wollny wrote:
>
> v2: - fix format definition line
> - disable for desktop GL
> - don't add GL_R8_EXT to glext.h since it is already in
> GLES2/gl2ext.h in glext.h and include this header where need
definitions and table entries
> and only add correct the location of PIPE_FORMAT_R8_SRGB in the
> format_conversion_table (Ilia Mirkin)
> - Split patch (1/2) to separate Gallium part and mesa/st part.
> (Roland Scheidegger)
> - Trim the commit messag
Reviewed-by: Ilia Mirkin
I suspect this was to take advantage of the 32-bit addressing modes
available on Fermi. No code was ever written for this though (or if it
was, it's now long-deleted).
On Mon, Oct 29, 2018 at 1:16 PM Eric Engestrom wrote:
>
> Signed-off-by: Eric Engestrom
&
Is this legal in C++98? I don't think we require C++11 mesa-wide, at
least not yet...
On Mon, Oct 29, 2018 at 1:16 PM Eric Engestrom wrote:
>
> Signed-off-by: Eric Engestrom
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir.cpp| 3 +--
> src/gallium/drivers/nouveau/codegen/nv50_ir_targ
On Mon, Oct 29, 2018 at 3:41 AM Gert Wollny wrote:
>
> This only adds support on the Gallium core level, for the drivers
> it is likely that additional changes are needed to support the
> new texture format.
>
> Enables on softpipe and makes pass:
> dEQP-GLES31.functional.srgb_texture_decode.ski
On Mon, Oct 29, 2018 at 3:39 AM Gert Wollny wrote:
>
> EXT_texture_sRGB_R8 adds a GLES sRGB texture format with only one channel.
>
> v2: - fix format definition line
> - disable for desktop GL
> - don't add GL_R8_EXT to glext.h since it is already in
> GLES2/gl2ext.h in glext.h and
Please confirm that this passes the piglit tests you sent to the list
when run with ES2 forced, i.e. not ES3.
(MESA_GLES_VERSION_OVERRIDE=2.0 iirc.) I'm concerned that the extra
logic was only added to _mesa_es3_error_check_bla and not the es2
paths.
On Thu, Oct 25, 2018 at 6:59 AM Erik Faye-Lund
On Mon, Oct 22, 2018 at 6:16 PM Jason Ekstrand wrote:
>
> This should be useful for drivers that don't support real integers.
>
> Cc: Alyssa Rosenzweig
> ---
> src/compiler/Makefile.sources | 1 +
> src/compiler/nir/meson.build | 1 +
> src/compiler/nir/nir_lower_b
On Fri, Oct 19, 2018 at 12:45 PM Gert Wollny wrote:
>
> Am Freitag, den 19.10.2018, 08:25 -0400 schrieb Ilia Mirkin:
> > I don't think a PIPE_CAP is the answer here... I think you're on the
> > right track with format checks and whatnot.
>
> The problem is that w
h "MESA_GLES_VERSION_OVERRIDE=3.2" (the tests needlessly check for
> > this), and
> >
> > dEQP-
> > GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_unsupported
> > _enum
> >
> > when extension is manually disabled via MESA_EXTENSION_OVERRIDE
> >
> > v2: - always enable
On Fri, Oct 19, 2018 at 6:32 AM Gert Wollny wrote:
>
> Am Donnerstag, den 06.09.2018, 22:36 -0400 schrieb Ilia Mirkin:
> > Not handling caps explicitly means that we're likely getting
> > incorrect values -- these need to be reviewed and set appropriately.
> >
>
On Thu, Oct 18, 2018 at 2:26 PM Erik Faye-Lund
wrote:
> On Oct 18, 2018 18:21, Ilia Mirkin wrote:
>
> Have you verified that this works OK on GLES2? This extension enables
> online compression, which isn't normally available in GLES, and I
> wouldn't be surprised if
Have you verified that this works OK on GLES2? This extension enables
online compression, which isn't normally available in GLES, and I
wouldn't be surprised if the current mesa TexImage handlers prevent
it.
-ilia
On Thu, Oct 18, 2018 at 11:05 AM Erik Faye-Lund
wrote:
>
> The extension is writt
On Wed, Oct 17, 2018 at 12:49 PM Ilia Mirkin wrote:
> On Wed, Oct 17, 2018 at 12:38 PM Gert Wollny wrote:
> > diff --git a/src/mesa/main/extensions_table.h
> > b/src/mesa/main/extensions_table.h
> > index 09bf923bd0..1185156f23 100644
> > --- a/src/mesa/main/exten
On Wed, Oct 17, 2018 at 12:39 PM Gert Wollny wrote:
>
> From: Gert Wollny
>
> With this patch the extension EXT_sRGB_write_control is enabled for
> gallium drivers that support sRGB formats as render targets.
>
> Tested (and pass) on r600(evergreen) and softpipe:
>
> dEQP-GLES31.functional.fbo.
Reviewed-by: Ilia Mirkin
On Wed, Oct 17, 2018 at 12:51 PM Neil Roberts wrote:
>
> Some of the .dir-locals.el had the wrong name for the truthy value so
> it wasn’t setting indent-tabs-mode.
> ---
> src/gallium/drivers/freedreno/.dir-locals.el | 2 +-
> src/gallium/drivers/r
On Wed, Oct 17, 2018 at 12:45 PM Neil Roberts wrote:
>
> Ilia Mirkin writes:
>
> > Are you sure? It works fine for me... I'm not against fixing it to be
> > "t", but the current contents definitely worked fine for me. (As I
> > recall, I may be the o
On Wed, Oct 17, 2018 at 12:38 PM Gert Wollny wrote:
>
> From: Gert Wollny
>
> This GLES extension gives the applications the control over deciding whether
> the conversion from linear space to sRGB is necessary by enabling or
> disabling this conversion at framebuffer write or blending time just
Are you sure? It works fine for me... I'm not against fixing it to be
"t", but the current contents definitely worked fine for me. (As I
recall, I may be the one who checked this file in.)
On Wed, Oct 17, 2018 at 11:38 AM Neil Roberts wrote:
>
> The .dir-locals.el had the wrong name for the truthy
Reviewed-by: Ilia Mirkin
On Wed, Oct 10, 2018 at 3:12 PM wrote:
>
> From: Boyuan Zhang
>
> vlVaGetImage should respect the width, height, and coordinates x and y that
> passed in. Therefore, pipe_box should be created with the passed in values
> instead of surface width/h
On Tue, Oct 9, 2018 at 4:32 PM wrote:
>
> From: Boyuan Zhang
>
> vlVaGetImage should respect the width, height, and coordinates x and y that
> passed in. Therefore, pipe_box should be created with the passed in values
> instead of surface width/height.
>
> v2: add input size check, return error w
On Tue, Oct 9, 2018 at 4:03 PM wrote:
>
> From: Boyuan Zhang
>
> vlVaGetImage should respect the width, height, and coordinates x and y that
> passed in. Therefore, pipe_box should be created with the passed in values
> instead of surface width/height.
>
> v2: add input size check, return error w
On Tue, Oct 9, 2018 at 3:09 PM Boyuan Zhang wrote:
>
> Thanks for the explanation ilia.
>
> I'm curious too here that if it's legal for player to not respect the
> image size when calling vlVaGetImage. If player already know the size of
> image is 100x100, then why should it still call vlVaGetImag
On Tue, Oct 9, 2018 at 1:59 PM Boyuan Zhang wrote:
>
> Hi ilia,
>
> I saw the function
> u_box_clip_2d(https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/auxiliary/util/u_box.h#n74).
>
> But I still don't quite understand why we need to do this? Or say, what
> will happen if we don't do this
single component blits wouldn't work.
>
> Reviewed-by: Karol Herbst
>
> On Tue, Oct 9, 2018 at 1:03 PM Ilia Mirkin wrote:
> >
> > Ones that blit to srgb, yes. Couldn't get those to work with the 2d
> engine.
> >
> > On Tue, Oct 9, 2018, 04:46 Karol He
Ones that blit to srgb, yes. Couldn't get those to work with the 2d engine.
On Tue, Oct 9, 2018, 04:46 Karol Herbst wrote:
> but this movs all single color blits to the 3d blitter, right?
> On Sun, Oct 7, 2018 at 11:50 PM Ilia Mirkin wrote:
> >
> > For some reason the
On Wed, Sep 26, 2018 at 3:30 AM Gert Wollny wrote:
>
> Am Dienstag, den 25.09.2018, 10:20 -0400 schrieb Ilia Mirkin:
> > I haven't double-checked yet, but doesn't this result in a reduction
> > of functionality for pre-independent-blend GPUs (like the early
I have a recollection of wanting to do something similar in the past.
However I also have a record of the test passing before (circa 2015).
OTOH we do things differently on GM107+, so ... who knows. My guess is
that it was the splitting out of is_user_buffer changed how the code
behaved somehow - p
See my feedback from your earlier submission for how to make this work
on more than triangles. Seems easy enough to just do it.
https://patchwork.freedesktop.org/patch/250192/
On Mon, Oct 8, 2018 at 12:07 AM Jonathan Marek wrote:
>
> a20x can only draw 65535 vertices at once. this fix only applie
For some reason the 2d engine can't handle this. Red formats get special
treatment there, so perhaps related.
Fixes dEQP-GLES3 tests of the form:
dEQP-GLES3.functional.fbo.blit.conversion.r{8,16f,32f}_to_srgb8_alpha8
Signed-off-by: Ilia Mirkin
Cc: mesa-sta...@lists.freedesktop.org
---
The current state tracker can generate these sometimes. Fixing this is
more involved, and due to some integer math we can generate
divisions-by-zero.
Signed-off-by: Ilia Mirkin
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/nv50/nv50_surface.c | 7 +++
src/gallium
don't blend, there's no harm in the fact that the
"A" component gets written anyways.
Fixes, among others:
https://www.khronos.org/registry/webgl/sdk/tests/conformance2/textures/canvas/tex-2d-rgb8ui-rgb_integer-unsigned_byte.html
Signed-off-by: Ilia Mirkin
Cc: mesa-sta...@l
There's a WebGL test here
https://www.khronos.org/registry/webgl/sdk/tests/conformance2/rendering/blitframebuffer-size-overflow.html
which does a fairly ridiculous blit:
srcX0=-1, srcY0=-1, srcX1=2147483647, srcY1=2147483647,
dstX0=-1, dstY0=-1, dstX1=2147483647, dstY1=2147483647
The un
On Sat, Oct 6, 2018 at 1:24 AM Ilia Mirkin wrote:
>
> This happens in situations where we might do
>
> vec.wzyx[i] = ...
>
> The swizzle would get effectively ignored because of the interaction
> between how ir_assignment->set_lhs works and overwriting the write_mask.
&g
ask-indexing.shader_test
Signed-off-by: Ilia Mirkin
Cc: mesa-sta...@lists.freedesktop.org
---
v1 -> v2:
- include info about piglit tests
- add a fix for the nonconst case -- doing set_lhs last instead of
first.
Ian Romanick reviewed v1, but given the subtlety of the additional
change for v2, going to
On Fri, Oct 5, 2018 at 12:55 PM Ian Romanick wrote:
>
> On 10/04/2018 11:25 PM, Ilia Mirkin wrote:
> > This happens in situations where we might do
> >
> > vec.wzyx[i] = ...
>
> Ouch.
>
> I haven't looked on the piglit list yet, but is there a pigl
This is an improvement, but I think you need to clip the box to
1. Size of the surface
2. Size of the image
I think that there are clipping helpers available to do that (maybe
pipe_box_clip or so? I forget, check the auxiliary dir). Christian -
does that make sense to you?
Cheers,
-ilia
On Fr
sts/conformance2/glsl3/vector-dynamic-indexing-swizzled-lvalue.html
Signed-off-by: Ilia Mirkin
Cc: mesa-sta...@lists.freedesktop.org
---
src/compiler/glsl/lower_vector_derefs.cpp | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/compiler/glsl/lower_vector_derefs.cpp
On Wed, Oct 3, 2018 at 10:59 AM Koenig, Christian
wrote:
>
> Am 03.10.2018 um 16:56 schrieb Ilia Mirkin:
> > On Wed, Oct 3, 2018 at 9:36 AM Christian König
> > wrote:
> >> What the heck are you talking about? As far as I can see this patch is
> >> a
On Wed, Oct 3, 2018 at 9:36 AM Christian König
wrote:
>
> What the heck are you talking about? As far as I can see this patch is
> about adding hw specific alignment to vlVaCreateImage which is a state
> tracker function.
>
> Completely agree that vlVaGetImage should respect the parameters given
>
vlVaGetImage should respect the x/y/width/height. The surface size
need not have any correlation to the image size. Someone should
double-check the docs for how that function should work, but the
current logic seems completely bogus.
On Tue, Oct 2, 2018 at 3:09 PM Koenig, Christian
wrote:
>
> Well
Shouldn't it be possible to use the x11 platform (+drisw)?
On Mon, Oct 1, 2018 at 3:43 PM Dylan Baker wrote:
>
> Currently mesa only supports EGL for KMS (Linux, *BSD) systems and
> Haiku, we should actually enforce this. This fixes the default build on
> MacOS.
> ---
>
> meson.build | 7 ++-
copy use surface width=48. Which is giving a wrong
> stride for dst buffer.
>
> Thanks,
> Suresh G
>
> Get Outlook for Android
>
> ____
> From: Ilia Mirkin
> Sent: Tuesday, October 2, 2018 7:53:09 AM
> To: Sharma, Deepak
> Cc: ML Mesa
Mon, Oct 1, 2018 at 10:17 PM Sharma, Deepak wrote:
>
> 16 was considering UVD.
>
> in vlVagetImage, the width,height passed to function is not used but rather
> the surface width/height and that causes issue in this case,not sure how
> driver will handle that ?
>
> ___
On Mon, Oct 1, 2018 at 9:47 PM Sharma, Deepak wrote:
>
> From: suresh guttula
>
> In case of decoding of resolution like 40x24, while allocating surface
> video buffer is always aligned with macroblock width/height which is 16.
> But when application tries to get data after decoding through vaCre
On Tue, Sep 25, 2018 at 6:54 PM, Kenneth Graunke wrote:
> On Wednesday, September 26, 2018 12:48:13 AM CEST Kenneth Graunke wrote:
>> On Tuesday, September 25, 2018 4:20:04 PM CEST Ilia Mirkin wrote:
>> > I haven't double-checked yet, but doesn't this result in a red
I haven't double-checked yet, but doesn't this result in a reduction
of functionality for pre-independent-blend GPUs (like the early NVIDIA
Tesla series)? Configuring blending for an integer RT does nothing on
NVIDIA hardware, so it all works out there just fine...
Perhaps both patches should just
Reviewed-by: Ilia Mirkin
On Sun, Sep 23, 2018 at 12:59 PM, Rhys Perry wrote:
> Seems this fixes linking problems that occur in some situations.
>
> Signed-off-by: Rhys Perry
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
> 1 file changed,
gt; + Value *tmp = bld.mkCmp(OP_SET, CC_GT, TYPE_U32, bld.getSSA(),
> TYPE_U32, samples, bld.mkImm(2))->getDef(0);
> + return bld.mkOp2v(OP_AND, TYPE_U32, bld.getSSA(), tmp, bld.mkImm(1));
I'd prefer OP_NEG here (with a TYPE_S32). That will allow the modifier
to get embedded
Reviewed-by: Ilia Mirkin
On Thu, Sep 20, 2018 at 1:44 PM, Rhys Perry wrote:
> Signed-off-by: Rhys Perry
> ---
> src/gallium/drivers/nouveau/nvc0/nvc0_context.h | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nvc0/n
Reviewed-by: Ilia Mirkin
On Thu, Sep 20, 2018 at 1:10 PM, Rhys Perry wrote:
> Fixes: 66ca7e400b8 ('nvc0: add support for programmable sample locations')
> Signed-off-by: Rhys Perry
> ---
> .../drivers/nouveau/nvc0/nvc0_query_hw_sm.c | 36 +--
> 1 fi
Based on the various fixes, warning seems bogus -- is the proper
solution -Wno-class-memaccess? (Or however one disables such
things...)
On Fri, Sep 21, 2018 at 9:50 AM, Eric Engestrom
wrote:
> Signed-off-by: Eric Engestrom
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir.cpp| 2 +-
>
On Wed, Sep 19, 2018 at 7:04 AM, Jakob Bornecrantz wrote:
> This patch regresses about 3000 dEQP [2,3,3.1] tests on virgl. Full
> setup is dEQP running on virgl with vtest that is running RadeonSI. So
> QEMU is not in the picture. All instances of the Mesa driver is from
> the same tree and have t
On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker wrote:
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about deleting the autotools build. So, is
> there
> anything left that autotools can do that meson cannot (that we actually want
g
generous, making a shared helper that can be used in both places.
Cheers,
-ilia
On Mon, Sep 17, 2018 at 3:36 PM, Ilia Mirkin wrote:
> On Mon, Sep 17, 2018 at 2:22 PM, Jonathan Marek wrote:
>> a20x can only draw 65535 vertices at once. this fix only applies to
>> trian
On Mon, Sep 17, 2018 at 2:22 PM, Jonathan Marek wrote:
> a20x can only draw 65535 vertices at once. this fix only applies to
> triangles.
>
> Signed-off-by: Jonathan Marek
> ---
> src/gallium/drivers/freedreno/a2xx/fd2_draw.c | 30 +--
> 1 file changed, 28 insertions(+), 2 deleti
On Mon, Sep 17, 2018 at 11:00 AM, Rhys Perry wrote:
> NVC0_CB_AUX_BINDLESS_INFO isn't written to on Maxwell+ and it's too small
> anyway.
>
> With these changes, TXQ is used to determine the number of samples and
> the coordinate adjustment information looked up in a small array in the
> driver co
On Wed, Sep 12, 2018 at 11:30 AM, Danylo Piliaiev
wrote:
> Hi,
>
> Thank you for the directions!
>
> On 9/12/18 6:13 PM, Jason Ekstrand wrote:
>
> Danylo,
>
> You're free to implement anything not already implemented. Here are some
> other (probably simpler) extensions that I think can be reasona
On Mon, Sep 10, 2018 at 4:27 PM, Leo Liu wrote:
> v2: Tell B10G10R10X2 and R10G10B10X2 formats for different HW.
>
> Signed-off-by: Leo Liu
> ---
> src/gallium/auxiliary/vl/vl_winsys.h | 5 ++
> src/gallium/auxiliary/vl/vl_winsys_dri.c | 69
> 2 files changed, 64 in
On Mon, Sep 10, 2018 at 12:03 PM, Samuel Pitoiset
wrote:
> Noticed while working in this area. Ported from RadeonSI.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_pipeline.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_pipelin
On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy wrote:
> Tests showed Intel on windows does always clamp
> RCP, RSQ and LOG (thus preventing inf/nan generation),
> for all shader versions (some vendor behaviours vary
> with shader versions).
By the way, this happens because on Intel, the ALU is put int
On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy wrote:
> For now clamp for all drivers. An ulterior optimization
> would be to avoid clamping for drivers with MUL_ZERO_WINS
> for the specific shader versions where NV or AMD don't
> clamp.
Too bad. The whole point of this feature was for nine to use it.
On Fri, Sep 7, 2018 at 12:35 PM, Józef Kucia wrote:
> On Fri, Sep 7, 2018 at 4:42 PM Danylo Piliaiev
> wrote:
>
>> @@ -1546,8 +1548,8 @@ update_image_surface(struct brw_context *brw,
>> .format = format,
>> .base_level = obj->MinLevel + u->Level,
>> .levels
FWIW, this looks right.
Reviewed-by: Ilia Mirkin
On Fri, Sep 7, 2018 at 11:39 AM, Danylo Piliaiev
wrote:
> Comment for array_len field states:
> "Indicates the number of array elements starting at
>Base Array Layer."
>
> And most usages of array_len expect it
On Fri, Sep 7, 2018 at 11:09 AM, Danylo Piliaiev
wrote:
>
> On 9/7/18 5:48 PM, Ilia Mirkin wrote:
>>
>> On Fri, Sep 7, 2018 at 10:41 AM, Danylo Piliaiev
>> wrote:
>>>
>>> Comment for array_len field states:
>>> "Indicates the numbe
On Fri, Sep 7, 2018 at 10:59 AM, Lionel Landwerlin
wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107856
> Signed-off-by: Lionel Landwerlin
> ---
> src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/s
On Fri, Sep 7, 2018 at 10:41 AM, Danylo Piliaiev
wrote:
> Comment for array_len field states:
> "Indicates the number of array elements starting at
>Base Array Layer."
>
> And most usages of array_len expect it to be equal or less than
> total layers - base layer
>
> Fixes: 5a8c8903
> Bugzil
Not handling caps explicitly means that we're likely getting incorrect
values -- these need to be reviewed and set appropriately.
While we're at it, add in some missing caps, and set all the subpixel
stuff to 8 as that seems to be what the blob reports.
Signed-off-by: Ilia Mirkin
On Wed, Sep 5, 2018 at 1:04 PM, Elie Tournier wrote:
> This patch fixes the following Piglit test:
> spec@egl_mesa_configless_context@basic
> It also fixes few test in a virgl guest.
>
> Suggested-by: Emil Velikov
> Signed-off-by: Elie Tournier
> ---
> I cc'ed some Gallium driver people.
> Can y
This passes the handful of tests in piglit.
Signed-off-by: Ilia Mirkin
---
... once the gl_TexCoord lowering fix is in, but that affects everyone
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nvc0
With compat creeping up to geometry and tess shaders, lowering texcoord
accesses/writes becomes more complicated. Since it's an optimization
anyways, just avoid the complication for now.
Signed-off-by: Ilia Mirkin
---
src/compiler/glsl/opt_dead_builtin_varyings.cpp | 6 ++
1 file chang
You have to make sure to flip blend->independent_blend_enable to 1 in
that case, and that will only work on some (well, most, but not all)
hardware. Pre-something Tesla-era and I assume r600-era gpu's must
have all rt's configured the same way.
I'm also not 100% sure that it's OK to access the dra
On Fri, Aug 24, 2018 at 9:39 PM, Nanley Chery wrote:
> On Fri, Aug 24, 2018 at 09:17:03PM -0400, Ilia Mirkin wrote:
>> On Fri, Aug 24, 2018 at 8:46 PM, Nanley Chery wrote:
>> > According to internal docs, some gen9 platforms have a pixel shader push
>> > constant sync
On Fri, Aug 24, 2018 at 8:46 PM, Nanley Chery wrote:
> According to internal docs, some gen9 platforms have a pixel shader push
> constant synchronization issue. Although not listed among said
> platforms, this issue seems to be present on the GeminiLake 2x6's we've
> tested.
>
> We consider the a
This breaks the build for me. It selects python3 instead of python2,
and gen_xmlpool.py bails out when trying to print \xf3 to stdout with
a LANG=C locale. Revert until scripts are fixed and try again?
On Thu, Aug 23, 2018 at 10:34 AM, Emil Velikov wrote:
> From: Emil Velikov
>
> Pretty much all
Withdrawn. This doesn't actually work. Will follow up with something that does.
On Thu, Aug 23, 2018 at 11:08 PM, Ilia Mirkin wrote:
> With LANG=C, print won't output any non-ascii characters. Since we're
> trying to get specific bytes onto stdout, we can just write these
&
With LANG=C, print won't output any non-ascii characters. Since we're
trying to get specific bytes onto stdout, we can just write these
directly.
Signed-off-by: Ilia Mirkin
---
src/util/xmlpool/gen_xmlpool.py | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
di
I admit to always being confused by depth, but:
On Wed, Aug 22, 2018, 16:23 Sagar Ghuge wrote:
> Gen >= 9 have ability to control clamping of depth values separately at
> near and far plane.
>
> z_w is clamped to the range [min(n,f), 0] if clamping at near plane is
> enabled, [0, max(n,f)] if cl
t; Marek
>
> On Wed, Aug 8, 2018 at 12:00 PM, Ilia Mirkin wrote:
>> Sorry, I thought I was answering your question.
>>
>> If glTexBufferEXT is aliased to glTexBuffer (/glTexBufferARB), which
>> are already in the list of dispatch functions, you should not add the
>
301 - 400 of 5930 matches
Mail list logo
