-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/03/16 01:08, Jason Ekstrand wrote:
> On Thu, Mar 10, 2016 at 4:00 PM, Connor Abbott
> wrote:
>
>> On Mon, Mar 7, 2016 at 3:45 AM, Samuel Iglesias Gonsálvez
>> wrote:
>>> From: Jason Ekstrand
>>>
>>> v2: Fix size/type mask to properly ha
On Mar 10, 2016 1:21 PM, "Eirik Byrkjeflot Anonsen"
wrote:
>
> Ian Romanick writes:
>
> > From: Ian Romanick
> >
> > I don't understand why the old code was bad, but the new code is fine.
>
> Probably because the *loop counter* can no longer overflow. Thus the
> loop can be optimized. The fact t
https://bugs.freedesktop.org/show_bug.cgi?id=94481
--- Comment #2 from Roland Scheidegger ---
The initialization should be pretty easy to fix I think, if noone beats me to
it I'll see what I can do...
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Conta
On Fri, 2016-03-11 at 10:09 +0800, Chih-Wei Huang wrote:
> 2016年3月10日 下午6:47於 "Marek Olšák" 寫道：
> >
> >
> > Those functions are only supported by LLVM 3.7 and later, and if
> > you
> > have such a version, the AMDGPU backend must be enabled in your
> > LLVM
> > build.
> Yes, I knew that.
> But se
Am 11.03.2016 um 03:50 schrieb Kenneth Graunke:
> On Friday, March 11, 2016 2:50:46 AM PST Roland Scheidegger wrote:
>> Technically, this is still wrong for rendering traditional gl points,
>> which indeed require points either be drawn in full (even the parts
>> outside viewport, if the center is
Fixes:
dEQP-GLES3.functional.negative_api.state.get_framebuffer_attachment_parameteriv
Apparently, GL_FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is not allowed when
GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is GL_FRAMEBUFFER_DEFAULT, and
is expected to result in a GL_INVALID_ENUM error.
No GL specification a
On Friday, March 11, 2016 2:50:46 AM PST Roland Scheidegger wrote:
> Technically, this is still wrong for rendering traditional gl points,
> which indeed require points either be drawn in full (even the parts
> outside viewport, if the center is inside viewport) or not at all (if
> the center is ou
On 10 March 2016 at 15:21, Eric Anholt wrote:
> - There's no reason there would be only 64 operations that read from the
> output of a mov from VPM, so we might smash the stack (fixes etqw trace)
>
> - Fixes segfault where we assumed that a single-use temp had a def (fixes
> 2 piglit tests)
>
2016年3月10日 下午6:47於 "Marek Olšák" 寫道：
>
> Those functions are only supported by LLVM 3.7 and later, and if you
> have such a version, the AMDGPU backend must be enabled in your LLVM
> build.
Yes, I knew that.
But seems you misunderstood my question.
It's a compile time error instead of a linking t
Iago Toral writes:
> On Wed, 2016-03-09 at 19:04 -0800, Francisco Jerez wrote:
>> Matt Turner writes:
>>
>> > On Wed, Mar 9, 2016 at 1:37 PM, Francisco Jerez
>> > wrote:
>> >> Iago Toral writes:
>> >>
>> >>> On Tue, 2016-03-08 at 17:42 -0800, Francisco Jerez wrote:
>> brw_cfg.h already
Technically, this is still wrong for rendering traditional gl points,
which indeed require points either be drawn in full (even the parts
outside viewport, if the center is inside viewport) or not at all (if
the center is outside viewport). Albeit the gles language may be
different (and looks like
On Thu, Mar 10, 2016 at 8:05 PM, Ilia Mirkin wrote:
> I thought there was some deal where viewport was *not* supposed to act
> as a scissor... perhaps I misunderstood though.
It is, btw, entirely conceivable that I remember that precisely in the
context of wide points/lines...
>
> On Thu, Mar 10
On Thu, Mar 10, 2016 at 7:59 PM, Kenneth Graunke wrote:
> I need to use this in multiple source files.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_state.h | 20
> src/mesa/drivers/dri/i965/gen6_sf_state.c | 20
> 2 files
I thought there was some deal where viewport was *not* supposed to act
as a scissor... perhaps I misunderstood though.
On Thu, Mar 10, 2016 at 7:59 PM, Kenneth Graunke wrote:
> We'll need to use scissoring to restrict fragments to the viewport
> soon. It seems harmless to include it generally, s
Wide points and lines are not supposed to be clipped by the viewport.
Rather, they should be rendered, and any fragments outside of the
viewport should be discarded.
The traditional use case for this behavior is rendering moving wide
point particles. When the center of the point approaches the vi
Similar to is_drawing_points().
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_state.h | 26 ++
1 file changed, 26 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_state.h
b/src/mesa/drivers/dri/i965/brw_state.h
index 9a17b73..ba448b3 100644
--
We're about to start allowing wide points/lines whose vertices are
outside the viewport past the clipper. This scissoring hack ensures
that any fragments generated are still restricted to the viewport.
It is not necessary on Gen8+ as those platforms already discard
fragments which are outside the
We'll need to use scissoring to restrict fragments to the viewport
soon. It seems harmless to include it generally, so let's do that.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94453
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94454
Signed-off-by: Kenneth Graunke
---
src/
I need to use this in multiple source files.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_state.h | 20
src/mesa/drivers/dri/i965/gen6_sf_state.c | 20
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/src/mesa/driv
On Thu, Mar 10, 2016 at 4:00 PM, Connor Abbott wrote:
> On Mon, Mar 7, 2016 at 3:45 AM, Samuel Iglesias Gonsálvez
> wrote:
> > From: Jason Ekstrand
> >
> > v2: Fix size/type mask to properly handle 8-bit types.
> >
> > Signed-off-by: Juan A. Suarez Romero
> > ---
> > src/compiler/nir/nir.h |
On Mon, Mar 7, 2016 at 3:45 AM, Samuel Iglesias Gonsálvez
wrote:
> From: Jason Ekstrand
>
> v2: Fix size/type mask to properly handle 8-bit types.
>
> Signed-off-by: Juan A. Suarez Romero
> ---
> src/compiler/nir/nir.h | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
On Thu, Mar 10, 2016 at 9:30 AM, tournier.elie wrote:
> First, thank you all for your answers.
>
> So if I summarize what was said, we need
> Ian:
> - add
> - negate
> - absolute value
> - multiply
> - reciprocal
> - convert to single precision
> - convert from single precision
> Roland:
>
On 10.03.2016 12:50, Glenn Kennard wrote:
On Thu, 10 Mar 2016 18:13:03 +0100, Ilia Mirkin
wrote:
On Thu, Mar 10, 2016 at 12:04 PM, Glenn Kennard
wrote:
On Thu, 10 Mar 2016 17:02:15 +0100, Ilia Mirkin
wrote:
On Thu, Mar 10, 2016 at 10:57 AM, Nicolai Hähnle
wrote:
- if (c->MaxCombinedA
From: Nicolai Hähnle
---
src/mesa/state_tracker/st_atom_image.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_atom_image.c
b/src/mesa/state_tracker/st_atom_image.c
index d0f0c42..bf7486b 100644
--- a/src/mesa/state_tracker/st_atom_image.c
+++ b/
From: Nicolai Hähnle
The enums MAX_COMBINED_IMAGE_UNITS_AND_FRAGMENT_OUTPUTS and
MAX_COMBINED_SHADER_OUTPUT_RESOURCES are equal and should therefore only
appear once.
Noticed while implementing ARB_shader_image_load_store without previously
implementing SSBO.
---
src/mesa/main/get.c
Quoting Marek Olšák (2016-03-10 06:57:57)
> On Thu, Mar 10, 2016 at 3:30 PM, tournier.elie
> wrote:
> > First, thank you all for your answers.
> >
> > So if I summarize what was said, we need
> > Ian:
> > - add
> > - negate
> > - absolute value
> > - multiply
> > - reciprocal
> > - convert
On Thu, Mar 10, 2016 at 3:08 PM, Patrick Baggett
wrote:
> On Thu, Mar 10, 2016 at 12:25 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Sandy Bridge / Ivy Bridge / Haswell
>> total instructions in shared programs: 8462180 -> 8462174 (-0.00%)
>> instructions in affected programs: 564 -> 558 (
Ian Romanick writes:
> From: Ian Romanick
>
> I don't understand why the old code was bad, but the new code is fine.
Probably because the *loop counter* can no longer overflow. Thus the
loop can be optimized. The fact that "i" might overflow has become
irrelevant to the warning.
(And from that
On Thu, Mar 10, 2016 at 12:25 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Sandy Bridge / Ivy Bridge / Haswell
> total instructions in shared programs: 8462180 -> 8462174 (-0.00%)
> instructions in affected programs: 564 -> 558 (-1.06%)
> helped: 6
> HURT: 0
>
> total cycles in shared program
- There's no reason there would be only 64 operations that read from the
output of a mov from VPM, so we might smash the stack (fixes etqw trace)
- Fixes segfault where we assumed that a single-use temp had a def (fixes
2 piglit tests)
- We need to only mark progress when we actually did the
On Thu, Mar 10, 2016 at 3:24 PM, Ilia Mirkin wrote:
> On Thu, Mar 10, 2016 at 1:25 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Sandy Bridge / Ivy Bridge / Haswell
>> total instructions in shared programs: 8462180 -> 8462174 (-0.00%)
>> instructions in affected programs: 564 -> 558 (-1.06
On Thu, Mar 10, 2016 at 1:25 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Sandy Bridge / Ivy Bridge / Haswell
> total instructions in shared programs: 8462180 -> 8462174 (-0.00%)
> instructions in affected programs: 564 -> 558 (-1.06%)
> helped: 6
> HURT: 0
>
> total cycles in shared programs
On Wednesday, March 9, 2016 3:18:50 PM PST Jon Turney wrote:
> On 05/03/2016 03:33, Kenneth Graunke wrote:
> > We resolved the implicit version directive when processing control lines,
> > such as #ifdef, to ensure any built-in macros exist. However, we failed
> > to resolve it when handling ordin
On 03/10/2016 06:30 AM, tournier.elie wrote:
> First, thank you all for your answers.
>
> So if I summarize what was said, we need
> Ian:
> - add
> - negate
> - absolute value
> - multiply
> - reciprocal
> - convert to single precision
> - convert from single precision
> Roland:
> - sqrt
https://bugs.freedesktop.org/show_bug.cgi?id=94481
--- Comment #1 from Greg ---
This problem also exists in mip_filter_linear_aniso(...)
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
m
On Thu, Mar 10, 2016 at 10:13 AM, Topi Pohjolainen
wrote:
> Uniform linking in (see link_assign_uniform_locations()) already
> stores the index to the storage in ir_variable which is further
> stored into nir_variable (see nir_visitor::visit(ir_variable *)).
>
> Instead of doing uniform_num^2 stri
On Thu, Mar 10, 2016 at 10:25 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> No shader-db changes, but this is symmetric with the previous commit.
Right, i965 doesn't use these operations.
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev
On Thu, Mar 10, 2016 at 10:25 AM, Ian Romanick wrote:
> From: Ian Romanick
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Mar 10, 2016 at 10:25 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> On Intel platforms that don't set lower_flrp, using bcsel instead of
> flrp seems to be a small amount worse.
Yep, that's my experience too. It's because bcsel turns into CMP+SEL,
and because of the flag register we c
On Thu, Mar 10, 2016 at 10:25 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> Sandy Bridge / Ivy Bridge / Haswell
> total instructions in shared programs: 8462180 -> 8462174 (-0.00%)
> instructions in affected programs: 564 -> 558 (-1.06%)
> helped: 6
> HURT: 0
>
> total cycles in shared program
On Thu, Mar 10, 2016 at 10:25 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> This also prevented some regressions with other patches in my local
> tree.
>
> Broadwell / Skylake
> total instructions in shared programs: 8980835 -> 8980833 (-0.00%)
> instructions in affected programs: 45 -> 43 (-4
On Thu, Mar 10, 2016 at 10:25 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> This enables removing ssa_201 and ssa_202 in sequences like:
>
> vec1 ssa_200 = flt ssa_199, ssa_194
> vec1 ssa_201 = b2i ssa_200
> vec1 ssa_202 = i2b -ssa_201
Review
Hi,
On 10-03-16 16:35, Aaron Watry wrote:
On Thu, Mar 10, 2016 at 9:14 AM, Hans de Goede wrote:
Extend the MEMORY file support to differentiate between global, local
and shared memory, as well as "input" memory.
"MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a
special mem
On Thu, Mar 10, 2016 at 10:25 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> Previously we were doing the lowering by hand in vec4_visitor::emit_lrp.
> By doing it in NIR, we have the opportunity for NIR to do additional
> optimization of the expanded code.
>
> This also enables optimizations a
This is the first round of patches to improve the way we deal with
floating point values used to represent Booleans. I have a bunch more,
but this is the set that has been stable and shows almost exclusively
improvement.
I'm not married to the first 3 patches in the series. I was trying to
silen
From: Ian Romanick
Sandy Bridge / Ivy Bridge / Haswell
total instructions in shared programs: 8462180 -> 8462174 (-0.00%)
instructions in affected programs: 564 -> 558 (-1.06%)
helped: 6
HURT: 0
total cycles in shared programs: 117542462 -> 117542276 (-0.00%)
cycles in affected programs: 9768 ->
From: Ian Romanick
On Intel platforms that don't set lower_flrp, using bcsel instead of
flrp seems to be a small amount worse. On those platforms, the use of
flrp, bcsel, and multiply of b2f is still an active area of research.
shader-db results:
G4X / Ironlake
total instructions in shared pro
From: Ian Romanick
I don't understand why the old code was bad, but the new code is fine.
brw_state_dump.c: In function ‘brw_debug_batch’:
brw_state_dump.c:677:4: warning: cannot optimize loop, the loop counter may
overflow [-Wunsafe-loop-optimizations]
for (i = 0; i < size / 4; i += 4) {
From: Ian Romanick
No shader-db changes, but this is symmetric with the previous commit.
Signed-off-by: Ian Romanick
---
src/compiler/nir/nir_opt_algebraic.py | 4
1 file changed, 4 insertions(+)
diff --git a/src/compiler/nir/nir_opt_algebraic.py
b/src/compiler/nir/nir_opt_algebraic.py
From: Ian Romanick
Previously we were doing the lowering by hand in vec4_visitor::emit_lrp.
By doing it in NIR, we have the opportunity for NIR to do additional
optimization of the expanded code.
This also enables optimizations added by the next commit.
shader-db results:
G4X / Ironlake
total
From: Ian Romanick
This also prevented some regressions with other patches in my local
tree.
Broadwell / Skylake
total instructions in shared programs: 8980835 -> 8980833 (-0.00%)
instructions in affected programs: 45 -> 43 (-4.44%)
helped: 1
HURT: 0
total cycles in shared programs: 70077904 ->
From: Ian Romanick
In the results below, 2 SIMD16 shaders in Trine are lost.
G4X
total instructions in shared programs: 4012279 -> 4011108 (-0.03%)
instructions in affected programs: 116776 -> 115605 (-1.00%)
helped: 339
HURT: 0
total cycles in shared programs: 84315862 -> 84313584 (-0.00%)
cyc
From: Ian Romanick
This enables removing ssa_201 and ssa_202 in sequences like:
vec1 ssa_200 = flt ssa_199, ssa_194
vec1 ssa_201 = b2i ssa_200
vec1 ssa_202 = i2b -ssa_201
shader-db results:
Sandy Bridge
total instructions in shared programs: 8
From: Ian Romanick
brw_state_dump.c: In function ‘gen7_dump_sampler_state’:
brw_state_dump.c:405:22: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
for (int i = 0; i < size / 16; i++) {
^
brw_state_dump.c: In function ‘gen8_dump_ble
From: Ian Romanick
Remove the parameter. Also, reformat the function definition to match
Mesa coding style.
brw_state_dump.c: In function ‘q_to_float’:
brw_state_dump.c:266:44: warning: unused parameter ‘integer_end’
[-Wunused-parameter]
static float q_to_float(uint32_t data, int integer_end,
Am 10.03.2016 um 08:47 schrieb Andreas Fänger:
>
>> -Ursprüngliche Nachricht- Von: Roland Scheidegger Gesendet:
>> Mittwoch, 9. März 2016 17:31 Betreff: Re: [Mesa-dev] [PATCH] scons:
>> build osmesa swrast and gallium
>>
>> Am 09.03.2016 um 08:41 schrieb Andreas Fänger:
-Ursprüng
Uniform linking in (see link_assign_uniform_locations()) already
stores the index to the storage in ir_variable which is further
stored into nir_variable (see nir_visitor::visit(ir_variable *)).
Instead of doing uniform_num^2 string comparisons one can recur
over the uniform type the same way unif
On Thu, 2016-03-10 at 10:53 -0700, Kyle Brenneman wrote:
> On 03/10/2016 10:47 AM, Martin Peres wrote:
> >
> > That could be a hacky way of handling the case where multiple 3D
> > drivers could be used to drive the same GPU. This may be necessary in
> > the future if two mesa drivers support the
https://bugs.freedesktop.org/show_bug.cgi?id=94481
Greg changed:
What|Removed |Added
CC||greg.bea...@gmail.com
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=94481
Greg changed:
What|Removed |Added
Hardware|All |x86-64 (AMD64)
--
You are receiving this mail be
https://bugs.freedesktop.org/show_bug.cgi?id=94481
Bug ID: 94481
Summary: softpipe - access violation in img_filter_2d_nearest
Product: Mesa
Version: 11.2
Hardware: All
OS: Windows (All)
Status: NEW
Severi
Hi,
On 10-03-16 17:03, Samuel Pitoiset wrote:
Looks fine, except that you will need to lower FILE_SHADER_INPUT to
FILE_MEMORY_SHARED for Tesla because input kernel parameters are located at
s[0x10].
Ok, but should this be done in nv50_ir_from_tgsi.cpp ? That feels like the
wrong place to
ha
On 03/10/2016 10:47 AM, Martin Peres wrote:
On 09/03/16 20:15, Kyle Brenneman wrote:
The current implementation of libglvnd uses a new X extension called
x11glvnd to look up a vendor name for each screen and to find a screen
number for a GLXDrawable.
But, Adam Jackson pointed out that a GLX ex
On Thu, 10 Mar 2016 18:13:03 +0100, Ilia Mirkin wrote:
On Thu, Mar 10, 2016 at 12:04 PM, Glenn Kennard wrote:
On Thu, 10 Mar 2016 17:02:15 +0100, Ilia Mirkin
wrote:
On Thu, Mar 10, 2016 at 10:57 AM, Nicolai Hähnle
wrote:
- if (c->MaxCombinedAtomicBuffers > 0)
+ if (c->MaxCombinedAto
On 09/03/16 20:15, Kyle Brenneman wrote:
The current implementation of libglvnd uses a new X extension called
x11glvnd to look up a vendor name for each screen and to find a screen
number for a GLXDrawable.
But, Adam Jackson pointed out that a GLX extension could do the same job
more cleanly: Lo
From: Marek Olšák
This allows compiling the main shader part as ES or LS.
If we get the correct hint, non-separable GLSL shaders no longer have to be
compiled as VS first, followed by LS or ES compiled on demand.
The result is that fewer shaders are compiled by piglit, but it doesn't
improve pi
From: Marek Olšák
Radeonsi needs to know which shader stage will execute after a shader
in order to make the best decision about which shader variant to compile
first.
This is only set for VS and TES, because we don't need it elsewhere.
VS has 3 variants:
- next shader is FS
- next shader is GS
From: Marek Olšák
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 35 ++
1 file changed, 35 insertions(+)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 26e463e..27c8a47 100644
--- a/src/mesa/state_tracker
v2 is Reviewed-by: Ilia Mirkin
[in the future, I'd really appreciate inline patches... had to
"manually" de-base64 the attachment... gmail, in their infinite
wisdom, doesn't provide a way to view inline attachments]
On Thu, Mar 10, 2016 at 12:09 PM, Marek Olšák wrote:
> Yes, please see the atta
On Thu, Mar 10, 2016 at 12:04 PM, Glenn Kennard wrote:
> On Thu, 10 Mar 2016 17:02:15 +0100, Ilia Mirkin
> wrote:
>
>> On Thu, Mar 10, 2016 at 10:57 AM, Nicolai Hähnle
>> wrote:
- if (c->MaxCombinedAtomicBuffers > 0)
+ if (c->MaxCombinedAtomicBuffers > 0) {
extens
Yes, please see the attached updated patch.
Thanks,
Marek
On Thu, Mar 10, 2016 at 6:00 PM, Ilia Mirkin wrote:
> Do you also need to do this when validating the compute pipeline?
>
> On Thu, Mar 10, 2016 at 11:59 AM, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> Only used indirectly when checki
The patch makes a bit more sense to me after realizing a fallthrough was
changed to a break, so the whole patch is
Reviewed-by: Glenn Kennard
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-
On 03/10/2016 01:28 AM, Ilia Mirkin wrote:
On Wed, Mar 9, 2016 at 6:23 PM, Samuel Pitoiset
wrote:
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nvc0/nvc0_query.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc
On 03/10/2016 01:23 AM, Ilia Mirkin wrote:
On Wed, Mar 9, 2016 at 6:23 PM, Samuel Pitoiset
wrote:
+ if (screen->base.class_3d <= NVF0_3D_CLASS &&
+ screen->base.class_3d != NVEA_3D_CLASS) {
Why? NVEA should be the same as NVF0 I think... and actually
NVEA_3D_CLASS is 0xa
On Thu, 10 Mar 2016 17:02:15 +0100, Ilia Mirkin wrote:
On Thu, Mar 10, 2016 at 10:57 AM, Nicolai Hähnle wrote:
- if (c->MaxCombinedAtomicBuffers > 0)
+ if (c->MaxCombinedAtomicBuffers > 0) {
extensions->ARB_shader_atomic_counters = GL_TRUE;
+ extensions->ARB_shader_atomic_cou
Do you also need to do this when validating the compute pipeline?
On Thu, Mar 10, 2016 at 11:59 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> Only used indirectly when checking dirty.st != 0
> ---
> src/mesa/state_tracker/st_context.c | 2 --
> src/mesa/state_tracker/st_context.h | 2 +-
> src
From: Marek Olšák
Only used indirectly when checking dirty.st != 0
---
src/mesa/state_tracker/st_context.c | 2 --
src/mesa/state_tracker/st_context.h | 2 +-
src/mesa/state_tracker/st_draw.c| 4 ++--
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/mesa/state_tracker/st_co
Clear DCC flags if necessary when binding a new sampler view.
v2: Do not reset DCC flags of bound sampler views.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeon/r600_texture.c | 2 --
src/gallium/drivers/radeonsi/si_descriptors.c | 10 +++---
2 files changed, 7 insertio
On Thu, Mar 10, 2016 at 5:36 PM, Marek Olšák wrote:
> On Thu, Mar 10, 2016 at 12:07 AM, Nicolai Hähnle wrote:
>> From: Nicolai Hähnle
>>
>> ---
>> src/gallium/drivers/r600/r600_state_common.c | 30
>>
>> 1 file changed, 30 insertions(+)
>>
>> diff --git a/src/galli
On Thu, Mar 10, 2016 at 12:07 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> ---
> src/gallium/drivers/r600/r600_state_common.c | 30
>
> 1 file changed, 30 insertions(+)
>
> diff --git a/src/gallium/drivers/r600/r600_state_common.c
> b/src/gallium/drivers/r6
ping?
I've already pushed patches 1 and 2, but the rest still require review.
On Sat, Feb 27, 2016 at 11:21 AM, Ilia Mirkin wrote:
> GL ES adds several extensions that enable the full functionality. I
> sent many of these out before on a piecemeal basis, but this unifies
> everything in one seri
On 09.03.2016 16:12, Bas Nieuwenhuizen wrote:
Clear DCC flags if necessary when binding a new sampler_view. Also
rebind all sampler views so that the sampler views that were already
bound are also up to date.
Seems mostly reasonable to me and should cover all the cases.
I don't think rebinding
On Thu, 2016-03-10 at 08:32 -0700, Kyle Brenneman wrote:
> > That could work, although I would expect "vendor-specific info" to
> > mean "random, arbitrary, and probably not machine-parsable". I'd be
> > hesitant to try to impose a structure on something that's never had
> > any structure befor
On 11:05 AM - Mar 10 2016, Ilia Mirkin wrote:
> On Thu, Mar 10, 2016 at 11:03 AM, Pierre Moreau wrote:
> > You might want to increment the address by at least
> > `info->prop.cp.inputOffset`, and if inputs still end up in shared on Tesla,
>
> There's a cp.sharedOffset just for that :) However it
On Thu, Mar 10, 2016 at 11:05 AM, Samuel Pitoiset
wrote:
>> If I understand correctly, the goal is to have user inputs in a
>> `screen->uniform_bo`, and so for all generations?
>
> Sure for fermi, and probably for Tesla.
I think continuing to use the USER_PARAMS or whatever mechanism on
telsa mak
On 03/10/2016 05:03 PM, Pierre Moreau wrote:
On 04:27 PM - Mar 10 2016, Samuel Pitoiset wrote:
On 03/10/2016 04:23 PM, Ilia Mirkin wrote:
On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede wrote:
Add support for clover / OpenCL kernel input parameters.
Signed-off-by: Hans de Goede
---
..
On Thu, Mar 10, 2016 at 11:03 AM, Pierre Moreau wrote:
> You might want to increment the address by at least
> `info->prop.cp.inputOffset`, and if inputs still end up in shared on Tesla,
There's a cp.sharedOffset just for that :) However it doesn't appear
to get set anywhere...
__
Looks fine, except that you will need to lower FILE_SHADER_INPUT to
FILE_MEMORY_SHARED for Tesla because input kernel parameters are located
at s[0x10]. No need to do this for Fermi+ because it's already lowered
to c0[]. Note that input kernel parameters will be probably sticked on
c7[] after m
On 04:27 PM - Mar 10 2016, Samuel Pitoiset wrote:
>
>
> On 03/10/2016 04:23 PM, Ilia Mirkin wrote:
> >On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede wrote:
> >>Add support for clover / OpenCL kernel input parameters.
> >>
> >>Signed-off-by: Hans de Goede
> >>---
> >> .../drivers/nouveau/codeg
On Thu, Mar 10, 2016 at 10:57 AM, Nicolai Hähnle wrote:
>> - if (c->MaxCombinedAtomicBuffers > 0)
>> + if (c->MaxCombinedAtomicBuffers > 0) {
>> extensions->ARB_shader_atomic_counters = GL_TRUE;
>> + extensions->ARB_shader_atomic_counter_ops = GL_TRUE;
>> + }
>
>
> I believe the
On 20.02.2016 00:13, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
---
src/mesa/state_tracker/st_extensions.c | 4 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 60 +++---
2 files changed, 57 insertions(+), 7 deletions(-)
diff --git a/src/mesa/state_tracker/st
I'm not super familiar with this code, but it looks good to me, so:
Reviewed-by: Nicolai Hähnle
On 20.02.2016 00:13, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
---
src/compiler/glsl/builtin_functions.cpp | 110 +++
src/compiler/glsl/glcpp/glcpp-parse.y|
On 03/10/2016 04:43 PM, Ilia Mirkin wrote:
On Thu, Mar 10, 2016 at 10:27 AM, Samuel Pitoiset
wrote:
On 03/10/2016 04:23 PM, Ilia Mirkin wrote:
On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede
wrote:
Add support for clover / OpenCL kernel input parameters.
Signed-off-by: Hans de Goede
On Thu, Mar 10, 2016 at 10:27 AM, Samuel Pitoiset
wrote:
>
>
> On 03/10/2016 04:23 PM, Ilia Mirkin wrote:
>>
>> On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede
>> wrote:
>>>
>>> Add support for clover / OpenCL kernel input parameters.
>>>
>>> Signed-off-by: Hans de Goede
>>> ---
>>> .../driver
On Thu, Mar 10, 2016 at 9:14 AM, Hans de Goede wrote:
> Extend the MEMORY file support to differentiate between global, local
> and shared memory, as well as "input" memory.
>
> "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a
> special memory type is added for this, since the
On 03/09/2016 12:53 PM, Kyle Brenneman wrote:
On 03/09/2016 12:21 PM, Adam Jackson wrote:
On Wed, 2016-03-09 at 11:15 -0700, Kyle Brenneman wrote:
The current implementation of libglvnd uses a new X extension called
x11glvnd to look up a vendor name for each screen and to find a screen
number
On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede wrote:
> Extend the MEMORY file support to differentiate between global, local
> and shared memory, as well as "input" memory.
>
> "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a
> special memory type is added for this, since the
On 03/10/2016 04:23 PM, Ilia Mirkin wrote:
On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede wrote:
Add support for clover / OpenCL kernel input parameters.
Signed-off-by: Hans de Goede
---
.../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 18 +++---
1 file changed, 15 i
Reviewed-by: Samuel Pitoiset
On 03/10/2016 04:14 PM, Hans de Goede wrote:
When support for decl.Atomic and .Shared was added, tgsi_build_declaration
was not updated to propagate these properly.
Signed-off-by: Hans de Goede
---
src/gallium/auxiliary/tgsi/tgsi_build.c | 6 ++
1 file cha
Reviewed-by: Ilia Mirkin
On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede wrote:
> When support for decl.Atomic and .Shared was added, tgsi_build_declaration
> was not updated to propagate these properly.
>
> Signed-off-by: Hans de Goede
> ---
> src/gallium/auxiliary/tgsi/tgsi_build.c | 6 +
1 - 100 of 120 matches
Mail list logo
