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 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
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 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 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
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
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
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,
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
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
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,
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->
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 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
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
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 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,
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 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
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
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
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
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 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
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
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 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,
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 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
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@
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
__
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
>
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 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
Hey,
On 29 March 2016 at 19:06, Rob Clark wrote:
> On Tue, Mar 29, 2016 at 1:51 PM, Daniel Stone wrote:
>> Yep, you got it right: in the original intention, the only mappable
>> GBM BOs were cursor BOs. This is mostly because we lacked modifiers,
>> so it was assumed th
Hi,
On 29 March 2016 at 15:44, Rob Clark wrote:
> On Tue, Mar 29, 2016 at 10:30 AM, Rob Herring wrote:
>> On Tue, Mar 29, 2016 at 8:43 AM, Rob Clark wrote:
>>> On Mon, Mar 28, 2016 at 12:29 PM, Rob Herring wrote:
However, I found a bigger mismatch is there are no explicit map/unmap
c
Hi,
On 9 March 2016 at 02:57, Michel Dänzer wrote:
> On 08.03.2016 20:36, Daniel Stone wrote:
>> Taking the approach I suggested would allow us to solve multi-GPU
>> with the same approach, whereas with the wrapper driver ... who
>> volunteers to write the Radeon+Int
Hey Emil,
On 8 March 2016 at 17:04, Emil Velikov wrote:
> Summarising and stating some unsaid assumptions.
>
> Assumptions:
> - The proposed solution is a replacement of the wrapped drivers
> approach. No, it's meant to introduce an API mostly gears towards
> DRI_PRIME setups.
> - Wrapped drive
Hi,
On 7 March 2016 at 20:45, Emil Velikov wrote:
> On 7 March 2016 at 10:35, Daniel Stone wrote:
>> On 7 March 2016 at 10:19, Thierry Reding wrote:
>>> On Mon, Mar 07, 2016 at 10:46:52AM +0100, Lucas Stach wrote:
>>>> The wrapped driver takes away the abilit
Hi,
On 7 March 2016 at 10:19, Thierry Reding wrote:
> On Mon, Mar 07, 2016 at 10:46:52AM +0100, Lucas Stach wrote:
>> Am Freitag, den 04.03.2016, 18:34 + schrieb Emil Velikov:
>> > While I'm more inclined to Daniel's suggestion, I wonder why people
>> > moved away from Thierry's approach - cr
Hi,
On 4 March 2016 at 16:08, Lucas Stach wrote:
> Am Freitag, den 04.03.2016, 15:09 + schrieb Daniel Stone:
>> Thanks for taking this on, it looks really good! I just have the one
>> question though - did you look at the EGLDevice extension? Using that
>> to enumera
Hi Lucas,
On 4 March 2016 at 13:49, Lucas Stach wrote:
> this is a first shot at trying to hash out an API to allow bootstrapping
> an EGL context on top of split render/scanout DRM devices. It tries to make
> things really easy for applications, while leaving them in full control over
> swap/fli
Hi,
On 25 February 2016 at 01:47, Emil Velikov wrote:
> On 24 February 2016 at 18:56, Rob Herring wrote:
>> AOSP master branch has switched to clang from gcc and has major build
>> system changes moving away from GNU make.
>
> Out of curiosity: what are they moving to ? I can see "blueprint"
> (
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
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
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
>&
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
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 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 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'
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
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
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:
>&
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
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,
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,
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 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 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 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
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?
>
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
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
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 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 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
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,
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
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
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,
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
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,
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 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 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 Tuesday, March 3, 2015, Dave Airlie wrote:
>
> +EGLBoolean eglExportDMABUFImageQueryMESA(EGLDisplay dpy,
> + EGLImageKHR image,
> + int *fourcc,
> + int *num_planes);
>
Shouldn't this cont
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 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 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 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 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
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
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
Reviewed-by: Daniel Stone
On 16 September 2014 22:29, Emil Velikov wrote:
> Another humble ping.
>
> I realise that i915 hardware is not top priority yet 5 minutes of someone
> experienced with the driver will be greatly appreciated :)
>
> Cheers,
> Emil
>
> On 0
Reviewed-by: Daniel Stone
On 16 September 2014 22:23, Emil Velikov wrote:
> Hello gents,
>
> Can anyone spare a couple of minutes and review this patch ?
>
> Thanks
> Emil
>
> On 03/09/14 21:43, Andreas Pokorny wrote:
> > This changes enables EGL_KHR_image_pixmap
Hi,
On 29 August 2014 08:46, Gwenole Beauchesne wrote:
> Could you please describe in there the ownership model? I think the
> implementation should own the fd, so the clients should dup() it if
> ever necessary.
>
So the fd can be destroyed at any time, particularly with threads? Meaning
that
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 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
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
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
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 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
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
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
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
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 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
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
701 - 798 of 798 matches
Mail list logo
