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 w
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
> +*
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
d
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 that
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 w
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 proto
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. westo
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
Hi Dieter,
On Tue, 30 Jul 2024 at 23:06, Dieter Nützel wrote:
> what's going on over @
>
> https://cgit.freedesktop.org/mesa/mesa/log/
>
> for the last 3 days?
>
> mesa-git isn't working, too?
>
> /opt/mesa> !12
> git pull git://anongit.freedesktop.org/git/mesa/mesa
> Schwerwiegend: Lesefehler: C
Hi,
On 2 May 2016 at 11:44, Rob Clark wrote:
> On Mon, May 2, 2016 at 2:15 AM, Michel Dänzer wrote:
>> So, what is this based on? Maybe I'm not looking in the right place, but
>> out of hundreds of changes in Git touching those files, I see one change
>> from you about six months ago and five ch
ommit 6a0d036483caf87d43ebe2edd1905873446c9589.
Signed-off-by: Daniel Stone
Cc: Ben Widawsky
Cc: Topi Pohjolainen
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 4 ++--
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 ++
src/mesa/drivers/dri/i965/intel_mipmap_tree.h
Hi,
On 3 May 2016 at 14:52, Daniel Vetter wrote:
> On Mon, Feb 01, 2016 at 12:48:52PM +0900, Michel Dänzer wrote:
>> As I said before, looking at intel_validate_usage, I suspect the latter.
>
> Just jumping in here, but it's correct atm. Well if we ignore a recent bug
> to enable Y-tiling where m
This will be used so we can implement a better validateUsage, which
takes neither a screen nor a context.
Signed-off-by: Daniel Stone
Cc: Daniel Vetter
---
src/mesa/drivers/dri/i965/intel_image.h | 2 ++
src/mesa/drivers/dri/i965/intel_screen.c | 22 --
2 files changed
Add a more comprehensive validateUsage() call, checking that the tiling
mode for the __DRIimage.
Signed-off-by: Daniel Stone
Cc: Daniel Vetter
---
src/mesa/drivers/dri/i965/intel_screen.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b
Hi Jonas,
On 4 May 2016 at 09:53, Jonas Ådahl wrote:
> When EGL is used on some other thread than the thread that drives the
> main wl_display queue, the Wayland EGL dri2 implementation is
> vulnerable to a race condition related to display round trips and global
> object advertisements.
>
> The
Hi,
I'd already suggested the same, but it never got pushed:
https://lists.freedesktop.org/archives/mesa-dev/2016-May/115501.html
So I guess we can add the Tested-by from the other, for whichever gets
pushed.
Cheers,
Daniel
On Sunday, 8 May 2016, Hans de Goede wrote:
> This reverts commit 6a0d
Hi,
On 8 May 2016 at 20:05, Ben Widawsky wrote:
> On Sun, May 08, 2016 at 12:15:00PM +0100, Daniel Stone wrote:
>> I'd already suggested the same, but it never got pushed:
>> https://lists.freedesktop.org/archives/mesa-dev/2016-May/115501.html
>>
>> So I guess w
Hi,
On 13 May 2016 at 17:03, Plamena Manolova wrote:
> @@ -444,6 +444,8 @@ _eglCreateAPIsString(_EGLDisplay *dpy)
>strcat(dpy->ClientAPIsString, "OpenVG ");
>
> assert(strlen(dpy->ClientAPIsString) < sizeof(dpy->ClientAPIsString));
> +
> + _eglGlobal.ClientAPIsString = dpy->ClientAP
Hi,
On 18 May 2016 at 00:00, Ian Romanick wrote:
> On 05/17/2016 09:59 AM, Ben Widawsky wrote:
>> I think you misstated this. It's not invalid to have any other value. It's
>> invalid to not have one of the 3 values, which I suppose is technically
>> possible
>> if you say support ES2, but not E
d-off-by: Daniel Stone
Fixes: 7aeef2d4efdc ("dri3: allow building against older xcb (v3)")
Cc: Dave Airlie
---
src/egl/drivers/dri2/egl_dri2.c | 2 +-
src/egl/drivers/dri2/platform_x11_dri3.c | 10 ++
src/glx/dri3_glx.c | 8 +
VMware has no (published) support for Arm-architecture guests.
Signed-off-by: Daniel Stone
Cc: Dylan Baker
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index 88e90fe8119..24cad58c61e 100644
--- a/meson.build
+++ b/meson.build
On all Arm architectures (ARMv7 and below as 'arm', ARMv8 and above as
'aarch64'), only build swrast for DRI drivers. The only classic drivers
which could be used are r200 and NV20 cards, which seems unlikely enough
that it shouldn't be the default.
Signed-off-by:
The have-new-DRI3 codepaths would never actually properly trigger, since
there was a typo in configure.ac which broke the version check. This
went unnoticed but for an error in config.log if you looked closely
enough.
Signed-off-by: Daniel Stone
Reported-by: Lukas F. Hartmann
Fixes
On 20 March 2018 at 16:16, Dylan Baker wrote:
> Quoting Daniel Stone (2018-03-20 01:54:25)
>> VMware has no (published) support for Arm-architecture guests.
Pushed now with review and the new suggested title - thanks both for review!
Cheer
On 20 March 2018 at 16:24, Dylan Baker wrote:
> Quoting Daniel Stone (2018-03-20 09:17:21)
>> The have-new-DRI3 codepaths would never actually properly trigger, since
>> there was a typo in configure.ac which broke the version check. This
>> went unnoticed but for an error
Hi Juan,
On 19 March 2018 at 17:49, Juan A. Suarez Romero wrote:
> The first two patches in the series is a new fix for issue
> https://bugs.freedesktop.org/show_bug.cgi?id=105211, as the current version
> breaks when running the above command, due "make dist/distcheck" tries to
> generate the th
On 22 March 2018 at 11:16, Juan A. Suarez Romero wrote:
> On Thu, 2018-03-22 at 11:03 +, Emil Velikov wrote:
>> On 21 March 2018 at 13:36, Daniel Stone wrote:
>> > I thought we had resolved earlier to _not_ ship files generated by
>> > wayland-scanner in dist af
which we support, and only pass those.
Signed-off-by: Daniel Stone
---
src/egl/drivers/dri2/platform_x11_dri3.c | 19 +++
src/glx/dri3_glx.c | 21 +++--
2 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/src/egl/drivers/dri2
On 22 March 2018 at 15:20, Derek Foreman wrote:
> commit 03dd9a88b0be17ff0ce91e92f6902a9a85ba584a introduced per surface
> queues, but the display_sync for swrast_commit_backbuffer remained on
> the old queue. This is likely to break when dispatching the correct
> queue at the top of function (wh
Hi Juan,
On 22 March 2018 at 16:49, Juan A. Suarez Romero wrote:
> Instead we will re-generate them again on building.
Thanks for sending the v2 - that looks good to me. There was some kind
of problem with having the sources in BUILT_SOURCES though, which Emil
might be able to remember. Is it ne
Hi Ilia,
On 14 March 2018 at 19:02, Ilia Mirkin wrote:
> On Tue, Mar 13, 2018 at 5:30 AM, Daniel Stone wrote:
>> On 12 March 2018 at 20:45, Mario Kleiner wrote:
>>> This way the wayland server can signal support for these formats
>>> to wayland EGL clients. This i
11 compositor uses EGL.
I have no reason to doubt your testing, so this patch is:
Acked-by: Daniel Stone
But it does rather fill me with trepidation, given that X11 Pixmaps
are supposed to be a dumb 'bag of bits', doing nothing else than
providing the same number and size of channels
Hi Andreas,
On 30 March 2018 at 15:18, Andreas Müller wrote:
> What happened: I build all images cross with Openembedded/Yocto. To
> prepare next release there I updated my builds and that moved mesa
> 17.1.7 -> 17.3.7. Since then all applications using GL/GLES (e.g
> glmark2-es - tried others -
On 23 March 2018 at 13:03, Emil Velikov wrote:
> On 22 March 2018 at 15:27, Daniel Stone wrote:
>> The version passed to QueryVersion requests is the version that the
>> client supports. We were just passing in whatever version of XCB was
>> present on the system, which may
:
Modifier 0x0 vs. tiling (0x701) mismatch
Signed-off-by: Daniel Stone
Reported-by: Andreas Müller
Fixes: 3f8513172ff6 ("gallium/winsys/drm: introduce modifier field to
winsys_handle")
---
src/gallium/state_trackers/dri/dri2.c | 1 +
1 file changed, 1 insertion(+)
diff -
Hi Juan,
On 29 March 2018 at 11:25, Juan A. Suarez Romero wrote:
> The plan is to have 17.3.8 this Monday (2nd April), around or shortly after
> 11:00
> GMT.
Does this mean we could expect 17.3.9 in a couple of weeks, or is this
the last release for the 17.3.x branch?
Cheers,
Daniel
__
Hi Andreas,
On 31 March 2018 at 15:18, Andreas Müller wrote:
> Thanks for prompt an VERY helpful support. I did:
>
> * Check my configure and found: --disable-dri3!
> * Tested your patch (with --disable-dri3) and as expected it fixes the issue
> * Found what causes --disable-dri3 - it came in by
On 30 March 2018 at 19:20, Kenneth Graunke wrote:
> On Friday, March 30, 2018 7:40:13 AM PDT Chris Wilson wrote:
>> For i915, we are proposing to use a quality-of-service parameter in
>> addition to that of just a priority that usurps everyone. Due to our HW,
>> preemption may not be immediate and
>modifiers_supported && modifier
!= DRM_FORMAT_MOD_INVALID)'.
With that fixed, and I suppose with the same weak-symbol handling as
the others, this is:
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 2 April 2018 at 18:52, Eric Anholt wrote:
> Daniel Stone writes:
>> When allocating a buffer for DRI2, set the modifier to INVALID to inform
>> the backend that we have no supplied modifiers and it should do its own
>> thing. The missed initialisation force
Hi James,
On 30 March 2018 at 16:45, James Legg wrote:
> Fixes: bfa22266cd vulkan/wsi/wayland: Add support for zwp_dmabuf
> CC: Daniel Stone
> CC: Jason Ekstrand
Wow, the cleanup hunk must have been lost in a rebase somewhere. :( At
least, I think I remember writing it.
Thanks a lo
ier which supports fast-clears.
I've been running this for a while and haven't seen any issues with it
so far, so:
Reviewed-by: Daniel Stone
Tested-by: Daniel Stone
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.free
Hi all,
On 5 April 2018 at 23:55, Laura Ekstrand wrote:
> So I spoke with Daniel Stone today about the infrastructure. He estimates
> it will be ready to deploy the website in 2-3 weeks, at the most. So I'd
> say the infrastructure will be there when we are ready.
>
> In
Hi Sergii,
On 6 April 2018 at 09:12, Sergii Romantsov wrote:
> Commit 3160cb86aa92 adds optimization with flag 'reallocate'.
> Processing of flag causes buffers freeing while pointer
> is still hold in caller stack and than again used to be freed.
Thanks a lot for writing this. I take it the cor
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 m
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 uint
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
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
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 f
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 correct.
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 pro
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 = panfrost_fo
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
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 c
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 modif
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 veloci
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 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,
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 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
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 = (
*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 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. Prot
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 h
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 c
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 worrie
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
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 ho
t'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 lis
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.
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 f
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 Wes
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 b
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
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 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 an
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
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 cont
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 tho
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 lon
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 first
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 s
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 0
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 ht
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 simplest
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 these
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 a
Hi,
On 4 January 2012 18:45, Ian Romanick wrote:
> Okay, I looked back at your build output, and I think I see the problem:
>
> * econf: updating Mesa-/bin/config.sub with
> /usr/share/gnuconfig/config.sub
> * econf: updating Mesa-/bin/config.guess with
> /usr/share/gnuconfig/config.gue
The assertion added in f09910f3 broke nv50 completely by asserting that
the number of elements in a dereferenced pointer (i.e. 1) was greater
than i (which ranged up to six), rather than checking the number of
elements in the containing array.
Signed-off-by: Daniel Stone
---
src/gallium/drivers
On 7 February 2012 13:03, Christoph Bumiller
wrote:
> On 07.02.2012 13:47, Jose Fonseca wrote:
>> Makes sense.
>
> Very much so ...
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=189e6c7e81ce35b89d9b52d4bd0d6271a7e9c10f
> (of 26 hours ago).
Ha, snap. Thanks anyway. :)
(Doesn't matter too mu
Hi,
On Tuesday, 20 September 2011, Luc Verhaegen wrote:
> This sound like a rather redhat specific topic. How certain are you that
> redhat is going to send you to FOSDEM, and if they don't, are you coming
> regardless?
In much the same way that every RadeonHD talk was completely
Novell-specific
Hi,
On Tuesday, 20 September 2011, Chris Wilson
wrote:
> Daniel, think you might pop over for the weekend and teach us a thing or
> two about the DRM infrastructure and what it might look like in a year
> or two as more SoC gradually become mainline?
Perhaps. FOSDEM is a great conference and I r
Hi,
On 2 October 2011 08:17, Matthieu Herrb wrote:
> On Sat, Oct 01, 2011 at 03:14:12PM +0200, Luc Verhaegen wrote:
>> If you know that you are coming to FOSDEM, but for some reason think
>> that someone else should step up instead, then think again, and reply
>> ASAP.
>
> Luc,
>
> I hope that so
51b0a0b3 introduced a number of const restrictions in glext.h, but
didn't propagate these to the GL API XML files, leading to a number of
prototype mismatch warnings.
Signed-off-by: Daniel Stone
---
src/mapi/glapi/gen/ARB_debug_output.xml |2 +-
src/mapi/glap
On Thu, May 12, 2011 at 09:45:14AM -0400, Kristian Høgsberg wrote:
> A different solution could be to use the input thread idea and stop
> taking SIGIO.
The input thread needs a lot of work though - we don't do any locking at
all. So try doing device creation/destruction in a loop, or changing
th
configure.ac would previously refuse to complete if libX11 wasn't
installed, even if we'd disabled GLX and weren't building an X11 EGL
platform. Make the check simply set the no_x variable that's used (but
never set) immediately below for what looks like this very case.
S
Ever since df4a88ac, the check for compressed formats has been
unnecessary. And ever since cb72ec5f, the build has been broken with
FEATURE_ES. Remove it, as it does nothing.
Signed-off-by: Daniel Stone
---
src/mesa/main/teximage.c |4
1 file changed, 4 deletions(-)
diff --git a/src
Hi,
On 10 October 2012 01:07, Dan Nicholson wrote:
> On Oct 8, 2012 10:49 PM, "Matt Turner" wrote:
>> Wow, it's been like that since 2008.
>>
>> Reviewed-by: Matt Turner
>
> Originally configure basically supported only GLX either through DRI or
> Xlib, so Xlib was basically required. Not so mu
On Wed, 18 Dec 2024 at 10:32, Brian Starkey wrote:
> On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
> > For that reason I think linear modifiers with explicit pitch/size
> > alignment constraints is a sound concept and fits into how modifiers work
> > overall.
>
> Could we make it
On Thu, 19 Dec 2024 at 02:54, Marek Olšák wrote:
> On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey wrote:
>> On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
>> > For that reason I think linear modifiers with explicit pitch/size
>> > alignment constraints is a sound concept and fits i
701 - 800 of 802 matches
Mail list logo
