Kenneth
Thank you for the commit info. Please consider this patch abandoned.
On Thu, Dec 22, 2016 at 11:50 AM, Kenneth Graunke
wrote:
> On Thursday, December 22, 2016 10:47:46 AM PST Haixia Shi wrote:
> > Hello Mesa-Dev:
> >
> > To give you some background, we are obser
would propose
that we sanitize all input stencil mask values.
Thanks,
Haixia
On Thu, Dec 22, 2016 at 10:43 AM, Haixia Shi 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.
>
> The problem i
.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
Cc: Ian Romanick
---
src/mesa
: Haixia Shi
Cc: Jason Ekstrand ,
Cc: Stéphane Marchesin ,
Cc: Kenneth Graunke
Change-Id: I324c948b3323ff8107127c42934f14459e124b95
---
src/compiler/glsl/builtin_functions.cpp | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/compiler/glsl
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
Cc: Jason Ekstrand
> On Thu, Dec 8, 2016 at 3:31 PM, Haixia Shi 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.
>>
>> The problem is that w
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
Cc: Jason Ekstrand ,
Cc: Stéphane Marchesin ,
Cc: Kenneth
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 outpu
.*
Signed-off-by: Haixia Shi
Cc: Chad Versace
Cc: Stéphane Marchesin
Change-Id: I81bbc8ccdc7e125edaeae443baf6fa8fdefcc6b6
---
src/mesa/main/framebuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index 38bd680
(GL_IMPLEMENTATION_COLOR_READ_FORMAT) queries.
TEST=dEQP-GLES3.functional.state_query.integers.*
Signed-off-by: Haixia Shi
Cc: Chad Versace
Cc: Stéphane Marchesin
Change-Id: I81bbc8ccdc7e125edaeae443baf6fa8fdefcc6b6
---
src/mesa/main/framebuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
Pinging this thread - any objection to commit this? Thanks.
On Thu, Jul 28, 2016 at 8:58 PM, Tomasz Figa wrote:
> On Fri, Jul 29, 2016 at 2:51 AM, Haixia Shi wrote:
> > On android platform, the width and height of a native window surface may
> > be updated after initialization.
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
Cc: Jason Ekstrand
Cc: kenneth.w.grau...@intel.com
Cc: Chad Versace
Change-Id: I461ad5b204626d5a1c45611fc6b63735dcf29f63
---
src/m
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
Cc: Jason Ekstrand
Cc: kenneth.w.grau...@intel.com
Cc: Chad Versace
Change-Id: I461ad5b204626d5a1c45611fc6b63735dcf29f63
---
src/m
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 query_surfa
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
---
src/egl
the new git_sha1.h rules, I wonder if it is ok to
add a step for git_sha1.h.tmp that does a "touch git_sha1.h" to ensure the
file exists?
On Thu, Jun 16, 2016 at 12:48 PM, Emil Velikov
wrote:
> On 16 June 2016 at 20:47, Emil Velikov wrote:
> > On 16 June 2016 at 20:42, Haix
irst 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 wrote:
> Posting a question in case someone already know the issue.
>
> I'm observing &q
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
need
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
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
---
src/egl/drivers/dri2/platform_android.c | 9 -
1
Kristian
(1), (2): thanks, I will try the latest patches
(3): sorry, this is not specific to YUV sampling patches. I believe
this problem has always been there.
On Mon, May 16, 2016 at 4:33 PM, Kristensen, Kristian H
wrote:
> On Mon, May 16, 2016 at 4:21 PM, Haixia Shi 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?
(1) i965: fix NULL pointer access in intel_image_target_texture_2d
If image->planar_format is NULL we need to fall back to invok
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
Reviewed-by: Stéphane Marchesin
Cc: kenneth.w.grau...@intel.com
Change-Id: Ib75087aef1fbfb51baa72517207fed410dcd7b1e
---
src/mesa
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
Reviewed-by: Stéphane Marchesin
Cc: kenneth.w.grau...@intel.com
Change-Id: I5a081d7eaa7544afff0e7874cffef80d3f69a401
---
src/mesa
t;
> On Apr 6, 2016 7:23 PM, "Kenneth Graunke" 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
> workaround.
> > >
> > > Signed-off-by: Haixia
d on for GL ES (why? no clue.)
>
> On Tue, Apr 5, 2016 at 8:11 PM, Haixia Shi wrote:
> > Are you referring to the following check
> >
> > mesa_format
> > _mesa_get_render_format(const struct gl_context *ctx, mesa_format format)
> > {
> >if (ctx->
It is incorrect to assume BGRA byte order for the GLES3 sRGB workaround.
Signed-off-by: Haixia Shi
Reviewed-by: Stéphane Marchesin
Cc: kenneth.w.grau...@intel.com
Change-Id: I5a081d7eaa7544afff0e7874cffef80d3f69a401
---
src/mesa/drivers/dri/i965/brw_context.c | 18 --
1 file
investigate SRGB later.
v4: rebased on top of the GLES3 sRGB workaround fix.
Signed-off-by: Haixia Shi
Reviewed-by: Stéphane Marchesin
Cc: kenneth.w.grau...@intel.com
Change-Id: Ib75087aef1fbfb51baa72517207fed410dcd7b1e
---
src/mesa/drivers/dri/i965/intel_screen.c | 20
1
investigate SRGB later.
Signed-off-by: Haixia Shi
Reviewed-by: Stéphane Marchesin
Cc: kenneth.w.grau...@intel.com
Change-Id: Ib75087aef1fbfb51baa72517207fed410dcd7b1e
---
src/mesa/drivers/dri/i965/intel_screen.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff
false then I should not
have this problem? Thanks
On Tue, Apr 5, 2016 at 2:04 PM, Ilia Mirkin wrote:
> On Tue, Apr 5, 2016 at 4:57 PM, Haixia Shi wrote:
> > CC Stephane
> >
> > In my opinion we should not assume sRGB-capable when alpha is requested,
> > because UNO
5, 2016 at 1:52 PM, Ilia Mirkin wrote:
> On Tue, Apr 5, 2016 at 4:33 PM, Haixia Shi wrote:
> > It is incorrect to assume that pixel format is always in BGR byte order.
> > We need to check bitmask parameters (such as |redMask|) to determine
> whether
> > the RGB or BGR
: reformat code to stay within 80 character per line limit.
Signed-off-by: Haixia Shi
Reviewed-by: Stéphane Marchesin
Cc: kenneth.w.grau...@intel.com
Change-Id: Ib75087aef1fbfb51baa72517207fed410dcd7b1e
---
src/mesa/drivers/dri/i965/intel_screen.c | 20
1 file changed, 12
.
Signed-off-by: Haixia Shi
Reviewed-by: Stéphane Marchesin
Cc: kenneth.w.grau...@intel.com
Change-Id: Ib75087aef1fbfb51baa72517207fed410dcd7b1e
---
src/mesa/drivers/dri/i965/intel_screen.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965
Signed-off-by: Haixia Shi
---
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/platform_drm.c
+++ b/src
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
---
src/egl/drivers/dri2/Makefile.am | 5 ++
src/egl/drivers/dri2/egl_dri2.c | 13
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
---
src/egl/drivers/dri2/Makefile.am | 5 ++
src/egl/drivers/dri2/egl_dri2.c | 13
2015 at 8:42 AM, Emil Velikov wrote:
> On 23/01/15 02:00, Haixia Shi wrote:
>> Hi Emil,
>>
>> On Thu, Jan 22, 2015 at 4:38 PM, Emil Velikov
>> wrote:
>>> On 22/01/15 22:23, Haixia Shi wrote:
>>>> Hi Emil
>>>>
>>>>
The NULL platform is for off-screen rendering only. Render node support is
required.
Signed-off-by: Haixia Shi
---
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/platform_null.c
The NULL platform is for off-screen rendering only. Render node support is
required.
Signed-off-by: Haixia Shi
---
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/platform_null.c
Hi Emil,
On Thu, Jan 22, 2015 at 4:38 PM, Emil Velikov wrote:
> On 22/01/15 22:23, Haixia Shi wrote:
>> Hi Emil
>>
>> On Thu, Jan 22, 2015 at 1:36 PM, Emil Velikov
>> wrote:
>>> Hi Haixia Shi,
>>>
>>> On 22/01/15 17:35, Haixia Shi wrote:
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
---
src/egl/drivers/dri2/Makefile.am | 5 +
src/egl/drivers/dri2/egl_dri2.c | 13 ++-
src/egl/drivers/dri2/egl_dri2
Hi Emil
On Thu, Jan 22, 2015 at 1:36 PM, Emil Velikov 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 ass
Try the render node first and use it if available. Otherwise fall back to
normal nodes.
Signed-off-by: Haixia Shi
---
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/platform_null.c
Try the render node first and use it if available. Otherwise fall back to
normal nodes.
Signed-off-by: Haixia Shi
---
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/platform_null.c
Try the render node first and use it if available. Otherwise fall back to
normal nodes.
Signed-off-by: Haixia Shi
---
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/platform_null.c
Try the render node first and use it if available. Otherwise fall back to
normal nodes.
Signed-off-by: Haixia Shi
---
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/platform_null.c
s not have enough space
to hold the "[0]" suffix, resulting in an incomplete array specification like
"foobar[0".
Change-Id: Icd58cd6a73c9de7bbe5659d757b8009021846019
Signed-off-by: Haixia Shi
Reviewed-by: Stephane Marchesin
---
src/mesa/main/shaderapi.c | 5 -
1 fi
n Sat, Mar 30, 2013 at 4:26 AM, Dragomir Ivanov
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 wrote:
>
>> If the active un
s not have enough space
to hold the "[0]" suffix, resulting in an incomplete array specification like
"foobar[0".
Change-Id: Icd58cd6a73c9de7bbe5659d757b8009021846019
Signed-off-by: Haixia Shi
Reviewed-by: Stéphane Marchesin
---
src/mesa/main/shaderapi.c | 5 -
1 fi
49 matches
Mail list logo
