Debian packaging apparently just decided not to include i915g in the
transition? Not our fault.
On Mon, Dec 5, 2022 at 9:59 AM Rodrigo Vivi wrote:
> Cc: mesa-dev ml
>
> On Sat, Dec 03, 2022 at 03:00:44AM -0500, Felix Miata wrote:
> > From libgl1-mesa-dri:amd64 changelog:
> > mesa (22.0.0~rc2-1)
Now that Amber exists and glvnd seems to be the route we plan on for
"supporting" old DRI drivers, I'm working toward garbage collecting a lot
of extra layering that we have to support out of tree DRI drivers. I feel
that the loader interface gets in the way of implementing new EGL
functionality,
I just posted a status update to the MR with the summary of remaining work:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8044#note_1346175
I started this project back in December 2020, and have been pushing all the
TGSI drivers along since then. We're down to very few test regressio
Welcome! I'm really excited to see this happening, and your early
upstreaming work.
On Fri, Mar 4, 2022 at 7:44 AM wrote:
>
> Hi All,
>
> I'm excited to share that over the last year we've been working on a new
> Vulkan driver, compiler and Linux kernel DRM driver for our PowerVR
> GPUs. As it w
On Fri, Jan 7, 2022 at 6:18 AM Connor Abbott wrote:
>
> Unfortunately batch mode has only made it *worse* - I'm sure it's not
> intentional, but it seems that it's still running the CI pipelines
> individually after the batch pipeline passes and not merging them
> right away, which completely defe
As you've probably noticed, there have been issues with git access
this week. The fd.o sysadmins are desperately trying to stay on
vacation because they do deserve a break, but have still been working
on the problem and a couple of solutions haven't worked out yet.
Hopefully we'll have some news s
On Mon, Dec 6, 2021 at 3:50 PM Dylan Baker wrote:
>
> Classic is gone, and the cleanups have begun, obviously. There is
> another cleanup that I had in mind, which is moving src/mesa into
> src/gallium/frontends/mesa. This makes the build system a little
> cleaner, as currently we do some bending
On Sun, Oct 10, 2021 at 4:44 PM apinheiro wrote:
>
> Answering here, as it is the second time it is mentioned that Rb is only
> for "who can help support this years from now?", but not specifically to
> this email.
>
> On 7/10/21 15:00, Alyssa Rosenzweig wrote:
> >> I would love to see this be the
"
On Thu, Oct 7, 2021 at 1:38 AM Eero Tamminen wrote:
>
> Hi,
>
> On 6.10.2021 23.00, Jordan Justen wrote:
> > Bas Nieuwenhuizen writes:
> >> On Wed, Oct 6, 2021 at 8:49 PM Jordan Justen
> >> wrote:
> >>> I guess I missed where it was suggested that Marge should remove
> >>> Reviewed-by tags.
On Wed, Oct 6, 2021 at 12:28 PM Jordan Justen wrote:
>
> Mike Blumenkrantz writes:
>
> > On Wed, Oct 6, 2021 at 1:27 PM Bas Nieuwenhuizen
> > wrote:
> >
> >> On Wed, Oct 6, 2021 at 7:07 PM Jason Ekstrand
> >> wrote:
> >> >
> >> > My primary grip with approvals or the 👍 button is that it's the w
On Wed, Oct 6, 2021 at 10:07 AM Jason Ekstrand wrote:
>
> On Wed, Oct 6, 2021 at 11:24 AM Emma Anholt wrote:
> >
> > On Wed, Oct 6, 2021 at 9:20 AM Mike Blumenkrantz
> > wrote:
> > >
> > > Hi,
> > >
> > > It's recently come to my
On Wed, Oct 6, 2021 at 9:20 AM Mike Blumenkrantz
wrote:
>
> Hi,
>
> It's recently come to my attention that gitlab has Approvals. Was anyone else
> aware of this feature? You can just click a button and have your name
> recorded in the system as having signed off on landing a patch? Blew my mind
p-runner code:
https://gitlab.freedesktop.org/anholt/deqp-runner/-/merge_requests/14
Mesa commit showing its use:
https://gitlab.freedesktop.org/anholt/mesa/-/commit/8c70ab9a9e285882ec9740f1a1f058b3135c5ee9
Test Mesa pipeline:
https://gitlab.freedesktop.org/anholt/mesa/-/pipelines/365283
Should any
ea was to put everything in a classic branch and let distros
> > run "classic" hardware from that. What happens after 3 releases does i965
> > still go to the classic branch with the other classic drivers? If so is it
> > really worth waiting just because Ubuntu
On Mon, Jun 7, 2021 at 1:53 AM Zong, Wei wrote:
>
>
>
> > -Original Message-
> > From: Palli, Tapani
> > Sent: Thursday, June 3, 2021 1:23 PM
> > To: Zong, Wei ; mesa-dev@lists.freedesktop.org
> > Subject: Re: [Mesa-dev] bad performance issue in GPU & CPU data sharing
> >
> > Hi;
> >
> >
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 alon
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.
>
> Fi
+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
u can feed into the framework's
html generation
I would love to hear from anyone else who wants to try it out and see
how it works for you. repo at
https://gitlab.freedesktop.org/anholt/deqp-runner for any issues you
want to file.
___
mesa-dev mailin
, and flake
handling, and regressoin tracking, and etc.) should all be improved.
Installation instructions at:
https://gitlab.freedesktop.org/anholt/deqp-runner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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 n
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
> ha
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 r
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 b
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 x8
sary to enable it.
> > Currently fighting with meson cross files a bit, but the linting works
> > and the amd64 build works.
> >
> > https://gitlab.freedesktop.org/anholt/mesa/-/commits/ci-rust
>
> Good luck :)
>
> I didn't think to enforce a lint during CI. Pa
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 yo
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 m
thoughts.
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 with meson cross files a bit, but the linting works
and the amd64 build works.
https://gitlab.freedesktop.org/anholt/mesa/-/commits/ci-rust
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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 t
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:
> https://gitlab.freedesktop.
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
gi
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 suitable,
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 r
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 probl
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 reposi
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. nir_op_ufin
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
But as long as that's the resources we have, then we're paying
> > the cloud tradeoff, where we pay more money in exchange for fewer
> > problems.
>
> Admin for gitlab and CI is a full time role anyways. The system is
> definitely not self sustaining without time bei
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 long
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 enterpri
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 lis
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
mesa-dev@
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 mesa
at Marge rebased (they'll always
be rebased), you'll get:
Part-of:
<https://gitlab.freedesktop.org/anholt/gitlab-experiments/merge_requests/3>
In the final commit of that MR, you'll get:
Tested-by: Marge Bot
<https://gitlab.freedesktop.org/anholt/gitlab-experiments/merge_req
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 t
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 peop
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 drive
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
>>>
part of the 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 wit
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 .gi
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 MR
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
op the a630-specific skip list.
The lab has also been up for long enough that I'm convinced the HW is
stable enough to subject you all to it.
Once this is merged, please @anholt me on your MRs if you find spurious
failures in freedreno so I can go either disable those tests or fix
them.
For som
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
>
> GALLIVM_DEBUG=no_rho_approx,no_brilinear,no_q
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 g
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 ta
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 fir
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 th
tlab.freedesktop.org/mesa/piglit/tree/master/tests/apitrace
https://github.com/anholt/trace-db
It was bad. diff-images is too picky and you end up needing to bless
new images constantly. I have decided to not pursue this line of
testing any further because it was so unproductive.
What I *am* inter
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 co
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 na
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 deqp
"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 Tuesd
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 lik
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
> t
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 i
w.
>
>> Why not use pipe_reference instead of open-coding? That helper contains
>> some neat debug-helpers etc...
>
> pipe_reference kind of scares me... Most of the abstractions here are
> based heavily on v3d's; I figure if anholt had a good reason to do it,
> th
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 b
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 bi
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(..) instead
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
>> ---
>> src/gallium/auxiliary/util/u_tran
CONNECTION 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
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 initiali
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 --prefix
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?
signature.as
approach 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
m
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 s
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 would
1 - 100 of 5769 matches
Mail list logo
