Kenneth
Thank you for the commit info. Please consider this patch abandoned.
On Thu, Dec 22, 2016 at 11:50 AM, Kenneth Graunke <kenn...@whitecape.org>
wrote:
> On Thursday, December 22, 2016 10:47:46 AM PST Haixia Shi wrote:
> > Hello Mesa-Dev:
> >
> > To g
propose
that we sanitize all input stencil mask values.
Thanks,
Haixia
On Thu, Dec 22, 2016 at 10:43 AM, Haixia Shi <h...@chromium.org> wrote:
> Since the maximum supported precision for stencil buffers is 8 bits, we
> should set bits 8:31 in the input mask values to zero.
>
.functional.state_query.integers.stencil_value_mask_separate_both_getfloat
*
dEQP-GLES3.functional.state_query.integers.stencil_back_value_mask_separate_getfloat
*
dEQP-GLES3.functional.state_query.integers.stencil_back_value_mask_separate_both_getfloat
Signed-off-by: Haixia Shi <h...@chromium.org>
Cc: Ian Ro
-by: Haixia Shi <h...@chromium.org>
Cc: Jason Ekstrand <ja...@jlekstrand.net>,
Cc: Stéphane Marchesin <marc...@chromium.org>,
Cc: Kenneth Graunke <kenn...@whitecape.org>
Change-Id: I324c948b3323ff8107127c42934f14459e124b95
---
src/compiler/glsl/builtin_functions.cpp | 13 +
Clamp input scalar value to range [-10, +10] to avoid precision problems
when the absolute value of input is too large.
Fixes dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.* test
failures.
v2: added more explanation in the comment.
Signed-off-by: Haixia Shi <h...@chromium.
net> wrote:
> On Thu, Dec 8, 2016 at 3:31 PM, Haixia Shi <h...@chromium.org> wrote:
>
>> We're encountering failures in the latest version of dEQP (specifically,
>> dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.highp_*)
>> on all Intel devices.
&g
Clamp input scalar value to range [-10, +10] to avoid precision problems
when the absolute value of input is too large.
Fixes dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.* test
failures.
Signed-off-by: Haixia Shi <h...@chromium.org>
Cc: Jason Ekstrand <ja...@jleks
We're encountering failures in the latest version of dEQP (specifically,
dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.highp_*) on
all Intel devices.
The problem is that when the abs value of input is too large (say 80), the
function should return +/-1, but the actual shader
.*
Signed-off-by: Haixia Shi <h...@chromium.org>
Cc: Chad Versace <chadvers...@chromium.org>
Cc: Stéphane Marchesin <marc...@chromium.org>
Change-Id: I81bbc8ccdc7e125edaeae443baf6fa8fdefcc6b6
---
src/mesa/main/framebuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
(GL_IMPLEMENTATION_COLOR_READ_FORMAT) queries.
TEST=dEQP-GLES3.functional.state_query.integers.*
Signed-off-by: Haixia Shi <h...@chromium.org>
Cc: Chad Versace <chadvers...@chromium.org>
Cc: Stéphane Marchesin <marc...@chromium.org>
Change-Id: I81bbc8ccdc7e125edaeae443baf6fa8fdefcc6b6
Pinging this thread - any objection to commit this? Thanks.
On Thu, Jul 28, 2016 at 8:58 PM, Tomasz Figa <tf...@chromium.org> wrote:
> On Fri, Jul 29, 2016 at 2:51 AM, Haixia Shi <h...@chromium.org> wrote:
> > On android platform, the width and height of a nati
We need to include mt->offset in the calculation of src pointer because its
value may be non-zero, for example in a cubemap texture.
Signed-off-by: Haixia Shi <h...@chromium.org>
Cc: Jason Ekstrand <jason.ekstr...@intel.com>
Cc: kenneth.w.grau...@intel.com
Cc: Chad Versace <
We need to include mt->offset in the calculation of src pointer because its
value may be non-zero, for example in a cubemap texture.
Signed-off-by: Haixia Shi <h...@chromium.org>
Cc: Jason Ekstrand <jason.ekstr...@intel.com>
Cc: kenneth.w.grau...@intel.com
Cc: Chad Versace <
On android platform, the width and height of a native window surface may
be updated after initialization. It is therefore necessary to query android
framework for the current width and height.
v2: remove Android specific #ifdef's and just implement the fallback directly
if the platform
On android platform, the width and height of a native window surface may
be updated after initialization. It is therefore necessary to query android
framework for the current width and height.
TEST=dEQP-EGL.functional.resize.surface_size#* on cyan-cheets
Signed-off-by: Haixia Shi &l
l.com> wrote:
> > On 16 June 2016 at 20:42, Haixia Shi <h...@chromium.org> wrote:
> >> Bisect shows the problem started at commit
> >> 3689ef32afdafbb030069e560aac0e563fc29048
> >> Author: Emil Velikov <emil.veli...@collabora.com>
> >>
f-by: Emil Velikov <emil.veli...@collabora.com>
I'm not building from a release tarball, but the workflow first copies the
source tree to a tmp directory (without the .git directory), so there's no
git_sha1.h file, and the file is not generated either.
On Thu, Jun 16, 2016 at 11:46 AM, Haixia Shi &
Posting a question in case someone already know the issue.
I'm observing "missing git_sha1.h" errors sometime after Emil's git_sha1.h
patches by May 31st. This is not fixed at TOT with the latest patches on
Makefile.am.
The problem only happens if src/git_sha1.h doesn't exist already. I just
To avoid blocking other EGL calls, release the display mutex before
we enqueue buffer to android frameworks and re-acquire the mutex
upon return.
v2: moved lock/unlock inside droid_window_enqueue_buffer().
TEST=verify pinch zoom in Photos app no longer causes hangs
Signed-off-by: Haixia Shi &l
To avoid blocking other EGL calls, release the display mutex before
we enqueue buffer to android frameworks and re-acquire the mutex
upon return.
TEST=verify pinch zoom in Photos app no longer causes hangs
Signed-off-by: Haixia Shi <h...@chromium.org>
---
src/egl/drivers/dri2/platform_and
t 4:21 PM, Haixia Shi <h...@chromium.org> wrote:
>> Kristian
>>
>> While testing these we found several NULL pointer access and deadlock
>> problems with the YUV patches. I have uploaded a few proposed fixes,
>> can you take a look?
>
>
Kristian
While testing these we found several NULL pointer access and deadlock
problems with the YUV patches. I have uploaded a few proposed fixes,
can you take a look?
(1) i965: fix NULL pointer access in intel_image_target_texture_2d
If image->planar_format is NULL we need to fall back to
and investigate SRGB later.
v4: rebased on top of the GLES3 sRGB workaround fix.
v5: rebased on top of the GLES3 sRGB workaround fix v2.
Signed-off-by: Haixia Shi <h...@chromium.org>
Reviewed-by: Stéphane Marchesin <marc...@chromium.org>
Cc: kenneth.w.grau...@intel.co
It is incorrect to assume BGRA byte order for the GLES3 sRGB workaround.
v2: use _mesa_get_srgb_format_linear to handle all formats
Signed-off-by: Haixia Shi <h...@chromium.org>
Reviewed-by: Stéphane Marchesin <marc...@chromium.org>
Cc: kenneth.w.grau...@intel.co
lekstrand.net> wrote:
>
> On Apr 6, 2016 7:23 PM, "Kenneth Graunke" <kenn...@whitecape.org> wrote:
> >
> > On Wednesday, April 6, 2016 4:43:39 PM PDT Haixia Shi wrote:
> > > It is incorrect to assume BGRA byte order for the GLES3 sRGB
> workar
aults to off for desktop GL, and on for GL ES (why? no clue.)
>
> On Tue, Apr 5, 2016 at 8:11 PM, Haixia Shi <h...@chromium.org> wrote:
> > Are you referring to the following check
> >
> > mesa_format
> > _mesa_get_render_format(const struct gl_context *ctx, mesa_format
It is incorrect to assume BGRA byte order for the GLES3 sRGB workaround.
Signed-off-by: Haixia Shi <h...@chromium.org>
Reviewed-by: Stéphane Marchesin <marc...@chromium.org>
Cc: kenneth.w.grau...@intel.com
Change-Id: I5a081d7eaa7544afff0e7874cffef80d3f69a401
---
src/mesa/driv
and investigate SRGB later.
v4: rebased on top of the GLES3 sRGB workaround fix.
Signed-off-by: Haixia Shi <h...@chromium.org>
Reviewed-by: Stéphane Marchesin <marc...@chromium.org>
Cc: kenneth.w.grau...@intel.com
Change-Id: Ib75087aef1fbfb51baa72517207fed410dcd7b1e
---
src/mesa/driv
and investigate SRGB later.
Signed-off-by: Haixia Shi <h...@chromium.org>
Reviewed-by: Stéphane Marchesin <marc...@chromium.org>
Cc: kenneth.w.grau...@intel.com
Change-Id: Ib75087aef1fbfb51baa72517207fed410dcd7b1e
---
src/mesa/drivers/dri/i965/intel_screen.c | 20
1
false then I should not
have this problem? Thanks
On Tue, Apr 5, 2016 at 2:04 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Tue, Apr 5, 2016 at 4:57 PM, Haixia Shi <h...@chromium.org> wrote:
> > CC Stephane
> >
> > In my opinion we should not assu
5, 2016 at 1:52 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Tue, Apr 5, 2016 at 4:33 PM, Haixia Shi <h...@chromium.org> wrote:
> > It is incorrect to assume that pixel format is always in BGR byte order.
> > We need to check bitmask parameters (such as |redMa
: reformat code to stay within 80 character per line limit.
Signed-off-by: Haixia Shi <h...@chromium.org>
Reviewed-by: Stéphane Marchesin <marc...@chromium.org>
Cc: kenneth.w.grau...@intel.com
Change-Id: Ib75087aef1fbfb51baa72517207fed410dcd7b1e
---
src/mesa/drivers/dri/i965/intel_s
.
Signed-off-by: Haixia Shi <h...@chromium.org>
Reviewed-by: Stéphane Marchesin <marc...@chromium.org>
Cc: kenneth.w.grau...@intel.com
Change-Id: Ib75087aef1fbfb51baa72517207fed410dcd7b1e
---
src/mesa/drivers/dri/i965/intel_screen.c | 10 +-
1 file changed, 5 insertions(+), 5 deleti
The NULL platform is for off-screen rendering only. Render node support is
required.
Only consider the render nodes. Do not use normal nodes as they require
auth hooks.
Signed-off-by: Haixia Shi h...@chromium.org
---
src/egl/drivers/dri2/Makefile.am | 5 ++
src/egl/drivers/dri2/egl_dri2.c
Signed-off-by: Haixia Shi h...@chromium.org
---
src/egl/drivers/dri2/platform_drm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/egl/drivers/dri2/platform_drm.c
b/src/egl/drivers/dri2/platform_drm.c
index 02e87f7..834387f 100644
--- a/src/egl/drivers/dri2
The NULL platform is for off-screen rendering only. Render node support is
required.
Signed-off-by: Haixia Shi h...@chromium.org
---
src/egl/drivers/dri2/Makefile.am | 5 ++
src/egl/drivers/dri2/egl_dri2.c | 13 ++-
src/egl/drivers/dri2/egl_dri2.h | 3 +
src/egl/drivers/dri2
The NULL platform is for off-screen rendering only. Render node support is
required.
Signed-off-by: Haixia Shi h...@chromium.org
---
src/egl/drivers/dri2/Makefile.am | 5 ++
src/egl/drivers/dri2/egl_dri2.c | 13 ++-
src/egl/drivers/dri2/egl_dri2.h | 3 +
src/egl/drivers/dri2
On Fri, Jan 23, 2015 at 8:42 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 23/01/15 02:00, Haixia Shi wrote:
Hi Emil,
On Thu, Jan 22, 2015 at 4:38 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 22/01/15 22:23, Haixia Shi wrote:
Hi Emil
On Thu, Jan 22, 2015 at 1:36 PM, Emil Velikov
The NULL platform is for off-screen rendering only. Render node support is
required.
v2: Only consider the render nodes. Do not use normal nodes as they require
auth hooks.
Signed-off-by: Haixia Shi h...@chromium.org
---
src/egl/drivers/dri2/Makefile.am | 5 ++
src/egl/drivers/dri2
Hi Emil
On Thu, Jan 22, 2015 at 1:36 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
Hi Haixia Shi,
On 22/01/15 17:35, Haixia Shi wrote:
Try the render node first and use it if available. Otherwise fall back to
normal nodes.
What is the use-case for such a platform - I assume it's worth
Hi Emil,
On Thu, Jan 22, 2015 at 4:38 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 22/01/15 22:23, Haixia Shi wrote:
Hi Emil
On Thu, Jan 22, 2015 at 1:36 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Hi Haixia Shi,
On 22/01/15 17:35, Haixia Shi wrote:
Try the render node first
The NULL platform is for off-screen rendering only.
Try the render node first and use it if available. Otherwise fall back to
normal nodes.
Signed-off-by: Haixia Shi h...@chromium.org
---
src/egl/drivers/dri2/Makefile.am | 5 +
src/egl/drivers/dri2/egl_dri2.c | 13 ++-
src/egl
Try the render node first and use it if available. Otherwise fall back to
normal nodes.
Signed-off-by: Haixia Shi h...@chromium.org
---
src/egl/drivers/dri2/Makefile.am | 5 +
src/egl/drivers/dri2/egl_dri2.c | 13 ++-
src/egl/drivers/dri2/egl_dri2.h | 3 +
src/egl/drivers/dri2
Try the render node first and use it if available. Otherwise fall back to
normal nodes.
Signed-off-by: Haixia Shi h...@chromium.org
---
src/egl/drivers/dri2/Makefile.am | 5 +
src/egl/drivers/dri2/egl_dri2.c | 13 ++-
src/egl/drivers/dri2/egl_dri2.h | 3 +
src/egl/drivers/dri2
Try the render node first and use it if available. Otherwise fall back to
normal nodes.
Signed-off-by: Haixia Shi h...@chromium.org
---
src/egl/drivers/dri2/Makefile.am | 5 ++
src/egl/drivers/dri2/egl_dri2.c | 11 ++-
src/egl/drivers/dri2/egl_dri2.h | 3 +
src/egl/drivers
Try the render node first and use it if available. Otherwise fall back to
normal nodes.
Signed-off-by: Haixia Shi h...@chromium.org
---
src/egl/drivers/dri2/Makefile.am | 5 +
src/egl/drivers/dri2/egl_dri2.c | 11 ++-
src/egl/drivers/dri2/egl_dri2.h | 3 +
src/egl/drivers/dri2
enough space
to hold the [0] suffix, resulting in an incomplete array specification like
foobar[0.
Change-Id: Icd58cd6a73c9de7bbe5659d757b8009021846019
Signed-off-by: Haixia Shi h...@chromium.org
Reviewed-by: Stephane Marchesin marc...@chromium.org
---
src/mesa/main/shaderapi.c | 5 -
1 file
30, 2013 at 4:26 AM, Dragomir Ivanov drago.iva...@gmail.com
wrote:
I don't know OpenGL very much, but can uniforms be more than 10? So you
can have [24] where you will need +4, not +3.
On Sat, Mar 30, 2013 at 3:22 AM, Haixia Shi h...@chromium.org wrote:
If the active uniform is an array
enough space
to hold the [0] suffix, resulting in an incomplete array specification like
foobar[0.
Change-Id: Icd58cd6a73c9de7bbe5659d757b8009021846019
Signed-off-by: Haixia Shi h...@chromium.org
Reviewed-by: Stéphane Marchesin marc...@chromium.org
---
src/mesa/main/shaderapi.c | 5 -
1 file
49 matches
Mail list logo
