Re: [Mesa-dev] Documenting with Sphinx

On Tue, Dec 13, 2016 at 5:47 PM, Eric Anholt wrote: > Jason Ekstrand writes: > >> Hey All, >> I don't figure this will be terribly controversial (I'm about to be wrong, >> aren't I?) but how do people feel about switching our "primary" >> documentation focus, as far as we have one, to sphinx? Ri

Re: [Mesa-dev] Potentially EOL ilo gallium driver

not sure of this communities procedure? However, if it helps >> the patch is here: >> https://cgit.freedesktop.org/~funfunctor/mesa/log/?h=eol-ilo >> >> Kind Regards, >> Edward. >> >> On 12/07/2016 07:08 AM, Ilia Mirkin wrote: >>> On Tue, Dec 6,

Re: [Mesa-dev] Potentially EOL ilo gallium driver

On Tue, Dec 6, 2016 at 2:11 PM, Jason Ekstrand wrote: > On Tue, Dec 6, 2016 at 8:39 AM, Rob Clark wrote: >> >> On Tue, Dec 6, 2016 at 8:42 AM, Emil Velikov >> wrote: >> > On 6 December 2016 at 03:16, Edward O'Callaghan >> > wrote: >> >&

Re: [Mesa-dev] Potentially EOL ilo gallium driver

On Tue, Dec 6, 2016 at 8:42 AM, Emil Velikov wrote: > On 6 December 2016 at 03:16, Edward O'Callaghan > wrote: >> This patch is to potentially remove ourself from the maintaince >> burden of the ilo driver that appears to now be essentially >> unmaintained? >> >> I am not sure of our policy here

Re: [Mesa-dev] [PATCH 00/27] Renderbuffer Decompression (and GBM modifiers)

On Thu, Dec 1, 2016 at 5:09 PM, Ben Widawsky wrote: > When Kristian's interface is ready, kmscube can be modified to make use of it. > > Rob: are you interested in a PR for kmscube? sure, from a quick look seems like it should be backwards compatible.. probably we should set up a git tree on fd.o

[Mesa-dev] [PATCH 4/7] freedreno/ir3: don't offset inloc by 8

On a3xx/a4xx, the SP_VS_VPC_DST_REG.OUTLOCn is offset by 8, so we used to add this offset into fs->inputs[n].inloc. But a5xx drops this extra offset-by-8. So instead make inloc zero based and add the offset when we emit OUTLOCn values (for the gen's that need the offset). Signed-off

[Mesa-dev] [PATCH 5/7] freedreno: make gmem tile size alignment configurable

a5xx seems to prefer 64 pixel alignment, in at least some cases. Make this configurable per generation. Signed-off-by: Rob Clark --- src/gallium/drivers/freedreno/freedreno_gmem.c | 18 ++ src/gallium/drivers/freedreno/freedreno_screen.c | 6 ++ src/gallium/drivers

[Mesa-dev] [PATCH 2/7] freedreno/a4xx: use new shader linkage helper

Signed-off-by: Rob Clark --- src/gallium/drivers/freedreno/a4xx/fd4_program.c | 43 +--- 1 file changed, 16 insertions(+), 27 deletions(-) diff --git a/src/gallium/drivers/freedreno/a4xx/fd4_program.c b/src/gallium/drivers/freedreno/a4xx/fd4_program.c index 0e8efc2..4db846a

[Mesa-dev] [PATCH 3/7] freedreno/a3xx: use new shader linkage helper

Signed-off-by: Rob Clark --- src/gallium/drivers/freedreno/a3xx/fd3_program.c | 43 +--- 1 file changed, 16 insertions(+), 27 deletions(-) diff --git a/src/gallium/drivers/freedreno/a3xx/fd3_program.c b/src/gallium/drivers/freedreno/a3xx/fd3_program.c index 3146dc5..e72d432

[Mesa-dev] [PATCH 1/7] freedreno/ir3: add new helper for shader linkage

Helps simplify things on a5xx, where pos/psize get added to the vs-out map. And anyways, simplifies a3xx and a4xx. Signed-off-by: Rob Clark --- src/gallium/drivers/freedreno/ir3/ir3_shader.h | 44 ++ 1 file changed, 44 insertions(+) diff --git a/src/gallium/drivers

[Mesa-dev] [PATCH 0/7] freedreno: initial a5xx support

in next day or two. [1] https://lists.freedesktop.org/archives/freedreno/2016-November/000805.html Rob Clark (7): freedreno/ir3: add new helper for shader linkage freedreno/a4xx: use new shader linkage helper freedreno/a3xx: use new shader linkage helper freedreno/ir3: don't offset inl

Re: [Mesa-dev] [PATCH] Revert "glsl/es31: precision qualifier doesn't need to match in shader interface block members"

On Fri, Nov 25, 2016 at 3:43 PM, Kenneth Graunke wrote: > On Friday, November 25, 2016 3:19:57 PM PST Rob Clark wrote: >> no worries.. I can keep the reverts locally (it is marginally easier >> than rebuilding glmark2 and I only really care until I get far enough >> with

Re: [Mesa-dev] [PATCH] Revert "glsl/es31: precision qualifier doesn't need to match in shader interface block members"

; When I have a computer in front of me, I can look it up, but the GLSL ES > 1.00 spec is quite clear on the topic. There was a bug a couple months ago > where we discussed this to death. > > > > On November 25, 2016 9:44:10 AM Rob Clark wrote: > >> hmm, that is annoyin

Re: [Mesa-dev] [PATCH] Revert "glsl/es31: precision qualifier doesn't need to match in shader interface block members"

lem. The spec has always > required that precision qualifiers match. This patch is required to pass > conformance. We absolutely cannot revert it. > > > > On November 25, 2016 6:37:47 AM Rob Clark wrote: > >> hmm, actually looks like we need to revert >> 259fc5

Re: [Mesa-dev] [PATCH] Revert "glsl/es31: precision qualifier doesn't need to match in shader interface block members"

hmm, actually looks like we need to revert 259fc505454ea6a67aeacf6cdebf1398d9947759 ("glsl/linker: Fail linking on ES if uniform precision qualifiers don't match") too On Fri, Nov 25, 2016 at 9:32 AM, Rob Clark wrote: > fwiw, issue is that a bunch (all) have "precision me

Re: [Mesa-dev] [PATCH] Revert "glsl/es31: precision qualifier doesn't need to match in shader interface block members"

2016 at 9:30 AM, Rob Clark wrote: > This breaks a whole bunch of gles2 glmark2 "tests".. > > This reverts commit b50b82b8a553f93b4ee9ace734e4c53d5a388a35. > --- > src/compiler/glsl/link_interface_blocks.cpp | 7 ++- > src/compiler/glsl/linker.cpp

[Mesa-dev] [PATCH] Revert "glsl/es31: precision qualifier doesn't need to match in shader interface block members"

This breaks a whole bunch of gles2 glmark2 "tests".. This reverts commit b50b82b8a553f93b4ee9ace734e4c53d5a388a35. --- src/compiler/glsl/link_interface_blocks.cpp | 7 ++- src/compiler/glsl/linker.cpp| 10 +- 2 files changed, 3 insertions(+), 14 deletions(-) diff --g

Re: [Mesa-dev] [PATCH 05/10] gallium: wire up server_wait_sync

On Fri, Nov 18, 2016 at 5:07 PM, Marek Olšák wrote: > On Fri, Nov 18, 2016 at 2:39 PM, Rob Clark wrote: >> From: Rob Clark >> >> This will be needed for explicit synchronization with devices outside >> the gpu, ie. EGL_ANDROID_native_fence_sync. >> >> S

Re: [Mesa-dev] [PATCH 08/10] freedreno: native fence fd support

On Fri, Nov 18, 2016 at 9:20 AM, Chris Wilson wrote: > On Fri, Nov 18, 2016 at 08:39:37AM -0500, Rob Clark wrote: >> +void fd_fence_server_sync(struct pipe_context *pctx, >> + struct pipe_fence_handle *fence) >> +{ >> + struct fd_context *ctx = fd_con

[Mesa-dev] [PATCH 08/10] freedreno: native fence fd support

Requires newer libdrm, and the support only is advertised with a sufficiently new kernel (v4.9 and later) as it depends on fence fd support in the submit ioctl. Signed-off-by: Rob Clark --- configure.ac | 2 +- src/gallium/drivers/freedreno

[Mesa-dev] [RFC 10/10] virgl: native fence fd support

From: Gustavo Padovan --- src/gallium/drivers/virgl/virgl_context.c | 47 +++-- src/gallium/drivers/virgl/virgl_screen.c | 12 +++- src/gallium/drivers/virgl/virgl_winsys.h | 16 - src/gallium/winsys/virgl/drm/virgl_drm_winsys.c| 78 ++

[Mesa-dev] [PATCH 09/10] freedreno: no-op render when we need a fence

If app tries to create a fence but there is no rendering to submit, we need a dummy/no-op submit. Use a string-marker for the purpose.. mostly since it avoids needing to realize that the packet format changes in later gen's (so one less place to fixup for a5xx). Signed-off-by: Rob

[Mesa-dev] [PATCH 07/10] freedreno: some fence cleanup

Prep-work for next patch, mostly move to tracking last_fence as a pipe_fence_handle (created now only in fd_gmem_render_tiles()), and a bit of superficial renaming. Signed-off-by: Rob Clark --- src/gallium/drivers/freedreno/freedreno_batch.c | 2 -- src/gallium/drivers/freedreno

[Mesa-dev] [PATCH 06/10] gallium: support for native fence fd's

From: Rob Clark This enables gallium support for EGL_ANDROID_native_fence_sync, for drivers which support PIPE_CAP_NATIVE_FENCE_FD. Signed-off-by: Rob Clark --- src/gallium/drivers/freedreno/freedreno_screen.c | 2 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium

[Mesa-dev] [PATCH 05/10] gallium: wire up server_wait_sync

From: Rob Clark This will be needed for explicit synchronization with devices outside the gpu, ie. EGL_ANDROID_native_fence_sync. Signed-off-by: Rob Clark Reviewed-by: Marek Olšák --- src/gallium/include/pipe/p_context.h | 6 ++ src/gallium/state_trackers/dri/dri2.c | 6 +- 2 files

[Mesa-dev] [PATCH 04/10] egl: add EGL_ANDROID_native_fence_sync

From: Rob Clark With fixes from Chad squashed in, plus fixes for issues that Rafael found while writing piglit tests. Cc: Chad Versace Cc: Rafael Antognolli Signed-off-by: Rob Clark --- src/egl/drivers/dri2/egl_dri2.c | 58 - src/egl/main/eglapi.c

[Mesa-dev] [PATCH 02/10] egl: un-fallthrough sync attr parsing

Doesn't work so well when you start having more than one possible attrib. Prep-work for next patch. Signed-off-by: Rob Clark --- src/egl/main/eglsync.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/egl/main/eglsync.c b/src/egl/main/eglsync.c index 00

[Mesa-dev] [PATCH 03/10] dri: extend fence extension to support native fd fences

From: Rob Clark Required to implement EGL_ANDROID_native_fence_sync. Signed-off-by: Rob Clark --- include/GL/internal/dri_interface.h | 44 - 1 file changed, 43 insertions(+), 1 deletion(-) diff --git a/include/GL/internal/dri_interface.h b/include/GL

[Mesa-dev] [PATCH 01/10] egl: initialize SyncCondition after attr parsing

From: Rob Clark Reduce the noise in the next patch. For EGL_SYNC_NATIVE_FENCE_ANDROID the sync condition is conditional on EGL_SYNC_NATIVE_FENCE_FD_ANDROID attribute. Signed-off-by: Rob Clark --- src/egl/main/eglsync.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src

[Mesa-dev] [PATCH 00/10] mesa: support for EGL_ANDROID_native_fence_sync (vN+1)

c.txt [2] https://patchwork.freedesktop.org/series/14498/ [3] https://github.com/robclark/kmscube/commits/atomic-fence [4] https://git.collabora.com/cgit/user/robertfoss/drm_hwcomposer.git/log/?h=hwc2_fence_v2 Gustavo Padovan (1): RFC: virgl: native fence fd support Rob Clark (9): egl: initialize SyncCondi

Re: [Mesa-dev] [PATCH 00/13] implement EGL_EXT_image_dma_buf_import_modifiers

On Tue, Nov 15, 2016 at 1:04 PM, Marek Olšák wrote: > On Tue, Nov 15, 2016 at 6:26 PM, Rob Clark wrote: >> On Tue, Nov 15, 2016 at 12:17 PM, Marek Olšák wrote: >>> On Tue, Nov 15, 2016 at 5:58 PM, Rob Clark wrote: >>>> On Tue, Nov 15, 2016 at 11:44 AM, Mare

Re: [Mesa-dev] [PATCH 10/13] gallium: introduce format modifier querying

see drm_fourcc.h (if the extension txt didn't mention that, perhaps it should) BR, -R On Tue, Nov 15, 2016 at 12:23 PM, Roland Scheidegger wrote: > It looks like there aren't any possible modifier bits defined, so how is > this supposed to work? > > Roland > > Am 15.11.2016 um 15:24 schrieb Vara

Re: [Mesa-dev] [PATCH 00/13] implement EGL_EXT_image_dma_buf_import_modifiers

On Tue, Nov 15, 2016 at 12:17 PM, Marek Olšák wrote: > On Tue, Nov 15, 2016 at 5:58 PM, Rob Clark wrote: >> On Tue, Nov 15, 2016 at 11:44 AM, Marek Olšák wrote: >>> >>> Hi, >>> >>> Is the modifier just a driver-specific description of the tiling &

Re: [Mesa-dev] [PATCH 00/13] implement EGL_EXT_image_dma_buf_import_modifiers

On Tue, Nov 15, 2016 at 11:44 AM, Marek Olšák wrote: > > Hi, > > Is the modifier just a driver-specific description of the tiling > layout and compression? > > What makes you think that 8 bytes is enough to describe that? What if > I need 9 bytes just to program the display hardware? > > Drivers i

Re: [Mesa-dev] [PATCH] egl/android: Remove handling of RGB_888 pixel format

On Thu, Nov 10, 2016 at 10:29 AM, Tomasz Figa wrote: > On Thu, Nov 10, 2016 at 11:42 PM, Rob Clark wrote: >> On Wed, Nov 9, 2016 at 11:23 PM, Tomasz Figa wrote: >>> On Thu, Nov 10, 2016 at 5:21 AM, Emil Velikov >>> wrote: >>>> On 9 November 2016 at

Re: [Mesa-dev] [PATCH] egl/android: Remove handling of RGB_888 pixel format

ng >> the RGB_888. > > Hard to say. Personally I haven't worked with any platform using it, > but AFAIK some Qualcomm SoCs support it. I guess a question to Rob > Clark. ;) adreno does support rendering to 888 (and as well scanning it out). I'm not really sure what, if any

Re: [Mesa-dev] [RFC 03/12] egl: add EGL_ANDROID_native_fence_sync

On Mon, Nov 7, 2016 at 6:29 PM, Rafael Antognolli wrote: > On Mon, Oct 31, 2016 at 08:58:26AM -0700, Rafael Antognolli wrote: >> On Sat, Oct 29, 2016 at 01:15:44PM -0400, Rob Clark wrote: >> > On Fri, Oct 28, 2016 at 7:44 PM, Rafael Antognolli >> > wrote: > > ..

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

On Fri, Nov 4, 2016 at 11:31 AM, Emil Velikov wrote: > On 1 November 2016 at 22:05, Rob Clark wrote: >> On Tue, Nov 1, 2016 at 5:42 PM, Mauro Rossi wrote: >>>> Mauro or Chih-Wei should be able to answer this (being do static >>>> wallpapers work in i965?

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

On Tue, Nov 1, 2016 at 5:42 PM, Mauro Rossi wrote: >> Mauro or Chih-Wei should be able to answer this (being do static >> wallpapers work in i965?). >> >> Rob > > Hi, I've perfomed tests with mesa > https://github.com/maurossi/mesa/commits/13.0.0_nougat-x86 > and the deafult pink wallpaper of noug

Re: [Mesa-dev] [RFC 03/12] egl: add EGL_ANDROID_native_fence_sync

s laying around with > those things fixed. > > On Mon, Oct 10, 2016 at 10:43:50AM -0700, Chad Versace wrote: >> From: Rob Clark >> >> [chadv]: Resolve rebase conflicts. >> >> Signed-off-by: Rob Clark >> --- >> src/egl/drivers/dri2/egl_dri2.c |

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

On Fri, Oct 28, 2016 at 1:24 AM, Tapani Pälli wrote: > On 10/27/2016 01:48 PM, Rob Clark wrote: >> >> On Thu, Oct 27, 2016 at 2:59 AM, Tapani Pälli >> wrote: >>> >>> On 10/27/2016 12:16 AM, Rob Clark wrote: >>>> >>>> So, not q

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

On Thu, Oct 27, 2016 at 2:59 AM, Tapani Pälli wrote: > On 10/27/2016 12:16 AM, Rob Clark wrote: >> >> So, not quite sure if this is the *correct* solution, but it is at least >> *a* solution to a problem with android wallpaper vs mesa that I've been >> debugg

[Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

So, not quite sure if this is the *correct* solution, but it is at least *a* solution to a problem with android wallpaper vs mesa that I've been debugging. Basically, what happens is: EGLSurface tmpSurface = mEgl.eglCreatePbufferSurface(mEglDisplay, mEglConfig, attribs); mEgl.eglMakeCurren

Re: [Mesa-dev] [RFC 00/12] egl, i965: Support EGL_ANDROID_native_fence_sync (v2)

On Thu, Oct 13, 2016 at 4:37 PM, Rafael Antognolli wrote: > Hi all, > > On Tue, Oct 11, 2016 at 01:47:37PM -0400, Robert Foss wrote: >> >> >> On 2016-10-11 01:37 PM, Chad Versace wrote: >> > On Tue 11 Oct 2016, Emil Velikov wrote: >> > > On 10 Octo

Re: [Mesa-dev] [RFC 00/12] egl, i965: Support EGL_ANDROID_native_fence_sync (v2)

_ANDROID_native_fence_sync > squash! egl: add EGL_ANDROID_native_fence_sync > squash! egl: add EGL_ANDROID_native_fence_sync > i965: Add intel_screen::has_fence_fd > i965: Add intel_batchbuffer_flush_fence() > i965/sync: Add brw_fence::type > i965/sync: Fail syn

Re: [Mesa-dev] [PATCH] gallium: add missing zero-init for resource templates

so, btw, the question is whether to push this patch, or the one that initializes ->next to NULL in the drivers, or possibly both for good measure. memset'ing the templ is probably a sane future-proofing thing to do regardless. BR, -R On Fri, Oct 7, 2016 at 12:02 PM, Rob Clark wrote:

[Mesa-dev] [PATCH] gallium: add missing zero-init for resource templates

Mostly test code, plus one spot I noticed in r600. Signed-off-by: Rob Clark --- src/gallium/drivers/radeon/r600_texture.c | 1 + src/gallium/tests/graw/clear.c| 1 + src/gallium/tests/graw/fs-test.c | 2 ++ src/gallium/tests/graw/graw_util.h| 2 ++ src/gallium/tests

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

Please memset in state tracker. Most of the other state trackers do this, although I haven't finished auditing yet. BR, -R On Fri, Oct 7, 2016 at 1:56 AM, Axel Davy wrote: > Hi, > > as of writing, there doesn't seem to be a concensus on the fix. > Could one be found for Mesa 13 ? Gallium nine i

Re: [Mesa-dev] Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?)

On Thu, Sep 29, 2016 at 10:56 AM, Emil Velikov wrote: > On 28 September 2016 at 19:53, Marek Olšák wrote: >> Hi, >> >> It's been almost 4 months since the 12.0 branch was created, and soon >> it will have been 3 months since Mesa 12.0 was released. >> >> Is there any reason we haven't created the

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

t 1:45 AM, Roland Scheidegger wrote: >> Sounds reasonable to me. >> >> Roland >> >> Am 04.10.2016 um 01:44 schrieb Rob Clark: >>> There are a lot of callers for ->resource_create() and friends.. >>> although I suspect it is a small subset that don'

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

al world everybody would zero-intialize the template I suppose > - then it would easily survive such interface changes. > I thought though there shouldn't be many callers but I might have been > wrong about this... > > Roland > > > Am 03.10.2016 um 18:48 schrieb Rob

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

always overwrites this to > zero no matter what. Well I suppose those are the consequences of an > interface hack.) > > I'd say state trackers should be fixed up and call it a day. > > Roland > > > Am 03.10.2016 um 18:07 schrieb Rob Clark: >> Fix potential iss

[Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

Fix potential issues if state-tracker passes in garbage in templ->next ptr. See: https://lists.freedesktop.org/archives/mesa-dev/2016-September/129867.html Signed-off-by: Rob Clark --- src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++ src/gallium/drivers/i915/i915_resource_buffe

Re: [Mesa-dev] [PATCH] gallium/r300: initialize pipe_resource::next to NULL

On Tue, Sep 27, 2016 at 10:56 PM, Michel Dänzer wrote: > On 28/09/16 12:33 AM, Rob Clark wrote: >> Signed-off-by: Rob Clark >> --- >> I had a scan through the rest of pipe_resource allocations, and I think >> this is the only remaining one (besides r600_alloc_buffer_s

[Mesa-dev] [PATCH] gallium/r300: initialize pipe_resource::next to NULL

Signed-off-by: Rob Clark --- I had a scan through the rest of pipe_resource allocations, and I think this is the only remaining one (besides r600_alloc_buffer_struct()) which was using MALLOC_STRUCT().. sorry 'bout that src/gallium/drivers/r300/r300_screen_buffer.c | 1 + 1 file chang

Re: [Mesa-dev] [PATCH 3/7] mesa/st: support lowering multi-planar YUV

On Mon, Sep 12, 2016 at 9:39 PM, Roland Scheidegger wrote: >> so, fwiw, reworking __DRIImage + st_texture_object + st_texture_image >> to have multiple resources, tacks on about another +223/-192.. >> untested (so might have missed some things.. the >> st_texture_image/st_texture_object split is a

Re: [Mesa-dev] [PATCH 3/7] mesa/st: support lowering multi-planar YUV

On Sat, Sep 10, 2016 at 10:04 AM, Roland Scheidegger wrote: > Am 09.09.2016 um 02:58 schrieb Rob Clark: >> On Thu, Sep 8, 2016 at 8:28 PM, Roland Scheidegger >> wrote: >>> Am 09.09.2016 um 02:19 schrieb Rob Clark: >>>> On Thu, Sep 8, 2016 at 7:54 PM, Rob Cla

Re: [Mesa-dev] [PATCH 3/7] mesa/st: support lowering multi-planar YUV

On Mon, Sep 12, 2016 at 9:01 AM, Marek Olšák wrote: > On Thu, Sep 8, 2016 at 10:30 PM, Rob Clark wrote: >> Support multi-planar YUV for external EGLImage's (currently just in the >> dma-buf import path) by lowering to multiple texture fetch's for each >> plane and

Re: [Mesa-dev] [PATCH 3/7] mesa/st: support lowering multi-planar YUV

On Thu, Sep 8, 2016 at 8:28 PM, Roland Scheidegger wrote: > Am 09.09.2016 um 02:19 schrieb Rob Clark: >> On Thu, Sep 8, 2016 at 7:54 PM, Rob Clark wrote: >>> On Thu, Sep 8, 2016 at 6:41 PM, Roland Scheidegger >>> wrote: >>>> Am 08.09.2016 um 23:43 schri

Re: [Mesa-dev] [PATCH 3/7] mesa/st: support lowering multi-planar YUV

On Thu, Sep 8, 2016 at 7:54 PM, Rob Clark wrote: > On Thu, Sep 8, 2016 at 6:41 PM, Roland Scheidegger wrote: >> Am 08.09.2016 um 23:43 schrieb Rob Clark: >>> On Thu, Sep 8, 2016 at 5:11 PM, Roland Scheidegger >>> wrote: >>>> Am 08.09.2016 um 22:30 schrie

Re: [Mesa-dev] [PATCH 3/7] mesa/st: support lowering multi-planar YUV

On Thu, Sep 8, 2016 at 6:41 PM, Roland Scheidegger wrote: > Am 08.09.2016 um 23:43 schrieb Rob Clark: >> On Thu, Sep 8, 2016 at 5:11 PM, Roland Scheidegger >> wrote: >>> Am 08.09.2016 um 22:30 schrieb Rob Clark: >>>> Support multi-planar YUV for extern

Re: [Mesa-dev] [PATCH 3/7] mesa/st: support lowering multi-planar YUV

On Thu, Sep 8, 2016 at 5:11 PM, Roland Scheidegger wrote: > Am 08.09.2016 um 22:30 schrieb Rob Clark: >> Support multi-planar YUV for external EGLImage's (currently just in the >> dma-buf import path) by lowering to multiple texture fetch's for each >> plane and CSC

[Mesa-dev] [PATCH 5/7] mesa/st: pass st_compute_program to st_get_cp_variant

Makes it more consistent with vp/fp variants, and will be needed in a following patch. Signed-off-by: Rob Clark --- src/mesa/state_tracker/st_atom_shader.c | 2 +- src/mesa/state_tracker/st_program.c | 12 ++-- src/mesa/state_tracker/st_program.h | 3 +-- 3 files changed, 8

[Mesa-dev] [PATCH 4/7] mesa/st: a bit of basic_variant refactoring

Add a helper to initialize the key, and pass the key into the helper that iterates the variants, similar to how it works for vp/fp variants. The 'prog' arg to the helper gets used in a following patch, and is the reason to pass the key into st_get_basic_variant(). Signed-off-by:

[Mesa-dev] [PATCH 6/7] mesa/st: pass prog to st_get_basic_variant()

Needed in a following patch. Signed-off-by: Rob Clark --- src/mesa/state_tracker/st_atom_shader.c | 6 +++--- src/mesa/state_tracker/st_program.c | 16 src/mesa/state_tracker/st_program.h | 2 +- 3 files changed, 12 insertions(+), 12 deletions(-) diff --git a/src

[Mesa-dev] [PATCH 3/7] mesa/st: support lowering multi-planar YUV

Support multi-planar YUV for external EGLImage's (currently just in the dma-buf import path) by lowering to multiple texture fetch's for each plane and CSC in shader. Signed-off-by: Rob Clark --- src/gallium/auxiliary/util/u_inlines.h | 4 +- src/gallium/include/pipe

[Mesa-dev] [PATCH 7/7] mesa/st: support for YUV in VS/VS/GS/TCS/TEC..

maybe we don't keep these bits? Signed-off-by: Rob Clark --- src/mesa/state_tracker/st_atom_shader.c | 2 ++ src/mesa/state_tracker/st_context.c | 20 +++ src/mesa/state_tracker/st_program.c | 63 ++--- src/mesa/state_tracker/st_program.h

[Mesa-dev] [PATCH 2/7] mesa/st: add nir pass to lower tex_src_plane

Signed-off-by: Rob Clark --- Note: the alternative is to fold this logic into nir_lower_tex (ie. make nir_lower_tex support either multiple samplers or the extra nir_tex_src_plane arg. That probably means changing around the order so that nir_lower_tex runs after nir_lower_samplers, but I guess

[Mesa-dev] [PATCH 1/7] mesa/st: add lowering pass for YUV samplers

Signed-off-by: Rob Clark --- src/mesa/Makefile.sources | 2 + src/mesa/state_tracker/st_tgsi_lower_yuv.c | 447 + src/mesa/state_tracker/st_tgsi_lower_yuv.h | 34 +++ 3 files changed, 483 insertions(+) create mode 100644 src/mesa/state_tracker

[Mesa-dev] [PATCH 0/7] mesa/st: support for YUV EGLImages

test code, which uses gbm to create dmabuf's so it should run on any driver: https://github.com/robclark/kmscube/commits/yuv-cube You can find the latest versions of the patches here: https://github.com/freedreno/mesa/commits/wip-yuv Rob Clark (7): mesa/st: add lowering pass for YUV sam

[Mesa-dev] [PATCH] nir/lower_tex: fix typo with sample_dim

Numeric 2 is actually GLSL_SAMPLER_DIM_3D, which I don't think is what was intended. Signed-off-by: Rob Clark --- src/compiler/nir/nir_lower_tex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler/nir/nir_lower_tex.c b/src/compiler/nir/nir_lower_tex.c

[Mesa-dev] [PATCH 2/2] nir: move tex_instr_remove_src

I want to re-use this in a different pass, so move to nir.h Signed-off-by: Rob Clark --- src/compiler/nir/nir.h | 16 src/compiler/nir/nir_lower_tex.c | 20 ++-- 2 files changed, 18 insertions(+), 18 deletions(-) diff --git a/src/compiler/nir/nir.h b

[Mesa-dev] [PATCH 1/2] nir/lower_tex: remove tex_instr_find_src()

Turns out it already exists.. so don't duplicate it. Signed-off-by: Rob Clark --- src/compiler/nir/nir_lower_tex.c | 17 +++-- 1 file changed, 3 insertions(+), 14 deletions(-) diff --git a/src/compiler/nir/nir_lower_tex.c b/src/compiler/nir/nir_lower_tex.c index 93637a3..b5

Re: [Mesa-dev] [PATCH 3/4] radeonsi: add more unlikely() uses into si_draw_vbo

On Tue, Sep 6, 2016 at 8:23 PM, Michel Dänzer wrote: > On 06/09/16 08:33 PM, Marek Olšák wrote: >> On Sep 6, 2016 12:03 PM, "Michel Dänzer" > > wrote: >>> On 06/09/16 06:04 PM, Marek Olšák wrote: >>> > On Tue, Sep 6, 2016 at 3:54 AM, Michel Dänzer >

Re: [Mesa-dev] [RFC 0/2] mesa/st: support for YUV EGLImages

On Mon, Sep 5, 2016 at 12:37 PM, Ilia Mirkin wrote: > On Mon, Sep 5, 2016 at 12:32 PM, Rob Clark wrote: >>>> + single plane (interleaved) YUV formats? And seems like android >>>>wants YV12 (which is I420 with the 2nd and 3rd planes swapped). >>>>

Re: [Mesa-dev] [RFC 0/2] mesa/st: support for YUV EGLImages

On Mon, Sep 5, 2016 at 12:12 PM, Marek Olšák wrote: > On Fri, Sep 2, 2016 at 9:45 PM, Rob Clark wrote: >> So, android and blob GLES drivers were left unchecked for too long, and >> now we are stuck with this annoying OES_EGL_image_external extension and >> the expectatio

Re: [Mesa-dev] [PATCH] gbm: add missing R8 and GR88 formats

On Mon, Sep 5, 2016 at 6:50 AM, Eric Engestrom wrote: > On Sat, Sep 03, 2016 at 08:52:07AM -0400, Rob Clark wrote: >> Signed-off-by: Rob Clark > > Reviewed-by: Eric Engestrom > >> --- >> I would have added RG88 except we seem to have no corresponding >> __

[Mesa-dev] [PATCH] gbm: add missing R8 and GR88 formats

Signed-off-by: Rob Clark --- I would have added RG88 except we seem to have no corresponding __DRI_IMAGE_FORMAT_RG88 src/gbm/backends/dri/gbm_dri.c | 6 ++ src/gbm/main/gbm.h | 6 ++ 2 files changed, 12 insertions(+) diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm

[Mesa-dev] [RFC 2/2] mesa/st: support lowering multi-planar YUV

Support multi-planar YUV for external EGLImage's (currently just in the dma-buf import path) by lowering to multiple texture fetch's for each plane and CSC in shader. Currently lots of TODO's, only NV12 implemented so far, only wired up in frag shader, etc, etc.. --- src/gallium/auxiliary/util/u_

[Mesa-dev] [RFC 0/2] mesa/st: support for YUV EGLImages

ably some room for a bit of cleanup. And maybe I could split up the patchset better. Anyways, figured I should send this out in it's current state, before I spend too much longer on it, to get some feedback. Rob Clark (2): mesa/st: add lowering pass for YUV samplers mesa/st: supp

[Mesa-dev] [RFC 1/2] mesa/st: add lowering pass for YUV samplers

--- src/mesa/Makefile.sources | 2 + src/mesa/state_tracker/st_tgsi_lower_yuv.c | 441 + src/mesa/state_tracker/st_tgsi_lower_yuv.h | 34 +++ 3 files changed, 477 insertions(+) create mode 100644 src/mesa/state_tracker/st_tgsi_lower_yuv.c create mo

Re: [Mesa-dev] [PATCH mesa 1/2] get_reviewer.pl: fix mesa check

f926cf5bd0ade3273b32 ("docs: Rename GL3.txt to features.txt") > CC: Ian Romanick > CC: Rob Clark > Signed-off-by: Eric Engestrom > --- > scripts/get_reviewer.pl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/get_reviewer.pl b/s

Re: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

t;> query >> which drm_fourcc.h formats EGL supports or if just failing with >> EGL_BAD_MATCH when the >> application >> has use one EGL doesn't support is sufficient. Any thoughts? >> >> >> Cheers, >> >> Tom >> >> >> 8<-

Re: [Mesa-dev] [PATCH mesa] Introduce .editorconfig

On Tue, Aug 30, 2016 at 12:16 PM, Emil Velikov wrote: > On 29 August 2016 at 22:30, Eric Engestrom wrote: > >> A couple of people have also suggested I add `tab_width`, but IMO this >> concept >> should die: it comes from the confusion between indentation (a logic concept >> meant to convey code

Re: [Mesa-dev] simple gallium clean-up task

On Thu, Aug 25, 2016 at 8:00 PM, Brian Paul wrote: > If someone is looking for a simple task in gallium... > > In commit 0135bd44 Marek introduced some new enum types in p_defines.h > > In p_context.h we should replace several instances of "unsigned shader" with > "enum pipe_shader_type shader" an

Re: [Mesa-dev] [PATCH 2/3] gallium: add a pipe_context parameter to resource_get_handle

On Mon, Aug 22, 2016 at 10:39 AM, Marek Olšák wrote: > From: Marek Olšák > > radeonsi needs to do some operations (DCC decompression) for OpenGL-OpenCL > interop and this is the only way to make it coherent with the current > context. It can optionally be set to NULL. so, random thought.. couldn

Re: [Mesa-dev] [PATCH] gallium/util: fix error detection in s3tc init

On Mon, Aug 22, 2016 at 12:58 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: > I am marking this patch as rejected at Patchwork. > > Reason: The patch moved from the 1st page to the 2nd page of > https://patchwork.freedesktop.org/project/mesa/series/?ordering=-last_updated > > Although I am letting it go

Re: [Mesa-dev] [PATCH 2/2] nir: Fix crash in nir_lower_drawpixels.

On Fri, Aug 19, 2016 at 7:12 PM, Eric Anholt wrote: > Generally you'd see the gl_Color reference first and get some cursor set. > However, in piglit draw-pixel-with-texture we're now seeing the TexCoord > dereferenced first. yeah, that makes sense, r-b > --- > src/compiler/nir/nir_lower_drawpix

Re: [Mesa-dev] [PATCH 1/2] nir: Fix a comment typo in nir_lower_drawpixels.

On Fri, Aug 19, 2016 at 7:11 PM, Eric Anholt wrote: > opps, r-b > --- > src/compiler/nir/nir_lower_drawpixels.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/compiler/nir/nir_lower_drawpixels.c > b/src/compiler/nir/nir_lower_drawpixels.c > index 7ffaa525b5a4..a71

Re: [Mesa-dev] [PATCH 0/6] mesa: support for EGL_ANDROID_native_fence_sync

On Fri, Aug 19, 2016 at 5:57 PM, Rob Clark wrote: > Ok, quick update on state of explicit fence fd's / > EGL_ANDROID_native_fence_sync: > > For folks working on other drivers wishing to add support, we don't > have a "real" userspace yet. But Gustavo has ad

Re: [Mesa-dev] [PATCH 0/6] mesa: support for EGL_ANDROID_native_fence_sync

yone else working on their drivers all the bits they need to get started on fence-fd support. BR, -R On Fri, Apr 1, 2016 at 4:29 PM, Rob Clark wrote: > From: Rob Clark > > This patchset implements support for EGL_ANDROID_native_fence_sync[1] > for egl and gallium. This extension

Re: [Mesa-dev] XDC 2016 : Call for paper

On Thu, May 12, 2016 at 6:56 PM, Martin Peres wrote: > Hello, > > I have the pleasure to announce that the X.org Developer Conference 2016 > will be held in Helsinki from September 21 to September 23. The venue is > located at Haaga-Helia university[0], next to the Pasila station. > > The official

Re: [Mesa-dev] XDC 2016 : Call for paper

On Thu, May 12, 2016 at 6:56 PM, Martin Peres wrote: > Hello, > > I have the pleasure to announce that the X.org Developer Conference 2016 > will be held in Helsinki from September 21 to September 23. The venue is > located at Haaga-Helia university[0], next to the Pasila station. > > The official

Re: [Mesa-dev] [RFC] gbm: wire up fence extension

On Thu, Aug 18, 2016 at 8:45 AM, Emil Velikov wrote: > On 16 August 2016 at 18:01, Rob Clark wrote: >> I noticed that fence extension wasn't exposed for drm/gbm, which sort >> of defeats the purpose of using fence fd's for synchronizing rendering >> and atomic

Re: [Mesa-dev] [RFC] gbm: wire up fence extension

On Thu, Aug 18, 2016 at 9:28 AM, Emil Velikov wrote: > On 18 August 2016 at 14:12, Rob Clark wrote: >> On Thu, Aug 18, 2016 at 8:45 AM, Emil Velikov >> wrote: >>> On 16 August 2016 at 18:01, Rob Clark wrote: >>>> I noticed that fence extension wasn'

Re: [Mesa-dev] [RFC] gbm: wire up fence extension

On Thu, Aug 18, 2016 at 8:45 AM, Emil Velikov wrote: > On 16 August 2016 at 18:01, Rob Clark wrote: >> I noticed that fence extension wasn't exposed for drm/gbm, which sort >> of defeats the purpose of using fence fd's for synchronizing rendering >> and atomic

[Mesa-dev] [RFC] gbm: wire up fence extension

I noticed that fence extension wasn't exposed for drm/gbm, which sort of defeats the purpose of using fence fd's for synchronizing rendering and atomic pageflip. I suppose that somewhere or other, there needs to be a similar change to .../state_trackers/dri/dri2.c to avoid breaking things on i965.

Re: [Mesa-dev] [PATCH 3/6] gallium/u_blitter: split out a helper for common clear state

On Mon, Aug 15, 2016 at 10:44 AM, Marek Olšák wrote: > On Sat, Aug 13, 2016 at 8:57 PM, Rob Clark wrote: >> On Sat, Aug 13, 2016 at 2:23 PM, Rob Clark wrote: >>> Signed-off-by: Rob Clark >>> --- >>> src/gallium/auxiliary/util/u_blitter.c | 38 >>>

Re: [Mesa-dev] [PATCH 3/6] gallium/u_blitter: split out a helper for common clear state

On Sat, Aug 13, 2016 at 2:23 PM, Rob Clark wrote: > Signed-off-by: Rob Clark > --- > src/gallium/auxiliary/util/u_blitter.c | 38 > ++ > src/gallium/auxiliary/util/u_blitter.h | 5 + > 2 files changed, 30 insertions(+), 13 deletions(-) &g

[Mesa-dev] [PATCH 6/6] freedreno/a4xx: use generic clear path

Signed-off-by: Rob Clark --- src/gallium/drivers/freedreno/a4xx/fd4_context.c | 3 +- src/gallium/drivers/freedreno/a4xx/fd4_draw.c| 216 +-- 2 files changed, 4 insertions(+), 215 deletions(-) diff --git a/src/gallium/drivers/freedreno/a4xx/fd4_context.c b/src/gallium

<    3   4   5   6   7   8   9   10   11   12   >