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:
>
> ..
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
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
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
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
&
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
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
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
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
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
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
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
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
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
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
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
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 ++
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
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
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
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
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
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
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
; 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
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
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
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
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
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
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
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
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
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
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:
>> >&
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,
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
On Wed, Dec 21, 2016 at 12:32 PM, Charmaine Lee wrote:
>
> Hi Rob,
>
> Your mesa commit a5e733c mesa: drop current draw/read buffer when ctx is
> released
> is causing rendering issue when running with vmware svga driver.
>
> The problem is when the winsys draw/read buffers are unreferenced, the
er’
> ../../src/compiler/nir/nir.h:1830: note: previous declaration of ‘nir_shader’
> was here
>
> Suggested-by: Rob Clark
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96235
> Signed-off-by: Vinson Lee
> Reviewed-by: Jason Ekstrand
Thanks,
Reviewed-
ee patches reviewed and pushed. And suggestions
about the remaining issues welcome, since there is still some room
for further gains.
[1] https://github.com/freedreno/libdrm/commits/fd-next
Rob Clark (12):
gallium/util: make util_copy_framebuffer_state(src=NULL) work
gallium: un-inline pipe_sur
From: Rob Clark
Be more consistent with the other u_inlines util_copy_xyz_state()
helpers and support NULL src.
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/util/u_framebuffer.c | 37 +-
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/src
Before, it would happily copy list_head next/prev (ie. pointer to the
*from* list_head), leaving things in a confused state and causing much
mayhem.
Signed-off-by: Rob Clark
---
src/util/list.h | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/util/list.h b
Want to re-use this struct, so un-inline it.
Signed-off-by: Rob Clark
---
src/gallium/include/pipe/p_state.h | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/src/gallium/include/pipe/p_state.h
b/src/gallium/include/pipe/p_state.h
index f4bee38
From: Rob Clark
Signed-off-by: Rob Clark
---
src/gallium/drivers/freedreno/freedreno_batch.c | 25
src/gallium/drivers/freedreno/freedreno_util.h | 31 ++---
2 files changed, 33 insertions(+), 23 deletions(-)
diff --git a/src/gallium/drivers/freedreno
From: Rob Clark
Signed-off-by: Rob Clark
---
src/gallium/drivers/freedreno/freedreno_batch.c| 35 ++
src/gallium/drivers/freedreno/freedreno_batch.h| 7 +
src/gallium/drivers/freedreno/freedreno_context.c | 11 ---
src/gallium/drivers/freedreno
Make it easier to track batches, to ensure things happen properly when
they are reordered.
Signed-off-by: Rob Clark
---
src/gallium/drivers/freedreno/freedreno_draw.c | 6 --
src/gallium/drivers/freedreno/freedreno_gmem.c | 6 --
2 files changed, 8 insertions(+), 4 deletions(-)
diff
Note that I originally also had a entry-point that would construct a key
and do lookup from a pipe_surface. I ended up not needing that (yet?)
but it is easy-enough to re-introduce later if we need it for the blit
path.
Signed-off-by: Rob Clark
---
src/gallium/drivers/freedreno
rateMipmap().
Signed-off-by: Rob Clark
---
src/gallium/drivers/freedreno/freedreno_context.h | 6 ++
src/gallium/drivers/freedreno/freedreno_draw.c | 10 ++
src/gallium/drivers/freedreno/freedreno_resource.c | 21 -
3 files changed, 32 insertions(+), 5 deletions(-)
From: Rob Clark
Introduce the batch object, to track a batch/submit's worth of
ringbuffers and other bookkeeping. In this first step, just move
the ringbuffers into batch, since that is mostly uninteresting
churn.
For now there is just a single batch at a time. Note that one
outcome of
For now, not enabled by default, but can be enabled (on a3xx/a4xx) with
FD_MESA_DEBUG=reorder.
Signed-off-by: Rob Clark
---
src/gallium/drivers/freedreno/freedreno_batch.c| 168 ++---
src/gallium/drivers/freedreno/freedreno_batch.h| 1 +
src/gallium/drivers/freedreno
). The
alternative would be having to re-calculate GMEM layout on every
batch, even if the dimensions of the render targets are the same.
Note: This opens up the possibility of pushing gmem/submit into a
helper thread.
Signed-off-by: Rob Clark
---
src/gallium/drivers/freedreno/a2xx/fd2_draw.c
reference is held by cmdstream) as a shadow.
This is done by blitting the remaining other levels (and whatever part
of current level that is not discarded) from the old/shadow buffer to
the new one.
Signed-off-by: Rob Clark
---
src/gallium/drivers/freedreno/freedreno_context.h | 5 +
src
So, this is a bit sad, but this breaks things for 0ad.. and maybe
others. I have an api-trace:
https://people.freedesktop.org/~robclark/0ad-cycladic-archipelago.trace.xz
The problem is the interaction with the VERT_ATTRIB_POS /
VERT_ATTRIB_GENERIC0 switcharoo in vbo_exec_bind_arrays(), althoug
attrsz[0] = 0;
+ exec->vtx.active_sz[0] = 0;
exec->vtx.enabled &= (~BITFIELD64_BIT(VBO_ATTRIB_POS));
exec->vtx.enabled |= BITFIELD64_BIT(VBO_ATTRIB_GENERIC0);
}
---
will fix it...
BR,
-R
On Tue, Jul 5, 2016 at 2:56 PM, Rob Clark wro
vbo_exec_bind_arrays() can re-use it to reset POS.
Signed-off-by: Rob Clark
---
src/mesa/vbo/vbo_exec.h | 1 +
src/mesa/vbo/vbo_exec_api.c | 14 --
src/mesa/vbo/vbo_exec_draw.c | 2 +-
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/src/mesa/vbo/vbo_exec.h b/src/mesa/vbo
On Wed, Jul 6, 2016 at 9:53 AM, Brian Paul wrote:
> On 07/05/2016 08:57 PM, Mathias Fröhlich wrote:
>>
>> On Tuesday, July 05, 2016 15:47:45 Rob Clark wrote:
>>
>> > In bc4e0c4 (vbo: Use a bitmask to track the active arrays in
>> vbo_exec*.)
>>
>&g
On Sat, Jul 2, 2016 at 12:52 PM, Rob Clark wrote:
> So, games/apps that are aware of how a tiler gpu works will make an
> effort to avoid mid-batch (tile pass) updates to textures, UBOs, etc,
> since this will force a flush, and extra resolve (tile->mem) and
> restore (mem->
On Thu, Jun 23, 2016 at 9:35 AM, Emil Velikov wrote:
> Hi all,
>
> On 21 June 2016 at 15:35, Emil Velikov wrote:
>> The fourth release candidate for Mesa 12.0.0 is now available.
>>
>> Note: this is the final release candidate, with Mesa 12.0.0 expected in a
>> couple of days.
>>
> Considering t
On Sat, Jul 2, 2016 at 12:52 PM, Rob Clark wrote:
> So, games/apps that are aware of how a tiler gpu works will make an
> effort to avoid mid-batch (tile pass) updates to textures, UBOs, etc,
> since this will force a flush, and extra resolve (tile->mem) and
> restore (mem->
On Fri, Jul 8, 2016 at 8:00 PM, Chad Versace wrote:
> See the comments.
> ---
> include/GL/internal/dri_interface.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/GL/internal/dri_interface.h
> b/include/GL/internal/dri_interface.h
> index 99c83ec..051ddb4 100644
> ---
destroyed before it is signaled.
Signed-off-by: Rob Clark
---
Maybe adding util_queue_add_job2() is a bit overkill.. although I
think Marek has some in-flight stuff using u_queue, so maybe this
approach is less conflicty?
src/gallium/auxiliary/util/u_queue.c | 12
src/gallium/auxiliary
On Thu, Jun 30, 2016 at 1:16 PM, Francesco Ansanelli
wrote:
>
this looks like the right thing to do.. r-b for the series. Do you
need me to push?
BR,
-R
> ---
> src/gallium/drivers/freedreno/a2xx/fd2_screen.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/
I've pushed 'em, thx
On Wed, Jul 13, 2016 at 1:03 PM, Francesco Ansanelli
wrote:
> Yes, please.
>
> Cheers,
> Francesco
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Jul 14, 2016 at 10:41 AM, Eric Engestrom
wrote:
> On Thu, Jul 14, 2016 at 12:24:32PM +0200, Pali Rohár wrote:
>> Any news? Or possible fix?
>
> Have you tried Emil's suggestion, ie. upgrading to at least 0.8.0?
>
> Build system wizards:
> Any way to check the version and abort the compilat
destroyed before it is signaled.
Signed-off-by: Rob Clark
---
v2: drop the util_queue_add_job2() and just fixup existing callers
src/gallium/auxiliary/util/u_queue.c| 6 +-
src/gallium/auxiliary/util/u_queue.h| 6 +-
src/gallium/drivers/radeonsi/si_state_shaders.c | 3
In d035d50 this changed to 64b.. which I'm pretty sure was
unintentional. Revert it back to 32b so the entire state struct
is a nice round 64b (cache-line size).
(Note sure that it would actually be measurable, but I did notice
that check_state() was hot in some benchmarks.)
Signed-off-by
On Thu, Jul 14, 2016 at 4:41 PM, Gustaw Smolarczyk wrote:
> 2016-07-14 22:14 GMT+02:00 Rob Clark :
>> In d035d50 this changed to 64b.. which I'm pretty sure was
>> unintentional. Revert it back to 32b so the entire state struct
>> is a nice round 64b (cache-line siz
On Fri, Jul 8, 2016 at 12:14 PM, Rob Clark wrote:
> One of the annoying things, since pipe_resource is per-screen, not
> per-context, I end up having to push batch_cache down into screen.
> Which means that, for example, one context switching fb state could
> force flushing a batch
On Mon, Jul 18, 2016 at 8:16 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> There are 2 uses:
> - Asynchronous flushing for multithreaded drivers.
> - Return a fence without flushing (mid-command-buffer fence). The driver
> can defer flushing until fence_finish is called.
This should also be u
On Mon, Jul 18, 2016 at 9:24 AM, Marek Olšák wrote:
> On Mon, Jul 18, 2016 at 2:25 PM, Rob Clark wrote:
>> On Mon, Jul 18, 2016 at 8:16 AM, Marek Olšák wrote:
>>> From: Marek Olšák
>>>
>>> There are 2 uses:
>>> - Asynchronous flushing for multit
On Sun, Jul 17, 2016 at 7:46 PM, Eric Engestrom wrote:
> diff --git a/src/gallium/drivers/freedreno/.editorconfig
> b/src/gallium/drivers/freedreno/.editorconfig
> new file mode 100644
> index 000..cc8e11f
> --- /dev/null
> +++ b/src/gallium/drivers/freedreno/.editorconfig
> @@ -0,0 +1,2 @@
>
Helper to block until all previous jobs are complete.
---
So I think this might end up being useful to me in some cases.. but
the implementation only works for a single threaded queue (which is
all I need). I could also just put a helper in my driver code.
Opinions?
src/gallium/auxiliary/util/u
On Mon, Jul 18, 2016 at 4:34 PM, Nicolai Hähnle wrote:
> On 18.07.2016 22:25, Rob Clark wrote:
>>
>> Helper to block until all previous jobs are complete.
>> ---
>> So I think this might end up being useful to me in some cases.. but
>> the implementation only
st, I suggest you keep
> N+1 fences around (a ring of fences) that you reuse for new jobs and
> keep a pointer to the most-recently-used fence. That way you know
> which fence you need to wait on to make the whole queue idle.
>
> Marek
>
> On Mon, Jul 18, 2016 at 10:25 PM, Rob
On Tue, Jul 19, 2016 at 6:54 AM, Emil Velikov wrote:
> On 19 July 2016 at 04:21, Tomasz Figa wrote:
>> On Tue, Jul 19, 2016 at 2:35 AM, Emil Velikov
>> wrote:
>>> On 18 July 2016 at 16:38, Tomasz Figa wrote:
On Mon, Jul 18, 2016 at 11:58 PM, Emil Velikov
wrote:
> On 18 July 201
()
On Mon, Jul 18, 2016 at 9:11 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> The goal is to do this in st_validate_state:
>while (dirty)
> atoms[u_bit_scan(&dirty)]->update(st);
>
> That implies that atoms can't specify which flags they consume.
> There is exactly one ST_NEW_* flag f
On Tue, Jul 19, 2016 at 11:40 AM, Emil Velikov wrote:
> On 19 July 2016 at 14:36, Rob Clark wrote:
>> On Tue, Jul 19, 2016 at 6:54 AM, Emil Velikov
>> wrote:
>>> On 19 July 2016 at 04:21, Tomasz Figa wrote:
>>>> On Tue, Jul 19, 2016 at 2:35 AM, Emil Velikov
On Wed, Jul 20, 2016 at 7:51 AM, Daniel Stone wrote:
> On 20 July 2016 at 13:47, Daniel Stone wrote:
>> On 19 July 2016 at 20:47, Jonathan wrote:
>>> +typedef VkResult (VKAPI_PTR *PFN_vkGetDmaBufINTEL)(VkDevice device,
>>> VkDeviceMemory mem, VkImage image, int *fd, uint32_t *pitch);
>>
>> Some
Would be nice if we could also have lockdep, like in the linux kernel.
But this is better than nothing.
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/os/os_thread.h | 16
1 file changed, 16 insertions(+)
diff --git a/src/gallium/auxiliary/os/os_thread.h
b/src/gallium
On Thu, Jul 21, 2016 at 6:07 PM, Stéphane Marchesin
wrote:
> On Tue, Jul 19, 2016 at 6:36 AM, Rob Clark wrote:
>> On Tue, Jul 19, 2016 at 6:54 AM, Emil Velikov
>> wrote:
>>> On 19 July 2016 at 04:21, Tomasz Figa wrote:
>>>> On Tue, Jul 19, 2016 at 2:35 AM,
On Thu, Jul 21, 2016 at 1:48 PM, Vedran Miletić wrote:
> LLVM and Mesa both define the DEBUG macro in incompatible ways. As a
> general practice, we should avoid using such generic names when it is
> possible to do so.
>
> This patch renames all occurrences of the DEBUG macro to MESA_DEBUG,
> and
On Thu, Jul 21, 2016 at 9:35 PM, Rob Clark wrote:
> On Thu, Jul 21, 2016 at 1:48 PM, Vedran Miletić wrote:
>> LLVM and Mesa both define the DEBUG macro in incompatible ways. As a
>> general practice, we should avoid using such generic names when it is
>> possible to do
On Fri, Jul 22, 2016 at 4:39 AM, Vedran Miletić wrote:
> On 07/22/2016 03:37 AM, Rob Clark wrote:
>>
>> On Thu, Jul 21, 2016 at 9:35 PM, Rob Clark wrote:
>>>
>>> On Thu, Jul 21, 2016 at 1:48 PM, Vedran Miletić
>>> wrote:
>>>>
>>>&
On Tue, Jul 19, 2016 at 3:24 PM, Ian Romanick wrote:
> After seeing Dave's series to add support GL_ARB_shader_gpu_int64 and
> thinking about adding support for 8- and 16-bit integers, I decided
> that something had to be done about the cut-and-paste madness that is
> ir_constant_expression.cpp.
On Mon, Jul 25, 2016 at 11:16 AM, Brian Paul wrote:
> On 07/18/2016 07:11 AM, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> The goal is to do this in st_validate_state:
>> while (dirty)
>>atoms[u_bit_scan(&dirty)]->update(st);
>>
>> That implies that atoms can't specify which flags
On Mon, Jul 25, 2016 at 8:47 PM, Eric Anholt wrote:
> Rob Herring writes:
>
>> It is necessary to reuse existing BOs when dmabufs are imported. There
>> are 2 cases that need to be handled. dmabufs can be created/exported and
>> imported by the same process and can be imported multiple times.
>>
On Mon, Jul 25, 2016 at 1:19 PM, Marek Olšák wrote:
> On Mon, Jul 25, 2016 at 5:42 PM, Rob Clark wrote:
>> On Mon, Jul 25, 2016 at 11:16 AM, Brian Paul wrote:
>>> On 07/18/2016 07:11 AM, Marek Olšák wrote:
>>>>
>>>> @@ -183,49 +107,42 @@ static vo
On Thu, Jul 28, 2016 at 6:31 AM, Emil Velikov wrote:
> On 28 July 2016 at 09:21, Eric Engestrom wrote:
>> On Wed, Jul 27, 2016 at 07:37:56PM +0200, Francesco Ansanelli wrote:
>>> Hello,
>>>
>>> unluckily this didn't fix the warning...
>>> I've done some more compile testing and found this solutio
ialization for ‘key.vsaturate_s’) [-Wmissing-field-initializers]
>
> With my latest suggestion no warnings on that row, neither from clang:
>
> Ubuntu clang version 3.4-1ubuntu3~precise2 (tags/RELEASE_34/final) (based on
> LLVM 3.4)
>
> Up to you how to proceed..
>
> Cheers
On Thu, Jul 28, 2016 at 6:44 PM, Rob Herring wrote:
> On Thu, Jul 28, 2016 at 1:07 PM, Rob Clark wrote:
>> tbh, I haven't used anything as ancient as 4.6 in a while.. these days
>> I'm using 6.1 and even with 5.x I don't remember seeing that warning.
>
> FW
On Thu, Jul 28, 2016 at 6:36 PM, Rob Herring wrote:
> On Thu, Jun 30, 2016 at 12:16 PM, Francesco Ansanelli
> wrote:
>> ---
>> src/gallium/drivers/freedreno/a2xx/fd2_screen.c |8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/gallium/drivers/freedreno/a2xx
> 2016-07-29 1:53 GMT+02:00 Rob Clark :
>>
>> On Thu, Jul 28, 2016 at 6:44 PM, Rob Herring wrote:
>> > On Thu, Jul 28, 2016 at 1:07 PM, Rob Clark wrote:
>> >> tbh, I haven't used anything as ancient as 4.6 in a while.. these days
>> >> I'
thanks, pushed
On Fri, Jul 29, 2016 at 7:56 AM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
> Valgrind detected that variable ir_copy_propagation_visitor::killed_all
> is uninitialized.
>
> Signed-off-by: Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0...@gmail.com>
> ---
> src/compiler/glsl/opt_co
thanks, applied locally and will push in next day or two..
BR,
-R
On Fri, Jul 29, 2016 at 8:23 PM, Eric Engestrom wrote:
> CovID: 1362445, 1362446
> Signed-off-by: Eric Engestrom
> ---
> src/gallium/drivers/freedreno/a2xx/ir-a2xx.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
hmm, these were actually intended to fall-thru to the 'x' case, just
to give the hw something sensible. (Not that it is a case that should
ever happen.) Maybe better to use unreachable()?
BR,
-R
On Fri, Jul 29, 2016 at 8:27 PM, Eric Engestrom wrote:
> CovID: 1362455, 1362456, 1362457
> Signed-
On Fri, Jul 29, 2016 at 8:33 PM, Eric Engestrom wrote:
> Previously, the bitshift would be performed on a simple int (32 bits on
> most systems), overflow, and then be cast to 64 bits.
and actually 32b on 100% of systems that had a2xx ;-)
I've picked this up locally and will push soon.. thanks
On Fri, Jul 29, 2016 at 3:57 PM, Rob Herring wrote:
> Hi,
>
> This commit in virglrenderer causes a regression in Android for me.
> The parameters that get passed in are last_level = 8, width = 1. I'm
> not really sure if this is valid (I'm guessing there should be some
> min width?), or where I s
it.
Fixes crash with debug build of mesa in:
dEQP-GLES3.functional.vertex_arrays.single_attribute.strides.fixed.user_ptr_stride17_components2_quads1
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95000
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/util/u_vbuf.c | 6 --
1 file
On Mon, Aug 1, 2016 at 1:30 AM, Marc-André Lureau wrote:
>
> Hi
>
> - Original Message -
>> On Fri, Jul 29, 2016 at 3:57 PM, Rob Herring wrote:
>> > Hi,
>> >
>> > This commit in virglrenderer causes a regression in Android for me.
>> > The parameters that get passed in are last_level = 8,
On Mon, Aug 1, 2016 at 8:10 AM, Eric Engestrom
wrote:
> On Sat, Jul 30, 2016 at 09:49:57AM +0200, Francesco Ansanelli wrote:
>> Signed-off-by: Francesco Ansanelli
>> ---
>> src/gallium/drivers/freedreno/a2xx/fd2_screen.c |8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> d
301 - 400 of 1957 matches
Mail list logo
