[Mesa-dev] [PATCH 2/3] gallium: add GREMEDY_string_marker

From: Rob Clark Signed-off-by: Rob Clark --- src/gallium/docs/source/screen.rst | 1 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers

[Mesa-dev] [PATCH 0/3] GREMEDY_string_marker support

From: Rob Clark Punch it through mesa and gallium, plus implementation in freedreno to serve as an example. Radeon should be able to do a similar thing with no-op packets. Not sure about other drivers. Plan to use this extension from apitrace, to emit call and frame #'s for draw command

[Mesa-dev] [PATCH 1/3] mesa: add GREMEDY_string_marker

From: Rob Clark Signed-off-by: Rob Clark --- src/mapi/glapi/gen/GREMEDY_string_marker.xml | 18 ++ src/mapi/glapi/gen/Makefile.am | 1 + src/mapi/glapi/gen/gl_API.xml| 2 ++ src/mesa/main/dd.h | 6 ++ src/mesa/main

[Mesa-dev] [PATCH 3/3] freedreno: implement emit_string_marker

From: Rob Clark Writes string to cmdstream in payload of a no-op packet. Signed-off-by: Rob Clark --- src/gallium/drivers/freedreno/freedreno_context.c | 27 +++ src/gallium/drivers/freedreno/freedreno_screen.c | 2 +- 2 files changed, 28 insertions(+), 1 deletion

Re: [Mesa-dev] [PATCH] mesa: add NV_read_{depth, stencil, depth_stencil} extensions

On Mon, Aug 10, 2015 at 12:54 PM, Marek Olšák wrote: > On Mon, Aug 10, 2015 at 1:02 PM, Rob Clark wrote: >> From: Rob Clark >> >> These extensions allow reading depth/stencil for GLES contexts, which is >> useful for tools like apitrace. >> >> Signed-off-

Re: [Mesa-dev] [PATCH] mesa: add NV_read_{depth, stencil, depth_stencil} extensions

On Mon, Aug 10, 2015 at 3:28 PM, Marek Olšák wrote: > On Mon, Aug 10, 2015 at 9:15 PM, Rob Clark wrote: >> On Mon, Aug 10, 2015 at 12:54 PM, Marek Olšák wrote: >>> On Mon, Aug 10, 2015 at 1:02 PM, Rob Clark wrote: >>>> From: Rob Clark >>>> >>>

[Mesa-dev] [PATCH] mesa: add NV_read_{depth, stencil, depth_stencil} extensions

From: Rob Clark These extensions allow reading depth/stencil for GLES contexts, which is useful for tools like apitrace. Signed-off-by: Rob Clark --- v2: rework format/type checking src/mesa/main/extensions.c | 3 +++ src/mesa/main/readpix.c| 48

[Mesa-dev] [PATCH 2/2] retrace: use GREMEDY_string_marker to emit call no's

If the extension is present, use it to log call numbers for draw commands. Signed-off-by: Rob Clark --- retrace/glretrace.hpp | 2 ++ retrace/glretrace_main.cpp | 15 +++ retrace/retrace.hpp| 2 ++ retrace/retrace_main.cpp | 4 4 files changed, 23 insertions

[Mesa-dev] [PATCH 1/2] retrace: support depth/stencil attachment for gles

type. Still trying to untangle all the logic here... gles really doesn't make it easy. Signed-off-by: Rob Clark --- retrace/glstate.cpp | 3 ++ retrace/glstate_images.cpp | 69 ++-- retrace/glstate_internal.hpp | 1 + 3 files change

Re: [Mesa-dev] [PATCH 1/2] retrace: support depth/stencil attachment for gles

oh, and these two patches are for apitrace.. guess I should have put something in the subject line to make that more clear. No idea if this is the right place to send apitrace patches.. BR, -R On Mon, Aug 10, 2015 at 5:35 PM, Rob Clark wrote: > If we have the NV_read_depth_stencil extens

Re: [Mesa-dev] [PATCH] mesa: add NV_read_{depth, stencil, depth_stencil} extensions

On Mon, Aug 10, 2015 at 5:37 PM, Ilia Mirkin wrote: > On Mon, Aug 10, 2015 at 5:28 PM, Rob Clark wrote: >> From: Rob Clark >> >> These extensions allow reading depth/stencil for GLES contexts, which is >> useful for tools like apitrace. >> >> Signed-

[Mesa-dev] [PATCH] ttn: add buffer texture type

From: Rob Clark Signed-off-by: Rob Clark --- src/gallium/auxiliary/nir/tgsi_to_nir.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c b/src/gallium/auxiliary/nir/tgsi_to_nir.c index 4130697..93dfb80 100644 --- a/src/gallium/auxiliary/nir

[Mesa-dev] [RFC 0/3] Flesh out DiscardFramebuffer and InvalidateFramebuffer

From: Rob Clark Currently, these extension entry points were implemented, but other than error-checking, they were no-op. (Technically, DiscardFramebuffer had a driver hook, but no one implemented it.) So refactor the driver API slightly, and turn these all into calls to DiscardTexture, which

[Mesa-dev] [RFC 1/3] mesa: Driver.DiscardFramebuffer -> Driver.DiscardTexture

From: Rob Clark No one was implementing this driver hook, so let's first turn it into something more useful and better matching the rest of the Driver API. Signed-off-by: Rob Clark --- src/mesa/drivers/common/driverfuncs.c | 2 +- src/mesa/main/dd.h| 6 +++--- src

[Mesa-dev] [RFC 3/3] mesa/st: wire up DiscardTexture

From: Rob Clark Turn it into call to optional pipe->invalidate_resource(). Signed-off-by: Rob Clark --- src/mesa/state_tracker/st_cb_fbo.c | 12 1 file changed, 12 insertions(+) diff --git a/src/mesa/state_tracker/st_cb_fbo.c b/src/mesa/state_tracker/st_cb_fbo.c index 5707

[Mesa-dev] [RFC 2/3] mesa: hook up DiscardTexture for InvalidateFramebuffer and friends

From: Rob Clark We can use same Driver hook for these, in addition to DiscardFramebufferEXT() Signed-off-by: Rob Clark --- src/mesa/main/fbobject.c | 25 ++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/src/mesa/main/fbobject.c b/src/mesa/main

Re: [Mesa-dev] Mesa 11.0.0 release plan

On Tue, Aug 11, 2015 at 1:45 PM, Emil Velikov wrote: > On 29/07/15 19:20, Emil Velikov wrote: >> Hi all, >> >> Below is the preliminary release schedule for Mesa 11.0.0 >> >> August 21st 2015 - Feature freeze/Release candidate 1 >> August 28th 2015 - Release candidate 2 >> September 04th 2015 - Re

Re: [Mesa-dev] [PATCH 0/3] GREMEDY_string_marker support

On Mon, Aug 17, 2015 at 1:12 PM, Ian Romanick wrote: > On 08/10/2015 09:15 AM, Rob Clark wrote: >> From: Rob Clark >> >> Punch it through mesa and gallium, plus implementation in freedreno to >> serve as an example. Radeon should be able to do a similar thing with

Re: [Mesa-dev] [RFC 2/3] mesa: hook up DiscardTexture for InvalidateFramebuffer and friends

On Mon, Aug 17, 2015 at 3:38 PM, Eric Anholt wrote: > Rob Clark writes: > >> From: Rob Clark >> >> We can use same Driver hook for these, in addition to >> DiscardFramebufferEXT() >> >> Signed-off-by: Rob Clark >> --- >> src/mesa/mai

Re: [Mesa-dev] [PATCH v3] mesa: Implement glMemoryBarrierByRegion

so this one appears to break gles dispatch (on i965, but probably others).. Somehow glCheckFramebufferStatus() ends up in _mesa_DeleteFramebuffers(), which doesn't go so well.. not sure I understand the dispatch code to understand what the issue is. But could someone either fix it or revert this

Re: [Mesa-dev] [PATCH v3] mesa: Implement glMemoryBarrierByRegion

ace/retrace_main.cpp:539 #7 0x004078cb in mainLoop () at /home/robclark/src/apitrace/retrace/retrace_main.cpp:599 #8 main (argc=4, argv=0x7fffdfb8) at /home/robclark/src/apitrace/retrace/retrace_main.cpp:908 BR, -R On Fri, Aug 21, 2015 at 5:41 PM, Rob Clark wrote: > so th

Re: [Mesa-dev] [PATCH v3] mesa: Implement glMemoryBarrierByRegion

BR, -R On Mon, Aug 24, 2015 at 11:08 AM, Rob Clark wrote: > ping? It would be kinda nice to have gles working again. > > Fwiw, issue seems to be an off-by-one in the dispatch table, resulting > in (for example) glCheckFramebufferStatus() ending up in > _mesa_DeleteFramebu

Re: [Mesa-dev] [PATCH] freedreno/ir3: fix build breaks due to nir changes

oh, I guess I should have checked mesa list first.. but already pushed fixes for the build breaks before I noticed this.. Btw, you can actually build freedreno on x86 (to at least compile test it).. hint, hint.. BR, -R On Mon, Aug 24, 2015 at 11:43 PM, Jason Ekstrand wrote: > For whatever it's

Re: [Mesa-dev] Mesa 11.0.0 release candidate 2

Emil, could you also cherry-pick: afb6c24a207fe7b9917644b940e4c5d1870c5c92 and then 000e225360c020e8b3de142c4c898baad321d242 (the 2nd depends on the 1st) Those fix x11 font rendering (ie. xterm) with glamor.. BR, -R On Mon, Aug 31, 2015 at 12:55 PM, Marek Olšák wrote: > Hi Emil, > > Would yo

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

[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] 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/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/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

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

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] 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

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

[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: 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:

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] [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] [PATCH] src: replace RTLD_NOW with RTLD_LAZY

On Sat, Aug 6, 2016 at 3:01 AM, Eric Anholt wrote: > Rob Clark writes: > >> On Fri, Aug 5, 2016 at 8:42 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote: >>> Mesa source code prior to this patch uses both RTLD_NOW and RTLD_LAZY. >>> This patch removes all RTLD_N

Re: [Mesa-dev] [PATCH] src: replace RTLD_NOW with RTLD_LAZY

On Sat, Aug 6, 2016 at 4:28 AM, Enrico Weigelt, metux IT consult wrote: > On 06.08.2016 04:05, ⚛ wrote: > >> Question 2: Exists there a reason for _not_ linking radeonsi_dri.so, >> swrastg_dri.so, etc, directly to Mesa's libGL.so? The Gallium >> *_dri.so libraries are the same inode on the filesys

Re: [Mesa-dev] [PATCH 1/3] freedreno/a2xx: fix comparison out of range warnings

Thanks.. my expectation is that ~0 gets cast to the same enum on both sides of the != so I *think* we should be good. BR, -R On Sat, Aug 6, 2016 at 9:05 AM, Francesco Ansanelli wrote: > Hello, > > I did more tests... and I didn't experience any error. > I attach last version of the script. > > C

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

On Sat, Aug 6, 2016 at 11:32 AM, Marek Olšák wrote: > From: Marek Olšák > > required by glClientWaitSync (GL 4.5 Core spec) that can optionally flush > the context Thanks, I've been meaning to add the same thing but haven't had time to work on the native fd fence stuff in a bit.. mind squashing

Re: [Mesa-dev] [PATCH] dri: use 'bool' instead 'int' for boolean variables

how strict are we on that actually? I think whenever we add new gl entry points (ie. implementing new extension, etc) we kinda sorta break ABI, don't we? I thought mixing/matching libGL vs *_dri.so was at least not recommended.. BR, -R On Mon, Aug 8, 2016 at 12:22 PM, Ian Romanick wrote: > I'm

Re: [Mesa-dev] Moving amdgpu/addrlib into a git submodule

On Tue, Aug 9, 2016 at 9:47 AM, Nicolai Hähnle wrote: > Hi everybody, > > addrlib is the addressing and alignment calculator which is used by > radeonsi. It's developed (and also used) internally at AMD, and so far we've > had one open source copy living in the Mesa repository at > src/gallium/win

Re: [Mesa-dev] cairo as state tracker

On Tue, Aug 9, 2016 at 11:11 AM, Enrico Weigelt, metux IT consult wrote: > On 07.08.2016 12:50, Marek Olšák wrote: > >> It would mainly be a futile task if it had to compete with their >> official Mesa driver. > > Not quite. Would give us all of gallium's capabilities also for > the intel chips, f

[Mesa-dev] [PATCH 1/6] gallium/u_blitter: export some functions

Signed-off-by: Rob Clark --- src/gallium/auxiliary/util/u_blitter.c | 145 + src/gallium/auxiliary/util/u_blitter.h | 9 ++ 2 files changed, 84 insertions(+), 70 deletions(-) diff --git a/src/gallium/auxiliary/util/u_blitter.c b/src/gallium/auxiliary/util

[Mesa-dev] [PATCH 2/6] gallium/u_blitter: add helper to save FS const buffer state

Not (currently) state that is overwridden by u_blitter itself, but drivers with custom blit/clear which are reusing part of the u_blitter infrastructure will use it. Signed-off-by: Rob Clark --- src/gallium/auxiliary/util/u_blitter.c | 10 ++ src/gallium/auxiliary/util/u_blitter.h | 15

[Mesa-dev] [PATCH 0/6] Custom u_blitter clear

use a generic u_blitter path). So I end up re-using u_blitter's state restore and some of the common clear state setup, but doing the VBO/shader/etc state setup myself in terms of the pipe_context API (so that it is generation independent). Rob Clark (6): gallium/u_blitter: export some f

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

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(-) diff --git a/src/gallium/auxiliary/util/u_blitter.c b/src/gallium/auxiliary/util

[Mesa-dev] [PATCH 4/6] freedreno: support for using generic clear path

Since clears are more or less just normal draws, there isn't that much benefit in having hand-rolled clear path. Add support to use u_blitter instead if gen specific backend doesn't implement ctx->clear(). Signed-off-by: Rob Clark --- src/gallium/drivers/freedreno/freedreno_dr

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

Signed-off-by: Rob Clark --- src/gallium/drivers/freedreno/a3xx/fd3_context.c | 3 +- src/gallium/drivers/freedreno/a3xx/fd3_draw.c| 201 +-- 2 files changed, 4 insertions(+), 200 deletions(-) diff --git a/src/gallium/drivers/freedreno/a3xx/fd3_context.c b/src/gallium

[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

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

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 >>>

[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] [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

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] [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] [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 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 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] 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/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] 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 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] [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 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

[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

[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 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] [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

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 >> __

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] [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] [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 >

[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

[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] 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 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 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 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 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 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

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

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 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 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 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 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

[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] 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

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 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 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] 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?

<    1   2   3   4   5   6   7   8   9   10   >