Hi,
On 12 June 2015 at 15:43, Emil Velikov wrote:
> On 11/06/15 17:43, Zach Reizner wrote:
>> + dri2_dpy->fd = open(card_path, O_RDWR);
> Pretty sure that we'd want some O_CLOEXEC/fcntl() magic but that can be
> done as a separate patch.
We absolutely want O_CLOEXEC; if that could be put in
Hi,
On 14 July 2015 at 00:22, Matt Turner wrote:
but it's not really
> useful in general because float arguments are always cast to double
> when passed as arguments to varargs functions like printf (why?), and
> it warns about that, generating a lot of noise.
It might shock you to learn that th
Hi,
On 14 July 2015 at 02:21, Brian Paul wrote:
> +
> +
> +
Surely texture rather than program?
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi,
On 20 July 2015 at 17:40, Emil Velikov wrote:
> On 18 July 2015 at 23:13, Jonathan Gray wrote:
>> $(RM) is set to 'rm -f' by GNU make, this is not true of other versions
>> of make and RM is not one of the macros required by POSIX.
>>
> Slightly unfortunate but I think we can live with it. W
Hi Lucas,
On 19 October 2015 at 10:25, Lucas Stach wrote:
> Am Sonntag, den 18.10.2015, 21:41 +0200 schrieb Christian Gmeiner:
>> 2015-10-16 15:31 GMT+02:00 Thierry Reding :
>> > Gallium driver is rather complicated, but that's due to the fact that
>> > graphics drivers are complex beasts.
>> >
>
Hi,
I know this isn't your fault, but I really really don't see any reason
why the vl winsys bits should continue to exist. We already have a
winsys/presentation layer in Mesa ...
Cheers,
Daniel
On 29 October 2015 at 17:40, Julien Isorce wrote:
> This patch allows to use gallium vaapi without re
ying the existing internal EGL platform API to be able to use it
from vl_*, rather than straight reuse. DItto for gbm if there's
anything useful in there that could use the same codepaths.
Cheers,
Daniel
> Cheers
> Julien
>
>
> On 30 October 2015 at 08:47, Daniel Stone wrote:
>&
ys sending full-surface damage.
bce64c6c provides the explanation for why we send maximum-range damage,
rather than the full size of the surface: in the presence of buffer
transformations, full-surface damage may not actually cover the entire
surface.
Signed-off-by: Daniel Stone
Cc: Jasper
On 12 November 2015 at 16:47, Jason Ekstrand wrote:
> On Thu, Nov 12, 2015 at 6:46 AM, Pekka Paalanen wrote:
>> Reviewed-by: Pekka Paalanen
>>
>> Perhaps a TODO comment referring to
>> https://bugs.freedesktop.org/show_bug.cgi?id=78190
>> would be nice.
>
> Yes, that would be good. One day, we
Hi,
On 20 January 2015 at 21:49, Dave Airlie wrote:
> On 19 January 2015 at 21:00, Chris Wilson wrote:
>> In order to suport GLX_EXT_buffer_age in DRI2, we need to pass back the
>> last swap buffer count that the back buffer was defined for. For
>> simplicity, we can reuse an existing field in t
Hi,
On Tuesday, March 3, 2015, Dave Airlie wrote:
>
> +EGLBoolean eglExportDMABUFImageQueryMESA(EGLDisplay dpy,
> + EGLImageKHR image,
> + int *fourcc,
> + int *num_planes);
>
Shouldn't this cont
Hi,
On 3 March 2015 at 18:40, Chad Versace wrote:
> On 03/03/2015 12:13 AM, Daniel Stone wrote:
>> On Tuesday, March 3, 2015, Dave Airlie > <mailto:airl...@gmail.com>> wrote:
>> +EGLBoolean eglExportDMABUFIm
Hi,
On 3 March 2015 at 18:56, Jason Ekstrand wrote:
> On Tue, Mar 3, 2015 at 10:07 AM, Chad Versace
> wrote:
>> On 02/23/2015 06:32 AM, Jonny Lamb wrote:
>> > + static const EGLint argb_attrs[] = {
>> > + EGL_TRANSPARENT_TYPE, EGL_TRANSPARENT_ALPHA_MESA,
>> > + EGL_NONE
>> > + };
Hi,
On 3 March 2015 at 23:26, Kristian Høgsberg wrote:
> On Tue, Mar 3, 2015 at 10:43 AM, Chad Versace wrote:
>> Please use EGLImages as the import/export object. That provides
>> consistency with existing similar EGL APIs. And it allows a clean
>> separation between EGL-aware code and GL-aware
Hi,
On 4 February 2017 at 05:29, Ben Widawsky wrote:
> On 17-01-31 11:33:39, Jason Ekstrand wrote:
>> On Mon, Jan 23, 2017 at 10:19 PM, Ben Widawsky wrote:
>>> + /* Preserve legacy behavior if plane is 0 */
>>> + if (plane == 0)
>>> + return _bo->stride;
>>
>> This implies that, for mul
Hi,
On 6 February 2017 at 19:22, Jason Ekstrand wrote:
> On Sun, Feb 5, 2017 at 1:15 PM, Ben Widawsky wrote:
>> Introducing the LINEAR modifier (which happened after v2 of this series) did
>> make things complex because it's possible in some horrific future that a
>> image
>> doesn't support li
Hi Nicolai,
On 7 February 2017 at 09:07, Nicolai Hähnle wrote:
> On 06.02.2017 20:57, Dave Airlie wrote:
>> I just saw this, EGL_MESA_drm_image is really not a good place to start,
>>
>> we have two specs instead,
>> EGL_EXT_image_dma_buf_import.
>> EGL_MESA_image_dma_buf_export
>>
>> does one of
mats would fail with an
error.
Signed-off-by: Daniel Stone
Cc: Emil Velikov
Cc: mesa-sta...@lists.freedesktop.org
Fixes: cb5e799448 ("egl/wayland: unify dri2_wl_create_surface implementations")
---
src/egl/drivers/dri2/platform_wayland.c | 21 ++---
1 file changed,
Hey,
On 13 February 2017 at 17:27, Emil Velikov wrote:
> On 13 February 2017 at 14:06, Daniel Stone wrote:
>> static EGLBoolean
>> dri2_wl_swrast_allocate_buffer(struct dri2_egl_display *dri2_dpy,
>> - int
Hi,
On 13 February 2017 at 17:49, Emil Velikov wrote:
> On 13 February 2017 at 17:34, Daniel Stone wrote:
>> On 13 February 2017 at 17:27, Emil Velikov wrote:
>>> Wouldn't it be better to have this in dri2_wl_create_window_surface() ?
>>> As-is we're passi
On 16 September 2016 at 18:02, Emil Velikov wrote:
> Introduce a helper and use it throughout the platform code. This allows
> us to reduce the amount of ifdef(s) and (potentially) use
> kms_swrast_dri.so for !drm platforms (namely wayland and x11).
Reviewed-by: Dan
roy(dri2_dpy->wl_queue);
> cleanup_dpy:
> free(dri2_dpy);
Adding wl_display_disconnect should be a separate change, and in any
case needs to come after wl_event_queue_destroy to avoid a
use-after-free.
With those fixed, assuming we're fine with an increased har
nly report now, but unless the world has switched to
requiring get_all_proc_addresses, it'll break a hell of a lot more.
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi Eric,
On 20 October 2016 at 00:09, Eric Engestrom wrote:
> I'm not sure this is the right fix. The other thing I'm starting to lean
> toward is to just remove these last two instruction (ie. everything after
> `return VK_SUCCESS`).
> Also, this is untested. It compiles, but that's it.
Indeed,
erate on a Minnowboard, due to spending a great deal of
its time attempting to query the age of the next buffer before redraw.
Revert to the previous behaviour of allowing rendering to begin but
delaying SwapBuffers, unless and until we can find a more gentle
behaviour.
Signed-off-by: Daniel Stone
On 24 October 2016 at 20:42, Daniel Stone wrote:
> This reverts commit 25cc889004aad6d1cab9edd76db898658e347b97, though
> since the code has changed, it was applied manually.
>
> The intent of moving blocking from SwapBuffers to get_back_bo, was to
> avoid unnecessary triple-buffer
Hi,
On 10 November 2016 at 06:08, Jonas Ådahl wrote:
> On Mon, Oct 24, 2016 at 08:42:59PM +0100, Daniel Stone wrote:
>> The intent of moving blocking from SwapBuffers to get_back_bo, was to
>> avoid unnecessary triple-buffering by ensuring that the compositor had
>> fully p
Hi,
On Nov 10 2016, at 2:09 pm, Pekka Paalanen wrote:
> On Wed, 9 Nov 2016 14:57:22 -0600
Derek Foreman wrote:
>
> > We find the oldest backbuffer we can, on the grounds that clients are
> only going to keep a fixed history queue, so this gives them the
> greatest chance of be
Hi,
On 11 November 2016 at 16:44, Emil Velikov wrote:
> As described in commit 690ead4a135 ("egl/wayland-egl: Fix for segfault
> in dri2_wl_destroy_surface.") if we attempt to destroy a EGL surface
> attached to already destroyed Wayland window we'll get a segfault.
s/destroy/resize/ ... ? The p
Hi,
On 11 November 2016 at 16:45, Emil Velikov wrote:
> @@ -174,14 +172,24 @@ dri2_wl_create_surface(_EGLDriver *drv, _EGLDisplay
> *disp,
> config = dri2_get_dri_config(dri2_conf, EGL_WINDOW_BIT,
> dri2_surf->base.GLColorspace);
>
> - dri2_surf->dri_drawab
me callback in
> get_back_bo not dri2_swap_buffers"")
> Cc: Daniel Stone
> Signed-off-by: Emil Velikov
Not sure how I missed this; apologies. Pushed now with my R-b.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop
Hi,
On 18 November 2016 at 14:50, Emil Velikov wrote:
> On 16 November 2016 at 09:28, Varad Gautam wrote:
>> + if (nonzero_modifier_found && dri2_dpy->image->createImageFromDmaBufs2) {
>> + dri_image =
>> + dri2_dpy->image->createImageFromDmaBufs2(dri2_dpy->dri_screen,
>> +
Hi Emil,
On 18 November 2016 at 15:24, Emil Velikov wrote:
> On 18 November 2016 at 15:17, Daniel Stone wrote:
>> Actually, present-and-zero modifier has a very well-defined meaning:
>> it _forces_ linear interpretation of the buffer, whereas a non-present
>> modifier may
Hey Marek,
On 18 November 2016 at 19:09, Marek Olšák wrote:
> On Fri, Nov 18, 2016 at 7:45 PM, Kai Wasserbäch
> wrote:
>> wouldn't a tool like Phabricator be much better for reviewing and reliably
>> tracking whether a patch has landed or not? Especially if you use it in
>> combination with Arca
Hi Jonas,
On 21 November 2016 at 05:56, Jonas Ådahl wrote:
> On Thu, Nov 10, 2016 at 10:38:51AM +0000, Daniel Stone wrote:
>> On 10 November 2016 at 06:08, Jonas Ådahl wrote:
>> > On Mon, Oct 24, 2016 at 08:42:59PM +0100, Daniel Stone wrote:
>> That relies on the composi
Hey Ben,
Sorry I didn't get to testing this before now; have been tied up with
all manner of stuff.
On 1 December 2016 at 22:09, Ben Widawsky wrote:
> The overall strategy is that the buffer/surface is created with a list of
> modifiers. The list of modifiers the hardware is capable of using will
Hi Ben,
On 1 December 2016 at 22:09, Ben Widawsky wrote:
> @@ -996,13 +997,22 @@ gbm_dri_bo_create(struct gbm_device *gbm,
> dri_use |= __DRI_IMAGE_USE_SHARE;
>
> bo->image =
> - dri->image->createImage(dri->screen,
> - width, height,
> -
Hi Ben,
On 1 December 2016 at 22:09, Ben Widawsky wrote:
> @@ -678,6 +679,28 @@ gbm_dri_bo_get_offset(struct gbm_bo *_bo, int plane)
> return (uint32_t)offset;
> }
>
> +static uint64_t
> +gbm_dri_bo_get_modifier(struct gbm_bo *_bo)
> +{
> + struct gbm_dri_device *dri = gbm_dri_device(_bo->
Hi,
On 2 December 2016 at 17:56, Eric Engestrom wrote:
> On Thursday, 2016-12-01 14:09:43 -0800, Ben Widawsky wrote:
>> --- a/src/gbm/main/gbm.h
>> +++ b/src/gbm/main/gbm.h
>> @@ -294,10 +294,10 @@ gbm_bo_map(struct gbm_bo *bo,
>> void
>> gbm_bo_unmap(struct gbm_bo *bo, void *map_data);
>>
>> -
Hi Ben,
On 2 December 2016 at 18:17, Ben Widawsky wrote:
> On 16-12-02 18:07:22, Daniel Stone wrote:
>> On 2 December 2016 at 17:56, Eric Engestrom
>> wrote:
>> I have to admit I didn't catch this one. It doesn't help on 64-bit
>> since unsigned int is sti
Hi,
On 10 June 2014 at 15:46, Rob Clark wrote:
> On Mon, Jun 9, 2014 at 5:53 AM, Pekka Paalanen wrote:
>> On Thu, 16 Aug 2012 17:28:19 -0500 Rob Clark wrote:
>>> From: Rob Clark
>>
>> it looks like this patch never made it into Mesa. Also the
>> implementation apparently didn't make it into Me
Hi Alexandre,
On 9 December 2016 at 13:20, Alexandre Courbot wrote:
> On 12/08/2016 04:16 PM, Alexandre Courbot wrote:
>> First, setting the tiling works indeed just fine if we are using an
>> ioctl for this. However my impression was that the preferred way of
>> doing it was through FB modifiers
Hi,
On 12 December 2016 at 15:28, Emil Velikov wrote:
> As mentioned by others - having the second number represent the month
> would be better, afaict.
> Namely: YY.MM.PP. Thus 17.02.01 provides direct and clear feedback that
> - 2017 release, from the second month (Feb).
> - first bugfix rele
Hi Jonathan,
On 19 July 2016 at 20:47, Jonathan wrote:
> +typedef VkResult (VKAPI_PTR *PFN_vkGetDmaBufINTEL)(VkDevice device,
> VkDeviceMemory mem, VkImage image, int *fd, uint32_t *pitch);
Some things you should consider adding to this:
- multi-plane support for multi-buffer formats (multipl
On 20 July 2016 at 13:47, Daniel Stone wrote:
> On 19 July 2016 at 20:47, Jonathan wrote:
>> +typedef VkResult (VKAPI_PTR *PFN_vkGetDmaBufINTEL)(VkDevice device,
>> VkDeviceMemory mem, VkImage image, int *fd, uint32_t *pitch);
>
> Some things you should consider adding
Hi,
On 21 July 2016 at 15:11, Emil Velikov wrote:
> On 21 July 2016 at 14:57, Adam Jackson wrote:
>>> + device_name = drv->QueryDeviceName(disp);
>>
>> This is /dev/dri/renderD128...
>>
>>> + mtx_lock(_eglGlobal.Mutex);
>>> +
>>> + assert(info->got_devices);
>>> +
>>> + for (dev = info->
Hi,
On 28 November 2013 10:04, Pekka Paalanen wrote:
> On Thu, 28 Nov 2013 10:24:33 +0100
> Benjamin Gaignard wrote:
>> From my point of view wl_drm isn't link to Mesa, it is only about
>> exchange buffers by using a file descriptor and, for example, doesn't
>> rely on EGL.
>>
>> I understand th
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 s
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
ere seems strange - both number used and it's relation
> > to double/triple 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
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
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 pa
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 i
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 h
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 branc
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 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 cmdline.)
> 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 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 w
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,
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
> > ren
se be _very_ careful
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 hav
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 representati
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,
On 18 January 2016 at 12:48, Jose Fonseca wrote:
> There's something weird going on with bugzilla and maybe ytrezq's browser.
> mesa-dev received a lot of CC add/remove notification emails from bugzilla,
> but if you look at https://bugs.freedesktop.org/show_bug.cgi?id=93686 web
> page there'
Hi,
On 19 January 2016 at 02:14, Timothy Arceri
wrote:
> On Mon, 2016-01-18 at 16:47 +0100, Jouk Jansen wrote:
>> Can someone insert these patches in the git-repository.
>> I cannot do it myself, because the git-client on my OpenVMS is very
>> -very
>> limited and does not allow this.
>
> Why not
Hi,
On 27 January 2016 at 09:34, Michel Dänzer wrote:
> The compositor may have the hardware scan out directly from the buffers
> sent by the client, so we must make sure the buffers we create are
> suitable for scanout.
If the compositor wants to scan out directly, it will import via GBM,
which
Hi,
On 27 January 2016 at 14:16, Axel Davy wrote:
> On 27/01/2016 13:43, Daniel Stone wrote:
>> On 27 January 2016 at 09:34, Michel Dänzer wrote:
>>> The compositor may have the hardware scan out directly from the buffers
>>> sent by the client, so we must make sur
On 28 January 2016 at 03:21, Michel Dänzer wrote:
> On 27.01.2016 23:54, Daniel Stone wrote:
>> On 27 January 2016 at 14:16, Axel Davy wrote:
>>> On 27/01/2016 13:43, Daniel Stone wrote:
>>>> If the compositor wants to scan out directly, it will import via
>&
On 29 January 2016 at 03:44, Michel Dänzer wrote:
> It still sounds like significant work (particularly for somebody like me
> who isn't very familiar with Wayland details yet). It should be done by
> somebody who cares about the difference you're describing. I think it's
> unreasonable to expect
Hi,
On 31 March 2016 at 04:21, Rob Herring wrote:
> diff --git a/include/GL/internal/dri_interface.h
> b/include/GL/internal/dri_interface.h
> index 6bbd3fa..b059112 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -1101,6 +1101,9 @@ struct __DR
Hi,
On 14 April 2016 at 13:19, Chokshi, Mitul wrote:
> If create_wl_buffer() closes the file descriptor returned by
> dri2_dpy->image->queryImage then OS hands out the same file
> descriptor number to other process which then experiences error
> when fd is closed due to CLOEXEC.
I don't really u
Hi,
On 17 April 2016 at 16:58, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> Secondly, the content of the wiki page feels overly bureaucratic to me. Not
> in absolute sense, but in relative sense: when compared to services such as
> github.com, the freedesktop.org wiki page feels like a nice example of
>
but perhaps
> we should.
> +
> #ifndef WL_DRM_FORMAT_ENUM
> #define WL_DRM_FORMAT_ENUM
> enum wl_drm_format {
Indeed, this is already provided by wayland-drm-*-protocol.h, and only
used in places which may include those files.
Reviewed-by: Daniel Stone
Cheers,
Daniel
__
ning to
> wait for it to be completely populated to start with.
If you want a bit more to add:
WAYLAND EGL SUPPORT
R: Daniel Stone
F: src/egl/wayland/*
F: src/egl/drivers/dri2/platform_wayland.c
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@
Hi,
On 22 April 2016 at 19:12, Eric Anholt wrote:
> I think this needs a longer comment to explain what the interface does:
>
> "Returns a map of the specified region of a __DRIimage for the specified
> usage.
>
> flags must always include __DRI_IMAGE_TRANSFER_READ and may include
> __DRI_IMAGE_T
Hi,
On 22 April 2016 at 19:21, Eric Anholt wrote:
> I don't think we want to always make a spare context just in case
> someone uses the map API. Contexts can be pretty expensive to set up,
> in time (for piglit tests on gbm) and memory (for X.Org).
>
> It's too bad I don't think we have a way t
Hi,
On 23 April 2016 at 03:08, Rob Herring wrote:
> On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov
> wrote:
>> Can we take a look at the GBM gralloc as well. One thing that worries
>> me is that (most likely) you are requesting/creating a bo without
>> GBM_BO_USE_WRITE whist using MAP + CPU writ
Hi Adrian,
On 25 April 2016 at 14:23, Adrian Pielech wrote:
> Till now window surface size on wayland was -1.
> It's better to assign windows size to proper surface property.
Hm. This will be done from update_buffers(), so will only be 'invalid'
before the first rendering has been done. I guess
Hi,
On 25 April 2016 at 15:25, Emil Velikov wrote:
> On 25 April 2016 at 13:46, Daniel Stone wrote:
>> On 23 April 2016 at 03:08, Rob Herring wrote:
>>> I'm not using GBM_BO_USE_WRITE and that is not a condition for mapping
>>> given that flag is tied to cur
drm_intel_bo_unreference(fence->batch_bo);
> + fence->batch_bo = NULL;
Should this branch be setting fence->signalled = true as well, to
match client_wait?
The rest looks good to me, going on what I remember of having looked
at this about 5 year
t __DRIswrastLoaderExtension API seems to have been
> designed with X11 in mind. As a result, it doesn't fit perfectly
> wayland: a copy could be avoided by upgrading this API.
> There doesn't seem to be interest in doing this work for a small
> gain for something that's no
Hi,
On 6 May 2015 at 07:25, Pekka Paalanen wrote:
> On Wed, 6 May 2015 11:00:13 +1000
> Dave Airlie wrote:
>> On 2 May 2015 at 20:15, Axel Davy wrote:
>> > Only EGL_WINDOW_BIT is supported. Remove tests related.
>>
>> Is this there no plans to support pixmap/pbuffer/ or any of the other bits?
>
Hi,
On 14 May 2015 at 23:33, Emil Velikov wrote:
> Hi Marek,
> On 12/05/15 22:54, Marek Olšák wrote:
>> -#elif defined(__WINSCW__) || defined(__SYMBIAN32__) /* Symbian */
>> +#elif defined(__APPLE__) || defined(__WINSCW__) || defined(__SYMBIAN32__)
>> /* Symbian */
>>
>> typedef int EGLNati
fect of calling UnbindContext() is that _mesa_make_current(NULL,
NULL, NULL) gets called, which is what we want.
Could you please document some part of that in the commit message for
future archaeology?
Reviewed-by: Daniel Stone
Cheers,
Daniel
> Signed-off-by: Alexandros Frantzis
> Signed
On 24 October 2014 11:18, Daniel Stone wrote:
> Yep, that looks good to me; seems like you've found the only possible case
> that would trigger this breakage. Calling DestroyContext will always unbind
> if it's current in that thread (see the end _mesa_free_context_data); i
Hi,
On 24 October 2014 18:51, Emil Velikov wrote:
> Sigh... why can't everyone be like Gentoo - set compiler flags and
> rebuild for your machine/cpu :P
>
> Apart from the Makefile.sources change spotted by Matt, can you make use
> of USE_SSE41 ? Take a look at commit b3121bfd413 for the whys an
Hi,
On 12 November 2014 12:37, wrote:
> @@ -544,9 +544,22 @@ dri2_convert_glx_attribs(unsigned num_attribs, const
> uint32_t *attribs,
>case GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB:
> *api = __DRI_API_OPENGL;
> break;
> - case GLX_CONTEXT_ES2_PROFILE_BIT_EXT:
> -
Hi,
On 14 November 2014 15:07, Erik Faye-Lund wrote:
> On Fri, Nov 14, 2014 at 3:39 PM, Emil Velikov
> wrote:
> > Are there any objections if I move to the above format starting with
> > mesa 10.4-rc1 ? I would appreciate any feedback over the next 2-3 days,
> > and based on it I'll tag the fir
Hi,
On 28 November 2014 at 09:17, Thierry Reding
wrote:
> On Fri, Nov 28, 2014 at 12:32:43AM -0500, Ilia Mirkin wrote:> Also, can
> you explain why it's advantageous for the setup to appear as
> > though it is a single device? i.e. what's wrong with just using
> > nouveau as a render node or wha
Hi,
On 17 March 2015 at 16:37, wrote:
> --- a/src/mesa/drivers/dri/i965/gen7_sf_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_sf_state.c
> @@ -198,9 +198,15 @@ upload_sf_state(struct brw_context *brw)
>float line_width =
> roundf(CLAMP(ctx->Line.Width, 0.0, ctx->Const.MaxLineW
Hi,
My two cents, which largely parallels Jason's ...
On 2 April 2015 at 08:35, Dave Airlie wrote:
> So nvidia have indicated they would like to use an EGLstreams based
> solution to enable wayland on their binary driver stack at some point.
No real surprise, I guess. NVIDIA have long pushed EGL
On 4 April 2015 at 08:46, Jordan Justen wrote:
> On 2015-04-03 19:18:35, Stéphane Marchesin wrote:
>> > Perhaps EGL_MESA_platform_surfaceless and platform_surfaceless.c?
>>
>> That's a very good name. As it happens, it also matches Chrome's naming.
>
> Chad made the point that this probably isn't
Hi,
On 8 April 2015 at 10:57, Vasilis Liaskovitis wrote:
> I have an issue where st_TexSubImage causes very high CPU load in
> __memcpy_sse2_unaligned (Mesa 10.1.3, Xorg 1.15.1, radeon driver, HD 7870).
>
> Any obvious causes / tips for this? e.g. align textures or use different
> format/type? I
Hi,
At Collabora (my lovely dayjob), we've been working with Valve on
SteamOS. Valve are keen to give back to the community, and we've been
discussing ways they can help do that, including providing free access
to Valve games on Steam to Debian developers last year.
We're happy to say that this ha
ly be
for me to pre-empt Valve saying so. I agree it would be nice though!
Cheers,
Daniel
> Thierry
>
> On Thu, Apr 09, 2015 at 06:10:42PM +0100, Daniel Stone wrote:
>> Hi,
>> At Collabora (my lovely dayjob), we've been working with Valve on
>> SteamOS. Valve are
Hi,
On 9 April 2015 at 17:20, Kristian Høgsberg wrote:
> On Wed, Apr 8, 2015 at 11:37 AM, Emil Velikov
> wrote:
>> Hi all,
>>
>> Can we get a pair of eyes on this patch please ?
>
> Reviewed-by: Kristian Høgsberg
>
> Thanks for the reminder.
Mind you, this does break 75b7e1df13, which explici
Hi,
On Saturday, April 18, 2015, Axel Davy wrote:
>
> There's a strange issue with xcb_get_geometry: If I use the new xcb
> connection
> it fails and the error is a drawable error. If I use the Xlib xcb
> connection (what
> I did in this patch) it works. If anyone knows why, please tell. We use
>
Hi,
On 23 April 2015 at 14:12, Emil Velikov wrote:
> Boyan Ding (2):
> i965: Add XRGB format to intel_screen_make_configs
> i915: Add XRGB format to intel_screen_make_configs
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=89689 but
re-breaks ES3 MSAA by reverting
htt
Hi,
On 16 February 2016 at 16:34, Derek Foreman wrote:
> +try_damage_buffer(struct dri2_egl_surface *dri2_surf,
> + const EGLint *rects,
> + EGLint n_rects)
> +{
> +/* The WL_SURFACE_DAMAGE_BUFFER_SINCE_VERSION macro and
> + * wl_proxy_get_version() were both int
1 - 100 of 802 matches
Mail list logo
