Hi Joao,
On Fri, 26 Apr 2024 at 08:42, Joao Paulo Silva Goncalves
wrote:
> On Thu, Apr 25, 2024 at 9:08 AM Lucas Stach wrote:
> > I can reproduce the issue, but sadly there is no simple fix for this,
> > as it's a bad interaction between some of the new features.
> > At the core of the issue is
On Thu, 25 Apr 2024 at 13:08, Lucas Stach wrote:
> I can reproduce the issue, but sadly there is no simple fix for this,
> as it's a bad interaction between some of the new features.
> At the core of the issue is the dmabuf-feedback support with the chain
> of events being as follows:
>
> 1.
On Fri, 26 Jan 2024 at 00:22, Faith Ekstrand wrote:
> On Thu, Jan 25, 2024 at 5:06 PM Gert Wollny wrote:
>> I think with Venus we are more interested in using utility libraries on
>> an as-needed basis. Here, most of the time the Vulkan commands are just
>> serialized according to the Venus
Hi Christian,
On Thu, 30 Mar 2023 at 20:15, Christian Gudrian wrote:
> We're running a custom Wayland compositor based on Qt Wayland on an i.MX6
> Quad system with a Vivante GC2000 GPU using the Mesa Gallium driver. While
> the compositor itself displays correctly, client buffers are displayed
On Wed, 13 Oct 2021 at 20:13, Jordan Justen wrote:
> Alyssa Rosenzweig writes:
> >> Upstream should do what's best for upstream, not for Intel's "unique"
> >> management.
> >>
> >>Not sure how from Emma explaining how Rb tags were used by Intel
> >>management it came the conclusion
On Thu, 7 Oct 2021 at 09:38, Eero Tamminen wrote:
> This sounds horrible from the point of view of trying to track down
> somebody who knows about what's & why's of some old commit that is later
> on found to cause issues...
But why would your first point of call not be to go back to the review
Hi,
On Wed, 23 Jun 2021 at 17:20, Daniel Vetter wrote:
> +*
> +* IMPLICIT SYNCHRONIZATION RULES:
> +*
> +* Drivers which support implicit synchronization of buffer access as
> +* e.g. exposed in `Implicit Fence Poll Support`_ should follow the
> +*
Sorry for the mobile reply, but V4L2 is absolutely not write-only; there has
never been an intersection of V4L2 supporting dmabuf and not supporting reads.
I see your point about the heritage of dma_resv but it’s a red herring. It
doesn’t matter who’s right, or who was first, or where the code
Hi Christian,
On Tue, 1 Jun 2021 at 13:51, Christian König
wrote:
> Am 01.06.21 um 14:30 schrieb Daniel Vetter:
> > If you want to enable this use-case with driver magic and without the
> > compositor being aware of what's going on, the solution is EGLStreams.
> > Not sure we want to go there,
Hi,
On Tue, 1 Jun 2021 at 14:18, Michel Dänzer wrote:
> On 2021-06-01 2:10 p.m., Christian König wrote:
> > Am 01.06.21 um 12:49 schrieb Michel Dänzer:
> >> There isn't a choice for Wayland compositors in general, since there can
> >> be arbitrary other state which needs to be applied
Hi,
On Fri, 30 Apr 2021 at 10:35, Daniel Vetter wrote:
> On Fri, Apr 30, 2021 at 11:08 AM Christian König
> wrote:
> > This doesn't work in hardware. We at least need to setup a few registers
> > and memory locations from inside the VM which userspace shouldn't have
> > access to when we want
Hi,
On Tue, 20 Apr 2021 at 20:30, Daniel Vetter wrote:
> The thing is, you can't do this in drm/scheduler. At least not without
> splitting up the dma_fence in the kernel into separate memory fences
> and sync fences
I'm starting to think this thread needs its own glossary ...
I propose we
Hi,
On Tue, 20 Apr 2021 at 20:03, Bas Nieuwenhuizen
wrote:
> On Tue, Apr 20, 2021 at 8:16 PM Daniel Stone wrote:
>
>> It's a jarring transition. If you take a very narrow view and say 'it's
>> all GPU work in shared buffers so it should all work the same', then
>&g
Hi,
On Tue, 20 Apr 2021 at 19:54, Daniel Vetter wrote:
> So I can mostly get behind this, except it's _not_ going to be
> dma_fence. That thing has horrendous internal ordering constraints
> within the kernel, and the one thing that doesn't allow you is to make
> a dma_fence depend upon a
On Tue, 20 Apr 2021 at 19:00, Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Am 20.04.21 um 19:44 schrieb Daniel Stone:
>
> But winsys is something _completely_ different. Yes, you're using the GPU
> to do things with buffers A, B, and C to produce buffer Z. Y
On Tue, 20 Apr 2021 at 17:25, Marek Olšák wrote:
> Daniel, imagine hardware that can only do what Windows does: future fences
> signalled by userspace whenever userspace wants, and no kernel queues like
> we have today.
>
> The only reason why current AMD GPUs work is because they have a ring
>
Hi,
On Tue, 20 Apr 2021 at 16:46, Jason Ekstrand wrote:
> It's still early in the morning here and I'm not awake yet so sorry if
> this comes out in bits and pieces...
>
No problem, it's helpful. If I weren't on this thread I'd be attempting to
put together a 73-piece chest of drawers whose
Hi,
On Tue, 20 Apr 2021 at 16:16, Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Am 20.04.21 um 17:07 schrieb Daniel Stone:
>
> If the compositor no longer has a guarantee that the buffer will be ready
> for composition in a reasonable amount of time (which
On Tue, 20 Apr 2021 at 15:58, Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Am 20.04.21 um 16:53 schrieb Daniel Stone:
>
> On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote:
>
>> Deadlock mitigation to recover from segfaults:
>> - The kernel knows whic
Hi,
On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote:
> Deadlock mitigation to recover from segfaults:
> - The kernel knows which process is obliged to signal which fence. This
> information is part of the Present request and supplied by userspace.
> - If the producer crashes, the kernel signals
Hi,
On Tue, 20 Apr 2021 at 13:01, Daniel Vetter wrote:
> - We live in a post xf86-video-$vendor world, and all these other
> compositors rely on implicit sync. You're not going to be able to get
> rid of them anytime soon. What's worse, all the various EGL/vk buffer
> sharing things also
Hi Marek,
On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote:
> *2. Explicit synchronization for window systems and modesetting*
>
> The producer is an application and the consumer is a compositor or a
> modesetting driver.
>
> *2.1. The Present request*
>
So the 'present request' is an ioctl,
On Tue, 30 Mar 2021 at 01:34, Ilia Mirkin wrote:
> 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.
>
*jedi handwave* no it doesn't
> On
On Tue, 16 Mar 2021 at 13:08, Jason Ekstrand wrote:
> On March 16, 2021 05:06:53 Daniel Stone wrote:
>
>> On Mon, 15 Mar 2021 at 20:54, Jason Ekstrand
>> wrote:
>>
>>> Three comments:
>>>
>>> 1. +1
>>> 2. Khronos has generally st
On Mon, 15 Mar 2021 at 20:54, 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 spellings in common
>
Hi,
On Fri, 2 Oct 2020 at 08:31, Kristian Kristensen wrote:
> On Fri, Oct 2, 2020 at 8:14 AM Dave Airlie wrote:
>> My feeling is the pieces that would benefit the most are the things
>> touch the real world, GLSL compiler, SPIR-V handling, maybe some of
>> the GL API space, but I also feel
Hi,
On Mon, 3 Aug 2020 at 17:16, Jason Ekstrand wrote:
> On Mon, Aug 3, 2020 at 11:12 AM Kenneth Graunke wrote:
> > Seems reasonable to me...in the old Subversion days, we called it
> > 'trunk'...then 'master' with Git...but calling the main development
> > branch 'main' is arguably the
Hi,
On Fri, 29 May 2020 at 10:08, Erik Faye-Lund
wrote:
> In the light of the explanation above, do you still have objections to
> this split?
>
> Obviously, we haven't moved forward yet ;-)
Well, we have now after getting some agreement. Please enjoy your
shiny new https://www.mesa3d.org and
Hi,
I'm generally ambivalent on which day it moves, though depending on
how late in the day it comes out, it might not actually be Thursday -
if the release comes out late at night, I'm more likely to finish up
the migration over the weekend.
On Wed, 13 May 2020 at 13:43, Brian Paul wrote:
> On
Hi Brian,
On Fri, 8 May 2020 at 15:30, Brian Paul wrote:
> Done. easydns says it may take up to 3 hours to go into effect.
Thanks for doing this! Could you please add the following TXT records
as well (note that they're FQDN, so you might want to chop the
trailing '.mesa3d.org' from the first
Hi,
On Thu, 7 May 2020 at 18:08, Erik Faye-Lund
wrote:
> On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote:
> > It seems like only the front page is served at the moment. Is it
> > possible to get a look at the rest? The front page looks nice.
>
> Yeah, we need to set up docs.mesa3d.org
Hi,
On Tue, 25 Feb 2020 at 23:42, 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
Hi,
On Mon, 16 Mar 2020 at 15:33, 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:
Contexts are different
Hi Tomek,
On Mon, 16 Mar 2020 at 12:55, Tomek Bury wrote:
> I've been wrestling with the sync problems in Wayland some time ago, but only
> with regards to 3D drivers.
>
> The guarantee given by the GL/GLES spec is limited to a single graphics
> context. If the same buffer is accessed by 2
Hi Jan,
On Fri, 28 Feb 2020 at 10:09, Jan Engelhardt wrote:
> On Friday 2020-02-28 08:59, Daniel Stone wrote:
> >I believe that in January, we had $2082 of network cost (almost
> >entirely egress; ingress is basically free) and $1750 of
> >cloud-storage cost (almost all
On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund
wrote:
> On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote:
> > Yeah, changes on vulkan drivers or backend compilers should be
> > fairly
> > sandboxed.
> >
> > We also have tools that only work for intel stuff, that should never
> > trigger
On Fri, 28 Feb 2020 at 08:48, Dave Airlie wrote:
> On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
> > The last I looked, Google GCP / Amazon AWS / Azure were all pretty
> > comparable in terms of what you get and what you pay for them.
> > Obviously providers like Packet
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
> sponsorship money that they are just giving straight to google to pay
> for hosting credits? Google are profiting in some minor
Hi Matt,
On Thu, 27 Feb 2020 at 23:45, Matt Turner wrote:
> We're paying 75K USD for the bandwidth to transfer data from the
> GitLab cloud instance. i.e., for viewing the https site, for
> cloning/updating git repos, and for downloading CI artifacts/images to
> the testing machines (AFAIU).
I
Hi Devashish,
It sounds like your application, as well as eglinfo, are not even
trying to use Wayland. Maybe they are autodetecting the platform
incorrectly and trying to use GBM instead. This could perhaps be
solved by setting the $WAYLAND_DISPLAY environment variable to the
name of the socket
Hi,
On Fri, 3 Jan 2020 at 16:57, Eric Anholt wrote:
> 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
I've pushed a
On Wed, 11 Dec 2019 at 22:35, Timothy Arceri wrote:
> 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 the project.
; Let's not expose the ->set_damage_region() method until the core is
> fixed to handle that properly.
>
> Cc: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Boris Brezillon
Acked-by: Daniel Stone
___
mesa-dev mailing list
mes
Hi Boris,
On Tue, 1 Oct 2019 at 09:25, Boris Brezillon
wrote:
> On Mon, 2 Sep 2019 16:32:01 +0200 Michel Dänzer wrote:
> > On 2019-08-30 7:00 p.m., Boris Brezillon wrote:
> > > So, next question is, do you think it's acceptable to pass a
> > > DRIcontext here, and if not, do you have any idea
Hi Kyle,
On Fri, 27 Sep 2019 at 17:06, Kyle Brenneman wrote:
> Okay, I've imported the Github repository here:
> https://gitlab.freedesktop.org/glvnd/libglvnd
That's great, thanks! I've given Adam Jackson access as requested (go
to the 'members' tab from the glvnd group page). It sounds like it
On Wed, 18 Sep 2019 at 20:43, Mark Janes wrote:
> Adam Jackson writes:
> > Strictly, the "Reporter" access level and above can manage labels,
> > milestones require "Developer" or above. Not super meaningful since the
> > mesa group really only has Developer or above.
> >
> > I'm not super
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 looks like it will migrate everything, i.e.
> repo, issues, prs, etc.
Yeah, we definitely
Hi,
On Sat, 31 Aug 2019 at 20:34, Matt Turner wrote:
> Getting patches into libglvnd has proven quite difficult (see [0] for
> example). There was some talk of moving it to FreeDesktop Gitlab on
> IRC recently. Can we move forward with that? Are there objections to
> doing so?
We'd be happy to
Hi Boris,
On Sat, 31 Aug 2019 at 18:33, Boris Brezillon
wrote:
> On Sat, 31 Aug 2019 17:06:30 +0100 Daniel Stone wrote:
> > On Fri, 30 Aug 2019 at 17:00, Rohan Garg wrote:
> > > Both the BO cache and the transient pool are shared across
> > > context's. Protect a
*ctx,
> - struct panfrost_batch *batch,
> +panfrost_job_clear(struct panfrost_batch *batch,
> unsigned buffers,
> const union pipe_color_union *color,
> double depth, unsigned stencil);
The series looks good
Hi Boris,
On Sat, 31 Aug 2019 at 11:47, Boris Brezillon
wrote:
> Right now, the transient memory allocator implements its own BO caching
> mechanism, which is not really needed since we already have a generic
> BO cache. Let's simplify things a bit.
>
> [...]
>
> bool fits_in_current =
Hi Rohan,
On Fri, 30 Aug 2019 at 17:00, Rohan Garg wrote:
> Both the BO cache and the transient pool are shared across
> context's. Protect access to these with mutexes.
These fixes seem right to me, and (minus the issues Boris pointed
out), both are:
Reviewed-by: Daniel Stone
I
Hi,
On Thu, 29 Aug 2019 at 21:35, Chris Wilson wrote:
> Quoting Kristian Høgsberg (2019-08-29 21:20:12)
> > On Thu, Aug 29, 2019 at 12:44 PM Chris Wilson
> > wrote:
> > > Quoting Kenneth Graunke (2019-08-29 19:52:51)
> > > > - Moving bug reports between the kernel and Mesa would be harder.
> >
Hi,
On Wed, 28 Aug 2019 at 11:18, Michel Dänzer wrote:
> On 2019-08-28 3:08 a.m., Eric Engestrom wrote:
> > On Tuesday, 2019-08-27 13:31:22 +, Jose Fonseca wrote:
> >> Appveyor seems to be building other MR 1781:
> >>
> >> https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/26989425
>
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 specifics of VideoCore hardware, but
at least for some of the common
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 require dealing with the hosting
> provider, getting it to host clones, etc. Everyone has email.
My position - and the evidence of
Hi,
On Fri, 5 Jul 2019 at 14:51, Alyssa Rosenzweig
wrote:
> > + switch(whandle->modifier) {
> > + case DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP):
> > + rsc->layout = PAN_AFBC;
> > + break;
>
> Why ROCKCHIP in particular? AFBC fourcc codes are based on
On Fri, 5 Jul 2019 at 14:38, Alyssa Rosenzweig
wrote:
> > +bool should_tile = !is_streaming && is_texture && is_2d &&
> > !is_scanout;
>
> I'm not opposed, but why can't we tile PIPE_BIND_SHARED textures? lima
> does exactly that. If we can't tile them, we certainly can't AFBC them.
We
Hi,
On Thu, 4 Jul 2019 at 09:47, Tomeu Vizoso wrote:
> On Thu, 4 Jul 2019 at 10:05, Tomeu Vizoso wrote:
> > -pres->layout = should_tile ? PAN_TILED : PAN_LINEAR;
> > + if (want_afbc || (is_renderable && can_afbc && !is_texture))
> > +pres->layout = PAN_AFBC;
>
> We
Hi Tomeu,
On Thu, 4 Jul 2019 at 09:05, Tomeu Vizoso wrote:
> @@ -362,14 +392,19 @@ panfrost_resource_create_bo(struct panfrost_screen
> *screen, struct panfrost_reso
>
> /* Tiling textures is almost always faster, unless we only use it
> once */
>
> +bool can_afbc =
Hi Drew,
On Wed, 3 Jul 2019 at 08:16, Drew DeVault wrote:
> Instead of assuming the first will be suitable. kmscube fails to start
> for me without this change.
There are a couple of unrelated changes combined in here, but I think
the core one is good.
eglChooseConfig has some really useful
Hi,
To be honest, I haven't been able to look too closely at this one. I
wasn't able to easily reason about the twists and turns, so had to run
away to reviews elsewhere. But as long as we reload every single
region passed in - be it individually or just lazily pulling in the
extents, it's
Hi Alyssa,
On Tue, 25 Jun 2019 at 19:54, Alyssa Rosenzweig
wrote:
> @@ -2,6 +2,7 @@
> * Copyright (c) 2011-2013 Luc Verhaegen
> * Copyright (c) 2018 Alyssa Rosenzweig
> * Copyright (c) 2018 Vasily Khoruzhick
> + * Copyright (c) 2019 Collabora
Please use 'Collabora, Ltd.' as that's our
or a particular drawable.
> >
> > Based on a commit originally authored by:
> > Harish Krupo
> > renamed extension, retargeted at DRI drawable instead of context,
> > rewritten description
>
> Oops, this patch is missing Daniel's SoB.
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 a
Hi,
On Mon, 24 Jun 2019 at 19:51, Simon Ser wrote:
> +GBM_EXPORT struct gbm_bo *
> +gbm_bo_create_with_modifiers2(struct gbm_device *gbm,
> + uint32_t width, uint32_t height,
> + uint32_t format,
> + const
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 reason for this?
>
> I'm not sure either. Daniel said it was a
Hi,
On Tue, 2 Apr 2019 at 00:19, Rob Clark wrote:
> On Mon, Apr 1, 2019 at 1:55 PM Jean Hertel wrote:
> > As we have spoken already in the past, I have the intention to move
> > adriconf under the mesa project umbrella, as an official tool for
> > configuring DRI options.
> > I would like to
Hi,
On Mon, 18 Feb 2019 at 18:58, Eric Engestrom wrote:
> On Monday, 2019-02-18 17:31:41 +0000, Daniel Stone wrote:
> > Two hours of end-to-end pipeline time is also obviously far too long.
> > Amongst other things, it practically precludes pre-merge CI: by the
> > time yo
Hi all,
A few people have noted that Mesa's GitLab CI is just too slow, and
not usable in day-to-day development, which is a massive shame.
I looked into it a bit this morning, and also discussed it with Emil,
though nothing in this is speaking for him.
Taking one of the last runs as
that you are replying to the original sender (in Reply-To) and not the
list itself.
Cheers,
Daniel
-- Forwarded message -
From: Daniel Stone
Date: Mon, 11 Feb 2019 at 23:38
Subject: PSA: Mailman changes, From addresses no longer accurate
To: ,
Hi all,
We have hit another step change
Hi,
On Fri, 20 Jul 2018 at 19:32, Eric Anholt wrote:
> Harish Krupo writes:
> > Thank you, understood it. I should have read the spec better :(.
> > Also, generalizing Android/deqp's usage seems to be wrong. Android's
> > deqp passed previously even when the driver wasn't restricting the
> >
On Thu, 7 Feb 2019 at 14:59, Eric Engestrom wrote:
> On Wednesday, 2019-02-06 18:36:09 +, Vinson Lee wrote:
> > ../src/gallium/drivers/freedreno/freedreno_resource.c: In function
> > ‘fd_resource_create_with_modifiers’:
> > ../src/gallium/drivers/freedreno/freedreno_resource.c:884:30: error:
Hi Kevin,
On Mon, 28 Jan 2019 at 18:43, Kevin Strasser wrote:
> Set loader caps indicating that wayland can handle both rgba ordering and
> fp16 formats.
>
> NOTE: This requries libwayland to provide definitions for
> WL_SHM_FORMAT_XBGR16161616F and WL_SHM_FORMAT_ABGR16161616F
To be honest, we
ell.
>
> 4 and 5 are:
>
> Reviewed-by: Adam Jackson
And they are also:
Reviewed-by: Daniel Stone
Thanks for chasing this up!
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi,
On Fri, 25 Jan 2019 at 23:24, Rob Clark wrote:
> (Hmm, I guess I should take a look at what sort of API gitlab offers,
> but that will probably have to wait until after the branchpoint.. tbh
> I'd actually be pretty happy w/ a gitlab equiv of 'git pw as -s' for
> merging things from
Hi,
On Wed, 23 Jan 2019 at 10:09, Eric Engestrom wrote:
> On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote:
> > Sending MRs from the main Mesa repository increase clutter in the
> > repository, and decrease visibility of project-wide branches. So it's
> > better if MRs are sent from
Hi,
On Thu, 17 Jan 2019 at 16:35, Jason Ekstrand wrote:
> On January 17, 2019 08:58:03 Erik Faye-Lund
> wrote:
> > Whoops! I meant to say something like "we'd need to be able to
> > distinguis between CI steps that are triggered due to new MRs versus
> > updated MRs, or pushes to existing
Hi,
On Thu, 17 Jan 2019 at 07:38, Erik Faye-Lund
wrote:
> 1. New MRs should probably get their cover-letter automatically sent to
> the mailing list for incrased visibility.
>
> [...]
>
> I don't think any of these issues are show-stoppers from moving
> entirely to MRs, though. Perhaps issue #1
Hi,
On Wed, 16 Jan 2019 at 13:01, Lionel Landwerlin
wrote:
> - It seems we only get notifications when adding to an MR, I could like to
> subscribe to particular tags
If you go to https://gitlab.freedesktop.org/mesa/mesa/labels/ then you
can subscribe to things per-label. That applies to both
Hi,
On Tue, 15 Jan 2019 at 23:47, Matt Turner wrote:
> On Mon, Jan 14, 2019 at 4:36 AM Daniel Stone wrote:
> > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand wrote:
> > > 5. There's no way with gitlab for Reviewed-by tags to get automatically
> > > applied as
Hey,
On Tue, 15 Jan 2019 at 20:22, Rob Clark wrote:
> On Tue, Jan 15, 2019 at 7:40 AM Daniel Stone wrote:
> > My question would again be what value that brings you. Do you just
> > like seeing the name there, or do you go poke the people on IRC, or
> > follow up via em
buffering.
> > Have you considered tracking/checking how many buffers we have?
>
> A hysteresis value of 18 is just something that worked well in
> practice. It didn't appear to defer the buffer destruction for too long
> while keeping the feedback loop well under control.
Yea
Hi,
On Tue, 15 Jan 2019 at 12:21, Rob Clark wrote:
> On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli wrote:
> > On 1/14/19 2:36 PM, Daniel Stone wrote:
> > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand wrote:
> > > In other projects, we looked for ways to
Hi,
On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand wrote:
> 5. There's no way with gitlab for Reviewed-by tags to get automatically
> applied as part of the merging process. This makes merging a bit more manual
> than it needs to be but is really no worse than it was before.
I'm still on the
Hi,
On Sat, 8 Dec 2018 at 05:15, Eric Engestrom wrote:
> On Friday, 2018-12-07 10:19:23 +0100, Erik Faye-Lund wrote:
> > Automated emails (and perhaps IRC bot) would be really nice.
>
> Agreed. Email would be great to help with the transition.
> There's work currently being done on GitLab to
Hi all,
Thanks for the CC. I'm on a sabbatical until mid-January; I'll be
around but not following the lists/etc as actively as before. Please
feel free to liberally CC me (on this address, not work) or poke me on
IRC if there's something I should see or could contribute to. I'll
have limited time
Hi Emil,
On Thu, 8 Nov 2018 at 15:26, Emil Velikov wrote:
> On Tue, 30 Oct 2018 at 12:57, Daniel Stone wrote:
> > If the client has requested that AcquireNextImage not block at all, with
> > a timeout of 0, then don't make any non-blocking calls.
> >
> > This w
format R8
> libEGL debug: No DRI config supports native format GR88
>
> is a lot easier to understand.
Series is:
Reviewed-by: Daniel Stone
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi,
On Tue, 6 Nov 2018 at 13:11, Eric Engestrom wrote:
> On Friday, 2018-11-02 14:40:49 -0700, Eric Anholt wrote:
> > +GBM_EXPORT char *
> > +gbm_format_get_name(uint32_t gbm_format, struct gbm_format_name_desc *desc)
> > +{
>
> Actually, This won't work with the two GBM_BO_FORMAT_{X,A}RGB;
On Fri, 2 Nov 2018 at 15:58, Emil Velikov wrote:
> Ff| 2 ++
> docs/relnotes/19.0.0.html | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
> create mode 100644 Ff
>
> diff --git a/Ff b/Ff
> new file mode 100644
> index 000..804e31ab99e
> --- /dev/null
>
removing a 'see
also' for gbm_bo_format, since we can't also use \sa to refer to a
family of anonymous #defines.
Signed-off-by: Daniel Stone
Reported-by: Pekka Paalanen
---
src/gbm/main/gbm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gbm/main/gbm.c b/src/gbm/main
If the client has requested that AcquireNextImage not block at all, with
a timeout of 0, then don't make any non-blocking calls.
This will still potentially block infinitely given a non-infinte
timeout, but the fix for that is much more involved.
Signed-off-by: Daniel Stone
Cc: mesa-sta
Hi,
On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote:
> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
> > > > Yeah, I thi
On Tue, 16 Oct 2018 at 08:17, Peter Hutterer wrote:
> On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > + \item Support free and open source projects through the
> > freedesktop.org
> > + infrastructure. For projects outside the scope of item (\ref{1})
> > support
> >
patch is:
Reviewed-by: Daniel Stone
I didn't have time to properly look at the others yet, but most of
what you said there makes sense to me, so I'll hang on for a v2.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lis
Hi,
On Mon, 1 Oct 2018 at 22:25, Jason Ekstrand wrote:
> index 70594d6c053..2850349a619 100644
> --- a/src/intel/vulkan/anv_image.c
> +++ b/src/intel/vulkan/anv_image.c
> @@ -109,6 +109,8 @@ choose_isl_tiling_flags(const struct
> anv_image_create_info *anv_info,
> case
Hi all,
On Fri, 21 Sep 2018 at 20:59, Daniel Stone wrote:
> On Wed, 29 Aug 2018 at 11:13, Juan A. Suarez Romero
> wrote:
> > This is a first part, version 2, of a more complete proposal to use GitLab
> > CI to
> > build and test Mesa. This first part just adds the
Hi Juan,
On Wed, 29 Aug 2018 at 11:13, Juan A. Suarez Romero wrote:
> This is a first part, version 2, of a more complete proposal to use GitLab CI
> to
> build and test Mesa. This first part just adds the required pieces to build
> Mesa, using the different supported tools (meson, autotools,
On Fri, 21 Sep 2018 at 19:48, Jason Ekstrand wrote:
> You should try building with clang.
>
If only there was some way we could do both, in some kind of automated
fashion!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
1 - 100 of 797 matches
Mail list logo
