>> unsigned int format_count[ARRAY_SIZE(visuals)] = {};
Isn't this invalid in C?
http://stackoverflow.com/questions/17589533/is-an-empty-initializer-list-valid-c-code
Other than that, this patch is
Reviewed-by: Gurchetan Singh
On Thu, Aug 25, 2016 at 9:23 AM, Emil Velikov
wrote:
&
Reviewed-by: Gurchetan Singh
On Thu, Aug 25, 2016 at 9:18 AM, Emil Velikov
wrote:
> From: Emil Velikov
>
> The latter already does it for us.
>
> As we're here annotate the masks as const and use unsigned for the
> index(es).
>
> Cc: Gurchetan Singh
> Cc: Cha
Reviewed-by: Gurchetan Singh
On Thu, Aug 25, 2016 at 9:18 AM, Emil Velikov
wrote:
> From: Emil Velikov
>
> Earlier commit introduced support for image_loader and left the
> dri2_loader code dangling/unused. Let's remove it.
>
> Fixes: 63c5d5c6c46 ("Added p
Reviewed-by: Gurchetan Singh
On Thu, Aug 25, 2016 at 9:18 AM, Emil Velikov
wrote:
> From: Emil Velikov
>
> Remove a few gratious blank lines and use the correct level of
> indentation.
>
> Signed-off-by: Emil Velikov
> ---
> src/egl/drivers/dri2/egl_dri2.h
Reviewed-by: Gurchetan Singh
On Thu, Aug 25, 2016 at 9:23 AM, Emil Velikov
wrote:
> From: Emil Velikov
>
> Currently we print a debug message if the total configs is non-zero only
> to do the same (at an error level) as we return from the function.
>
> Rework the message
Friendly ping ... this is not in master yet.
On Wed, Aug 31, 2016 at 12:58 AM, Eric Engestrom wrote:
> On Tue, Aug 30, 2016 at 04:49:53PM -0700, k...@bitplanet.net wrote:
> > From: "Kristian H. Kristensen"
> >
> > As long as the dma_buf fds import to the same drm_intel_bo, we're fine.
> >
> > R
It's possible to build Mesa for Android using the traditional
autotools workflow. To enable this, let's add the required
pkg-config checks and link against them.
---
configure.ac| 3 +++
src/egl/Makefile.am | 1 +
2 files changed, 4 insertions(+)
diff --git a/configure.ac b/configure.ac
In Android, the pthreads libs are in bionic. When building
Mesa for Android with the autotools workflow, we shouldn't
set -lpthread or -pthread.
---
configure.ac | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4761c59..3f21cd5 100644
--
PTHREAD_LIBS=$PTHREAD_CFLAGS in configure.ac
(3) Do a giant sed to convert PTHREAD_LIBS to PTHREAD_CFLAGS in the entire
tree
Any strong preferences???
On Fri, Oct 28, 2016 at 10:24 AM, Matt Turner wrote:
> On Fri, Oct 28, 2016 at 8:06 AM, Emil Velikov
> wrote:
> > On 27 October 2016 at 17:0
FLAGS.
On Fri, Oct 28, 2016 at 11:59 AM, Emil Velikov
wrote:
> On 28 October 2016 at 19:35, Gurchetan Singh
> wrote:
> > Removing the entire hunk causes build failures on CrOS mesa. Refer to
> this
> > for more information:
> >
> > http://stackoverflow.com/questi
PTHREAD_LIBS=$PTHREAD_CFLAGS in configure.ac
(3) Do a giant sed to convert PTHREAD_LIBS to PTHREAD_CFLAGS in the entire
tree
Any strong preferences???
On Fri, Oct 28, 2016 at 10:24 AM, Matt Turner wrote:
> On Fri, Oct 28, 2016 at 8:06 AM, Emil Velikov
> wrote:
> > On 27 October 2016 at 17:0
Why would PTHREAD_LIBS ever be set at all? Isn't the reason for the
proposed cleanup is we've been passing -pthread as a lib instead of as a
linker flag?
On Fri, Oct 28, 2016 at 5:23 PM, Emil Velikov
wrote:
> On Friday, 28 October 2016, Gurchetan Singh
> wrote:
>
>&
AX_PTHREADS sets PTHREAD_CFLAGS and PTHREAD_LIBS, and we should
not append to it.
This breaks building EGL since PTHREAD_CFLAGS isn't specified, so
let's add it here.
I couldn't find any other places where this breaks the build in
my configuration. If other configurations get broken, we should
a
It's possible to build Mesa for Android using the traditional
autotools workflow. To enable this, let's add the required
pkg-config checks and link against them.
v2: Bundle pkg-config checks together (Emil)
---
configure.ac| 1 +
src/egl/Makefile.am | 2 ++
2 files changed, 3 insertions(
It's possible to build Mesa for Android using the traditional
autotools workflow [1]. ChromiumOS fetches Android prebuilts and
puts them in a sysroot. We now want to use pkg-config to specify
the location of system headers and libraries [2].
To enable this, let's add the required pkg-config checks
There a few places in the code where clearing and reading are done on incorrect
buffers for GLES contexts. See comments for details. This fixes 75 GLES3
dEQP tests on the surfaceless platform with no regressions.
v2: Corrected unclear comment
v3: Make the change in context.c instead of get.c
---
There are a few places in the code where clearing and reading are done on
incorrect buffers for GLES contexts. See comments for details. This
fixes 75 GLES3 dEQP tests on the surfaceless platform with no regressions.
v2: Corrected unclear comment
v3: Make the change in context.c instead of get.c
On Mon, Feb 25, 2019 at 12:35 AM Boris Brezillon
wrote:
>
> From: Daniel Stone
>
> pipe_boxes are x/y + width/height, rather than x0/y0 -> x1/y1. This
> means that (x+width) is not included in the box.
>
> The box intersection check was seemingly written for inclusive regions,
> and would falsely
On Thu, Feb 28, 2019 at 12:39 AM Boris Brezillon
wrote:
>
> Hello Gurchetan,
>
> On Wed, 27 Feb 2019 10:34:26 -0800
> Gurchetan Singh wrote:
>
> > On Mon, Feb 25, 2019 at 12:35 AM Boris Brezillon
> > wrote:
> > >
> > > From: Daniel Stone
>
On Thu, Feb 28, 2019 at 8:15 PM Roland Scheidegger wrote:
>
> Am 01.03.19 um 00:28 schrieb Gurchetan Singh:
> > On Thu, Feb 28, 2019 at 12:39 AM Boris Brezillon
> > wrote:
> >>
> >> Hello Gurchetan,
> >>
> >> On Wed, 27 Feb 2019 10:34:26 -08
When the draw_buffer_enum_to_bitmask function is called while Mesa is
in it's meta state, the wrong GLbitfield is returned sometimes for
OpenGL ES contexts. This is because the _mesa_meta_begin function
makes the ctx->API always equal to the desktop GL during the meta
state.
In the case of GL_BAC
There a few places in the code where clearing and reading are done on incorrect
buffers for GLES contexts. See comments for details. This fixes 75 GLES3
dEQP tests on the surfaceless platform with no regressions.
---
src/mesa/main/buffers.c | 14 --
src/mesa/main/clear.c | 8 +
There a few places in the code where clearing and reading are done on incorrect
buffers for GLES contexts. See comments for details. This fixes 75 GLES3
dEQP tests on the surfaceless platform with no regressions.
v2: Corrected unclear comment
---
src/mesa/main/buffers.c | 14 --
sr
et.c to further
avoid bugs. Let me know if that works for you and I'll send a modified
patch.
I do agree it is a bit hacky ... I'd definitely be interested in
alternative solutions.
On Mon, Jun 27, 2016 at 1:45 PM, Ilia Mirkin wrote:
> On Mon, Jun 27, 2016 at 4:17 PM, Gurchetan Sing
any other ideas.
On Mon, Jun 27, 2016 at 7:55 PM, Ilia Mirkin wrote:
> On Mon, Jun 27, 2016 at 6:30 PM, Gurchetan Singh
> wrote:
> > Hi Ilia,
> >
> > The changes for get.c where prompted by the es3fIntegerStateQueryTests
> (see
> > modules/gles3/functional/es3fIn
Since the fence implementation is not dri2.c specific, put
it in a separate file. This way SW implementations can use this
extension too.
v2: Don't depend on dri2.c for extensions (Emil)
v3: Make this patch only move extension into a separate file (Chad).
---
src/gallium/state_trackers/dri/Makefi
This is desirable for synchronization in virtual machines.
---
src/gallium/state_trackers/dri/drisw.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/state_trackers/dri/drisw.c
b/src/gallium/state_trackers/dri/drisw.c
index b85a73c57d..8fbfa9ecea 100644
--- a/src/gallium/state_t
Just a heads up to Gallium experts (Emil, Tim, Robs + anyone else who
knows this code) -- we'll probably push this soon unless we get more review
comments ...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mail
hetan,
>
> On 9 June 2017 at 01:28, gurchetansi...@chromium.org
> wrote:
> > From: Gurchetan Singh
> >
> > Otherwise, this extension is not visible to the EGL user
> > ---
> > src/egl/drivers/dri2/egl_dri2.c | 1 +
> > 1 file changed, 1 insertion(+)
The naming is verbose and somewhat inconsistent. We have:
dri2_init_surface
dri2_fini_surface
dri2_egl_surface_alloc_local_buffer
dri2_egl_surface_free_local_buffers
I suggest you implement the following convention:
dri2_surface_init
dri2_surface_fini
dri2_surface_alloc_attachment (instead of '
Can you wrap color_buffers around:
#if defined(HAVE_WAYLAND_PLATFORM) || defined(HAVE_DRM_PLATFORM)
|| defined(HAVE_ANDROID_PLATFORM)
flags? This is because platform_surfaceless has no native surfaces and
it's good to be explicit in that regard.
On Fri, Oct 6, 2017 at 2:38 PM, Gwan-gyeong Mun
dri2_egl_surface_destroy_image_front
and dri2_egl_surface_destroy_image_back are almost identical. Why don't
you just create a dri2_surface_free_image(struct dri2_egl_surface
*dri2_surf, __DRIimage **img) that you will call with both the front and
back images? In addition, only platform_android h
OUNT];
#endif
#endif
WDYT?
On Wed, Oct 18, 2017 at 2:55 AM, Emil Velikov
wrote:
> On 17 October 2017 at 21:38, Gurchetan Singh
> wrote:
> > The naming is verbose and somewhat inconsistent. We have:
> >
> > dri2_init_surface
> > dri2_fini_surface
> >
Reviewed-by: Gurchetan Singh
On Wed, Oct 18, 2017 at 9:09 AM, Eric Engestrom
wrote:
> Suggested-by: Emil Velikov
> Signed-off-by: Eric Engestrom
> ---
> src/egl/drivers/dri2/platform_surfaceless.c | 3 +--
> src/egl/drivers/dri2/platform_wayland.c | 3 +--
> sr
The comment "we don't use get_back_bo() since ..." only makes sense in
context on droid_swap_buffers. Why aren't you calling this helper
in dri2_drm_swap_buffers and dri2_wl_swap_buffers_with_damage? It seems
like you can.
On Tue, Oct 17, 2017 at 7:38 AM, Emil Velikov
wrote:
> On 6 October 20
De-duplicating and then trimming down works for me.
On Thu, Oct 19, 2017 at 3:31 AM, Emil Velikov
wrote:
> On 18 October 2017 at 23:36, Gurchetan Singh
> wrote:
> >> Then again, I'd suggest keeping that as separate series. These patches
> >> started as a way to min
you for reviewing the patches.
>
> 2017-10-20 6:18 GMT+09:00 Gurchetan Singh :
> > De-duplicating and then trimming down works for me.
> >
> > On Thu, Oct 19, 2017 at 3:31 AM, Emil Velikov
> > wrote:
> >>
> >> On 18 October 2017 at 23:36, Gurchetan
GMT+09:00 Gurchetan Singh :
> > dri2_egl_surface_destroy_image_front and dri2_egl_surface_destroy_
> image_back
> > are almost identical. Why don't you just create a
> > dri2_surface_free_image(struct dri2_egl_surface *dri2_surf, __DRIimage
> > **img) that you will
No plans to merge dri2_surface_destroy_back_image
and dri2_surface_destroy_front_image ;-)? Otherwise, looks consistent with
the previous review comments. Patches 1-6 are:
Reviewed-by: Gurchetan Singh
On Tue, Oct 24, 2017 at 2:45 PM, Gwan-gyeong Mun wrote:
> To share common dest
This patch series was intended to:
a) de-duplicate code across various platforms.
b) do preparatory work for platform_tizen.
There was some confusion[1] on how we want to move forward with
platform_tizen. Until we can figure that out, I suggest we drop patches
that move stuff out of platform_and
From: Gurchetan Singh
These files provide helper structs and functions for dri2.c and drisw.c,
and name change better conveys that.
---
src/gallium/state_trackers/dri/Makefile.sources| 4 ++--
src/gallium/state_trackers/dri/dri2.c | 2 +-
src
These files provide helper structs and functions for dri2.c and drisw.c,
and name change better conveys that.
---
src/gallium/state_trackers/dri/Makefile.sources| 4 ++--
src/gallium/state_trackers/dri/dri2.c | 2 +-
src/gallium/state_trackers/dri/{
These functions will be used both by drisw.c and
dri2.c. This patch also moves some headers that can
be shared.
---
src/gallium/state_trackers/dri/dri2.c| 105 +-
src/gallium/state_trackers/dri/dri_helpers.c | 108 ++-
src/gallium/state_track
Otherwise, this extension is not visible to the EGL users who
use the swrast driver.
v2: add it to optional_core_extensions instead of swrast_core_extensions,
so it's not a requirement (Emil)
---
src/egl/drivers/dri2/egl_dri2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/egl/drive
Since the revelant functions have been moved to dri_helpers,
drisw.c can make use of the extension. Note we have version 6
of the extension, since we want to support createImageFromTexture.
---
src/gallium/state_trackers/dri/drisw.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/
Although it doesn't seem like a strict requirement of the
code base, we do it when possible and it looks nice.
---
src/gallium/state_trackers/dri/dri_helpers.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/dri/dri_helpers.c
b/src/gallium/state
This will allow the swrast driver to use eglCreateImageKHR,
provided the target is EGL_GL_TEXTURE_2D_KHR or
EGL_GL_RENDERBUFFER_KHR. Note we still have to implement the
create from render buffer path.
---
src/egl/drivers/dri2/platform_x11.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Since the revelant functions have been moved to dri_helpers,
drisw.c can make use of the extension. Note we have version 6
of the extension, since we want to support createImageFromTexture.
v2: Rebase to master
---
src/gallium/state_trackers/dri/drisw.c | 11 +++
1 file changed, 11 insert
Otherwise, this extension is not visible to the EGL users who
use the swrast driver.
This will allow the swrast driver to use eglCreateImageKHR,
provided the target is EGL_GL_TEXTURE_2D_KHR or
EGL_GL_RENDERBUFFER_KHR. Note we still have to implement the
create from render buffer path.
v2: add it
used regardless whether the driver is hardware or
swrast.
On Tue, Aug 1, 2017 at 8:55 AM, Emil Velikov
wrote:
> On 28 July 2017 at 04:48, Gurchetan Singh
> wrote:
> > This will allow the swrast driver to use eglCreateImageKHR,
> > provided the target is EGL_GL
Would kms_swrast + vgem for surfaceless also work for the use case raised
in the bug, or is that a no-go because it assumes the presence of a
driver? I've been testing it[1], it works pretty well, except for one
issue during ChromeOS startup.
[1] https://chromium-review.googlesource.com/c/558218
From: Gurchetan Singh
Use the same fence implementation for drisw.c as dri2.c by
making dri2FenceExtension an external variable. This is desirable
for synchronization in virtual machines.
---
src/gallium/state_trackers/dri/dri2.c | 2 +-
src/gallium/state_trackers/dri/dri_drawable.h | 1
Use the same fence implementation for drisw.c as dri2.c by making
dri2FenceExtension an external variable. Since the fence implementation
is not dri2.c specific, put it in a separate file. This is desirable for
synchronization in virtual machines.
v2: Don't depend on dri2.c for extensions (Emil)
-
Chrome is going to use EGLSync a lot to synchronize between EGL/KMS (along
with the flush image external extension). VM's are used for testing, so
adding this path would be helpful.
On Fri, May 5, 2017 at 5:54 PM, Emil Velikov
wrote:
> Hi Gurchetan,
>
> On 5 May 2017 at 20:56, G
Reviewed-by: Gurchetan Singh
On Thu, May 11, 2017 at 11:57 AM, Emil Velikov
wrote:
> From: Emil Velikov
>
> Cc: Chad Versace
> Cc: Gurchetan Singh
> Signed-off-by: Emil Velikov
> ---
> src/egl/drivers/dri2/platform_surfaceless.c | 22 --
> 1 fi
Reviewed-by: Gurchetan Singh
On Thu, May 11, 2017 at 11:57 AM, Emil Velikov
wrote:
> From: Emil Velikov
>
> Within dri2_display_release() we already tear down all the display
> specifics. Within the platform specific dri initialize however we badly
> and partially duplicate
Reviewed-by: Gurchetan Singh
On Thu, May 11, 2017 at 11:57 AM, Emil Velikov
wrote:
> From: Emil Velikov
>
> Cc: Chad Versace
> Cc: Gurchetan Singh
> Signed-off-by: Emil Velikov
> ---
> src/egl/drivers/dri2/platform_surfaceless.c | 22 --
> 1 fi
Ping.
On Mon, May 8, 2017 at 3:25 PM, Gurchetan Singh wrote:
> Use the same fence implementation for drisw.c as dri2.c by making
> dri2FenceExtension an external variable. Since the fence implementation
> is not dri2.c specific, put it in a separate file. This is desirable for
> syn
Ping
On Mon, May 8, 2017 at 3:29 PM, Gurchetan Singh wrote:
> Chrome is going to use EGLSync a lot to synchronize between EGL/KMS (along
> with the flush image external extension). VM's are used for testing, so
> adding this path would be helpful.
>
> On Fri, May 5, 2
Reviewed-by: Gurchetan Singh
On Wed, Nov 15, 2017 at 7:27 AM, Gwan-gyeong Mun wrote:
> To share common free DRIimage code.
>
> In preparation to adding of new platform which uses this helper.
>
> v2:
> - Fixes from Eric's review:
>a) Split out series of refactor
Emil, would you be fine with leaving the image extension in dri2.c but
still adding it as a drisw extension? That solution would look like:
https://patchwork.freedesktop.org/patch/154807/
On Fri, Jun 9, 2017 at 8:40 AM, Gurchetan Singh wrote:
> Actually, these are the only patches that
Regarding the issues with the emulator, I filed a bug based your comments
and the emulator team has started looking at it (see
https://android-review.googlesource.com/#/c/418541/).
On Tue, Jun 20, 2017 at 1:19 AM, Emil Velikov
wrote:
> On 19 June 2017 at 20:46, Chad Versace wrote:
> > O
Ping...
On Wed, Jun 21, 2017 at 4:40 PM, Gurchetan Singh <
gurchetansi...@chromium.org> wrote:
> Emil,
>
> If I understand you correctly, you're proposing to add the ability to use
> the kms_swrast driver in platform_x11.c (the host is a standard Ubuntu box
> for the e
he time in making it work if it is achievable ...
On Wed, Jun 28, 2017 at 8:24 AM, Emil Velikov
wrote:
> On 9 June 2017 at 01:28, gurchetansi...@chromium.org
> wrote:
> > From: Gurchetan Singh
> >
> > Otherwise, this extension is not visible to the EGL user
> > ---
Hi Robert,
Thanks for looking into this! We need to decide if we want:
(1) A common struct that implementations can subclass, i.e:
struct blah_gralloc_handle {
alloc_handle_t alloc_handle;
int x, y, z;
}
(2) An accessor library that vendors can implement, i.e:
struct drmAndro
handle would
add complexity to our (*registerBuffer) path.
On Thu, Dec 21, 2017 at 10:14 AM, Rob Herring wrote:
> On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
> wrote:
> > Hi Robert,
> >
> > Thanks for looking into this! We need to decide if we want:
> >
gt; Heya,
>
>
> On 12/22/17 1:09 PM, Tomasz Figa wrote:
>
>> On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
>> wrote:
>>
>>> So the plan is for alloc_handle_t to not be sub-classed by the
>>> implementations, but have all necessary information that
12, 2018 at 5:26 AM, Robert Foss
>> wrote:
>>
>>> Heya,
>>>
>>>
>>> On 12/22/17 1:09 PM, Tomasz Figa wrote:
>>>
>>>>
>>>> On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
>>>> wrote:
>>>>
&g
gt; On Fri, Jan 12, 2018 at 2:29 AM, Tomasz Figa wrote:
> > Hi Rob,
> >
> > On Fri, Jan 12, 2018 at 5:26 AM, Robert Foss
> wrote:
> >> Heya,
> >>
> >>
> >> On 12/22/17 1:09 PM, Tomasz Figa wrote:
> >>>
> >>> On Fri, Dec
Hi Eric,
Yes, you pushing this series would be great. I did run our test suite on
this patchset as well.
Best wishes,
Gurchetan
On Tue, Oct 3, 2017 at 7:02 AM, Eric Engestrom
wrote:
> On Monday, 2017-10-02 20:48:24 +, gurchetansi...@chromium.org wrote:
> > From: Gurche
fully runs with
this patchset, though I just ran a few tests. I expect the full suite to be
up and running soon ...
On Tue, Oct 3, 2017 at 10:04 AM, Eric Engestrom
wrote:
> On Tuesday, 2017-10-03 16:30:18 +, Gurchetan Singh wrote:
> > Hi Eric,
> >
> > Yes, you pushing
"The GL state tracker, which is the only one that runs into the
multi-context subtleties (due to share groups), already guarantees that
sampler views are destroyed before their context of creation is destroyed."
How does the GL state tracker guarantee this? Does this guarantee also
apply to pipe_
Reviewed-by: Gurchetan Singh
On Tue, Oct 10, 2017 at 5:46 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> Clarify when headers can be updated here.
>
> Signed-off-by: Dave Airlie
> ---
> include/drm-uapi/README | 3 +++
> 1 file changed, 3 insertions(+)
>
>
None of the PCI id headers have licensing information. Let's add
the standard Mesa license.
---
include/pci_ids/i810_pci_ids.h | 22 ++
include/pci_ids/i915_pci_ids.h | 22 ++
include/pci_ids/i965_pci_ids.h | 22 ++
incl
The tgsi_invariant code never landed in the Mesa side. Is the caps
code is resilient enough to handle this case? From my understanding
the guest caps and host caps don't have to match exactly, and the
"right thing" will be done.
On Mon, Jun 4, 2018 at 6:03 AM Gert Wollny wrote:
>
> Am Donnerstag
Got it, thanks. Let me send a patch to virglrenderer to change
tgsi_invariant to some sort of bitset, since when it lands it'll just
need one bit.
On Mon, Jun 4, 2018 at 9:39 AM Gert Wollny wrote:
>
> Am Montag, den 04.06.2018, 09:07 -0700 schrieb Gurchetan Singh:
> > The tg
I sent out a patch that adds capability bits to this struct, and the
first bit is the tgsi invariant capability. It's dependent on this
patch to apply correctly to master.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop
Tested-by: Gurchetan Singh
Reviewed-by: Gurchetan Singh
On Mon, Jun 4, 2018 at 9:32 PM Dave Airlie wrote:
>
> From: Dave Airlie
>
> This enables ARB_gpu_shader_fp64 if the host provides it.
> ---
> src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
> 1 file changed, 2 inse
Reviewed-by: Gurchetan Singh
On Wed, Jun 6, 2018 at 5:45 PM Dave Airlie wrote:
>
> From: Dave Airlie
>
> This hopefully adds virgl to the correct places and current statuses
> of various extensions.
>
> virgl of course relies on two external things
> a) host driver that
Tested-by: Gurchetan Singh
Reviewed-by: Gurchetan Singh
On Thu, Jun 7, 2018 at 7:24 PM Dave Airlie wrote:
>
> From: Dave Airlie
>
> This enables ARB_gpu_shader_fp64 if the host provides it.
> ---
> src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
> 1 file changed, 2 inse
We don't have cases for atomic types, some of which are explicitly
signed or unsigned.
The other opcodes could have uint or int return types, based on the
sources.
---
src/gallium/auxiliary/tgsi/tgsi_info.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_i
On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák wrote:
> From: Nicolai Hähnle
>
> Allow the caller to specify the row stride (in bytes) with which an image
> should be mapped. Note that completely ignoring USER_STRIDE is a valid
> implementation of mapImage.
>
> This is horrible API design. Unfortun
That sounds fine to me. We can just modify the stride after dri_bo_create(..).
On Wed, Apr 25, 2018 at 7:30 PM, Marek Olšák wrote:
> On Wed, Apr 25, 2018 at 6:56 PM, Gurchetan Singh
> wrote:
>>
>> On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák wrote:
>> > From: Nico
e:
>>
>> Why would you want to modify it? It's exactly what you get when you map
>> it, but that stride can't be used for modesetting.
>>
>> Marek
>>
>>
>> On Wed, Apr 25, 2018 at 11:14 PM, Gurchetan Singh
>> wrote:
>>>
>>
On Thu, Apr 26, 2018 at 3:08 PM, Marek Olšák wrote:
> On Thu, Apr 26, 2018 at 2:40 PM, Gurchetan Singh
> wrote:
>>
>> On Thu, Apr 26, 2018 at 10:23 AM, Marek Olšák wrote:
>> > Gurchetan, can you confirm that the stride returned at alloc() is only
>> >
On Fri, Apr 27, 2018 at 2:00 AM, Nicolai Hähnle wrote:
> On 26.04.2018 04:30, Marek Olšák wrote:
>>
>> On Wed, Apr 25, 2018 at 6:56 PM, Gurchetan Singh
>> mailto:gurchetansi...@chromium.org>> wrote:
>>
>> On Wed, Apr 25, 2018 at 2:16 PM, Marek Olšák
On Mon, Apr 30, 2018 at 2:38 PM, Marek Olšák wrote:
> On Mon, Apr 30, 2018 at 3:11 PM, Eric Anholt wrote:
>>
>> Marek Olšák writes:
>>
>> > From: Nicolai Hähnle
>> >
>> > Allow the caller to specify the row stride (in bytes) with which an
>> > image
>> > should be mapped. Note that completely i
F_REV on the host when reading back
GL_R11F_G11F_B10F and probably converts to GL_FLOAT on the guest. I
guess nobody, even conformance suites, wanted to deal with
GL_UNSIGNED_INT_10F_11F_11F_REV ...
Reviewed-by: Gurchetan Singh
(don't have commit access so hopefully someone merges this)
O
On Fri, May 4, 2018 at 1:11 PM, Ilia Mirkin wrote:
> On Fri, May 4, 2018 at 2:50 PM, Gert Wollny wrote:
>> For that reason I think that a render state validation within st_Clear
>> makes sense, because it makes sure that the states like SCISSOR_TEST
>> or DISCARD_RASTERIZER are properly send to
In vrend_clear, we already save and restore colormasks and stencils:
https://cgit.freedesktop.org/virglrenderer/commit/?id=b75e0a1dabdfbda44c310a69026a9dbd7d980294
https://cgit.freedesktop.org/virglrenderer/commit/?id=252b00d77c30ce39608c1a9de18523cbdcaca623
It would be nice if we can put everyth
Yes, it seems needed for the GLES on GLES work. Still needs to land:
Reviewed-by: Gurchetan Singh
On Wed, May 9, 2018 at 7:15 PM Dave Airlie wrote:
> On 4 April 2018 at 02:06, Jakob Bornecrantz wrote:
> > Signed-off-by: Jakob Bornecrantz
> not sure if still needed or not, but
Reviewed-by: Gurchetan Singh
On Fri, May 18, 2018 at 6:01 AM Elie Tournier
wrote:
> Wrong ML. I add
>
> On Fri, May 18, 2018 at 10:46:29AM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > The host side hasn't got support for this feature yet, so don&#
Reviewed-by: Gurchetan Singh
On Mon, May 21, 2018 at 12:37 AM Gert Wollny
wrote:
> Am Donnerstag, den 17.05.2018, 12:33 +0200 schrieb Gert Wollny:
> > The driver must support at least one of
> >
> > PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT
> > PIPE_CAP_TGSI
Reviewed-by: Gurchetan Singh
On Wed, May 23, 2018 at 1:36 AM Tomeu Vizoso
wrote:
> Virgl could save a lot of work converting buffers in the host side
> between formats if Mesa supported a bunch of other formats when reading
> pixels.
>
> This commit adds cases to handle spec
Without this, I get:
> platform_surfaceless.c:38:10: fatal error: 'loader.h' file not found
> #include "loader.h"
> ^~
> 1 error generated.
I also included this for platform_android, but I haven't tested that
case.
---
src/egl/meson.build | 2 ++
1 file changed, 2 insertions(+)
Haven't tested this, but we do include loader.h
in platform_android.c
Fixes: c5ec1556859b7d33637c9fad13d3473c7b2f9eb3 ("meson: wire up egl/android")
---
src/egl/meson.build | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/egl/meson.build b/src/egl/meson.build
index 9c0b6b4b4a..06922c6c3c 1
Without this, I get:
> platform_surfaceless.c:38:10: fatal error: 'loader.h' file not found
> #include "loader.h"
> ^~
> 1 error generated.
Fixes: 108d257a16859898f5ce02f4759c5c58f9b8c050 ("meson: build libEGL")
v2: Split up patches, modify commit message (Dylan)
---
src/egl/me
On Thu, Aug 30, 2018 at 6:41 AM Erik Faye-Lund
wrote:
>
> From: Tomeu Vizoso
>
> Emulating atomics on top of ssbos can lead to too small max SSBO count,
> so let's use the hw-atomics mechanism to expose atomic buffers instead.
>
> Signed-off-by: Erik Faye-Lund
> ---
> src/gallium/drivers/virgl/
On Thu, Aug 30, 2018 at 6:41 AM Erik Faye-Lund
wrote:
>
> This moves the evergreen-specific max-sizes out as a driver-cap, so
> other drivers with less strict requirements also can use hw-atomics.
>
> Remove ssbo_atomic as it's no longer needed.
>
> We should now be able to use hw-atomics for some
Series is:
Reviewed-by: Gurchetan Singh
On Tue, Sep 4, 2018 at 2:09 AM Erik Faye-Lund
wrote:
>
> OK, so here's a respin of this series, with the following changes:
>
> - [Gurchetan] Use PIPE_MAX_SHADER_BUFFERS instead of
> PIPE_MAX_HW_ATOMIC_BUFFERS.
> - [Gurcheta
1 - 100 of 164 matches
Mail list logo
