Hi Jordan,
https://cgit.freedesktop.org/piglit
This still displays the "master" branch by default. I think you're
supposed to change ... something ... in the repo, which indicates
which is the default branch.
Cheers,
-ilia
On Mon, Mar 29, 2021 at 8:31 PM Jordan Justen wrote:
>
> On
Probably nv30 would do well to "move on" as well. But it also presents
an interesting question -- the nv30 driver has lots of problems. I
have no plans to fix them, nor am I aware of anyone else with such
plans. However if such a developer were to turn up, would it be
reasonable to assume that
On Wed, Mar 10, 2021 at 3:39 PM Dylan Baker wrote:
> 0464117ad9 ci: remove nouveau from shader-db runs
Hey Dylan,
You're going to have a bad time if you don't backport this, as CI will
hang instead of completing. The "fix" for the hanging introduced
practical issues at runtime, and I figured it
t
> enabled in order to successfully write the gl_Layer output. If anything, this
> should be beneficial to those nvidia chipsets based on your description since
> previously the fragment shader would've had nothing to read.
>
>
> Mike
>
> On Mon, Dec 14, 2020 a
Hey Mike,
This is in reference to your change
https://cgit.freedesktop.org/mesa/mesa/commit/?id=614c2ac2f48955537efcfefaf0609d6c03e5
.
A fragment shader should still be able to read gl_Layer even without
PIPE_CAP_TGSI_VS_LAYER_VIEWPORT. A frag shader can read gl_Layer any
time
>
> I'm not sure how to properly fix it though... any ideas would be
> appreciated.
>
> Thanks,
>
> Thong Thai
>
> On 2020-11-30 10:52 a.m., Liu, Leo wrote:
> > +Thong.
> >
> > -Original Message-
> > From: mesa-dev On Behalf Of Ilia
> >
Hi Thong,
In this change:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=49465babdb35d88ed8a283e925d6cd346255d50c
You appear to change the height of the underlying resource while doing
a blit. This is never legal though -- the height of the resource is
effectively immutable (and subject to
On Thu, Apr 23, 2020 at 12:39 AM Dylan Baker wrote:
>
> Quoting Ilia Mirkin (2020-04-22 15:47:59)
> > On Wed, Apr 22, 2020 at 6:39 PM Danylo Piliaiev
> > wrote:
> > > I'm sorry for this trouble. However looking at it I think: maybe
> > > something could be
On Wed, Apr 22, 2020 at 6:39 PM Danylo Piliaiev
wrote:
> I'm sorry for this trouble. However looking at it I think: maybe something
> could be
> changed about applying patches to stable to safeguard against such issues.
We used to get pre-announcements a few days prior to a release which
would
On Wed, Apr 1, 2020 at 2:39 PM Erik Faye-Lund
wrote:
>
> While working on the NIR to DXIL conversion code for D3D12, I've
> noticed that we're not exactly doing the best we could here.
>
> First some background:
>
> NIR currently has a few instructions that does kinda the same:
>
> 1.
The bitmask is _EffEnabledNonZeroDivisor, so no need to invert it before
returning.
Fixes: fd6636ebc06d (st/mesa: simplify determination whether a draw needs
min/max index)
Signed-off-by: Ilia Mirkin
---
I haven't done any extensive testing on this, but it does seem to fix a
regression on nv50
On Mon, Feb 24, 2020 at 6:56 PM Ilia Mirkin wrote:
>
> On Sun, Feb 23, 2020 at 8:57 PM Ilia Mirkin wrote:
> >
> > ---
> >
> > We talked about something like this a while back, but the end result
> > was inconclusive. I added a TGSI MUL_ZERO_WINS shader pro
On Sun, Feb 23, 2020 at 8:57 PM Ilia Mirkin wrote:
>
> ---
>
> We talked about something like this a while back, but the end result
> was inconclusive. I added a TGSI MUL_ZERO_WINS shader property for nine.
> But it'd be nice for wine to be able to control this too.
>
>
On Mon, Feb 24, 2020 at 1:10 PM Ian Romanick wrote:
>
> On 2/23/20 5:57 PM, Ilia Mirkin wrote:
> > ---
> >
> > We talked about something like this a while back, but the end result
> > was inconclusive. I added a TGSI MUL_ZERO_WINS shader property for nine.
> >
000..cb274f06571
--- /dev/null
+++ b/docs/specs/MESA_ieee_fp_alu_mode.spec
@@ -0,0 +1,136 @@
+Name
+
+MESA_ieee_fp_alu_mode
+
+Name Strings
+
+GL_MESA_ieee_fp_alu_mode
+
+Contact
+
+Ilia Mirkin, ilia 'at' x.org
+
+IP Status
+
+No known IP issues.
+
+Status
+
+Proposed
.GL3Tests.transform_feedback.transform_feedback_builtins.
The issue was reproduced on GM107 and GP108.
Signed-off-by: Ilia Mirkin
---
.../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers
they continue to fail due to inaccuracies).
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_surface.c | 12
src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 16 ++--
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers
this framebuffer, and it work fine.
> Should I add support DRM or KMS support on my driver for OpenGL work right?
>
> On 12/25/19 6:10 AM, Ilia Mirkin wrote:
> > Not specific to swrast, but there's a "drm" platform via gbm (or a gbm
> > platform with drm output? I
Not specific to swrast, but there's a "drm" platform via gbm (or a gbm
platform with drm output? I'll never remember). You should be able to
use this to output directly to a kms output. An example of such an
application is kmscube -- it's more geared to hardware accel, but I
don't see any reason
Reviewed-by: Ilia Mirkin
On Thu, Dec 5, 2019 at 12:51 PM Jason Ekstrand wrote:
>
> Fixes: 385d13f26d2 "util/atomic: Add a _return variant of p_atomic_add"
> ---
> src/util/u_atomic.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a
I am. Reading code too late at night, apparently. Sorry!
On Thu, Dec 5, 2019 at 4:15 AM Lionel Landwerlin
wrote:
>
> Hmm... I don't see it.
>
> Are you not confused by brw_batch_reloc/brw_state_reloc?
>
> -Lionel
>
> On 05/12/2019 06:56, Ilia Mirkin wrote:
> &
Signed-off-by: Ilia Mirkin
---
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
index 91720dad5b4..137158f168a 100644
--- a/src/mesa/drivers/dri
Reviewed-by: Ilia Mirkin
On Sat, Nov 2, 2019 at 7:57 PM Karol Herbst wrote:
>
> Signed-off-by: Karol Herbst
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir.cpp | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir
It looks like the _mesa_generate_mipmap fallback has a similar problem
(which would happen for glGenerateMipmap with e.g. a s3tc format).
I think this could all use some piglit tests that iterate through all
or at least many different formats, including both renderable and
non-renderable ones.
On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin wrote:
>
> On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund
> wrote:
> >
> > On Fri, 2019-10-18 at 08:57 -0400, Ilia Mirkin wrote:
> > > On Fri, Oct 18, 2019 at 8:51 AM Erik Faye-Lund
> > > wrote:
> > >
On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund
wrote:
>
> On Fri, 2019-10-18 at 08:57 -0400, Ilia Mirkin wrote:
> > On Fri, Oct 18, 2019 at 8:51 AM Erik Faye-Lund
> > wrote:
> > > On Thu, 2019-10-17 at 22:24 -0400, Ilia Mirkin wrote:
> > > > In the meanwhil
On Fri, Oct 18, 2019 at 8:51 AM Erik Faye-Lund
wrote:
>
> On Thu, 2019-10-17 at 22:24 -0400, Ilia Mirkin wrote:
> > In the meanwhile (unless you plan on taking up Jason's suggestion),
> > might I recommend some assert's for the unhandled cases so that there
> > are no sur
want to implement this blindly, which is why I
> left this out for now.
>
> On October 17, 2019 5:09:36 PM GMT+02:00, Ilia Mirkin
> wrote:
>>
>> Hey Erik,
>>
>> Just saw your change
>> https://cgit.freedesktop.org/mesa/mesa/commit/?id=3298aedd6e9f12cefd5aa741
Hey Erik,
Just saw your change
https://cgit.freedesktop.org/mesa/mesa/commit/?id=3298aedd6e9f12cefd5aa7414eeebf69ce7538d1
. It looks like you assume that the UCPs will apply in the vertex
stage, but given that we support GL compat profiles for GL 4.0+ in
st/mesa, the UCPs actually apply to the
Reviewed-by: Ilia Mirkin
Based on the dot-output thing ("dotted" edge), presumably it was to
mark BB's that were somehow related? I have no idea what the design
was. Christoph hasn't been seen in ages, perhaps Curro knows, but I
think it's also fine to delete.
Cheers,
-ilia
On M
Oh. Probably. Let me have another look then.
On Mon, Oct 14, 2019 at 5:27 PM Karol Herbst wrote:
>
> isn't that what "UNKNOWN" is for?
>
> On Mon, Oct 14, 2019 at 11:16 PM Ilia Mirkin wrote:
> >
> > The idea was that this type would be used when you're not sur
The idea was that this type would be used when you're not sure, and
then run the classifier afterwards. Otherwise the classifier doesn't
know which edges to classify...
On Mon, Oct 14, 2019 at 5:10 PM Karol Herbst wrote:
>
> it was never used
>
> Signed-off-by: Karol Herbst
> ---
>
Observed an issue when looking at the code generatedy by the
image-vertex-attrib-input-output piglit test. Even though the test
itself worked fine (due to TIC 0 being used for the image), this needs
to be fixed.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen
-layered_binding without breaking
anything else.
Signed-off-by: Ilia Mirkin
---
OK, first of all -- to whoever thought that binding single layers of a 3d
image and telling the shader they were regular 2d images was a good idea --
I disagree.
This change feels super super dirty, but I honestly don't
$ git grep CmdBeginTransformFeedback
src/amd/vulkan/radv_cmd_buffer.c:void radv_CmdBeginTransformFeedbackEXT(
src/intel/vulkan/genX_cmd_buffer.c:void genX(CmdBeginTransformFeedbackEXT)(
Not *that* hard to search for...
On Thu, Oct 3, 2019 at 10:35 AM wrote:
>
>
>
> Sorry for being a bit thick
This mirrors the intrinsics in the GLSL IR. One could imagine an
alternate definition where reading the semantic would account for the
READ_HELPER functionality, but that feels potentially dodgy and could be
subject to CSE unpleasantness.
Signed-off-by: Ilia Mirkin
---
.../auxiliary/tgsi
Signed-off-by: Ilia Mirkin
---
This passes the available piglit tests (once they are fixed to not
require GL 4.5)
.../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp| 12
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 +
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
k
>
> On Tue, Aug 27, 2019 at 9:24 PM Ilia Mirkin wrote:
>>
>> By the way, I took the liberty of composing a test which fails with
>> current mesa, and I'm pretty sure it continues to fail with this
>> patch. It does pass if I just make it a GLubyte like all the
We were previously not doing at least some of the checks. This uses the
same logic that is used in glTexImage*.
Signed-off-by: Ilia Mirkin
---
This seems to leave the Intel CI happy -
https://mesa-ci.01.org/imirkin/builds/32/group/63a9f0ea7bb98050796b649e85481845
And fixes things
Instead of changing the code each time, allow the fourcc to be passed
in as an argument.
Signed-off-by: Ilia Mirkin
---
common.c | 4 ++--
common.h | 2 +-
kmscube.c| 20 +++-
texturator.c | 2 +-
4 files changed, 23 insertions(+), 5 deletions(-)
diff --git
/
On Tue, Aug 27, 2019 at 7:37 PM Ilia Mirkin wrote:
>
> I don't think the original author was included -- CC was probably
> stripped by the ML. Adding here.
>
> On Tue, Aug 27, 2019 at 6:49 PM Marek Olšák wrote:
> >
> > Yes, but if the original author does
I don't think the original author was included -- CC was probably
stripped by the ML. Adding here.
On Tue, Aug 27, 2019 at 6:49 PM Marek Olšák wrote:
>
> Yes, but if the original author doesn't reply, I'd like to push this.
>
> Marek
>
> On Thu, Aug 15, 2019 at 8:01 PM
On Mon, Aug 26, 2019 at 6:41 AM Juan A. Suarez Romero
wrote:
>
> On Sat, 2019-08-17 at 12:17 -0400, Ilia Mirkin wrote:
> > The compute paths in vl are a bit AMD-specific. For example, they (on
> > nouveau), try to use a BGRX8 image format, which is not supported.
> > Fix
/show_bug.cgi?id=111213
Fixes: 9364d66cb7 (gallium/auxiliary/vl: Add video compositor compute shader
render)
Signed-off-by: Ilia Mirkin
---
src/gallium/auxiliary/util/u_screen.c| 2 +-
src/gallium/auxiliary/vl/vl_compositor.c | 2 +-
src/gallium/docs/source/screen.rst | 4 ++--
src/gallium
On Fri, Aug 16, 2019 at 11:38 AM Alyssa Rosenzweig
wrote:
>
> The texture coordinate for a 2D texture could be a vec2 or a vec3,
> depending if it's an array texture or not. If it's vec2 (non-array
> texture), we should not reference the z component; otherwise, liveness
> analysis will get very
Subtle. The source format *can* be 64-bit, by the way, but if it's
GL_DEPTH_COMPONENT it may well be 32-bit.
But what if it's GL_STENCIL_INDEX -- could it not be 1-byte? IOW,
should this just be a char *, and use byte addressing and be done with
it?
On Thu, Aug 15, 2019 at 7:56 PM Marek Olšák
Without commenting on Android-specific issues, of which I'm blissfully
unaware, all NVIDIA G80+ (i.e. DX10+) GPUs support both RGBA8 and
BGRA8 for display and color rendering:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/dispnv50/base507c.c#n206
On Tue, Aug 13, 2019 at 4:49 PM Eric Anholt wrote:
>
> Ilia Mirkin writes:
>
> > Hi Eric,
> >
> > I see that you recently added testing dEQP with llvmpipe in the CI. It
> > looks like a number of your expected failures would be resolved by
> > disabling
Hi Eric,
I see that you recently added testing dEQP with llvmpipe in the CI. It
looks like a number of your expected failures would be resolved by
disabling some llvmpipe optimizations. You can do this by running with
GALLIVM_DEBUG=no_rho_approx,no_brilinear,no_quad_lod
in the environment. Some
Signed-off-by: Ilia Mirkin
---
.../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 10 ++
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
b/src
This debug situation is unforunate. debug_printf only does something
with DEBUG set, but in practice all that needs to be moved to !NDEBUG.
For now, use _debug_printf which always prints. However the whole
function is guarded by !NDEBUG.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers
PIPE_CAP_IMAGE_LOAD_FORMATTED is designed to allow
PIPE_FORMAT_NONE to be provided as a format and still enable LOAD
operations to be performed.
So the shader has all the information it needs about the format.
Signed-off-by: Ilia Mirkin
---
src/mesa/state_tracker/st_extensions.c | 3 ---
1 file
Both AMD and NVIDIA hardware define it this way. Instead of replicating
the logic everywhere, just fix it up in one place.
Signed-off-by: Ilia Mirkin
---
I'm open to also not doing this. Just seems like it'll make our
collective lives a little easier, since this is what the hw wants
Hi Pierre-Eric,
I see you recently added EXT_shader_image_load_store - nice. It seems
like you're relying on the format-less read access feature to make it
happen:
+ extensions->EXT_shader_image_load_store &=
+ screen->get_param(screen, PIPE_CAP_IMAGE_LOAD_FORMATTED);
Can you elaborate
r away) the object is, because W is the divisor (which makes objects
> smaller as it increases).
>
> The W=0 plane intersects the viewer. It is exactly in the middle of the "eye
> ball".
>
> W < 0 means behind the viewer.
>
> Marek
>
> On Fri., Aug. 2, 2019, 2
lation is driven by W, not Z. Interpolating W and
> then computing barycentric coordinates using 1/W is what causes the
> perspective distortion.
>
> Marek
>
> On Fri, Aug 2, 2019 at 4:59 PM Ilia Mirkin wrote:
>>
>> On Fri, Aug 2, 2019 at 3:46 PM Gert Wollny wrote:
>
On Fri, Aug 2, 2019 at 3:46 PM Gert Wollny wrote:
>
> Am Freitag, den 02.08.2019, 15:09 -0400 schrieb Ilia Mirkin:
> > On Fri, Aug 2, 2019 at 1:28 PM Gert Wollny > > wrote:
> > > Am Donnerstag, den 01.08.2019, 07:22 -0400 schrieb Ilia Mirkin:
> > > >
On Fri, Aug 2, 2019 at 1:28 PM Gert Wollny wrote:
>
> Am Donnerstag, den 01.08.2019, 07:22 -0400 schrieb Ilia Mirkin:
> > Hey Gert,
> >
> > I'm looking at
> > https://cgit.freedesktop.org/mesa/mesa/commit/?id=b048d8bf8f056759d1845a799d4ba2ac84bce30f
> >
Hey Gert,
I'm looking at
https://cgit.freedesktop.org/mesa/mesa/commit/?id=b048d8bf8f056759d1845a799d4ba2ac84bce30f
, which attempts to implement depth clamping (rather than clipping)
with shader tricks.
You're forcing the final vertex stage's position's depth to 0, and
then making up for it in
Hi Gert,
I just saw you pushed commit
https://cgit.freedesktop.org/mesa/mesa/commit/?id=4ee638cd7826e8a4bed76f51c7b73395a2fcdb
which just returns if rasterizer_discard is set, similar to if the
render condition doesn't match. However this breaks TF and any
image/etc writes in vertex stages when
assert accessing null pointer
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111007
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67
Signed-off-by: Mark Menzynski
Reviewed-by: Ilia Mirkin
Reviewed-by: Tobias Klausmann
___
AM Karol Herbst wrote:
>
> Reviewed-by: Karol Herbst
>
> On Fri, Jul 26, 2019 at 5:31 AM Ilia Mirkin wrote:
> >
> > Previously the code only handled it for positions 1 and up (as would be
> > for UBO's in GL). It's not a lot of trouble to handle this, and vl o
as return values.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
This can happen if it's e.g. a uniform or a function argument.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111217
Signed-off-by: Ilia Mirkin
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 5 +++--
1 file changed, 3 insertions
eau_statebuf.h which is unused (and
has a mention of DEBUG which is how I found it).
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/Makefile.sources | 1 -
.../drivers/nouveau/codegen/nv50_ir_driver.h | 2 +-
.../drivers/nouveau/codegen/nv50_ir_inlines.h | 2 +-
.../drivers/nouveau/co
Previously the code only handled it for positions 1 and up (as would be
for UBO's in GL). It's not a lot of trouble to handle this, and vl or
vdpau want this.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111213
Signed-off-by: Ilia Mirkin
Cc: mesa-sta...@lists.freedesktop.org
Apparently vl (or vdpau) wants to pass that in now. Handle it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111213
Signed-off-by: Ilia Mirkin
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/nv50/nv50_state.c | 14 --
src/gallium/drivers/nouveau/nvc0
video
compositor render)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111213
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111217
Signed-off-by: Ilia Mirkin
---
src/gallium/auxiliary/vl/vl_compositor_cs.c | 102 ++--
1 file changed, 51 insertions(+), 51 deletions
On Tue, Jul 23, 2019 at 11:15 AM Karol Herbst wrote:
>
> On Tue, Jul 23, 2019 at 4:50 PM Ilia Mirkin wrote:
> >
> > You handle 1/n but not 1%n? TBH, the 1/n code isn't 100% obvious to
> > me... 1/n = |n|-1 > 0 ? i forget how SLCT works, but I can't
&
You handle 1/n but not 1%n? TBH, the 1/n code isn't 100% obvious to
me... 1/n = |n|-1 > 0 ? i forget how SLCT works, but I can't
think of a way to finish that expression in terms of |n|-1 and n. And
what about n == 0. I'd just as soon drop that case.
On Tue, Jul 23, 2019 at 10:20 AM Mark
ilia
On Sat, Jun 29, 2019 at 12:08 AM Ilia Mirkin wrote:
>
> Ken pointed out on IRC today that there was still a lot of "boolean"
> (vs bool/_Bool) usage in gallium. In fact, many interfaces are
> specified with boolean.
>
> I had it in my mind that I had at
On Mon, Jul 22, 2019 at 11:49 AM Samuel Pitoiset
wrote:
>
> For TES as NGG.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_nir_to_llvm.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
>
On Fri, Jul 19, 2019 at 12:07 PM Tobias Klausmann
wrote:
> On 19.07.19 15:39, Eric Engestrom wrote:
> > On Friday, 2019-07-19 13:56:30 +0200, Mark Menzynski wrote:
> >> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=111007
> >> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=67
> >
On Fri, Jul 19, 2019 at 11:34 AM Mark Menzynski wrote:
>
> On Fri, Jul 19, 2019 at 5:04 PM Ilia Mirkin wrote:
> >
> > On Fri, Jul 19, 2019 at 10:57 AM Mark Menzynski wrote:
> > >
> > > Nvidia actively uses these instructions, maybe they are better in
> &g
On Fri, Jul 19, 2019 at 10:57 AM Mark Menzynski wrote:
>
> Nvidia actively uses these instructions, maybe they are better in
> something.
> Long offset checking function was made because these functions only have 24
> bit
> address offsets.
>
> Signed-off-by: Mark Menzynski
> ---
>
The patch is correct as-is.
Reviewed-by: Ilia Mirkin
On Fri, Jul 19, 2019 at 9:39 AM Eric Engestrom wrote:
>
> On Friday, 2019-07-19 13:56:30 +0200, Mark Menzynski wrote:
> > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=111007
> > Fixes: https://bugs.freedesktop.o
On Wed, Jul 10, 2019 at 9:25 AM Alyssa Rosenzweig
wrote:
>
> Fixes a buggy dEQP test.
>
> Signed-off-by: Alyssa Rosenzweig
> ---
> .../drivers/panfrost/ci/expected-failures.txt | 6 --
> src/gallium/drivers/panfrost/meson.build | 1 +
> .../drivers/panfrost/midgard/compiler.h | 6
Reviewed-by: Ilia Mirkin
The tcp input patch size is not a compile-time value, and even if it
were, not sure where we'd use it. The tep input patch size is set at
compile time, but in the code you're removing, we set it to ~0
anyways.
On Mon, Jul 8, 2019 at 3:22 PM Karol Herbst wrote
I see this as driving away contributions, esp from new people. MR's
are annoying to create, since they require dealing with the hosting
provider, getting it to host clones, etc. Everyone has email.
Cheers,
-ilia
On Sat, Jul 6, 2019 at 7:41 AM Eric Engestrom wrote:
>
> Hi,
>
> I sent an MR to
Reviewed-by: Ilia Mirkin
On Fri, Jul 5, 2019 at 12:59 AM Ian Romanick wrote:
>
> From: Ian Romanick
>
> Set the absolute minimum possible GLSL version. API_OPENGL_CORE can
> mean an OpenGL 3.0 forward-compatible context, so that implies a minimum
> possible version o
On Fri, Jul 5, 2019 at 12:56 AM Ian Romanick wrote:
>
> On 7/4/19 4:21 PM, Ilia Mirkin wrote:
> > For example wine might query GL_SHADING_LANGUAGE_VERSION on a driver
> > that doesn't support GLSL. This is not a problem in itself, we can just
> > return a INVALID_ENUM
For example wine might query GL_SHADING_LANGUAGE_VERSION on a driver
that doesn't support GLSL. This is not a problem in itself, we can just
return a INVALID_ENUM error.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109524
Signed-off-by: Ilia Mirkin
---
src/mesa/main/getstring.c | 2
Signed-off-by: Ilia Mirkin
---
It's actually a bit tricky to compile all the bits involved, so some of
this is untested. However if it so happens that I missed a spot, it
should be trivial to fix.
src/gallium/include/state_tracker/graw.h | 8 +-
src/gallium/include/state_tracker/st_api.h
On Tue, Jul 2, 2019 at 12:04 PM Karol Herbst wrote:
>
> On Tue, Jul 2, 2019 at 5:54 PM Ilia Mirkin wrote:
> >
> > Can you check on PIPE_CAP_COMPUTE_SHADER_DERIVATIVES ? I think we
> > should be able to just flip that on for nvc0. Also the
> > CS_DERIVED_SYSTEM_VAL
Can you check on PIPE_CAP_COMPUTE_SHADER_DERIVATIVES ? I think we
should be able to just flip that on for nvc0. Also the
CS_DERIVED_SYSTEM_VALUES thing might be useful -- I had wanted to do
that a while ago but laziness defeated me. Now that it's there though
... we have sysvals for many of those
On Mon, Jul 1, 2019 at 10:56 AM Alyssa Rosenzweig
wrote:
> As a side effect, we rework how vertex buffers are handled, duplicating
> them to be 1:1 with vertex descriptors to simplify instancing code paths
> dramatically. This might be a performance regression, but this remains
> to be seen; if
It looks like I was mistaken -- a primary node is always allocated. Sorry!
On Sat, Jun 29, 2019 at 4:28 AM Mathias Fröhlich
wrote:
>
> Emil,
>
> Ok, I thought Ilja is a reference here. In this case forget that change!
> Thanks!
>
> best
>
> Mathias
>
> On Friday, 28 June 2019 18:26:07 CEST Emil
Ken pointed out on IRC today that there was still a lot of "boolean"
(vs bool/_Bool) usage in gallium. In fact, many interfaces are
specified with boolean.
I had it in my mind that I had at some point removed most boolean
usage, but that is just not the case - first of all, the interfaces
remain
Reviewed-by: Ilia Mirkin
On Tue, Jun 18, 2019 at 5:14 PM Dave Airlie wrote:
>
> From: Dave Airlie
>
> This is pointless in that we won't ever hit those paths in real life,
> but coverity complains.
>
> Fixes: f014ae3c7cce ("nouveau: add support for nir")
>
On Mon, Jun 17, 2019 at 6:37 AM wrote:
>
> From: Mathias Fröhlich
>
>
> Emil,
>
> that one probably matches your original intent then.
>
> please review
> Thanks
>
> Mathias
>
>
> Do not offer a hardware drm backed egl device if no render node
> is available. The current implementation will fail
txf supplies an lod, but tg4's is implicitly always 0.
On Thu, May 30, 2019 at 2:26 PM Bas Nieuwenhuizen
wrote:
>
> On Thu, May 30, 2019 at 6:50 PM Rhys Perry wrote:
> >
> > Otherwise LLVM can sink them and their texture coordinate calculations
> > into divergent branches.
> >
> > Cc:
> >
, that's a GNU extension. It also works in clang but not MSVC which is
> > used to build NIR.
> >
> > On May 25, 2019 13:30:29 Rob Clark wrote:
> >
> > > On Sat, May 25, 2019 at 11:13 AM Ilia Mirkin wrote:
> > >>
> > >> On Sat, May 25, 2019
On Sat, May 25, 2019 at 2:03 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Debugging use of unsafe iterators when you should have used the _safe
> version sucks. Add some DEBUG build support to catch and assert if
> someone does that.
>
> I didn't update the UPPERCASE verions of the iterators.
On Fri, May 24, 2019 at 2:46 PM Alyssa Rosenzweig wrote:
>
> > I /think/ that should be adequate here too.
>
> Do inexact values not need to handle NaNs strictly, then? I'm not sure
> what this corresponds to in the various GLs/CLs/Vulkan specs, hence
> labeling this RFC.
I don't know about
How does max(NaN, 0) work? IIRC there's some provision that this
becomes 0, while abs(NaN) = NaN.
On Thu, May 23, 2019 at 10:47 PM Alyssa Rosenzweig wrote:
>
> I noticed this pattern in glmark's jellyfish scene.
>
> Assuming this is correct (it should be...?), could someone do a
> shader-db run?
, values(values),
> -bindless_targets(NULL), bindless_access(NULL)
> +bindless_targets(NULL), bindless_access(NULL),
> +shader_storage_blocks_write_access(9)
Probably meant 0 here. With that, the series is
Acked-by: Ilia Mirkin
> {
> }
>
> --
&
her way, get rid of the divergent/convergent references.)
>
> Signed-off-by: Alyssa Rosenzweig
> Cc: Jason Ekstrand
> Cc: Ilia Mirkin
> ---
> src/compiler/nir/nir_search_helpers.h | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/src/co
On Fri, May 10, 2019 at 5:47 AM Connor Abbott wrote:
>
> On Fri, May 10, 2019 at 11:09 AM Christian Gmeiner
> wrote:
> >
> > Signed-off-by: Christian Gmeiner
> > ---
> > src/etnaviv/compiler/eir.h| 3 +
> > src/etnaviv/compiler/eir_live_variables.c | 258
Sigh ... given that there's both "is_used_by_if" and
"is_not_used_by_if" ... gonna go with "no".
On Tue, May 7, 2019 at 6:42 PM Alyssa Rosenzweig wrote:
>
> Gotcha. I wasn't sure negations in the NIR search rule were possible...?
___
mesa-dev mailing
On Tue, May 7, 2019 at 5:45 PM Alyssa Rosenzweig wrote:
>
> > IMO better names might be is_scalar_swizzle or something.
>
> Ah, yes, that would be a better name! is_not_scalar_swizzle in this case
> (logic is flipped).
>
> > Can num_components be 1? If so, then this will return false, whereas
> >
1 - 100 of 5859 matches
Mail list logo
