https://bugs.freedesktop.org/show_bug.cgi?id=101503
--- Comment #5 from Hi-Angel ---
What are they anyway? Will they may be not appear again if I remove and
redownload whole piglit repo dir?
--
You are receiving this mail because:
You are the QA Contact for the bug._
You should fix the commit message. The subject should be shorter.
Additional comments can be put in a longer description after the short
summary line. See, e.g. https://www.mesa3d.org/submittingpatches.html
for guidelines.
On Thu, Jun 8, 2017 at 5:32 PM, Sandra Koroniewska
wrote:
> ---
> tests/s
On Wed, Jun 21, 2017 at 02:36:42PM -0700, Eric Anholt wrote:
> Rafael Antognolli writes:
>
> > This time, reuse most of the code from egl_khr_fence_sync test.
> >
> > Cc: Eric Anholt
> >
> > Rafael Antognolli (8):
> > egl_khr_fence_sync: Prepare to support android native_sync.
> > egl_khr_fe
Rafael Antognolli writes:
> This time, reuse most of the code from egl_khr_fence_sync test.
>
> Cc: Eric Anholt
>
> Rafael Antognolli (8):
> egl_khr_fence_sync: Prepare to support android native_sync.
> egl_khr_fence_sync: add tests for android fence.
> egl_khr_fence_sync: Add sw_sync lib.
Rafael Antognolli writes:
> Add a test that creates a sync file using sw_sync, and then creates an
> EGL fence sync from that sync file. It also verify that the fence sync
> EGL_SYNC_CONDITION_KHR is set to EGL_SYNC_NATIVE_FENCE_SIGNALED_ANDROID,
> and that EGL_SYNC_STATUS_KHR changes to EGL_SIGN
On 06/21/2017 09:35 AM, Thomas Hellstrom wrote:
On 06/21/2017 05:22 PM, Brian Paul wrote:
On 06/21/2017 08:34 AM, Thomas Hellstrom wrote:
Hi Brian,
On 06/21/2017 04:20 PM, Brian Paul wrote:
On 06/21/2017 06:24 AM, Thomas Hellstrom wrote:
Window systems (read dri3) that allocate a fake frontb
On 06/21/2017 10:29 AM, Thomas Hellstrom wrote:
Window systems (read dri3) that allocate a fake frontbuffer on demand will
effectively read out from the real front before the first swapbuffers after
fake front creation, and the real front buffer content is subject to errors
caused by, among other
Window systems (read dri3) that allocate a fake frontbuffer on demand will
effectively read out from the real front before the first swapbuffers after
fake front creation, and the real front buffer content is subject to errors
caused by, among other things, window reparenting. So increase the likel
Hi, is this patch good for pushing now?
Regards,
Sandra
On Thu, Jun 8, 2017 at 5:35 PM, sandra koroniewska <
sandra.koroniew...@gmail.com> wrote:
> Just corrected the typo in the title and restored the previously deleted
> glUnmapBuffer as Jozef suggested.
> Sorry for posting this in the new mes
https://bugs.freedesktop.org/show_bug.cgi?id=101503
--- Comment #4 from Hi-Angel ---
(In reply to Dylan Baker from comment #3)
>
> Ahh. Okay. That .tmp file is what's tripping it up.
Well, other tmp files are probably fine
$ ls results/master-d69f82c3c940467/tests/*.tmp
https://bugs.freedesktop.org/show_bug.cgi?id=101503
--- Comment #3 from Dylan Baker ---
Ahh. Okay. That .tmp file is what's tripping it up.
--
You are receiving this mail because:
You are the QA Contact for the bug.___
Piglit mailing list
Piglit
On Mon, 2017-06-19 at 16:22 -0700, Eric Anholt wrote:
> Marek Olšák writes:
>
> > From: Marek Olšák
> >
> > Most of the original code is simply wrong.
> >
> > This patch makes sure that at least the returned GPU offsets and strides
> > are correct. This doesn't fix the incorrect CPU upload pat
On 06/21/2017 05:22 PM, Brian Paul wrote:
On 06/21/2017 08:34 AM, Thomas Hellstrom wrote:
Hi Brian,
On 06/21/2017 04:20 PM, Brian Paul wrote:
On 06/21/2017 06:24 AM, Thomas Hellstrom wrote:
Window systems (read dri3) that allocate a fake frontbuffer on demand
will
effectively read out from th
Hi, thanks for your comment. I modified the code a little to get rid of the
compound literal, but change as little as possible.
Regards,
Sandra
On Wed, Jun 21, 2017 at 5:32 PM, Sandra Koroniewska <
sandra.koroniew...@gmail.com> wrote:
> This fixes
> spec/khr_texture_compression_astc/khr_compress
On 06/21/2017 05:16 PM, Brian Paul wrote:
On 06/21/2017 06:25 AM, Thomas Hellstrom wrote:
the (tex->color != color) test, if false may cause uploading of stale
tex_data to the texture and cause a comparison failure. Also add a flush
after uploading so that texture data actually becomes visible f
On 06/21/2017 08:34 AM, Thomas Hellstrom wrote:
Hi Brian,
On 06/21/2017 04:20 PM, Brian Paul wrote:
On 06/21/2017 06:24 AM, Thomas Hellstrom wrote:
Window systems (read dri3) that allocate a fake frontbuffer on demand
will
effectively read out from the real front before the first swapbuffers
a
On 06/21/2017 06:25 AM, Thomas Hellstrom wrote:
Color spacing of 1 between consecutive textures may yield false positives
when probing, and defer error reporting to the transition from color 255 to
color 0. That may be confusing. So increase the color spacing to detect
errors earlier.
Cc: Frank
On 06/21/2017 06:25 AM, Thomas Hellstrom wrote:
the (tex->color != color) test, if false may cause uploading of stale
tex_data to the texture and cause a comparison failure. Also add a flush
after uploading so that texture data actually becomes visible for the draw
thread.
Cc: Frank Henigman
Si
Color spacing of 1 between consecutive textures may yield false positives
when probing, and defer error reporting to the transition from color 255 to
color 0. That may be confusing. So increase the color spacing to detect
errors earlier.
Cc: Frank Henigman
Signed-off-by: Thomas Hellstrom
---
te
the (tex->color != color) test, if false may cause uploading of stale
tex_data to the texture and cause a comparison failure. Also add a flush
after uploading so that texture data actually becomes visible for the draw
thread.
Cc: Frank Henigman
Signed-off-by: Thomas Hellstrom
---
tests/glx/glx-
Hi Brian,
On 06/21/2017 04:20 PM, Brian Paul wrote:
On 06/21/2017 06:24 AM, Thomas Hellstrom wrote:
Window systems (read dri3) that allocate a fake frontbuffer on demand
will
effectively read out from the real front before the first swapbuffers
after
fake front creation, and the real front buf
On 06/21/2017 06:24 AM, Thomas Hellstrom wrote:
Window systems (read dri3) that allocate a fake frontbuffer on demand will
effectively read out from the real front before the first swapbuffers after
fake front creation, and the real front buffer content is subject to errors
caused by, among other
On 06/21/2017 06:25 AM, Thomas Hellstrom wrote:
Backbuffer contents become undefined after a swapbuffer call, so instead
probe the front buffer. Alternatively we can of course probe the back
before the swapbuffer call.
Cc: Frank Henigman
Signed-off-by: Thomas Hellstrom
---
tests/glx/glx-mult
Backbuffer contents become undefined after a swapbuffer call, so instead
probe the front buffer. Alternatively we can of course probe the back
before the swapbuffer call.
Cc: Frank Henigman
Signed-off-by: Thomas Hellstrom
---
tests/glx/glx-multithread-texture.c | 1 +
1 file changed, 1 insertio
Window systems (read dri3) that allocate a fake frontbuffer on demand will
effectively read out from the real front before the first swapbuffers after
fake front creation, and the real front buffer content is subject to errors
caused by, among other things, window reparenting. So increase the likel
On 06/20/2017 08:59 PM, Dylan Baker wrote:
Quoting Petri Latvala (2017-06-20 05:41:11)
On 04/13/2017 09:46 PM, Dylan Baker wrote:
Quoting Brian Paul (2017-04-12 13:04:59)
On 04/12/2017 11:55 AM, Dylan Baker wrote:
It doesn't makes sense to run if a user has removed all tests from a
selected p
26 matches
Mail list logo
