Including under __GNUC__ is going to break the build of
Mesa on everything compiled with clang/gcc that isn't Linux.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
We have intel_batchbuffer_emit_reloc(), which combines calculating and writing
out the right value to the batch buffer with emitting the relocation. It
determines the relocation offset from the current batch buffer position and
calculates the value to write in the batch buffer from the bo presumed
On Sunday, January 18, 2015 01:04:02 AM Francisco Jerez wrote:
> This is the first part of a series meant to improve our usage of the L3 cache.
> Currently it's far from ideal since the following objects aren't taking any
> advantage of it:
> - Pull constants (i.e. UBOs and demoted uniforms)
> -
While modern pthread mutexes are very fast, they still incur a call to an
external DSO and overhead of the generality and features of pthread mutexes.
Most mutexes in mesa only needs lock/unlock, and the idea here is that we can
inline the atomic operation and make the fast case just two intruction
On Tue, Jan 27, 2015 at 8:16 PM, Kenneth Graunke wrote:
> On Tuesday, January 27, 2015 02:32:19 PM Jason Ekstrand wrote:
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88792
>> ---
>>
>> Yes, computing it from the surface state and bo->offset64 is a little
>> strange when we could just
On 28.01.2015 04:05, Tom Stellard wrote:
> v2:
> - Only emit write SPI_TMPRING_SIZE once per packet.
> - Use context global scratch buffer.
>
> v3:
> - Patch shaders using WRITE_DATA packet instead of map/unmap.
> - Emit ICACHE_FLUSH, CS_PARTIAL_FLUSH, PS_PARTIAL_FLUSH, and
> VS_PARTIA
On Tuesday, January 27, 2015 02:32:20 PM Jason Ekstrand wrote:
> I haven't actually seen this bug in the wild, but it's possible that
> someone could ask to do a ST3C PBO download or something. This protects us
S3TC (typo)
> from accidentally creating a render target with a
On Tuesday, January 27, 2015 02:32:19 PM Jason Ekstrand wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88792
> ---
>
> Yes, computing it from the surface state and bo->offset64 is a little
> strange when we could just be using mt->offset. However, that's the way
> it's done on al
The _mesa_dlist_alloc() function is only guaranteed to return a pointer
with 4-byte alignment. On 64-bit systems which don't support unaligned
loads (e.g. SPARC or MIPS) this could lead to a bus error in the VBO code.
The solution is to add a new _mesa_dlist_alloc_aligned() function which
will r
On 27.01.2015 20:00, Marek Olšák wrote:
>
> The old pm4 state is leaked though.
Right, I wanted to mention that as well but forgot. :}
> The attached diff should fix it.
Looks good.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
Now that we can scalarize with NIR, there's no need for all this code
anymore. Let's get rid of it and just do scalar operations.
v2: run copy prop before lowering phi nodes
---
src/mesa/drivers/dri/i965/brw_fs.h | 15 -
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 489 ++---
v2 Jason Ekstrand :
- Add better comments
- Use nir_ssa_dest_init and nir_src_for_ssa more places
- Fix some void * casts
v3 Jason Ekstrand :
- Rework the way we determine whether or not to sccalarize a phi node to
make the recursion non-bogus
- Treat load_const instructions as scalarizabl
Originally, get_alu_src was supposed to handle resolving swizzles and
things like that. However, now that basically every instruction we have
only takes scalar sources, we don't really need it anymore. The only case
where it's still marginally useful is for the mov and vecN operations that
are le
EdB writes:
> ---
> src/gallium/state_trackers/clover/llvm/invocation.cpp | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index 10dbe08..510e195 10064
On Sat, Jan 17, 2015 at 10:33 AM, Matt Turner wrote:
> On Sat, Jan 17, 2015 at 8:31 AM, Thomas Helland
> wrote:
>> 2015-01-03 22:48 GMT+01:00 Matt Turner :
>>> On Sat, Jan 3, 2015 at 11:18 AM, Thomas Helland
>>> wrote:
This allows opt_algebraic to resolve open-coded
saturates into ir_u
I haven't actually seen this bug in the wild, but it's possible that
someone could ask to do a ST3C PBO download or something. This protects us
from accidentally creating a render target with a compressed or otherwise
non-renderable format.
---
src/mesa/drivers/dri/i965/intel_tex.c | 5 +
1 f
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88792
---
Yes, computing it from the surface state and bo->offset64 is a little
strange when we could just be using mt->offset. However, that's the way
it's done on all the other gens so I decided to be consistent.
src/mesa/drivers/dri/i965
On Tue, Jan 27, 2015 at 9:09 AM, Eduardo Lima Mitev wrote:
> On 01/21/2015 03:26 AM, Anuj Phogat wrote:
>> On Mon, Jan 19, 2015 at 3:32 AM, Eduardo Lima Mitev wrote:
>>> The specification states that glTexImage2D and glTexImage3D should return
>>> GL_INVALID_VALUE if the internal format is invali
https://bugs.freedesktop.org/show_bug.cgi?id=84019
--- Comment #5 from Martin Peres ---
The problem may be on my side. Sorry for the noise.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@li
On Tue, Jan 27, 2015 at 2:01 PM, Eric Anholt wrote:
> Jason Ekstrand writes:
>
> > On Mon, Jan 26, 2015 at 3:58 PM, Eric Anholt wrote:
> >
> >> Jason Ekstrand writes:
> >>
> >> > On Mon, Jan 26, 2015 at 11:21 AM, Eric Anholt
> wrote:
> >> >
> >> >> Jason Ekstrand writes:
> >> >> > + cas
oops, this should have been a v3
On Tue, Jan 27, 2015 at 1:32 PM, Jason Ekstrand
wrote:
> v2 Jason Ekstrand :
> - Add better comments
> - Use nir_ssa_dest_init and nir_src_for_ssa more places
> - Fix some void * casts
> ---
> src/glsl/Makefile.sources | 1 +
> src/glsl/nir/ni
Jason Ekstrand writes:
> On Mon, Jan 26, 2015 at 3:58 PM, Eric Anholt wrote:
>
>> Jason Ekstrand writes:
>>
>> > On Mon, Jan 26, 2015 at 11:21 AM, Eric Anholt wrote:
>> >
>> >> Jason Ekstrand writes:
>> >> > + case nir_instr_type_phi: {
>> >> > + nir_phi_instr *src_phi = nir_inst
https://bugs.freedesktop.org/show_bug.cgi?id=84019
--- Comment #4 from Martin Peres ---
Hello, the request is accepted. However, you gpg key is not currently visible.
I cannot create an account until this is solved.
PS: Sorry for the delay
--
You are receiving this mail because:
You are the as
v2 Jason Ekstrand :
- Add better comments
- Use nir_ssa_dest_init and nir_src_for_ssa more places
- Fix some void * casts
---
src/glsl/Makefile.sources | 1 +
src/glsl/nir/nir.h | 2 +
src/glsl/nir/nir_lower_phis_to_scalar.c | 251 +
---
src/gallium/drivers/radeonsi/si_compute.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index 4427d3b..ba63afd 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/sr
v2:
- Only emit write SPI_TMPRING_SIZE once per packet.
- Use context global scratch buffer.
v3:
- Patch shaders using WRITE_DATA packet instead of map/unmap.
- Emit ICACHE_FLUSH, CS_PARTIAL_FLUSH, PS_PARTIAL_FLUSH, and
VS_PARTIAL_FLUSH when patching shaders.
v4:
- Code cleanups.
This moves scratch buffer allocation from si_launch_grid() to
si_create_compute_state(). This helps to reduce the overhead of
launching a kernel and also fixes a bug in the code that would cause
the scratch buffer to be too small if a kernel with smaller scratch size
was launched before a kernel w
---
src/gallium/drivers/radeonsi/si_compute.c | 11 +--
src/gallium/drivers/radeonsi/si_shader.h | 1 +
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index ba63afd..840d21f 100644
---
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_pm4.c | 12
src/gallium/drivers/radeonsi/si_pm4.h | 1 +
src/gallium/drivers/radeonsi/si_state_shaders.c | 4
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeonsi
On 01/21/2015 03:26 AM, Anuj Phogat wrote:
> On Mon, Jan 19, 2015 at 3:32 AM, Eduardo Lima Mitev wrote:
>> The specification states that glTexImage2D and glTexImage3D should return
>> GL_INVALID_VALUE if the internal format is invalid, and GL_INVALID_ENUM is
>> the format type is invalid. However,
https://bugs.freedesktop.org/show_bug.cgi?id=88662
--- Comment #2 from Jonathan Gray ---
Yes, I can confirm that the patch fixes the crash on sparc64.
Tested with 10.4.3 so I had to change
fprintf(f, "NOP\n"); -> printf("NOP\n");
to make it build but it otherwise seems fine, thanks.
--
You ar
Am Freitag, 16. Januar 2015, 13:42:53 schrieb Marc Dietrich:
> The GCC specific target function attribute or pragma can be used to enable
> architecture depended optimisation options (e.g. SSE) directly in source
> files instead of specifing them on the compiler command line. This is
> useful when
On Tue, 27 Jan 2015 04:46:33 +0100, Dave Airlie wrote:
From: Dave Airlie
GLSL 1.50 specifies a fragment shader may have a primitive id
input without a geometry shader present.
On r600 hw there is a special GS scenario for this, you have
to enable GS_SCENARIO_A and pass the primitive id throu
On Tue, 27 Jan 2015 04:46:32 +0100, Dave Airlie wrote:
From: Dave Airlie
In order to detect that a pixel shader has a prim id
input when we have no geometry shader we need to reorder
the shader selection so the pixel shader is selected
first, then the vertex shader key can take into account
t
On Sat, Jan 24, 2015 at 4:32 AM, Michel Dänzer wrote:
> On 24.01.2015 11:56, Tom Stellard wrote:
>> On Thu, Jan 22, 2015 at 11:27:32AM +0900, Michel Dänzer wrote:
>>>
>>> Tom, for now I suggest this solution, summarized from Marek's previous
>>> descriptions:
>>>
>>> (At least) for shaders which h
Michel Dänzer writes:
> From: Michel Dänzer
>
> Fixes reading beyond allocated memory:
>
> ==1936== Invalid read of size 1
> ==1936==at 0x4C2C1B4: strlen (vg_replace_strmem.c:412)
> ==1936==by 0x9E00C30: std::basic_string,
> std::allocator >::basic_string(char const*, std::allocator
>
On 27 January 2015 at 18:04, Dave Airlie wrote:
> From: Dave Airlie
>
> This use the gallium poly stipple helper to modify
> the fragment shader and sets up the appropriate state
> around it.
>
> This renders the polys test from mesa demos properly.
> Fixes:
> https://bugs.freedesktop.org/show_bu
On 24.01.2015 11:56, Tom Stellard wrote:
> On Thu, Jan 22, 2015 at 11:27:32AM +0900, Michel Dänzer wrote:
>> On 21.01.2015 21:12, Marek Olšák wrote:
>>> We also had a case when the CPU accidentally corrupted shaders,
>>> because the shaders were mapped after textures and a CPU texture
>>> upload ov
On 22.01.2015 19:10, Francisco Jerez wrote:
> Michel Dänzer writes:
>
>> From: Michel Dänzer
>>
>> That's what device::ir_target() returns. Fixes reading beyond allocated
>> memory:
>>
>> ==1936== Invalid read of size 1
>> ==1936==at 0x4C2C1B4: strlen (vg_replace_strmem.c:412)
>> ==1936==
From: Michel Dänzer
Fixes reading beyond allocated memory:
==1936== Invalid read of size 1
==1936==at 0x4C2C1B4: strlen (vg_replace_strmem.c:412)
==1936==by 0x9E00C30: std::basic_string,
std::allocator >::basic_string(char const*, std::allocator const&)
(in /usr/lib/x86_64-linux-gnu/li
From: Dave Airlie
This use the gallium poly stipple helper to modify
the fragment shader and sets up the appropriate state
around it.
This renders the polys test from mesa demos properly.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=25280
TODO:
should this be in radeon common code? (rade
Thanks Tapani. I was waiting to see if their are any more comments
before addressing Emil's review.
Br,
Kalyan
On Mon, Jan 26, 2015 at 11:30 PM, Tapani Pälli wrote:
>
>
> On 01/08/2015 06:30 AM, Kalyan Kondapally wrote:
>>
>> This patch series adds support for following GLES2 Texture Float
>> ex
42 matches
Mail list logo
