On Wed, Apr 8, 2015 at 1:28 AM, Chad Versace wrote:
> On Tue 07 Apr 2015, Kristian Høgsberg wrote:
>>
>> On Tue, Apr 7, 2015 at 6:46 PM, Frank Henigman
>> wrote:
>>>
>>> The name "surfaceless" suits me.
>>>
>>> Does this platform need to provide a hint to the user about buffer
>>> format?
>>> Pla
On Tue 07 Apr 2015, Kristian Høgsberg wrote:
On Tue, Apr 7, 2015 at 6:46 PM, Frank Henigman wrote:
The name "surfaceless" suits me.
Does this platform need to provide a hint to the user about buffer format?
Platform drm does this via the EGL_NATIVE_VISUAL_ID query of
eglGetConfigAttrib(), retu
On Tue, Apr 7, 2015 at 6:46 PM, Frank Henigman wrote:
> The name "surfaceless" suits me.
>
> Does this platform need to provide a hint to the user about buffer format?
> Platform drm does this via the EGL_NATIVE_VISUAL_ID query of
> eglGetConfigAttrib(), returning a gbm format value. Unless we do
On 2015.04.07 09:18:08 -0700, Kristian Høgsberg wrote:
> On Mon, Apr 6, 2015 at 10:51 PM, Zhenyu Wang wrote:
> > On Gen7/8 for RAW surface format, the depth field (surf[3]) in surface
> > state means [30:21] bits of number of entries which is different from
> > other surface format which uses [26:
The name "surfaceless" suits me.
Does this platform need to provide a hint to the user about buffer format?
Platform drm does this via the EGL_NATIVE_VISUAL_ID query of
eglGetConfigAttrib(), returning a gbm format value. Unless we do the
same or similar here, how does the user robustly find the r
On 8 April 2015 at 10:43, Ilia Mirkin wrote:
> On Tue, Apr 7, 2015 at 8:02 PM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> We create textures internally for texsubimage, and we use
>> the values from sub image to create a new texture, however
>> we don't align these to valid sizes, and cube ma
From: Dave Airlie
Since we can subimage upload a number of cube map array layers,
that aren't a complete cube map array, we should specify things
as a 2D array and blit from that.
Suggested by Ilia Mirkin as an alternate fix for texsubimage
cube map array issues.
seems to work just as well.
Si
On Tue, Apr 7, 2015 at 8:02 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> We create textures internally for texsubimage, and we use
> the values from sub image to create a new texture, however
> we don't align these to valid sizes, and cube map arrays
> must have an array size aligned to 6.
>
>
From: Dave Airlie
We create textures internally for texsubimage, and we use
the values from sub image to create a new texture, however
we don't align these to valid sizes, and cube map arrays
must have an array size aligned to 6.
This fixes texsubimage cube_map_array on CAYMAN at least,
(it was
> Yes, copy propagation probably won't be so useful once we have value
> range propagation; the former is a special case of the latter.
Err, I meant constant propagation...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop
Hi Thomas,
Thanks for submitting a proposal! Some comments/answers below.
On Tue, Apr 7, 2015 at 3:34 PM, Thomas Helland
wrote:
> Hi,
>
> For those that don't know I've submitted a proposal for this years GSoC.
> I've proposed to implement value range propagation and loop unrolling in
> NIR.
> S
On Tue, Apr 7, 2015 at 1:30 PM, Rob Clark wrote:
> From: Rob Clark
>
> Since the rest of NIR really would rather have these as variables rather
> than registers, create a nir_variable per array. But rather than
> completely re-arrange ttn to be variable based rather than register
> based, keep t
On 04/07/2015 03:22 AM, Francisco Jerez wrote:
> Tapani Pälli writes:
>
>> From: Kalyan Kondapally
>>
>> Dynamic indexing of sampler arrays is prohibited by GLSL ES 3.00.
>> Earlier versions allow 'constant-index-expression' indexing, where
>> index can contain a loop induction variable.
>>
>> P
On 04/06/2015 05:06 PM, Kenneth Graunke wrote:
> This allows those formats to work with the meta PBO upload path.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_surface_formats.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965
From: Rob Clark
Since the rest of NIR really would rather have these as variables rather
than registers, create a nir_variable per array. But rather than
completely re-arrange ttn to be variable based rather than register
based, keep the registers. In the cases where there is a matching var
for
On Thu 02 Apr 2015, Axel Davy wrote:
Hi,
you may be interesting look at this related bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=87452#c5
Yours,
Axel Davy
On 02/04/2015 11:58, Volker Vogelhuber wrote :
We currently want to stream OpenGL output to an FPGA that does not
provide
a
From: Ian Romanick
Commit b616164 added an optimization of b2f generation of a comparison.
It also included an extra optimization of one of the comparison values
is a constant of zero. The trick was that some value was known to be
zero, so that value could be used in the SEL instruction instead
Hi,
For those that don't know I've submitted a proposal for this years GSoC.
I've proposed to implement value range propagation and loop unrolling in
NIR.
Since I'm no expert on compilers I've read up on some litterature:
I started with "Constant propagation with conditional branches" (thanks
Co
Signed-off-by: Jason Ekstrand
---
src/glsl/nir/nir.c | 36 ++--
src/glsl/nir/nir.h | 18 +-
2 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
index 1c6b603..c6e5361 100644
--- a/src/glsl/nir/ni
On Tue, Apr 7, 2015 at 12:05 PM, Marius Predut wrote:
> Consistently just use C99's __func__ everywhere.
> The patch was verified with Microsoft Visual studio 2013
> redistributable package(RTM version number: 18.0.21005.1)
Presumably not, since i965 isn't built with MSVC :)
But yeah, the patch
Consistently just use C99's __func__ everywhere.
The patch was verified with Microsoft Visual studio 2013
redistributable package(RTM version number: 18.0.21005.1)
Next MSVC versions intends to support __func__.
No functional changes.
Signed-off-by: Marius Predut
---
src/glx/apple/apple_glx_log.
Consistently just use C99's __func__ everywhere.
The patch was verified with Microsoft Visual studio 2013
redistributable package(RTM version number: 18.0.21005.1)
Next MSVC versions intends to support __func__.
No functional changes.
Signed-off-by: Marius Predut
---
src/mesa/drivers/dri/i915/i8
Consistently just use C99's __func__ everywhere.
The patch was verified with Microsoft Visual studio 2013
redistributable package(RTM version number: 18.0.21005.1)
Next MSVC versions intends to support __func__.
No functional changes.
Signed-off-by: Marius Predut
---
src/mesa/drivers/dri/common/
Consistently just use C99's __func__ everywhere.
The patch was verified with Microsoft Visual studio 2013
redistributable package(RTM version number: 18.0.21005.1)
Next MSVC versions intends to support __func__.
No functional changes.
Signed-off-by: Marius Predut
---
src/mesa/main/atifragshader.
Consistently just use C99's __func__ everywhere.
The patch was verified with Microsoft Visual studio 2013
redistributable package(RTM version number: 18.0.21005.1)
Next MSVC versions intends to support __func__.
No functional changes.
Signed-off-by: Marius Predut
---
src/mesa/state_tracker/st_at
Consistently just use C99's __func__ everywhere.
The patch was verified with Microsoft Visual studio 2013
redistributable package(RTM version number: 18.0.21005.1)
Next MSVC versions intends to support __func__.
No functional changes.
Signed-off-by: Marius Predut
---
src/mesa/swrast/s_linetemp.h
On Mon, Apr 6, 2015 at 4:12 PM, Kenneth Graunke
wrote:
> Suggested by Topi Pohjolainen.
>
> Signed-off-by: Kenneth Graunke
> Cc: Topi Pohjolainen
> ---
> src/mesa/drivers/dri/i965/gen7_sol_state.c | 16
> src/mesa/drivers/dri/i965/gen8_sol_state.c | 16
> 2 fi
https://bugs.freedesktop.org/show_bug.cgi?id=89899
Jason Ekstrand changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, Apr 6, 2015 at 5:06 PM, Kenneth Graunke
wrote:
> This allows those formats to work with the meta PBO upload path.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_surface_formats.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/mesa/drivers/
On Monday, April 06, 2015 09:44:07 PM Pohjolainen, Topi wrote:
> On Mon, Apr 06, 2015 at 11:37:08AM -0700, Ian Romanick wrote:
> > On 04/06/2015 08:33 AM, Pohjolainen, Topi wrote:
> > > On Sun, Apr 05, 2015 at 08:22:13PM +0300, Pohjolainen, Topi wrote:
> > >> On Sun, Apr 05, 2015 at 08:06:50PM +030
Reviewed-by: Mark Janes
Jason Ekstrand writes:
> These don't work in MSVC or in older versions of GCC
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89899
> Cc: Eric Anholt
> ---
> src/glsl/nir/nir_lower_tex_projector.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>
On Mon, Apr 6, 2015 at 10:51 PM, Zhenyu Wang wrote:
> On Gen7/8 for RAW surface format, the depth field (surf[3]) in surface
> state means [30:21] bits of number of entries which is different from
> other surface format which uses [26:21] bits field.
>
> Signed-off-by: Zhenyu Wang
> ---
> src/me
On 7 April 2015 at 16:21, Jose Fonseca wrote:
> On 07/04/15 15:01, Emil Velikov wrote:
...
>>
>> So let see if I got this correct, apologies in advance if it comes out
>> too blunt.
>>
>> Unless I'm mistaken the gallium interfaces are internal/private, so
>> comparing them with public ones (like t
On 07/04/15 17:16, Matt Turner wrote:
On Tue, Apr 7, 2015 at 5:14 AM, Jose Fonseca wrote:
Sorry for the delay. I've been away during the Easter.
On 02/04/15 19:02, Matt Turner wrote:
On Thu, Apr 2, 2015 at 7:32 AM, Jose Fonseca wrote:
These were being defined in SCons, but it's not practi
This looks good to me. Note that generally it is not true that this
doesn't affect things when flatshading isn't in effect - this is only
true if you only have old-style semantics, where color is the only
attribute which can be flatshaded (and is done so with the rasterizer
setting). But not true i
On Tue, Apr 7, 2015 at 12:32 PM, Jason Ekstrand wrote:
> On Tue, Apr 7, 2015 at 8:52 AM, Rob Clark wrote:
>> From: Rob Clark
>>
>> Since the rest of NIR really would rather have these as variables rather
>> than registers, create a nir_variable per array. But rather than
>> completely re-arrang
On Tue, Apr 7, 2015 at 8:52 AM, Rob Clark wrote:
> From: Rob Clark
>
> Introduce intrinsics to load/store global vars (since I'm not sure what
> the point is to have global as a var type if there is no way to access
> it, but maybe I'm missing something), and update ttn to generate global
> varia
On Tue, Apr 7, 2015 at 8:52 AM, Rob Clark wrote:
> From: Rob Clark
>
> Since the rest of NIR really would rather have these as variables rather
> than registers, create a nir_variable per array. But rather than
> completely re-arrange ttn to be variable based rather than register
> based, keep t
Ping.
On 04/01/2015 02:38 PM, Brian Paul wrote:
This is a follow-on fix from the earlier "glsl: allow ForceGLSLVersion
to override #version directives" change. Since we're not changing
the language_version field, we have to check forced_language_version
here.
---
src/glsl/glsl_parser_extras.h
BTW, I should have mentioned -- this affects the way that quads are
split up into tri's, which is most likely the source of any
differences from my later change which makes quads respect pv order.
On Tue, Apr 7, 2015 at 12:12 PM, Ilia Mirkin wrote:
> This should match to how drivers program hardw
On Mon, Apr 6, 2015 at 10:51 PM, Zhenyu Wang wrote:
> On Gen7/8 for RAW surface format, the depth field (surf[3]) in surface
> state means [30:21] bits of number of entries which is different from
> other surface format which uses [26:21] bits field.
>
> Signed-off-by: Zhenyu Wang
Is there a bu
On Tue, Apr 7, 2015 at 5:14 AM, Jose Fonseca wrote:
> Sorry for the delay. I've been away during the Easter.
>
> On 02/04/15 19:02, Matt Turner wrote:
>>
>> On Thu, Apr 2, 2015 at 7:32 AM, Jose Fonseca wrote:
>>>
>>> These were being defined in SCons, but it's not practical -- we actually
>>> nee
This should match to how drivers program hardware. It shouldn't matter
when flatshading isn't in effect, but somehow it seems to.
Signed-off-by: Ilia Mirkin
---
src/gallium/auxiliary/indices/u_primconvert.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/gallium/auxilia
This allows drivers to provide consistent flat shading for quads.
Otherwise a driver that only supported tris would have to force last
provoking vertex when drawing quads (and would have to say that quads
don't follow the provoking vertex convention).
Signed-off-by: Ilia Mirkin
---
vmware folks
Mystery semi-solved? Previously u_primconvert would always select
*FIRST* provoking order when flatshading wasn't enabled, but the quads
would still follow the "last" logic. No big deal. I added support for
quads to be able to follow the provoking vertex convention, but now
the way that the quad is
From: Rob Clark
Introduce intrinsics to load/store global vars (since I'm not sure what
the point is to have global as a var type if there is no way to access
it, but maybe I'm missing something), and update ttn to generate global
variables for arrays.
So, for example:
FRAG
PROPERTY FS_CO
From: Rob Clark
Since the rest of NIR really would rather have these as variables rather
than registers, create a nir_variable per array. But rather than
completely re-arrange ttn to be variable based rather than register
based, keep the registers. In the cases where there is a matching var
for
From: Rob Clark
Seemed like these were missing in action? This is how it works for
other vars (uniform/shader_in/shader_out/etc), so seemed sensible.
Signed-off-by: Rob Clark
---
src/glsl/nir/nir_intrinsics.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/glsl/n
On 07/04/15 15:01, Emil Velikov wrote:
On 7 April 2015 at 13:14, Jose Fonseca wrote:
Sorry for the delay. I've been away during the Easter.
On 02/04/15 19:02, Matt Turner wrote:
On Thu, Apr 2, 2015 at 7:32 AM, Jose Fonseca wrote:
These were being defined in SCons, but it's not practical -
It will look different with llvmpipe if you use the right debug
variables (GALLIVM_DEBUG=no_brilinear,no_quad_lod,no_rho_approx), though
still fail.
I think the test may not be really valid. This is because if you use
texgrad, the driver/hw probably will (or should) use per-pixel lod. But
if you do
On Apr 7, 2015 2:32 AM, "Kenneth Graunke" wrote:
>
> This pass performs a mark and sweep pass over a nir_shader's associated
> memory - anything still connected to the program will be kept, and any
> dead memory we dropped on the floor will be freed.
>
> The expectation is that this will be called
Other than my nitpicking below this looks great! Thanks for working on this!
On Apr 7, 2015 2:32 AM, "Kenneth Graunke" wrote:
>
> Jason pointed out that variable dereferences in NIR are really part of
> their parent instruction, and should have the same lifetime.
>
> Unlike in GLSL IR, they're not
Oh fun, those tests also fail with nvc0 and llvmpipe. But pass on
softpipe. (The llvmpipe fail is visually different from the nvc0 and
freedreno/a3xx one though.)
On Tue, Apr 7, 2015 at 10:25 AM, Ilia Mirkin wrote:
> Weird, this seems to regress
>
> bin/arb_shader_texture_lod-texgrad
> bin/arb_sh
Weird, this seems to regress
bin/arb_shader_texture_lod-texgrad
bin/arb_shader_texture_lod-texgradcube
Visually they look the same, but piglit finds small differences.
On Tue, Apr 7, 2015 at 2:20 AM, Ilia Mirkin wrote:
> On Tue, Apr 7, 2015 at 1:44 AM, Ilia Mirkin wrote:
>> Signed-off-by: Ilia
On 7 April 2015 at 13:14, Jose Fonseca wrote:
> Sorry for the delay. I've been away during the Easter.
>
> On 02/04/15 19:02, Matt Turner wrote:
>>
>> On Thu, Apr 2, 2015 at 7:32 AM, Jose Fonseca wrote:
>>>
>>> These were being defined in SCons, but it's not practical -- we actually
>>> need to i
When a vec has more elements than row components in a matrix, the
code could end up failing an assert inside assign_to_matrix_column().
This patch makes sure that when there is still room in the matrix for
more elements (but in other columns of the matrix), the data is actually
assigned.
This pat
Tapani Pälli writes:
> On 04/07/2015 01:22 PM, Francisco Jerez wrote:
>> Tapani Pälli writes:
>>
>>> From: Kalyan Kondapally
>>>
>>> Dynamic indexing of sampler arrays is prohibited by GLSL ES 3.00.
>>> Earlier versions allow 'constant-index-expression' indexing, where
>>> index can contain a l
Sorry for the delay. I've been away during the Easter.
On 02/04/15 19:02, Matt Turner wrote:
On Thu, Apr 2, 2015 at 7:32 AM, Jose Fonseca wrote:
These were being defined in SCons, but it's not practical -- we actually
need to include Gallium headers from external source trees, with
completely
Besides fixing the mentioned dEQP crashes, this patch also generally
fixes instance arrays with UBOs. The problem we have now is that each
element in the UBO instance array is a separate UBO mapped to a specific
binding point (and thus, a separate buffer), but we kill the instances
that are not bei
On 04/07/2015 01:22 PM, Francisco Jerez wrote:
Tapani Pälli writes:
From: Kalyan Kondapally
Dynamic indexing of sampler arrays is prohibited by GLSL ES 3.00.
Earlier versions allow 'constant-index-expression' indexing, where
index can contain a loop induction variable.
Patch allows dynami
Tapani Pälli writes:
> From: Kalyan Kondapally
>
> Dynamic indexing of sampler arrays is prohibited by GLSL ES 3.00.
> Earlier versions allow 'constant-index-expression' indexing, where
> index can contain a loop induction variable.
>
> Patch allows dynamic indexing for sampler arrays when GLSL
From: Kalyan Kondapally
Dynamic indexing of sampler arrays is prohibited by GLSL ES 3.00.
Earlier versions allow 'constant-index-expression' indexing, where
index can contain a loop induction variable.
Patch allows dynamic indexing for sampler arrays when GLSL ES < 3.00.
This change makes 'sampl
Phi sources are part of the phi instruction and should have the same
lifetime.
Signed-off-by: Kenneth Graunke
---
src/glsl/nir/nir_lower_phis_to_scalar.c | 2 +-
src/glsl/nir/nir_lower_vars_to_ssa.c| 2 +-
src/glsl/nir/nir_to_ssa.c | 2 +-
3 files changed, 3 insertions(+), 3 de
This pass performs a mark and sweep pass over a nir_shader's associated
memory - anything still connected to the program will be kept, and any
dead memory we dropped on the floor will be freed.
The expectation is that this will be called when finished building and
optimizing the shader. However,
Jason pointed out that variable dereferences in NIR are really part of
their parent instruction, and should have the same lifetime.
Unlike in GLSL IR, they're not used very often - just for intrinsic
variables, call parameters & return, and indirect samplers for
texturing. Also, nir_deref_var is
We can't allocate them out of the nir_ssa_def itself, because it may not
be ralloc'd (for example, nir_dest embeds a nir_ssa_def).
However, allocating them out of the instruction should work.
Signed-off-by: Kenneth Graunke
---
src/glsl/nir/nir.c | 6 ++
1 file changed, 2 insertions(+), 4 de
The lifetime of the params array needs to be match the nir_call_instr
itself. So, allocate it using the instruction itself as the context.
Signed-off-by: Kenneth Graunke
---
src/glsl/nir/nir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This is the 'nir-memory-v2' branch in my tree.
https://bugs.freedesktop.org/show_bug.cgi?id=89599
--- Comment #2 from Tomasz Paweł Gajc ---
This patch fixes this issues:
https://abf.io/openmandriva/mesa/blob/master/mesa-10.5.2-hide-few-symbols-to-workaround-clang.patch
--
You are receiving this mail because:
You are the QA Contact for the
68 matches
Mail list logo
