No good reason really, simply that the original functions seemed simpler
for the case of in-place swapping since you don't have to pass the dst
parameter explicitly, so I figured there was a marginal gain in letting
them stay, specially since their implementation is just an inline call
to the
It is explained here:
https://bugs.freedesktop.org/show_bug.cgi?id=84566#c35
So one example of this was a glReadPixels where we want to store the
pixel data as RGBA UINT, but the render buffer format we read from is
MESA_FORMAT_B8G8R8A8_UNORM. There are piglit tests that hit this case.
Iago
On
On Wed, 2014-11-19 at 12:11 -0800, Jason Ekstrand wrote:
General comment: Maybe this would be better in gltypes rather than in
mesa_formats
Ok, I'll move it.
On Tue, Nov 18, 2014 at 1:23 AM, Iago Toral Quiroga
ito...@igalia.com wrote:
---
src/mesa/main/formats.c | 285
On Wed, 2014-11-19 at 14:15 -0600, Patrick Baggett wrote:
On Tue, Nov 18, 2014 at 3:23 AM, Iago Toral Quiroga
ito...@igalia.com wrote:
We have _mesa_swap{2,4} but these do in-place byte-swapping
only. The new
functions receive an extra parameter so we can swap
On Thu, 2014-11-20 at 08:15 +0100, Samuel Iglesias Gonsálvez wrote:
On Tue, 2014-11-18 at 11:08 -0800, Jason Ekstrand wrote:
On Tue, Nov 18, 2014 at 12:44 AM, Iago Toral Quiroga
ito...@igalia.com wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
On Thu, 2014-11-20 at 08:08 +0100, Iago Toral wrote:
On Wed, 2014-11-19 at 10:27 -0800, Ian Romanick wrote:
On 11/19/2014 03:47 AM, Iago Toral Quiroga wrote:
Hi,
I came across a GLSL test that checks that doing something like this in
a shader should fail:
Is this one of the
Hi Pekka,
On 11/19/2014 04:34 PM, Pekka Paalanen wrote:
On Wed, 19 Nov 2014 15:32:38 +0900
Alexandre Courbot acour...@nvidia.com wrote:
Some more information: CPU usage of the EGL app (glmark2 here) is much
higher when this patch is applied, which I presume is what triggers the
frame skips.
On Wed, 2014-11-19 at 11:28 -0800, Jason Ekstrand wrote:
By and large, this looks good to me. Most of my comments are cosmetic
or suggestions for added documentation. There is one issue that I
think is subtly wrong with integer format conversion but that should
be easy to fix.
--Jason
On Friday, November 14, 2014 10:49:04 AM Matt Turner wrote:
On Thu, Nov 13, 2014 at 11:22 PM, Kenneth Graunke kenn...@whitecape.org
wrote:
Saves a tiny bit of CPU overhead.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vs_surface_state.c | 10
On Thu, 2014-11-20 at 08:42 +0100, Iago Toral wrote:
On Wed, 2014-11-19 at 11:43 -0800, Jason Ekstrand wrote:
A couple of specific comments are below. More generally, why are you
only considering the base format on two cases? Do we never use it for
anything else?
I thought about that
On Thu, 2014-11-20 at 09:55 +0100, Iago Toral wrote:
On Thu, 2014-11-20 at 08:15 +0100, Samuel Iglesias Gonsálvez wrote:
On Tue, 2014-11-18 at 11:08 -0800, Jason Ekstrand wrote:
On Tue, Nov 18, 2014 at 12:44 AM, Iago Toral Quiroga
ito...@igalia.com wrote:
From: Samuel
On Thu, 20 Nov 2014 18:24:34 +0900
Alexandre Courbot acour...@nvidia.com wrote:
Hi Pekka,
On 11/19/2014 04:34 PM, Pekka Paalanen wrote:
On Wed, 19 Nov 2014 15:32:38 +0900
Alexandre Courbot acour...@nvidia.com wrote:
Some more information: CPU usage of the EGL app (glmark2 here) is
On Thu, 2014-11-20 at 12:14 +0100, Samuel Iglesias Gonsálvez wrote:
On Thu, 2014-11-20 at 09:55 +0100, Iago Toral wrote:
On Thu, 2014-11-20 at 08:15 +0100, Samuel Iglesias Gonsálvez wrote:
On Tue, 2014-11-18 at 11:08 -0800, Jason Ekstrand wrote:
On Tue, Nov 18, 2014 at 12:44
On Tue, 2014-11-18 at 11:50 -0800, Jason Ekstrand wrote:
On Tue, Nov 18, 2014 at 12:44 AM, Iago Toral Quiroga
ito...@igalia.com wrote:
From: Samuel Iglesias Gonsalvez sigles...@igalia.com
This will be used to refactor code in pack.c and support
For what it's worth, I did a quick grep through the internal and public
shader-db and I couldn't find anything using this.
git grep -P '\b(?!e[+-])(?![.0-9])[0-9]+f\b'
If AMD disallows it then it seems like it would be reasonably safe to
disallow it in Mesa too.
GCC disallows it too which
On 19/11/14 17:21, Jon TURNEY wrote:
On 19/11/2014 15:25, Jose Fonseca wrote:
No idea. But the impression I generally have is MinGW has come a long
way since then (3 years ago.)
I think there was at least one bug in mesa which prevented this from
working, see commit cedfd79b
Yes, you're
On 19/11/14 21:17, Ilia Mirkin wrote:
On Wed, Nov 19, 2014 at 3:45 PM, Jose Fonseca jfons...@vmware.com wrote:
On 19/11/14 19:45, Ilia Mirkin wrote:
On Wed, Nov 19, 2014 at 2:32 PM, Eric Anholt e...@anholt.net wrote:
Eric Anholt e...@anholt.net writes:
This series removes a bunch of
Hi,
Honestly, I think I'm okay with our usual metrics like:
- Increased FPS in a game or benchmark
- Reduced number of instructions or memory accesses in
a shader program
- Reduced memory consumption
- Significant cycle reduction in callgrind or better generated code
(ideally if it's
On 11/20/2014 05:33 AM, Neil Roberts wrote:
For what it's worth, I did a quick grep through the internal and public
shader-db and I couldn't find anything using this.
git grep -P '\b(?!e[+-])(?![.0-9])[0-9]+f\b'
If AMD disallows it then it seems like it would be reasonably safe to
On 08/06/2014 11:56 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Check that the target is GL_TEXTURE_CUBE_MAP before emitting
TEXCOORDTYPE_VECTOR texture coordinates.
I'm not sure if the hardware would like CARTESIAN coordinates
with cube
Just clearing some old patch back log...
Patch 1 is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
With Matt's nits about patch 2 fixed, it is also R-b, but I guess the
point of that patch is really to enable patch 3. Where do we stand on that?
On 10/01/2014 02:07 PM, Jason Ekstrand
Mesa already implements the behavior of EGL_KHR_get_all_proc_addresses
and EGL_KHR_client_get_all_proc_addresses. This patch just exposes the
extension strings.
See:
https://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_get_all_proc_addresses.txt
Cc: Daniel Kurtz djku...@chromium.org
Cc:
On Wed, Nov 19, 2014 at 11:24 PM, Iago Toral ito...@igalia.com wrote:
Hi Jason,
we discussed this some weeks ago actually, the detailed explanation is
here:
https://bugs.freedesktop.org/show_bug.cgi?id=84566#c5
the short answer is that this is necessary because there is a normalized
On Wed, Nov 19, 2014 at 11:58 PM, Iago Toral ito...@igalia.com wrote:
On Wed, 2014-11-19 at 11:57 -0800, Jason Ekstrand wrote:
A couple of general comments on this patch:
1) The prerequisites should be moved to before the first patch in the
series and it should be squashed into the
On Thu, Nov 20, 2014 at 12:48 AM, Iago Toral ito...@igalia.com wrote:
On Wed, 2014-11-19 at 14:15 -0600, Patrick Baggett wrote:
On Tue, Nov 18, 2014 at 3:23 AM, Iago Toral Quiroga
ito...@igalia.com wrote:
We have _mesa_swap{2,4} but these do in-place byte-swapping
The restrict keyword is a C99 thing and I don't think it's supported in
MSVC so that would be a problem. If it won't build with MSVC then it's a
non-starter. If MSVC can handle restrict, then I don't know that I care
much either way about 2 functions or 4
MSVC uses __restrict which
On Wed, Nov 19, 2014 at 11:42 PM, Iago Toral ito...@igalia.com wrote:
On Wed, 2014-11-19 at 11:43 -0800, Jason Ekstrand wrote:
A couple of specific comments are below. More generally, why are you
only considering the base format on two cases? Do we never use it for
anything else?
I
On Wed 19 Nov 2014, Kenneth Graunke wrote:
On Wednesday, November 19, 2014 02:13:03 PM Ian Romanick wrote:
On 11/18/2014 09:11 PM, Chad Versace wrote:
This patch should diminish the likelihood of pointer arithmetic overflow
bugs, like the one fixed by b69c7c5dac.
Change the type of
On Thu, Nov 20, 2014 at 1:48 AM, Iago Toral ito...@igalia.com wrote:
On Wed, 2014-11-19 at 11:28 -0800, Jason Ekstrand wrote:
By and large, this looks good to me. Most of my comments are cosmetic
or suggestions for added documentation. There is one issue that I
think is subtly wrong with
On Thu, Nov 20, 2014 at 09:59:00AM -0800, Ian Romanick wrote:
On 08/06/2014 11:56 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Check that the target is GL_TEXTURE_CUBE_MAP before emitting
TEXCOORDTYPE_VECTOR texture coordinates.
I'm not
From: Ian Romanick ian.d.roman...@intel.com
../../src/mesa/main/api_validate.c: In function '_mesa_validate_DrawElements':
../../src/mesa/main/api_validate.c:376:37: warning: unused parameter
'basevertex' [-Wunused-parameter]
../../src/mesa/main/api_validate.c: In function
From: Ian Romanick ian.d.roman...@intel.com
This is generally the prefered style these days.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/main/api_validate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/api_validate.c
From: Ian Romanick ian.d.roman...@intel.com
GL 3-ish versions of the spec are less clear that an error should be
generated here, so Ken (and I during review) just missed it in 1afe335.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Kenneth Graunke kenn...@whitecape.org
---
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/drivers/dri/i965/brw_context.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
This little series is just a bit of house keeping in the valid-to-render
path. There is a follow-up series in progress that tries to optimize
some of these paths for CPU-bound workloads.
The whole series has been reordered several times. Orignally patches 4
and 5 of this series were farther
From: Ian Romanick ian.d.roman...@intel.com
Most of the code in _mesa_validate_DrawElements,
_mesa_validate_DrawRangeElements, and
_mesa_validate_DrawElementsInstanced was the same. Refactor this out to
common code.
As a side-effect, a bug in _mesa_validate_DrawElementsInstanced was
fixed.
From: Ian Romanick ian.d.roman...@intel.com
This makes some others patches (still in my local tree) a bit cleaner.
NOTE: This and the previous patch can probably get squashed together.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/main/api_validate.c | 49
From: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/drivers/dri/i965/brw_draw.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index b28eaf2..4c2802a 100644
---
On 11/19/2014 09:18 PM, Kenneth Graunke wrote:
On Wednesday, November 19, 2014 02:13:03 PM Ian Romanick wrote:
On 11/18/2014 09:11 PM, Chad Versace wrote:
This patch should diminish the likelihood of pointer arithmetic overflow
bugs, like the one fixed by b69c7c5dac.
Change the type of
From: Marek Olšák marek.ol...@amd.com
So far it has been compiled into pretty ugly code (8 instructions or so
for either opcode).
---
src/gallium/drivers/radeonsi/si_shader.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
https://bugs.freedesktop.org/show_bug.cgi?id=86480
Benjamin Bellec b.bel...@gmail.com changed:
What|Removed |Added
CC||b.bel...@gmail.com
On Thu, Nov 20, 2014 at 10:21:07PM +0100, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
Reviewed-by: Tom Stellard thomas.stell...@amd.com
So far it has been compiled into pretty ugly code (8 instructions or so
for either opcode).
---
src/gallium/drivers/radeonsi/si_shader.c |
On 11/20/2014 11:13 AM, Ville Syrjälä wrote:
On Thu, Nov 20, 2014 at 09:59:00AM -0800, Ian Romanick wrote:
On 08/06/2014 11:56 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Check that the target is GL_TEXTURE_CUBE_MAP before emitting
From: Jose Fonseca jfons...@vmware.com
This was the only state tracker emitting it, and hardware was just having
to lower it anyway (or failing to lower it at all).
v2: Extracted from a larger patch by Jose (which also dropped DP2A), fixed
to actually not reference TGSI_OPCODE_CND. Change
From: Jose Fonseca jfons...@vmware.com
The translation is lowering it to not using TGSI_OPCODE_NRM, anyway.
v2: Extracted from a larger patch by Jose that also dropped DP2A usage.
---
src/gallium/state_trackers/nine/nine_shader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
---
src/gallium/state_trackers/nine/nine_shader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/nine/nine_shader.c
b/src/gallium/state_trackers/nine/nine_shader.c
index cc027b4..9b324c3 100644
--- a/src/gallium/state_trackers/nine/nine_shader.c
Hi,
Series looks good. You can add my r-b.
Do you want also to remove the DP2A reference like
did Jose patch ?
Axel Davy
On 20/11/2014 23:31, Eric Anholt wrote :
---
src/gallium/state_trackers/nine/nine_shader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Reviewed-by: Jose Fonseca jfons...@vmware.com
for the series.
Jose
On 20/11/14 22:31, Eric Anholt wrote:
From: Jose Fonseca jfons...@vmware.com
This was the only state tracker emitting it, and hardware was just having
to lower it anyway (or failing to lower it at all).
v2: Extracted from a
On Thursday, November 20, 2014 11:14:54 AM Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Suggested commit message addition:
We used to use the return value to indicate whether software fallbacks
were necessary, but we haven't in years.
Reviewed-by: Kenneth Graunke
On Thursday, November 20, 2014 11:14:48 AM Ian Romanick wrote:
This little series is just a bit of house keeping in the valid-to-render
path. There is a follow-up series in progress that tries to optimize
some of these paths for CPU-bound workloads.
The whole series has been reordered
On Thursday, November 20, 2014 11:14:49 AM Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
GL 3-ish versions of the spec are less clear that an error should be
generated here, so Ken (and I during review) just missed it in 1afe335.
Signed-off-by: Ian Romanick
On Thu, Nov 20, 2014 at 12:29 AM, Iago Toral ito...@igalia.com wrote:
It is explained here:
https://bugs.freedesktop.org/show_bug.cgi?id=84566#c35
So one example of this was a glReadPixels where we want to store the
pixel data as RGBA UINT, but the render buffer format we read from is
On Thu, Nov 20, 2014 at 9:33 PM, Jason Ekstrand ja...@jlekstrand.net
wrote:
On Thu, Nov 20, 2014 at 12:29 AM, Iago Toral ito...@igalia.com wrote:
It is explained here:
https://bugs.freedesktop.org/show_bug.cgi?id=84566#c35
So one example of this was a glReadPixels where we want to store
On Thu, 2014-11-20 at 10:49 -0800, Jason Ekstrand wrote:
On Wed, Nov 19, 2014 at 11:58 PM, Iago Toral ito...@igalia.com
wrote:
On Wed, 2014-11-19 at 11:57 -0800, Jason Ekstrand wrote:
A couple of general comments on this patch:
1) The
On Thu, 2014-11-20 at 10:40 -0800, Jason Ekstrand wrote:
On Wed, Nov 19, 2014 at 11:24 PM, Iago Toral ito...@igalia.com
wrote:
Hi Jason,
we discussed this some weeks ago actually, the detailed
explanation is
here:
55 matches
Mail list logo
