Patches 2-4 are
Reviewed-by: Timothy Arceri
I'll take a better look at the other two in the next few days unless
someone beats me to it.
On Wed, 2016-03-16 at 00:12 -0700, Kenneth Graunke wrote:
> In half the callers, we already have a pointer, and don't need
> to look it up again. This will a
Hi,
On 16-03-16 11:45, Samuel Pitoiset wrote:
On 03/16/2016 10:23 AM, Hans de Goede wrote:
Commit c3083c7082 ("nv50/ir: add support for BUFFER accesses") disabled /
commented out some of the old resource handling code, but not all of it.
Effectively all of it is dead already, if we ever ente
On 03/16/2016 10:23 AM, Hans de Goede wrote:
Commit c3083c7082 ("nv50/ir: add support for BUFFER accesses") disabled /
commented out some of the old resource handling code, but not all of it.
Effectively all of it is dead already, if we ever enter the old code
paths in handeLOAD / handleSTORE
Hi,
On 16-03-16 11:37, Samuel Pitoiset wrote:
Could you please get rid of the cosmetic changes (eg. the switch ones)?
Because this doesn't really improve readability and in my opinion these changes
should be eventually done in a separate patch.
I need at least halve of those cosmetic changes,
On Sat, Mar 12, 2016 at 12:35 AM, Emil Velikov wrote:
> On 9 March 2016 at 18:36, Marek Olšák wrote:
>> On Wed, Mar 9, 2016 at 6:51 PM, Emil Velikov
>> wrote:
>>> On 9 March 2016 at 17:11, Marek Olšák wrote:
On Wed, Mar 9, 2016 at 4:31 PM, Emil Velikov
wrote:
> On 8 March 2016
Could you please get rid of the cosmetic changes (eg. the switch ones)?
Because this doesn't really improve readability and in my opinion these
changes should be eventually done in a separate patch.
Other than that, this patch is :
Reviewed-by: Samuel Pitoiset
Yes, this probably won't work a
Reviewed-by: Samuel Pitoiset
On 03/16/2016 10:23 AM, Hans de Goede wrote:
Make the store offset handling in CodeEmitterGK110::emitSTORE identical
to the one in CodeEmitterGK110::emitLOAD handling.
This is just a cleanup, it does not cause any functional changes.
Signed-off-by: Hans de Goede
Reviewed-by: Samuel Pitoiset
On 03/16/2016 10:23 AM, Hans de Goede wrote:
Use the dst temp variable which was used in the TGSI_FILE_OUTPUT
case everywhere. This makes the code somewhat easier to reads
and helps avoiding going over 80 chars with upcoming changes.
This also brings the dst handli
The offsets are wrong in this patch... But even after fixing them I have
a few number of regressions (~10 piglit tests). Anyway, these changes
are not too useful for now, so I'm going to get rid of it.
I'll now try with Kepler.
On 03/15/2016 09:55 PM, Samuel Pitoiset wrote:
The first 32 bytes
https://bugs.freedesktop.org/show_bug.cgi?id=94549
--- Comment #2 from Plamena Manolova ---
Hi Vinson,
Could you please give the proposed patch a go?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
Reviewed-by: Marek Olšák
Marek
On Wed, Mar 16, 2016 at 10:23 AM, Hans de Goede wrote:
> tgsi_default_instruction_memory / tgsi_build_instruction_memory were
> returning uninitialized memory for tgsi_instruction_memory.Texture and
> tgsi_instruction_memory.Format. Note 0 means not set, and thus
https://bugs.freedesktop.org/show_bug.cgi?id=94549
--- Comment #1 from Plamena Manolova ---
Created attachment 122339
--> https://bugs.freedesktop.org/attachment.cgi?id=122339&action=edit
Proposed Patch
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the as
Reviewed-by: Samuel Pitoiset
On 03/16/2016 09:55 AM, Hans de Goede wrote:
Add support for clover / OpenCL kernel input parameters.
Signed-off-by: Hans de Goede
Reviewed-by: Ilia Mirkin
---
Changes in v2:
-s/local/private/
-Add: Reviewed-by: Ilia Mirkin
---
.../drivers/nouveau/codegen/nv50
Reviewed-by: Samuel Pitoiset
Btw, usually when someone has reviewed the v1 we add (v1) after the Rb
tag, like:
Reviewed-by: XXX (v1)
On 03/16/2016 09:55 AM, Hans de Goede wrote:
Extend the MEMORY file support to differentiate between global, private
and shared memory, as well as "input" mem
Reviewed-by: Samuel Pitoiset
On 03/16/2016 09:55 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
Reviewed-by: Ilia Mirkin
---
Changes in v2:
-Add Reviewed-by: Ilia Mi
Hi,
On 15-03-16 21:55, Samuel Pitoiset wrote:
This avoids using magic numbers for the driver constbuf slot which
is always 15 except for compute shaders on gk104+ where the slot 0
is used.
For gk104+, some special compute-related values like the thread
index are uploaded to screen->parm which i
Add support for OpenCL global memory buffers, note this has only
been tested with regular load and stores and likely needs more work
for e.g. atomic ops.
Signed-off-by: Hans de Goede
---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 +
.../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
Make the store offset handling in CodeEmitterGK110::emitSTORE identical
to the one in CodeEmitterGK110::emitLOAD handling.
This is just a cleanup, it does not cause any functional changes.
Signed-off-by: Hans de Goede
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 4 +---
1 fi
FILE_MEMORY_GLOBAL is currently only used for buffer handling, as we
do not yet have (opencl) global memory support. Global memory support
actually requires some different handling during lowering, so rename
FILE_MEMORY_GLOBAL to FILE_MEMORY_BUFFER to reflect that the current
code is for buffer han
Commit c3083c7082 ("nv50/ir: add support for BUFFER accesses") disabled /
commented out some of the old resource handling code, but not all of it.
Effectively all of it is dead already, if we ever enter the old code
paths in handeLOAD / handleSTORE / handleATOM we will get an exception
due to tryi
Use the dst temp variable which was used in the TGSI_FILE_OUTPUT
case everywhere. This makes the code somewhat easier to reads
and helps avoiding going over 80 chars with upcoming changes.
This also brings the dst handling more in line with the src
handling.
Signed-off-by: Hans de Goede
---
src
tgsi_default_instruction_memory / tgsi_build_instruction_memory were
returning uninitialized memory for tgsi_instruction_memory.Texture and
tgsi_instruction_memory.Format. Note 0 means not set, and thus is a
correct default initializer for these.
Fixes: 3243b6fc97 ("tgsi: add Texture and Format to
On Mon, 2016-03-14 at 14:24 -0400, Connor Abbott wrote:
> On Mon, Mar 14, 2016 at 2:10 PM, Jason Ekstrand wrote:
(...)
> >>
> >> -opcode("ldexp", 0, tfloat, [0, 0], [tfloat, tint], "", """
> >> -dst = ldexpf(src0, src1);
> >> +opcode("ldexp", 0, tfloat32, [0, 0], [tfloat32, tint32], "", """
> >> +
On Wed, 2016-03-16 at 09:48 +0100, Samuel Iglesias Gonsálvez wrote:
>
> On 15/03/16 08:41, Iago Toral wrote:
> > On Mon, 2016-03-14 at 17:33 -0700, Jason Ekstrand wrote:
> [...]
> >> + nir_alu_type type; + union { - uint32_t u; -
> >> int32_t i; - float f; + uint64_t u; + int
Add support for clover / OpenCL kernel input parameters.
Signed-off-by: Hans de Goede
Reviewed-by: Ilia Mirkin
---
Changes in v2:
-s/local/private/
-Add: Reviewed-by: Ilia Mirkin
---
.../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 18 +++---
1 file changed, 15 insertions(+
Extend the MEMORY file support to differentiate between global, private
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 actual storage of these
(e.g. UBO-s) may differ per implementa
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
Reviewed-by: Ilia Mirkin
---
Changes in v2:
-Add Reviewed-by: Ilia Mirkin
---
src/gallium/auxiliary/tgsi/tgsi_build.c | 6 ++
1 file changed,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/03/16 08:41, Iago Toral wrote:
> On Mon, 2016-03-14 at 17:33 -0700, Jason Ekstrand wrote:
[...]
>> + nir_alu_type type; + union { - uint32_t u; -
>> int32_t i; - float f; + uint64_t u; + int64_t i; +
>> double d; } data;
On Tue, 2016-03-15 at 08:02 -0700, Jason Ekstrand wrote:
>
> On Mar 15, 2016 7:48 AM, "Connor Abbott" wrote:
> >
> > On Tue, Mar 15, 2016 at 10:43 AM, Connor Abbott
> wrote:
> > > On Tue, Mar 15, 2016 at 5:53 AM, Iago Toral
> wrote:
> > >> On Mon, 2016-03-14 at 16:48 -0700, Jason Ekstrand wrote
On 16.03.2016 08:05, Nicolai Hähnle wrote:
> If I understand your patch correctly, the only effect is that a larger
> HTILE buffer is allocated, right? I'm surprised that only hangs were
> reported and not VM faults. We should really introduce guard pages /
> gaps between mapped buffers.
FWIW, tha
Less boilerplate.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/common/meta.c | 34 -
src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 14 +++---
2 files changed, 8 insertions(+), 40 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/s
In half the callers, we already have a pointer, and don't need
to look it up again. This will also help with upcoming meta work.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/shaderapi.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/shaderapi.c
Previously, we gave our internal clear/blit shaders actual GL handles
and stored them in the shader/program hash table. We used ordinary
GL API entrypoints to work with them.
We thought this shouldn't be a problem because GL doesn't allow
applications to invent their own names for shaders or prog
In half the callers, we already have a pointer, and don't need
to look it up again. This will also help with upcoming meta work.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/shaderapi.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/src/mesa/main/shadera
This will allow me to use them directly from Meta, bypassing the
versions that work with GL integer handles.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/shaderapi.c | 20 ++--
src/mesa/main/shaderapi.h | 6 ++
2 files changed, 16 insertions(+), 10 deletions(-)
diff --g
https://bugs.freedesktop.org/show_bug.cgi?id=94561
--- Comment #4 from Axel Davy ---
Returning 2GB looks like a good idea.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailin
36 matches
Mail list logo
