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 other
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
> 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
> 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 bytes on a
>
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
> > wrote:
> > From: Samuel Iglesias Gonsalvez
> >
> > Signed-off-by: Samuel I
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
Hi Pekka,
On 11/19/2014 04:34 PM, Pekka Paalanen wrote:
On Wed, 19 Nov 2014 15:32:38 +0900
Alexandre Courbot 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 11/19/2014 03:05
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.
>
> --Jaso
On Friday, November 14, 2014 10:49:04 AM Matt Turner wrote:
> On Thu, Nov 13, 2014 at 11:22 PM, Kenneth Graunke
> wrote:
> > Saves a tiny bit of CPU overhead.
> >
> > Signed-off-by: Kenneth Graunke
> > ---
> > src/mesa/drivers/dri/i965/brw_vs_surface_state.c | 10 +-
> > src/mesa/driver
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 abou
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
> > > wrote:
> > > From: Samuel I
On Thu, 20 Nov 2014 18:24:34 +0900
Alexandre Courbot wrote:
> Hi Pekka,
>
> On 11/19/2014 04:34 PM, Pekka Paalanen wrote:
> > On Wed, 19 Nov 2014 15:32:38 +0900
> > Alexandre Courbot wrote:
> >
> >> Some more information: CPU usage of the EGL app (glmark2 here) is much
> >> higher when this pat
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,
On Tue, 2014-11-18 at 11:50 -0800, Jason Ekstrand wrote:
>
>
> On Tue, Nov 18, 2014 at 12:44 AM, Iago Toral Quiroga
> wrote:
> From: Samuel Iglesias Gonsalvez
>
> This will be used to refactor code in pack.c and support
> conversion
> to/from these type
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(? writes:
> 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
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 prob
On 19/11/14 21:17, Ilia Mirkin wrote:
On Wed, Nov 19, 2014 at 3:45 PM, Jose Fonseca wrote:
On 19/11/14 19:45, Ilia Mirkin wrote:
On Wed, Nov 19, 2014 at 2:32 PM, Eric Anholt wrote:
Eric Anholt writes:
This series removes a bunch of unused opcodes, mostly from TGSI. It
doesn't go as far
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
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(?
> If AMD disallows it then it seems like it would be reasonably safe to
> disallow it in Mesa too.
>
>
On 08/06/2014 11:56 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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 maps, and as I'm too lazy t
Just clearing some old patch back log...
Patch 1 is
Reviewed-by: Ian Romanick
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 wrote:
> I think these are abo
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
Cc: Frank Henigman
Signed
On Wed, Nov 19, 2014 at 11:24 PM, Iago Toral 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
> parameter to _m
On Wed, Nov 19, 2014 at 11:58 PM, Iago Toral 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 patch that
On Thu, Nov 20, 2014 at 12:48 AM, Iago Toral 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
> > wrote:
> > We have _mesa_swap{2,4} but these do in-place byte-swapping
> > only. The new
> >
>
>
>>
> 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 "__restric
On Wed, Nov 19, 2014 at 11:42 PM, 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 abou
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 param
On Thu, Nov 20, 2014 at 1:48 AM, Iago Toral 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 integer fo
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ä
> >
> > Check that the target is GL_TEXTURE_CUBE_MAP before emitting
> > TEXCOORDTYPE_VECTOR texture coordinates.
> >
> > I'm not sure if the hardw
From: Ian Romanick
../../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
'_mesa_validate_MultiDrawElements':
../../src/
From: Ian Romanick
This is generally the prefered style these days.
Signed-off-by: Ian Romanick
---
src/mesa/main/api_validate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index 181a61d..304d576 100644
--- a/s
From: Ian Romanick
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
Cc: Kenneth Graunke
---
src/mesa/main/api_validate.c | 10 +-
1 file changed, 9 insertions(+), 1
From: Ian Romanick
Signed-off-by: Ian Romanick
---
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
index 656cbe8..d1b5af7 100644
--- a/src/mesa/driv
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 apar
From: Ian Romanick
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. Previously this function wou
From: Ian Romanick
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
---
src/mesa/main/api_validate.c | 49 ++--
1 file changed, 24 in
From: Ian Romanick
---
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
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/m
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
From: Marek Olšák
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
b/src/gallium/drivers/radeonsi/si_shader
https://bugs.freedesktop.org/show_bug.cgi?id=86480
Benjamin Bellec changed:
What|Removed |Added
CC||b.bel...@gmail.com
--
You are receivi
On Thu, Nov 20, 2014 at 10:21:07PM +0100, Marek Olšák wrote:
> From: Marek Olšák
>
Reviewed-by: Tom Stellard
> 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 insert
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ä
>>>
>>> Check that the target is GL_TEXTURE_CUBE_MAP before emitting
>>> TEXCOORDTYPE_VECTOR texture
From: Jose Fonseca
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 by anholt.
---
src/g
From: Jose Fonseca
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 a/src/gallium/state
---
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 a/src/galliu
Reviewed-by: Jose Fonseca
for the series.
Jose
On 20/11/14 22:31, Eric Anholt wrote:
From: Jose Fonseca
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 droppe
On Thursday, November 20, 2014 11:14:54 AM Ian Romanick wrote:
> From: Ian Romanick
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
> ---
> src/mesa/drivers/dri/i96
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 s
On Thursday, November 20, 2014 11:14:49 AM Ian Romanick wrote:
> From: Ian Romanick
>
> 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
> Cc: Kenneth Graunke
> ---
>
On Thu, Nov 20, 2014 at 12:29 AM, Iago Toral 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
> MESA_FORMAT_B8G8
On Thu, Nov 20, 2014 at 9:33 PM, Jason Ekstrand
wrote:
>
>
> On Thu, Nov 20, 2014 at 12:29 AM, Iago Toral 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 U
On Thu, 2014-11-20 at 10:49 -0800, Jason Ekstrand wrote:
>
>
> On Wed, Nov 19, 2014 at 11:58 PM, Iago Toral
> wrote:
> On Wed, 2014-11-19 at 11:57 -0800, Jason Ekstrand wrote:
> > A couple of general comments on this patch:
> >
> >
> > 1) The prerequisites
On Thu, 2014-11-20 at 10:40 -0800, Jason Ekstrand wrote:
>
>
> On Wed, Nov 19, 2014 at 11:24 PM, Iago Toral
> wrote:
> Hi Jason,
>
> we discussed this some weeks ago actually, the detailed
> explanation is
> here:
> https://bugs.freedesktop.org/sh
55 matches
Mail list logo
