On Tue, Mar 23, 2021 at 7:02 AM Jason Ekstrand wrote:
>
> Trying to pick this discussion back up. Daniel Stone thinks it's a
> half hour of API bashing to retarget all the MRs so, if the fd.o
> admins have some heads up, it should be tractable. Should we do this
> right after branching 21.1
On Mon, Mar 22, 2021 at 3:27 PM Dylan Baker wrote:
>
> Hi list,
>
> We've talked about it a number of times, but I think it's time time to
> discuss splitting the classic drivers off of the main development branch
> again, although this time I have a concrete plan for how this would
> work.
>
>
+1 to all of this.
On Mon, Mar 15, 2021 at 1:54 PM Jason Ekstrand wrote:
>
> Three comments:
>
> 1. +1
> 2. Khronos has generally standardized on American English in their
> specs so I guess that provides some sort of prior art or something.
> 3. I'd generally be a fan of encouraging American
I wanted to link everyone to the new piglit runner that @pepp wrote
based on the deqp-runner codebase. You can find build instructions
and example command lines at https://crates.io/crates/deqp-runner
I'm planning on using it in freedreno CI. Some notable features it
has for freedreno compared
Just wanted to give a heads up that I've pushed a new release of the
deqp runner with fixes for test runtime based on today's investigation
into the cost of including skipped tests in the list of tests to run.
I've retuned the maximum test group size and disabled (by default)
some test group size
If you're like me, you may have noticed that when you're hacking on
something and rebuilding repeatedly, the ninja build spends a whole
lot of time on:
[1/90] Generating git_sha1.h with a custom command
I found https://github.com/nico/ninjatracing today and applied it, and
it looks like there's
You need to enable kmsro.
On Wed, Jan 6, 2021 at 3:31 AM wrote:
>
> Hi all,
>
> In order to check whether a OpenGL ES driver bug I'm hitting on the
> Raspberry Pi 4 still appears in the latest Mesa version, I'm trying to
> build Mesa myself and run my application with that. Unfortunately I'm
>
Classic swrast didn't have MSAA either, so it sounds like softpipe
meets your requirements as stated.
I suspect actually by MSAA you meant GL_POLYGON_SMOOTH_HINT, the weird
old sometimes-it-gets-you-coverage-in-alpha-output knob. Since you're
software rasterizing, I'd recommend that you instead
I've added you to chanserv permissions (I think), feel free to use it
for that spammer. Thanks!
On Sun, Dec 27, 2020 at 9:01 PM Ryan Houdek wrote:
>
> Can someone with permissions give me +o in #dri-devel through chanserv?
> IRC alias is HdkR, Nickserv alias is Sonicadvance1.
>
> Nobody should
On Mon, Nov 9, 2020 at 2:19 AM Federico Dossena wrote:
>
> I'm sorry to bother you in the dev list but it seems to be the only one
> with activity so it seems like the best place to ask.
>
> I maintain some Mesa builds for Windows. These are builds of libgl-gdi
> with llvmpipe, for both x86 and
On Wed, Oct 14, 2020 at 3:26 PM Alyssa Rosenzweig
wrote:
>
> > Since the majority opinion seemed to be "if someone wanted to use it
> > in a leaf node without making everyone use it, that's fine", I've
> > started trying to put together the CI bits necessary to enable it.
> > Currently fighting
On Tue, Oct 13, 2020 at 1:13 AM andrey simiklit
wrote:
>
> Hi,
>
> I would like to request merge access for piglit gitlab. I have contributed a
> number of commits for mesa/piglit. It would help in my work because sometimes
> even already reviewed MRs remain not pushed for months.
I've added
On Tue, Oct 13, 2020 at 12:08 AM Thomas Zimmermann wrote:
>
> Hi
>
> On Fri, 02 Oct 2020 08:04:43 -0700 "Dylan Baker" wrote:
>
> > I have serious concerns about cargo and crate usage. Cargo is basically npm
> > for rust, and shares all of the bad design decisions of npm, including
> > linking
On Thu, Oct 1, 2020 at 6:36 PM Alyssa Rosenzweig
wrote:
>
> Hi all,
>
> Recently I've been thinking about the potential for the Rust programming
> language in Mesa. Rust bills itself a safe system programming language
> with comparable performance to C [0], which is a naturally fit for
> graphics
On Fri, Oct 2, 2020 at 8:05 AM Dylan Baker wrote:
>
> I have serious concerns about cargo and crate usage. Cargo is basically npm
> for rust, and shares all of the bad design decisions of npm, including
> linking multiple versions of the same library together and ballooning
> dependency lists
On Thu, Oct 1, 2020 at 6:36 PM Alyssa Rosenzweig
wrote:
>
> Hi all,
>
> Recently I've been thinking about the potential for the Rust programming
> language in Mesa. Rust bills itself a safe system programming language
> with comparable performance to C [0], which is a naturally fit for
> graphics
On Sat, Sep 19, 2020 at 3:24 AM Marek Olšák wrote:
>
> Hi,
>
> I don't know if you have been following gitlab, but there are a few cleanups
> that I have been considering doing.
>
> Rename PIPE_TRANSFER flags to PIPE_MAP, and pipe_transfer_usage to
> pipe_map_flags:
>
I'd love to get some review on
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3395
I think it's time to make the switch for softpipe. It improves
performance significantly (~10%) and makes it pass far more piglit
tests than glsl_to_tgsi does. There are 5 regressions in doubles, but
On Sun, Aug 16, 2020 at 2:01 PM Dave Airlie wrote:
>
> meson-gallium builds all the gallium drivers but no vulkan drivers.
> meson-vulkan builds all the vulkan driver but no gallium.
>
> I've changed the enable to be -Dvulkan-drivers=swrast to enable it, so
> I suppose the former is more
On Mon, Aug 3, 2020 at 8:30 AM Jason Ekstrand wrote:
>
> All,
>
> I'm sure by now you've all seen the articles, LKML mails, and other
> chatter around inclusive language in software. While mesa doesn't
> provide a whole lot of documentation (hah!), we do have a website, a
> code-base, and a git
Looks like in configuring the runners to do !5661's nginx for getting
artifacts (.qpa xml files, particularly), I forgot that I had
previously used that port for passthrough caching of fd.o access to
reduce egress (which has been unused since switching off of LAVA).
And, after identifying the
With the landing of
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5839 we
entered a state that caused future pipelines to fail.
This is due to an unfortunate interaction between gitlab MRs and
ci-templates' model of container image distribution: MRs are tested in
the submitter's
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 currently has a few instructions that does kinda the same:
>
> 1.
On Fri, Feb 28, 2020 at 1:20 AM Eero Tamminen wrote:
>
> Hi,
>
> On 28.2.2020 10.48, Dave Airlie wrote:
> >> Yes, we could federate everything back out so everyone runs their own
> >> builds and executes those. Tinderbox did something really similar to
> >> that IIRC; not sure if Buildbot does as
On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie wrote:
>
> On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
> >
> > On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote:
> > > b) we probably need to take a large step back here.
> > >
> > > Look at this from a sponsor POV, why would I give X.org/fd.o
>
On Tue, Feb 25, 2020 at 3:42 PM Kristian Høgsberg wrote:
>
> It's been a while since Dylan did the work to make meson support
> Windows and there's been plenty of time to provide feedback or improve
> argue why we still need scons. I haven't seen any such discussion and
> I think we've waited
On Tue, Feb 4, 2020 at 7:54 PM Rob Clark wrote:
>
> it seems like BE vs formats (vs llvm) is a constant nightmare, because
> there are essentially no mesa dev's working on BE devices (ie. issues
> are generally discovered long after the fact when mesa changes finally
> propagate into into
On Thu, Jan 23, 2020 at 9:44 AM Jason Ekstrand wrote:
>
> Should we make iris the default for 20.0? I think it's time. Sadly, gitlab
> milestones don't let you comment on them.
It does seem like it's time to flip that switch.
___
mesa-dev mailing
marge broke over the holidays due to a gitlab upgrade. It's unclear
when we'll get it back up -- daniels might do a downgrade but is
currently out sick
https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/228
___
mesa-dev mailing list
On Tue, Dec 17, 2019 at 9:53 AM Juan A. Suarez Romero
wrote:
>
> On Fri, 2019-12-13 at 13:35 -0800, Eric Anholt wrote:
> > I finally got back around to experimenting with the gitlab merge bot,
> > and it turns out that the day I spent a few weeks back I had actually
> > g
On Fri, Dec 13, 2019 at 1:35 PM Eric Anholt wrote:
>
> I finally got back around to experimenting with the gitlab merge bot,
> and it turns out that the day I spent a few weeks back I had actually
> given up 5 minutes before the finish line.
>
> Marge is now enabled for
I finally got back around to experimenting with the gitlab merge bot,
and it turns out that the day I spent a few weeks back I had actually
given up 5 minutes before the finish line.
Marge is now enabled for mesa/mesa, piglit, and parallel-deqp-runner.
How you interact with marge:
- Collect your
On Wed, Dec 11, 2019 at 2:35 PM Timothy Arceri wrote:
>
> Hi,
>
> So it seems lately we have been increasingly merging patches with made
> up names, or single names etc [1]. The latest submitted patch has the
> name Icecream95. This seems wrong to me from a point of keeping up the
> integrity of
On Fri, Dec 6, 2019 at 3:56 PM Rob Clark wrote:
>
> On Fri, Dec 6, 2019 at 3:46 PM Bas Nieuwenhuizen
> wrote:
> >
> > On Fri, Dec 6, 2019 at 10:49 AM Michel Dänzer wrote:
> > >
> > >
> > > I just merged
> > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2794 , which
> > > affects
On Tue, Dec 3, 2019 at 4:39 PM 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 drivers won't share any code with master. glvnd will load them,
On Tue, Dec 3, 2019 at 10:48 PM Marek Olšák wrote:
>
> On Wed., Dec. 4, 2019, 01:20 Tapani Pälli, wrote:
>>
>> Hi;
>>
>> On 12/4/19 2:39 AM, Marek Olšák wrote:
>> > Hi,
>> >
>> > Here are 2 proposals to simplify and better optimize the GL->Gallium
>> > translation.
>> >
>> > 1) Move classic
On Tue, Nov 19, 2019 at 8:26 AM Jason Ekstrand wrote:
>
> 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
Eero Tamminen writes:
> Hi,
>
> On 27.9.2019 4.32, Eric Anholt wrote:
>> Alexandros Frantzis writes:
>>> The last couple of months we (at Collabora) have been working on a
>>> prototype for a Mesa testing system based on trace replays that supports
&
e upstream
> Mesa testing pipelines.
>
> It's worth noting that the last few months other people, most notably
> Eric Anholt, have made proposals to extend the scope of testing in CI.
> We believe there is much common ground here (multiple devices,
> deployment with gitlab runner
Eric Anholt writes:
> [ Unknown signature status ]
> I pushed the branch enabling freedreno CI today. Now all the MRs will
> get pre-merge testing with GLES3.1 on A630, and GLES2 on A307.
>
> See .gitlab-ci/README.md for more info on how it works. Also, as a
> reminder,
I pushed the branch enabling freedreno CI today. Now all the MRs will
get pre-merge testing with GLES3.1 on A630, and GLES2 on A307.
See .gitlab-ci/README.md for more info on how it works. Also, as a
reminder, if you want to get something tested before generating your MR,
you can either edit
Rob Clark writes:
> On Wed, Sep 4, 2019 at 1:42 PM Eric Anholt wrote:
>>
>> If you haven't seen this MR:
>>
>> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1632
>>
>> I feel ready to enable CI of freedreno on Mesa MRs. T
Tomeu Vizoso writes:
> On Fri, 6 Sep 2019 at 03:23, Rob Clark wrote:
>>
>> On Wed, Sep 4, 2019 at 1:42 PM Eric Anholt wrote:
>> >
>> > If you haven't seen this MR:
>> >
>> > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1632
>&
If you haven't seen this MR:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1632
I feel ready to enable CI of freedreno on Mesa MRs. There are some docs
here:
https://gitlab.freedesktop.org/mesa/mesa/blob/e81a2d3b40240651f506a2a5afeb989792b3dc0e/.gitlab-ci/README.md
Once we merge
Kenneth Graunke writes:
> [ Unknown signature status ]
> 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 per day, sweeping new reports under the rug, hiding comments,
> etc. This
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 some llvmpipe optimizations. You can do this by running with
>
>
Boris Brezillon writes:
> Hello,
>
> Alyssa recently proposed that I push my own panfrost-related
> submissions once they received proper review and are considered
> ready to merged (meaning that received enough A-b/R-b tags).
>
> In order to do that, I'd need to obtain write permissions on the
Jason Ekstrand writes:
> 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
>> >
Eric Engestrom writes:
> On Saturday, 2019-06-29 22:59:21 +0200, apinheiro wrote:
>>
>> On 29/6/19 2:30, Rob Clark wrote:
>> > I had interpreted it as literally the "block the gitlab merge button"
>> > option, ie. "I want to get feedback but it is not ready to merge and
>> > I'll drop the WIP
Daniel Stone writes:
> Hi,
>
> On Tue, 25 Jun 2019 at 16:07, Jason Ekstrand wrote:
>> On Tue, Jun 25, 2019 at 4:04 AM Daniel Stone wrote:
>>> 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
Elie Tournier writes:
> On Mon, Jun 24, 2019 at 11:41:55AM -0700, Eric Anholt wrote:
>> Elie Tournier writes:
>>
>> > Hi there,
>> >
>> > Great topic. For the past few days, I was looking at a CI for Mesa:
>> > https://gitlab.freedesktop.org
Rob Clark writes:
> On Thu, Jun 20, 2019 at 12:26 PM Eric Anholt wrote:
>
> (tbh I've not really played w/ renderdoc yet.. I should probably do so..)
>
>> - Mozilla folks tell me that firefox's WebRender display lists can be
>> captured in browser and then replaye
Elie Tournier writes:
> Hi there,
>
> Great topic. For the past few days, I was looking at a CI for Mesa:
> https://gitlab.freedesktop.org/hopetech/tracie
> OK, it's in a very very alpha stage. ;)
I did one of those things using apitrace diff-images in piglit:
Hey folks, I wanted to show you this follow-on to shader-db I've been
working on:
https://gitlab.freedesktop.org/anholt/renderdoc-traces
For x86 development I've got a collection of ad-hoc scripts to capture
FPS numbers from various moderately interesting open source apps so I
could compare-perf
Marek Olšák writes:
> From: Marek Olšák
>
> This helps fix:
> piglit/bin/ext_image_dma_buf_import-sample_yuv -fmt=NV12 -auto
>
> Fixes: d88f3392fff7c6342f3840c4bd8195a1296c2372
Reviewed-by: Eric Anholt
Apologies, I had only tested with the CTS.
signature.asc
Descript
Alyssa Rosenzweig writes:
> Complementing the new API-agnostic shader_enum blending style, we add
> helpers to translate between the two forms. Ideally, we could just use
> PIPE blending directly, but that makes Vulkan support challenging.
>
> Signed-off-by: Alyssa Rosenzweig
&g
ned-off-by: Alyssa Rosenzweig
> Cc: Eric Anholt
> Cc: Kenneth Graunke
> ---
> src/compiler/shader_enums.h | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/src/compiler/shader_enums.h b/src/compiler/shader_enums.h
> index ac293af451
Alyssa Rosenzweig writes:
>> Logic ops seem... challenging to emulate in the shader. That shader
>> would need the destination colors in the framebuffer storage format, and
>> I'm not sure that's always possible (maybe?).
>
> Alright, that's good to know.
>
> I will note that in Midgard, the
Alyssa Rosenzweig writes:
>> We start by building a container in Docker that contains a suitable
>> rootfs and kernel for the DUT, deqp and all dependencies for building
>> Mesa itself.
>
> Out of curiosity, what's the performance impact of this? If there are no
> changes to the kernel or to
"Zhou, David(ChunMing)" writes:
> Will linux be only mesa-linux? I thought linux is an open linux.
> Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need?
> reject?
> 2. one hw feature that opengl/amdvlk
Marek Olšák writes:
> On Tue, Apr 23, 2019 at 4:39 PM Mathias Fröhlich
> wrote:
>
>> Hi,
>>
>> On Tuesday, 23 April 2019 22:23:45 CEST Marek Olšák wrote:
>> > On Tue, Apr 23, 2019 at 4:05 PM Mathias Fröhlich <
>> mathias.froehl...@gmx.net>
>> > wrote:
>> >
>> > > Hi Marek,
>> > >
>> > > On
Jason Ekstrand writes:
> All,
>
> I've seen discussions come up several times lately about whether you should
> use MAYBE_UNUSED or UNUSED in what scenario and why do we have two of them
> anyway. That got me thinking a bit. Maybe what we actually want instead
> of MAYBE_UNUSED is something
Lucas Stach writes:
> The Mesa state tracker will emulate YUV texture sampling for drivers that
> don't support it natively by using multiple R8/RG88 samplers. Teach
> dri2_query_dma_buf_modifiers about this special case.
> This allows clients like GStreamer glupload or Kodi to properly query
>
Lucas Stach writes:
> From: Philipp Zabel
>
> Fix the gbm_dri_bo_get_handle_for_plane use case by allowing plane > 0
> in dri2_from_planar for images with multiple planes in separate chained
> texture resources.
This looks like a partial fix to me -- the dup will leave the child
image with the
t; 4 && tex; tex = tex->next)
> + i++;
> + *value = i;
>return GL_TRUE;
What's the "< 4" limit for? Other than that, patch 1-2 are:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Michel Dänzer writes:
> On 2019-04-15 12:57 p.m., Lucas Stach wrote:
>> Am Montag, den 15.04.2019, 12:04 +0200 schrieb Michel Dänzer:
>>> On 2019-04-12 7:33 p.m., Lucas Stach wrote:
Unconditionally requesting both bindings can lead to premature
failure to create a valid image.
Michel Dänzer writes:
> On 2019-04-12 7:33 p.m., Lucas Stach wrote:
>> Unconditionally requesting both bindings can lead to premature
>> failure to create a valid image.
>>
>> Signed-off-by: Lucas Stach
>> ---
>> src/gallium/state_trackers/dri/dri2.c | 13 +++--
>> 1 file changed, 11
Alyssa Rosenzweig writes:
>> > diff --git a/src/gallium/drivers/panfrost/pan_job.c
>> > b/src/gallium/drivers/panfrost/pan_job.c
>> > index 66a8b0d4b07..6c68575158f 100644
>> > --- a/src/gallium/drivers/panfrost/pan_job.c
>> > +++ b/src/gallium/drivers/panfrost/pan_job.c
>> > @@ -27,6 +27,13 @@
slot to take advantage of vectorized
> transform math). This patch adds vec3 scale/offset fields corresponding
> to the 3D Gallium viewport / glViewport+depth
>
> Signed-off-by: Alyssa Rosenzweig
> Cc: Eric Anholt
Reviewed-by: Eric Anholt
signature.asc
Ilia Mirkin writes:
> Shouldn't this sort of decision be left up to the driver? If the
> driver would like to use CS for blits, fine, but why not let it blit
> in the most optimal way possible and force it to use a compute shader?
Yeah, commit messages require an explanation of why a change is
Alyssa Rosenzweig writes:
>> Can you reuse u_vbuf_get_minmax_index()?
>
> From a preliminary read, it didn't look like that did caching?
It doesn't, but the inside of your caching function should probably be
using it.
signature.asc
Description: PGP signature
Alyssa Rosenzweig writes:
> This code is probably a wholesale duplication of the corresponding code
> in mesa/src/vbo/vbo_minmax_indices.c; we should investigate reusing
> that.
Can you reuse u_vbuf_get_minmax_index()?
signature.asc
Description: PGP signature
I've just put up a new repo that I'm hoping to use to enable automatic
shader-db results for various drivers on Gitlab CI merge requests (and
maybe with some more work, delete the simulator backends of vc4 and v3d).
https://gitlab.freedesktop.org/anholt/drm-shim
I've copied a bit of Mesa stuff
Rob Clark writes:
> On Thu, Mar 14, 2019 at 3:35 PM Eric Anholt wrote:
>>
>> Rob Clark writes:
>>
>> > On Fri, Mar 1, 2019 at 10:54 AM Christian Gmeiner
>> > wrote:
>> >>
>> >> Use u_transfer_helper_resource_create(..) inst
Rob Clark writes:
> On Fri, Mar 1, 2019 at 10:54 AM Christian Gmeiner
> wrote:
>>
>> Use u_transfer_helper_resource_create(..) instead which uses the
>> resource_create(..) function specified in u_transfer_vtbl.
>>
>> Signed-off-by: Christian Gmeiner
>> ---
>>
ECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#ifndef U_DRM_H
> +#define U_DRM_H
> +
> +#include
Maybe add a #include since you also use bool.
Other than that, the series is:
Reviewed-by: Eric Anholt
signature.asc
Descr
Ilia Mirkin writes:
> I believe the distinction here is between initializing all the fields
> and using them individually (thus leaving the padding uninitialized),
> vs using the fields to create a structure to hash as a sequence of
> bytes. For the latter, you really need all the memory
Brian Paul writes:
> On 03/11/2019 04:47 PM, Eric Anholt wrote:
>> Brian Paul writes:
>>
>>> Since the compiler may not zero-out padding in the object.
>>> Add a couple comments about this to prevent misunderstandings in
>>> the future.
>>&g
Brian Paul writes:
> Since the compiler may not zero-out padding in the object.
> Add a couple comments about this to prevent misunderstandings in
> the future.
>
> Fixes: 67d96816ff5 ("st/mesa: move, clean-up shader variant key decls/inits")
> ---
> src/mesa/state_tracker/st_atom_shader.c | 9
Eric Engestrom writes:
> On 2019-03-08 at 03:42, Brian Paul wrote:
>> Add new Introduction and Advanced Usage sections.
>> Spell out a few more details, like "ninja install".
>> Improve the layout around example commands.
>> Fix grammatical errors and tighten up the text.
>> Explain the
Christian Gmeiner writes:
> Use u_transfer_helper_resource_create(..) instead which uses the
> resource_create(..) function specified in u_transfer_vtbl.
I would need to run this through the CTS, as the stacking in
u_transfer_helper is fragile. What's fixed for you by this patch?
oach in iris, flushing the data cache
> on any MemoryBarrier() call, so I need st/mesa to actually call the
> pipe->memory_barrier() callback.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-d
Alyssa Rosenzweig writes:
>> Alyssa: do you see any problem if we change to submit only one atom per
>> ioctl?
>
> I don't think so; aesthetically I don't like the extra kernel traffic,
> but that's not a real concern, and it sounds like that's the correct
> approach anyway.
>
> A big reason we
Kristian Høgsberg writes:
> On Mon, Mar 4, 2019 at 6:29 PM Dave Airlie wrote:
>>
>> On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg wrote:
>> >
>> > On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig
>> > wrote:
>> > >
>> > > > Why aren't we using regular dma-buf fences here? The submit ioctl
Boris Brezillon writes:
> From: Daniel Stone
>
> pipe_boxes are x/y + width/height, rather than x0/y0 -> x1/y1. This
> means that (x+width) is not included in the box.
>
> The box intersection check was seemingly written for inclusive regions,
> and would falsely assert that adjacent boxes
Chris Wilson writes:
> Quoting Eric Anholt (2019-02-27 02:19:32)
>> Overall, I'm hesitatant to land support for actually doing anything with
>> APPLE_object_purgeable when there are no functional tests of it. I
>> don't mean to actually have tests that force purging, but at
om their own (presumably
> compressed, on disk) caches.
>
> v2: Refactor the repeated resource purging.
>
> Cc: Eric Anholt
> Cc: Kenneth Graunke
> Cc: Rob Clark
> ---
> .../drivers/freedreno/freedreno_resource.c| 10 ++
> .../drivers/freedreno/freedreno_screen.
Timothy Arceri writes:
> shader-db results i965 (SKL):
>
> total instructions in shared programs: 13219105 -> 13024761 (-1.47%)
> instructions in affected programs: 1169457 -> 975113 (-16.62%)
> helped: 599
> HURT: 154
>
> total cycles in shared programs: 333968972 -> 324822073 (-2.74%)
> cycles
One of the cpu pointers wasn't marked as read-write, causing gcc to complain:
../src/gallium/drivers/vc4/vc4_tiling_lt.c:181:17: error: output operand
constraint lacks ‘=’
__asm__ volatile (
Cc: Emil Velikov
---
This patch is for the 18.3 branch only
Carsten Haitzler writes:
> On Mon, 04 Feb 2019 16:31:57 -0800 Eric Anholt said:
>
>> Carsten Haitzler writes:
>>
>> > On Fri, 1 Feb 2019 11:08:07 + Emil Velikov
>> > said:
>> >
>> >> Hi Carsten,
>> >>
>> >
Alyssa Rosenzweig writes:
> Signed-off-by: Alyssa Rosenzweig
> ---
> src/gallium/drivers/panfrost/pan_blending.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/panfrost/pan_blending.c
> b/src/gallium/drivers/panfrost/pan_blending.c
> index
g is printed. There's no harm in
> executing the stub function in this case, but it's not "an error" to not
> have kmsro in the build; the driver missing warning should not printed
> kmsro.
>
> Signed-off-by: Alyssa Rosenzweig
> Reported-by: Karol Herbst
Reviewed-by: Eric
k at the end (avoiding clutter
> and distraction since this list may snowball in the future).
>
> v2: Alphabetize driver list.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.
st does
> - * eat application memory, which is quite limited on
> 32 bits. App
> - * shouldn't expect too much available memory. */
> -system_memory = MIN2(system_memory, 2048 << 20);
> -
This hunk looks o
viv)
> #if defined(GALLIUM_TEGRA)
> DEFINE_LOADER_DRM_ENTRYPOINT(tegra);
> #endif
> +
> +#if defined(GALLIUM_KMSRO)
> +DEFINE_LOADER_DRM_ENTRYPOINT(hx8357d)
> +DEFINE_LOADER_DRM_ENTRYPOINT(pl111)
> +DEFINE_LOADER_DRM_ENTRYPOINT(rockchip)
> +DEFINE_LOADER_DRM_ENTRYPOINT(meson)
> +#endif
Alphabetic
Alyssa Rosenzweig writes:
> Until the kernel side matures and the full driver is upstreamed, to
> avoid end-user surprises, Panfrost should only be built for the
> adventurous.
>
> Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Eric Anholt
signature.asc
Description
Carsten Haitzler writes:
> On Fri, 1 Feb 2019 11:08:07 + Emil Velikov
> said:
>
>> Hi Carsten,
>>
>> On 2019/01/31, Carsten Haitzler wrote:
>> > On Wed, 30 Jan 2019 18:33:35 + Emil Velikov
>> > said:
>> >
>> > You might want to hold off on this. My bugfix was actually patched out by
are just wants a vec4 index; NIR mirrors the GLSL; poof?
>
> I think I had troubles there, but I can't recall exactly.
Counting uniforms/attributes is all a confusing mess. I can confirm
that what I do in v3d works, I just can't explain how without going and
re-studying it.
>>
Alyssa Rosenzweig writes:
>> There's u_pipe_screen_get_param_defaults() that you really want to be
>> using to avoid regressions when people add new pipe caps. You can get
>> rid of a lot of your switch statement that way, too.
>
> Oh, good to know. Is that newer? I'm pretty sure that whole
gard_nir_algebraic.py
> b/src/gallium/drivers/panfrost/midgard/midgard_nir_algebraic.py
> new file mode 100644
> index 00..1727b7
> --- /dev/null
> +++ b/src/gallium/drivers/panfrost/midgard/midgard_nir_algebraic.py
> +algebraic = [
> +(('b2i32', a), ('iand@
1 - 100 of 5366 matches
Mail list logo
