Looks shiny but
We need to be very careful here. One of the big no-nos with Khronos
trademark rules is using logos for things where implementations aren't
conformant. Mesa has been living in a mirky in-between land for a
while and everything has been mostly fine. We've been very careful to
*
On Intel, mesa currently supports fp16 as well as int16 and int8 for
Vulkan. We support them for ALU ops as well as UBOs, SSBOs, and
shared memory.
We have hardware for some texture instructions with fp16 sources or
destinations but it's all over the map in terms of what ops support
what. In the
> @Jason, take the above as naming suggestions :P
I believe I did suggest FBH as a name for something that... isn't
AMD's FFBH. :-P
--Jason
>
> Daniel
>
> On 1/4/20 22:52, Jason Ekstrand wrote:
>
> On Wed, Apr 1, 2020 at 1:52 PM Eric Anholt wrote:
>
> O
On Wed, Apr 1, 2020 at 1:52 PM Eric Anholt wrote:
>
> On Wed, Apr 1, 2020 at 11:39 AM 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 curren
On Tue, Mar 31, 2020 at 3:00 PM Ian Romanick wrote:
>
> On 3/31/20 12:25 PM, Fabio Estevam wrote:
> > The 'complemented' variable is a pointer to boolean. Use the !! operator
> > to fix the following build warning:
> >
> > ../texturator.c:603:45: warning: '*' in boolean context, suggest '&&'
> >
On Sun, Mar 29, 2020 at 6:06 PM Bas Nieuwenhuizen
wrote:
>
> On Sun, Mar 29, 2020 at 11:36 PM Eric Engestrom wrote:
> >
> >
> >
> > On 2020-03-29 at 20:58, Jason Ekstrand wrote:
> > > On Sun, Mar 29, 2020 at 11:45 AM Kristian Høgsberg
> > > wrot
that's fine with me. It's
>> technically more challenging for driver loaders and packaging though.
>>
>> Marek
>>
>> On Sun., Mar. 29, 2020, 02:51 Jason Ekstrand, wrote:
>>>
>>> On Sat, Mar 28, 2020 at 11:41 PM Marek Olšák wrote:
>>>
back-end compiler. Even though we're not adding features, I
still find myself having to fix those up from time to time due to
reworks elsewhere. Maybe the answer is to copy and isolate them too
but, at that point, why not just put them in a branch?
--Jason
> Marek
>
> On Sun., Ma
On Wed, Mar 25, 2020 at 6:32 PM Marek Olšák wrote:
>
>
>
> On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke wrote:
>>
>> On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote:
>> > Hi,
>> >
>> > Here are 2 proposals to simplify and better optimize the GL->Gallium
>> > translation.
>> >
>> >
On Wed, Mar 18, 2020 at 12:20 AM Jacob Lifshay wrote:
>
> On Tue, Mar 17, 2020 at 7:08 PM Jason Ekstrand wrote:
> >
> > On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay
> > wrote:
> > >
> > > On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote:
> >
On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay wrote:
>
> On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote:
> >
> > Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> > > I think I found a userspace-accessible way to create sync_files and
> > > dma_fences that would fulfill the re
On Tue, Mar 17, 2020 at 12:13 PM Jacob Lifshay wrote:
>
> One related issue with explicit sync using sync_file is that combined
> CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> rendering in userspace (like llvmpipe but for Vulkan and with extra
> instructions for GPU tasks) but ne
On Tue, Mar 17, 2020 at 10:33 AM Nicolas Dufresne wrote:
>
> Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit :
> > Hi Jason,
> >
> > On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote:
> > > On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinch
On Tue, Mar 17, 2020 at 3:01 AM Simon Ser wrote:
>
> On Monday, March 16, 2020 5:04 PM, Jason Ekstrand
> wrote:
>
> > Hopefully, that will provide some motivation for other compositors
> > (kwin, gnome-shell, etc.) because they now have a real user of it in
> >
On Mon, Mar 16, 2020 at 6:39 PM Roman Gilg wrote:
>
> On Wed, Mar 11, 2020 at 8:21 PM Jason Ekstrand wrote:
> >
> > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand
> > wrote:
> > >
> > > All,
> > >
> > > Sorry for casting such a b
On Mon, Mar 16, 2020 at 4:15 PM Laurent Pinchart
wrote:
>
> Hi Jason,
>
> On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote:
> > On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote:
> > > On Wed, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote:
On Mon, Mar 16, 2020 at 10:33 AM Tomek Bury wrote:
>
> > GL and GLES are not relevant. What is relevant is EGL, which defines
> > interfaces to make things work on the native platform.
> Yes and no. This is what EGL spec says about sharing a texture between
> contexts:
>
> "OpenGL and OpenGL ES m
On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart
wrote:
>
> On Wed, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote:
> > (I know I'm going to be spammed by so many mailing list ...)
> >
> > Le mercredi 11 mars 2020 à 14:21 -0500, Jason Ekstrand a écrit :
>
explain it.)
--Jason
On March 13, 2020 21:03:21 Marek Olšák wrote:
There is no synchronization between processes (e.g. 3D app and compositor)
within X on AMD hw. It works because of some hacks in Mesa.
Marek
On Wed, Mar 11, 2020 at 1:31 PM Jason Ekstrand wrote:
All,
Sorry for casting such a
very much want to solve the problem "properly" but unless
we're very sure we can get it solved properly everywhere quickly, a
solution which lets us improve our driver kernel APIs independently of
misc. Wayland compositors seems advantageous.
On Wed, Mar 11, 2020 at 6:02 PM Adam Jack
On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand wrote:
>
> All,
>
> Sorry for casting such a broad net with this one. I'm sure most people
> who reply will get at least one mailing list rejection. However, this
> is an issue that affects a LOT of components and that'
on to start moving others and maybe we can actually build the
momentum to get most everything converted.
For reference, you can find the kernel RFC patches and mesa MR here:
https://lists.freedesktop.org/archives/dri-devel/2020-March/258833.html
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037
At this point, I welcome your thoughts, comments, objections, and
maybe even help/review. :-)
--Jason Ekstrand
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
hort order.
Again, sorry I was so terse. I was just trying to slow the panic.
> Le dimanche 01 mars 2020 à 14:18 -0600, Jason Ekstrand a écrit :
> > I've seen a number of suggestions which will do one or both of those things
> > including:
> >
> > - Batching m
I don't think we need to worry so much about the cost of CI that we need to
micro-optimize to to get the minimal number of CI runs. We especially
shouldn't if it begins to impact coffee quality, people's ability to merge
patches in a timely manner, or visibility into what went wrong when CI
fai
On Sat, Feb 29, 2020 at 3:47 PM Timur Kristóf wrote:
>
> On Sat, 2020-02-29 at 14:46 -0500, Nicolas Dufresne wrote:
> > >
> > > 1. I think we should completely disable running the CI on MRs which
> > > are
> > > marked WIP. Speaking from personal experience, I usually make a lot
> > > of
> > > cha
On Fri, Feb 28, 2020 at 11:00 AM Rob Clark wrote:
>
> On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer wrote:
> >
> > On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote:
> > >
> > > We could also do stuff like reducing the amount of tests we run on each
> > > commit, and punt some testing to a per-weeke
+Jose & Brian
I'm not personally opposed but I also can't remember the last time I had to
fix the scons build. I think it's been years. Maybe that's because I don't
work on GL anymore? In any case, I don't know that it's really costing us
that much given that basically none of the drivers actu
FYI: GitLab merge requests are the preferred way to send patches these days.
--Jason
On February 5, 2020 21:52:25 James Jones wrote:
This series pulls in the proposed
DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D() format
modifier macro and wires it up in the nouveau
nvc0 driver. In doing so, it imp
On Wed, Jan 29, 2020 at 4:46 AM Bas Nieuwenhuizen
wrote:
> On Tue, Jan 28, 2020 at 8:46 PM Dylan Baker wrote:
> >
> > Quoting Dylan Baker (2020-01-22 10:27:05)
> > > Hi list, due to some last minute changes in plan I'll be managing the
> 20.0
> > > release. The release calendar has been updated,
Should we make iris the default for 20.0? I think it's time. Sadly,
gitlab milestones don't let you comment on them.
On Wed, Jan 22, 2020 at 12:26 PM Dylan Baker wrote:
> Hi list, due to some last minute changes in plan I'll be managing the 20.0
> release. The release calendar has been updated
When were we planning to cut the 20.0 release? We just landed Vulkan 1.2
support for ANV and RADV this morning so it seems like a good time to me.
The release calendar has nothing for 2020:
https://www.mesa3d.org/release-calendar.html
--Jason
___
mesa-
On Mon, Jan 13, 2020 at 11:27 AM Luke Kenneth Casson Leighton
wrote:
>
>
> On Monday, January 13, 2020, Jacob Lifshay
> wrote:
>
>> On Thu, Jan 9, 2020 at 3:56 AM Luke Kenneth Casson Leighton
>> wrote:
>> >
>>
>> > jacob perhaps you could clarify, here?
>>
>> So the major issue with the approac
On Wed, Jan 8, 2020 at 7:55 PM Luke Kenneth Casson Leighton
wrote:
>
>
> On Thursday, January 9, 2020, Jason Ekstrand wrote:
>
>> Drive-by comment:
>>
>
> really appreciate the feedback.
>
>
>> I don't think you actually want to base any de
Drive-by comment: I don't think you actually want to base any decisions an
a vec4 architecture. Nearly every company in the graphics industry thought
that was a good idea and designed vec4 processors. Over the course of the
last 15 years or so they have all, one by one, realized that it was a ba
On Wed, Dec 11, 2019 at 11:33 AM Michel Dänzer wrote:
> On 2019-12-11 5:47 p.m., Brian Paul wrote:
> >
> > I've had little time for Mesa work the past 18 months.
>
> That makes me sad, I hope you'll have more time again in the future.
>
>
> > 1. I don't think the mesa-dev list should be shut down
On Tue, Dec 10, 2019 at 4:59 PM Dylan Baker wrote:
> Quoting Zebediah Figura (2019-12-10 10:58:45)
> > On 12/10/19 12:21 PM, Matt Turner wrote:
> > > On Mon, Dec 9, 2019 at 6:07 PM Dylan Baker
> wrote:
> > >>
> > >> Hi everyone,
> > >>
> > >> I think its time we discussed whether we're going to
Pushed. Thanks for catching this!
On Thu, Dec 5, 2019 at 11:52 AM Ilia Mirkin wrote:
> 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"
&g
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/src/util/u_atomic.h b/src/util/u_atomic.h
index 45e8e2e0188..9cbc6dd1eaa 100644
--- a/src/util/u_atomic.h
+++ b/src/util/u_atomic.h
@@
On Wed, Dec 4, 2019 at 5:51 AM Timothy Arceri wrote:
>
>
> On 4/12/19 3:45 pm, Jason Ekstrand wrote:
> > On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie > <mailto:airl...@gmail.com>> wrote:
> >
> > On Wed, 4 Dec 2019 at 10:39, Marek Olšák
On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie wrote:
> On Wed, 4 Dec 2019 at 10:39, Marek Olšák wrote:
> >
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium
> translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master.
> Classic dr
Ok, that's a bit of a weird click-bait title but it's descriptive. One of
the things that we really need to get tested in piglit is the GL <-> Vulkan
interop extensions. The Vulkan bits are implemented in ANV and RADV and
the GL bit is implemented in radeonsi but we don't have a good test plan at
Reviewed-by: Jason Ekstrand
On Mon, Nov 11, 2019 at 5:45 PM Brian Paul wrote:
> ---
> src/compiler/nir/nir_builder.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/nir/nir_builder.h
> b/src/compiler/nir/nir_builder.h
> index de
First off, ignore the whole 48-bit heap thing. It exists to work around
some weird issues with our vertex fetch hardware. We're going to be
deleting it and switching to using a different workaround (more tracking
and flushing) in the near future.
As far as heap sizes go, copying ANV is probably n
On Thu, Oct 17, 2019 at 10:39 AM Erik Faye-Lund <
erik.faye-l...@collabora.com> wrote:
> This is discussed in the merge request thread. Zink currently only support
> vertex and fragment shaders, so it's the only place this can occur. If
> someone wants to enable this for drivers that supports geom
On October 10, 2019 15:15:29 Marek Olšák wrote:
Hi,
I expect to make a new libdrm release soon. Any objections to changing the
versioning scheme?
Current: 2.4.n
n = starts from 0, incremented per release
New proposals:
year.n.0 (19.0.0)
Following the Mesa convention seems reasonable
On Wed, Sep 18, 2019 at 2:08 PM Mark Janes wrote:
> Right now, anyone can create milestones. Is there a way to limit the
> capability to release managers? Would that be desirable?
>
I don't think so. We may want to use milestones for other task tracking
beyond just releases such as "Switch ra
On September 4, 2019 13:27:51 Kyle Brenneman wrote:
On 9/4/19 8:44 AM, Daniel Stone wrote:
Hi,
On Wed, 4 Sep 2019 at 15:12, Chuck Atkins wrote:
Can we use Gitlab's GitHub import feature?
https://gitlab.freedesktop.org/help/user/project/import/github.md
I haven't used it before but it
+1
On Thu, Aug 29, 2019 at 2:36 PM Rob Clark wrote:
> On Thu, Aug 29, 2019 at 12:02 PM Kenneth Graunke
> wrote:
> >
> > Hi all,
> >
> > As a lot of you have probably noticed, Bugzilla seems to be getting a
> > lot of spam these days - several of us have been disabling a bunch of
> > accounts pe
On Mon, Aug 26, 2019 at 6:43 AM Daniel Stone wrote:
> Hi Andreas,
>
> On Sun, 25 Aug 2019 at 21:11, Andreas Bergmeier
> wrote:
> > For a few weeks now I am working on implementing Vulkan for VideoCore 6
> AKA 42 (using V3D/DRM). Don't hold you breath ;)
>
> Great! I can't say much about the spec
On Wed, Aug 21, 2019 at 10:05 AM apinheiro wrote:
> (Thanks Chema for pointing me this thread)
>
> On 21/8/19 9:09, Emil wrote:
> > Hi Jason,
> >
> > On 21 August 2019 01:22:00 EEST, Jason Ekstrand
> wrote:
> >> Sorry for the late breaking hold but I
Sorry for the late breaking hold but I just realized that GL_ARB_gl_spirv
and OpenGL 4.6 for Intel is 1 regression (I think it's not even a
regression) away from landing. Can I have 24 hours?
On Mon, Aug 19, 2019 at 10:30 AM Emil Velikov
wrote:
> On Sunday, 18 August 2019, Matt Turner wrote:
>
On Thu, Aug 15, 2019 at 10:48 AM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> On Wed, Aug 14, 2019 at 10:05:34PM -0500, Jason Ekstrand wrote:
> > I take it this happens when subslices_delta == 0 and we take the early
> return?
>
> Yes, exactly, in that case d
I take it this happens when subslices_delta == 0 and we take the early
return?
On Wed, Aug 14, 2019 at 5:45 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> I failed to initialize it on the other cases in GEN11 and it was causing
> a segfault when going through anv_DestroyDevice, if c
Reviewed-by: Jason Ekstrand
Thanks for figuring this out!
On Mon, Aug 12, 2019 at 4:19 PM Francisco Jerez
wrote:
> See "i965/gen9: Optimize slice and subslice load balancing behavior."
> for the rationale. According to Jason, improves Aztec Ruins
> performance by 2.
On Sat, Aug 10, 2019 at 4:55 PM Francisco Jerez
wrote:
> Jason Ekstrand writes:
>
> > On Sat, Aug 10, 2019 at 2:22 PM Francisco Jerez
> > wrote:
> >
> >> Jason Ekstrand writes:
> >>
> >> > On Fri, Aug 9, 2019 at 7:22 PM Francisco Jerez &
On Sat, Aug 10, 2019 at 2:22 PM Francisco Jerez
wrote:
> Jason Ekstrand writes:
>
> > On Fri, Aug 9, 2019 at 7:22 PM Francisco Jerez
> > wrote:
> >
> >> See "i965/gen9: Optimize slice and subslice load balancing behavior."
> >> for th
On Fri, Aug 9, 2019 at 7:22 PM Francisco Jerez
wrote:
> See "i965/gen9: Optimize slice and subslice load balancing behavior."
> for the rationale. Marked optional because no performance evaluation
> has been done on this commit, it is provided to match the hashing
> settings of the Iris driver.
This gets us +2.7% on Aztec Ruins (5 runs on each branch)
On Sat, Aug 10, 2019 at 7:31 AM Jason Ekstrand wrote:
> Let's hold this for at least a tiny bit. I'll run some benchmarks and may
> want to tweak how in interacts with the rest of the vulkan state
> tracking.
> Tha
Let's hold this for at least a tiny bit. I'll run some benchmarks and may
want to tweak how in interacts with the rest of the vulkan state tracking.
Thanks for figuring out a heuristic!
--Jason
On August 9, 2019 19:22:48 Francisco Jerez wrote:
See "i965/gen9: Optimize slice and subslice lo
overall for gl_driver2 it was
something along the lines of 2-3%. Looking at perf-report, slab_free
(+ slab_free_fast) went from ~20% to nearly nothing(ish) iirc..
BR,
-R
On Wed, Aug 7, 2019 at 4:58 PM Jason Ekstrand wrote:
Do you have any actual numbers for this?
On August 7, 2019 17:02:22
Do you have any actual numbers for this?
On August 7, 2019 17:02:22 Rob Clark wrote:
From: Rob Clark
I noticed slab_free() showing up at the top of perf results in
gl_driver2, due to "streaming" GPU state objects, which are allocated
and destroyed within a single draw call.
In this case, it
Reviewed-by: Jason Ekstrand
The only real difference is that the common one also handles casts. Would
probably be good to handle them here too.
--Jason
On Wed, Jul 31, 2019 at 12:36 AM Dave Airlie wrote:
> From: Dave Airlie
>
> This doesn't seem to need it's own copy
On Wed, Jul 24, 2019 at 2:00 AM Xu, Xing wrote:
> Hi, I tried to add some logs as below in file
> ./src/vulkan/wsi/wsi_common_x11.c (x11_queue_present):
>
> printf("%s,%d\n",__FUNCTION__,__LINE__);
>
> assert(0);
>
> but got nothing when I run my application.
>
>
>
> How I build run my applicatio
On Tue, Jul 9, 2019 at 11:19 AM Kristian Høgsberg
wrote:
> On Tue, Jul 9, 2019 at 12:17 AM Daniel Stone wrote:
> >
> > Hi,
> >
> > On Sat, 6 Jul 2019 at 18:39, Ilia Mirkin wrote:
> > > I see this as driving away contributions, esp from new people. MR's
> > > are annoying to create, since they r
Congratulations on this monumental achievement! Bringing up a whole
back-end compiler is a huge amount of work and doing it in a year with only
a couple of people is pretty impressive. It's great to see this work
finally see the light of day and I look forward to seeing how it progresses
going fo
I needed this patch today so I've pushed it. FYI, we do have MRs for
shader-db which are a bit easier to find than a needle in the hay-stack
that is mesa-dev.
--Jason
On Fri, Jun 7, 2019 at 11:27 AM Emil Velikov
wrote:
> On Fri, 7 Jun 2019 at 00:30, Ian Romanick wrote:
> >
> > From: Ian Roman
On Tue, Jun 25, 2019 at 4:04 AM Daniel Stone wrote:
> Hi,
>
> On Tue, 25 Jun 2019 at 07:26, Simon Ser wrote:
> > > I noticed that original patch (v1) for gbm_bo_create_with_modifiers did
> > > have usage at first but it was removed during the review. I'm having
> > > trouble digging what was the
Thanks!
Reviewed-by: Jason Ekstrand
On Wed, Jun 19, 2019 at 8:09 AM Boris Brezillon <
boris.brezil...@collabora.com> wrote:
> We don't expect the output of a TXS instruction to be wider than a
> vec3. Add an assert() to make sure this never happens.
>
> Suggested-by: J
On Wed, Jun 19, 2019 at 3:09 AM Timothy Arceri
wrote:
> This helps reduce the amount of abstraction in this pass and allows
> us to retain more information about the src such as any swizzles.
> Retaining the swizzle information is required for a bugfix in the
> following patch.
>
> Fixes: 6772a17
, &tex->dest.ssa, lod),
> +nir_imm_int(b, 1));
> +
> + /* Make sure the component encoding the array size (if any) is not
> +* minified.
> +*/
> + if (tex->is_array) {
> + nir_ssa_def *comp[3];
>
Min
On Mon, Jun 17, 2019 at 12:42 PM Boris Brezillon <
boris.brezil...@collabora.com> wrote:
> On Mon, 17 Jun 2019 10:53:47 -0500
> Jason Ekstrand wrote:
>
> > On Mon, Jun 17, 2019 at 5:49 AM Boris Brezillon <
> > boris.brezil...@collabora.com> wrote:
> >
On Mon, Jun 17, 2019 at 12:03 PM Boris Brezillon <
boris.brezil...@collabora.com> wrote:
> On Mon, 17 Jun 2019 10:54:20 -0500
> Jason Ekstrand wrote:
>
> > Why do you need to call it in a loop?
>
> Well, I need to call it at least twice (first pass to lower TEX(RECT)
+++ b/src/compiler/nir/nir_lower_tex.c
> @@ -266,6 +266,8 @@ lower_offset(nir_builder *b, nir_tex_instr *tex)
> static void
> lower_rect(nir_builder *b, nir_tex_instr *tex)
> {
> + tex->sampler_dim = GLSL_SAMPLER_DIM_2D;
>
Mind throwing in a short comment?
/* Set the s
Reviewed-by: Jason Ekstrand
On Mon, Jun 17, 2019 at 5:21 AM Boris Brezillon <
boris.brezil...@collabora.com> wrote:
> The code considers that projector lowering was done even if it's not
> really the case. Change the project_src() prototype to return a bool
> encoding whethe
Why do you need to call it in a loop?
On Mon, Jun 17, 2019 at 5:21 AM Boris Brezillon <
boris.brezil...@collabora.com> wrote:
> Hello,
>
> I've recently been working on adding a new lowering option to the
> lower_tex() logic and found out that doing
>
> do progress = nir_lower_tex(); whil
On Mon, Jun 17, 2019 at 5:49 AM Boris Brezillon <
boris.brezil...@collabora.com> wrote:
> The V3D driver has an open-coded solution for this, and we need the
> same thing for Panfrost, so let's add a generic way to lower TXS(LOD)
> into max(TXS(0) >> LOD, 1).
>
> Signed-off-by: Boris Brezillon
>
Feel free to call it a bugfix and CC stable if you'd like.
On Tue, Jun 11, 2019 at 10:54 AM Jason Ekstrand
wrote:
>
>
> On Mon, Jun 10, 2019 at 6:21 AM Ville Syrjala <
> ville.syrj...@linux.intel.com> wrote:
>
>> From: Ville Syrjälä
>>
>> Modern DXV
kBufferMemoryBarrier*pBufferMemoryBarriers,
> +uint32_timageMemoryBarrierCount,
> +const VkImageMemoryBarrier* pImageMemoryBarriers)
> +{
> +#if GEN_GEN >= 8
> + ANV_FROM_HANDL
Alright then.
Reviewed-by: Jason Ekstrand
On June 11, 2019 04:57:27 Samuel Iglesias Gonsálvez
wrote:
According to the Vulkan spec, uniform blocks are not allowed to be
updated through vkCmdPushDescriptorSetKHR().
There are these spec quotes from "13.2.1. Descriptor Set Layout"
derivatives, whether explicitly
(dFdx/dFdy) *or* implicitly (any texturing). Accordingly, we set this
bit when texturing to fix edge case behaviour (literally, haha).
Hehe
Thank you to Jason Ekstrand and Ilia Mirkin for pointing out the
representative dEQP test failed along triangle edges and for
to set the Project field of this restriction
> to HSW:GT3, what do you think about shortening the comment to mention
> that? I'd like to give this a RB as is, but there are a lot of truth
> claims I'd have to verify in order to do so..
>
> -Nanley
>
> On Mon, Dec 3, 20
Feel free to land
On Wed, May 29, 2019 at 4:50 PM Nanley Chery wrote:
> On Wed, Feb 14, 2018 at 12:19 PM Jason Ekstrand
> wrote:
> >
> > Cannonlake hardware adds a new resolve type in 3DSTATE_PS called
> > FAST_CLEAR_0 which does an ambiguate. Now that the hardware ca
Yeah, 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 at 2:03 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Debugging use of unsafe ite
Seems fine. Rb
On May 19, 2019 20:11:50 Dave Airlie wrote:
From: Dave Airlie
we validate assert entry just before this, but since that doesn't
stop execution, we need to check entry before the next validation
assert.
---
src/compiler/nir/nir_validate.c | 2 +-
1 file changed, 1 insertion(+),
ust called
nir_eval_const_opcode to do a u2u32 on the value.
--Jason
On Fri, May 17, 2019 at 1:24 AM Karol Herbst wrote:
> ohhh, yeah.. I think we can actually just remove that code, as it
> shouldn't have any affect on the constants value.
>
> On Fri, May 17, 2019 at 4:07 AM Jason E
I think it's fine but I'm not at my computer right now.
--Jason
On May 16, 2019 20:58:03 Dave Airlie wrote:
Coverity gave me this:
mesa-19.1.0-rc2/src/compiler/spirv/spirv_to_nir.c:1987:
overlapping_assignment: Assigning "src[1][i].u8" to "src[1][i].u32",
which have overlapping memory locati
Ran it through shader-db. No changes. Feel free to stuff that in the
commit message somewhere.
Reviewed-by: Jason Ekstrand
On Wed, May 15, 2019 at 12:04 AM Alyssa Rosenzweig
wrote:
> This line is no longer relevant now that booleans are 1-bit, and in fact
> causes issues (infinite pr
Yes, it does work though the newer Fixes: tag is preferred. The process
hasn't actually involved the mesa-stable making list in a while. Instead,
there are scripts used by the release managers that troll the got lots
looking for Cc: to stable and Fixes: tags and grabs the appropriate
patches. T
Likely you're either getting slightly different build flags for some reason
it else something extra is getting linked into the gallium driver that want
before. Not all they concerning but I'll happily agree it is a bit odd and
probably worth some investigation. If nothing else, your build setup
Also, my preferred solution to this problem is to just make nir_validate
faster:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/862
On Fri, May 10, 2019 at 9:47 PM Jason Ekstrand wrote:
> Please, no. You could make a case for changing the default in
> debugoptimized builds (w
Please, no. You could make a case for changing the default in
debugoptimized builds (which I would still be against) but we should
definitely still compile it. Why is it so hard to set NIR_VALIDATE=0 when
you really care about compiler times?
--Jason
On May 10, 2019 20:15:56 Marek Olšák wr
We have unit tests for that pass. Maybe you could write one which
exercises the issue? It'd help in debugging.
On Thu, May 9, 2019 at 8:12 PM Dave Airlie wrote:
> I've got a bunch of cases where copy prop vars is getting things wrong
> around casts, it finds a store to an vec2 but ends up with
Reviewed-by: Jason Ekstrand
On Fri, May 10, 2019 at 12:59 PM Alyssa Rosenzweig
wrote:
> This allows algebraic optimizations to check if the argument accesses
> multiple distinct components of a vector. So a swizzle like "xyz" will
> return true, but "yyy" will r
On Wed, May 8, 2019 at 1:29 PM Matt Turner wrote:
> Whoops/Nice!
>
> Are there any shader-db changes as a result?
>
total instructions in shared programs: 15311103 -> 15311100 (<.01%)
instructions in affected programs: 1554 -> 1551 (-0.19%)
helped: 3
HURT: 0
total cycles in shared programs: 355
We only have one node per VGRF so this was adding way too much
interference. No idea how we didn't catch this before.
Fixes: 014edff0d20d "intel/fs: Add interference between SENDS sources"
---
src/intel/compiler/brw_fs_reg_allocate.cpp | 11 +++
1 file changed, 3 insertions(+), 8 deletio
They aren't. It's just a function pointer. We could add support for it but
it doesn't seem worth the effort.
On May 7, 2019 17:42:23 Alyssa Rosenzweig wrote:
Gotcha. I wasn't sure negations in the NIR search rule were possible...?
___
mesa-dev maili
That's a bit gross that we have to do that Oh, well.
Reviewed-by: Jason Ekstrand
On Mon, Apr 29, 2019 at 6:01 PM Matt Turner wrote:
> In the FS IR we pretend that the instruction is predicated with (+f0.1)
> just for flag dependency tracking purposes. Since the instructio
cessors, where a convergent
> > swizzle can be done in one clock (replicating as if a scalar) but a
> > divergent one must be scalarized. In these cases, it is useful to
> > optimize differently based on whether the swizzle diverges. (Use case is
> > the &quo
m.color_outputs_valid & BITFIELD_RANGE(rt,
> array_len))) {
> + /* Unused or out-of-bounds, throw it away, unless it is the first
> + * RT and we have alpha to coverage enabled.
> + */
> + if (rt != 0 || !stage->key.wm.alpha_to_coverage) {
ke Dylan's suggestions (which I think are
reasonable), it doesn't use the length. Second, it means that the C code
will now have an unverifiable random number in it. Are you sure it's
really 137? I dare you to go count them.
--Jason
> On Fri, May 3, 2019 at 10:26 PM Jason Eks
101 - 200 of 12089 matches
Mail list logo
