On 09/03/2015 09:54 PM, Ilia Mirkin wrote:
On Thu, Sep 3, 2015 at 7:58 AM, Tapani Pälli wrote:
Signed-off-by: Tapani Pälli
---
src/glsl/linker.cpp | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
On Saturday, August 29, 2015 02:24:04 AM Kenneth Graunke wrote:
> Because we only support geometry shaders in core profile, we can safely
> ignore any driver-extending of VS outputs.
>
> Those are:
> - Legacy userclipping (doesn't exist in core profile)
> - Edgeflag copying (Gen4-5 only, no GS sup
On 09/03/2015 10:02 PM, Brian Paul wrote:
On 09/03/2015 04:25 AM, Tapani Pälli wrote:
Signed-off-by: Tapani Pälli
---
configure.ac | 5 +
1 file changed, 5 insertions(+)
diff --git a/configure.ac b/configure.ac
index 90ba4fe..0fed26e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -11
From: Jeremy Huddleston
Cc: "10.6 11.0"
Bugzilla: https://bugs.gentoo.org/240956
---
After talking with Ian today, we determined that this disables an
optimization.
And FWIW, NVIDIA's fork of glapi (libglvnd) contains this kind of
writable-text optimization for x86-64.
configure.ac | 10 +
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
It's not required to set buffer_offset, because buffer=NULL and
user_buffer=NULL indicate a disabled slot. Anyway:
Reviewed-by: Marek Olšák
Marek
On Fri, Sep 4, 2015 at 2:25 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> If we skip a vbuffer we need to make sure we NULL out
> the contents, ot
Reviewed-by: Jason Ekstrand
On Sep 2, 2015 11:28 PM, "Kenneth Graunke" wrote:
> commit 472ef9a02f2e5c5d0caa2809cb736a0f4f0d4693 introduced code to
> change the types of SEL and MOV instructions for moves that simply
> "copy bits around". It didn't account for type conversion moves,
> however.
From: Dave Airlie
If we skip a vbuffer we need to make sure we NULL out
the contents, otherwise when it gets passed to the driver
it will get confused.
This was hit by:
GL41-CTS.gpu_shader_fp64.varyings
Signed-off-by: Dave Airlie
---
src/mesa/state_tracker/st_atom_array.c | 6 +-
1 file c
On Thu, Sep 3, 2015 at 11:07 AM, Jean-Sébastien Pédron
wrote:
> ... to free the ralloc context at program exit.
>
> On Linux, atexit(3) handlers are called when the program exits but also
> when a library is unloaded. The latter behavior is a Glibc extension.
>
> On systems where this extension is
This had got pretty tangled.
For the series:
Reviewed-by: Chris Forbes
On Sat, Aug 29, 2015 at 9:24 PM, Kenneth Graunke wrote:
> The old code was disasterously complex - spread across multiple atoms
> which may not even run, inspecting the dirty bits to try and decide
> whether it was necessar
On Saturday, August 29, 2015 02:23:58 AM Kenneth Graunke wrote:
> This is now only used for the vertex shader, so it makes sense to get it
> out of any paths run by the geometry shader.
>
> By wrapping the run() method, we can eliminate the bogus NULL
> parameter in the GS case, and do VS things o
Please add Matt Turner's patch:
[PATCH 10.6] i965/fs: Handle MRF destinations in
lower_integer_multiplication().
This fixes a sandy bridge regression in dEQP. dEQP regressions on
stable will prevent ChromeOS from using 10.6.6 as the basis for their
Mesa build.
thanks,
Mark
Emil Velikov write
Oh, that's quite a subtle bug...
Reviewed-by: Roland Scheidegger
Am 03.09.2015 um 18:00 schrieb Oded Gabbay:
> round(val*dscale) produces a double result, as val and dscale are double.
> However, LLVMConstInt receives unsigned long long, so there is an
> implicit conversion from double to unsign
Setting max != 100 should remove the "%" sign.
Marek
On Thu, Sep 3, 2015 at 11:04 PM, Benjamin Bellec wrote:
> Yes I meant "unit", "sign" is a bad translation.
> In gallium/hud, the temperature is displayed as a percentage, which is quite
> confusing. But maybe there is better and simpler approa
Yes I meant "unit", "sign" is a bad translation.
In gallium/hud, the temperature is displayed as a percentage, which is
quite confusing. But maybe there is better and simpler approach to fix
that. I do not really understand the code so I tried to copy other part of
the code.
___
Hi Benjamin,
In my opinion, your commit message is a bit confusing
I think you meant "unit" instead of "sign", right?
Besides, I'm not sure we want to add a new unit for temperature but I
could live with it.
Marek, what do you think?
See my comments, below.
On 09/03/2015 09:43 PM, Benjam
Signed-off-by: Benjamin Bellec
---
src/gallium/auxiliary/hud/hud_context.c | 5 +
src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
src/gallium/include/pipe/p_defines.h | 1 +
src/mesa/state_tracker/st_cb_perfmon.c| 5 +
4 files changed, 12 insertions(+), 1 dele
On Thu, Sep 3, 2015 at 3:30 PM, Marek Olšák wrote:
> It looks like the comments have mostly been negative. If I get any
> other bugs related to this, I'll have to resort to using setenv in the
> driver to get the behavior that should be the default.
>
> There are 2 unresolved issues though:
>
> 1)
It looks like the comments have mostly been negative. If I get any
other bugs related to this, I'll have to resort to using setenv in the
driver to get the behavior that should be the default.
There are 2 unresolved issues though:
1) The location is hardcoded to /etc/drirc in xmlconfig.c. Install
From: Rob Clark
Since debugging issues w/ fd's close()d at the wrong time can be quite
fun, this should probably be made more explicit in the docs.
Signed-off-by: Rob Clark
---
src/gallium/include/pipe/p_screen.h | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/include/p
On 09/03/2015 04:25 AM, Tapani Pälli wrote:
Signed-off-by: Tapani Pälli
---
configure.ac | 5 +
1 file changed, 5 insertions(+)
diff --git a/configure.ac b/configure.ac
index 90ba4fe..0fed26e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1110,6 +1110,11 @@ AC_MSG_RESULT([$with_sha1])
On Thu, Sep 3, 2015 at 7:58 AM, Tapani Pälli wrote:
> Signed-off-by: Tapani Pälli
> ---
> src/glsl/linker.cpp | 31 +++
> 1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
> index bc76af6..2be5660 100644
> ---
On Thu, Sep 3, 2015 at 7:58 AM, Tapani Pälli wrote:
> This applies to OpenGL Core >= 4.5 and OpenGL ES >= 3.1.
>
> Signed-off-by: Tapani Pälli
> ---
> src/glsl/linker.cpp | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
> ind
https://bugs.freedesktop.org/show_bug.cgi?id=34495
Fabio Pedretti changed:
What|Removed |Added
CC||fabio@libero.it
--
You are receivi
... to free the ralloc context at program exit.
On Linux, atexit(3) handlers are called when the program exits but also
when a library is unloaded. The latter behavior is a Glibc extension.
On systems where this extension is not supported, this causes an
application to crash when, for instance, a
Prevents regressions in ~128 tests when fixing unlink_block_successors
in the next commit.
XXX: Zero thought has been put into whether this is the right solution
Signed-off-by: Kenneth Graunke
---
src/glsl/nir/nir_control_flow.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
The
Consider the following NIR:
block block_0;
/* succs: block_1 block_2 */
if (...) {
block block_1;
...
} else {
block block_2;
}
Calling split_block_beginning() on block_1 would break block_0's
successors: link_block() sets both successors of a block, so calling
l
This is invalid, and causes disasters if we try to unlink successors:
removing the first will work, but removing the second copy will fail
because the block isn't in the successor's predecessor set any longer.
Signed-off-by: Kenneth Graunke
---
src/glsl/nir/nir_validate.c | 1 +
1 file changed,
Calling unlink_blocks(block, block->successors[0]) will successfully
unlink the first successor, but then will shift block->successors[1]
down to block->successor[0]. So the successors[1] != NULL check will
always fail.
Signed-off-by: Kenneth Graunke
---
src/glsl/nir/nir_control_flow.c | 4 ++--
I need to do this in a second place, and I'd rather make a helper
function than cut and paste the code.
Signed-off-by: Kenneth Graunke
---
src/glsl/nir/nir_control_flow.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/glsl/nir/nir_control_flow.c b/src/g
https://bugs.freedesktop.org/show_bug.cgi?id=91869
Bug ID: 91869
Summary: [PATCH] ralloc: atexit(3) handlers used in dlopened
libraries
Product: Mesa
Version: 10.6
Hardware: Other
OS: FreeBSD
Sta
On 09/03/2015 09:05 AM, Chris Wilson wrote:
> If the user supplies a pixel format of GL_RGB + GL_UNSIGNED_SHORT_5_6_5
> and specifies a generic unsized GL_RGB internal format, match that to a
> texture format of MESA_FORMAT_B5G6R5 if supported by the hardware.
>
> Noticed while playing with mesa-d
On Thu, Sep 3, 2015 at 7:09 AM, Hans de Goede wrote:
> Hi,
>
> On 02-09-15 16:44, Ilia Mirkin wrote:
>>
>> On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede wrote:
>>>
>>> Hi Ilia
>
>
>
>
Of course I don't really see how MS can work at all with nv30 since it
doesn't support a resolve step:
On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede wrote:
> On nv4x with a msaa visual after a while the gpu locks up, attach gdb to
> impress shows it is hanging waiting for a fence which never comes.
>
> Killing ooimpress at this point works exactly once, trying to do any
> 3d operations after killin
On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede wrote:
> On nv3x we will likely end up using the cpu to do color resolving for msaa
> blits. Disable msaa on these cards so that we do not end up using the cpu.
Actually the CPU fallback won't do scaled, so it's stuck with SIFM or
assert(false). Which
On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede wrote:
> Note this is not ideal. Since the sifm can only do source sizes upto
> 1024x1024 we end up using the blitter on nv4x, which is not that fast.
Moral of the story: don't do use nv3x/nv4x :)
Reviewed-by: Ilia Mirkin
Cc: "10.6 11.0"
>
> And o
On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede wrote:
> Scanout buffers on nv30 must always be non-swizzled and have special
> width alignment constraints.
>
> These constrains have been taken from the xf86-video-nouveau
> src/nv_accel_common.c: nouveau_allocate_surface() function.
>
> nouveau_allo
On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede wrote:
> Hi All,
>
> Here is a bunch of fixes for nv30 cards, the first patch is a resend of
> a patch I send a while back. AFAICT that one is ready for merging, but
> it is not entirely clear to me what the process is for getting (nouveau)
> mesa patc
On Thu, Sep 03, 2015 at 06:28:07PM +0200, Marek Olšák wrote:
> Sadly, this patch requires LLVM 3.5, which I didn't realize. Would it
> be okay to remove LLVM 3.4.2 support?
>
Yes, that would be fine.
-Tom
> Marek
>
> On Wed, Sep 2, 2015 at 7:48 PM, Tom Stellard wrote:
> > On Tue, Sep 01, 2015
Sadly, this patch requires LLVM 3.5, which I didn't realize. Would it
be okay to remove LLVM 3.4.2 support?
Marek
On Wed, Sep 2, 2015 at 7:48 PM, Tom Stellard wrote:
> On Tue, Sep 01, 2015 at 11:18:15PM +0200, Marek Olšák wrote:
>> From: Marek Olšák
>>
>
> Reviewed-by: Tom Stellard
>> Just a c
On Thu, Sep 03, 2015 at 12:15:50PM -0400, Ilia Mirkin wrote:
> On Thu, Sep 3, 2015 at 12:05 PM, Chris Wilson
> wrote:
> > If the user supplies a pixel format of GL_RGB + GL_UNSIGNED_SHORT_5_6_5
> > and specifies a generic unsized GL_RGB internal format, match that to a
> > texture format of MESA_
On Thu, Sep 3, 2015 at 12:05 PM, Chris Wilson wrote:
> If the user supplies a pixel format of GL_RGB + GL_UNSIGNED_SHORT_5_6_5
> and specifies a generic unsized GL_RGB internal format, match that to a
> texture format of MESA_FORMAT_B5G6R5 if supported by the hardware.
>
> Noticed while playing wi
Pushed the series. Thanks.
Marek
On Thu, Sep 3, 2015 at 12:54 AM, Grazvydas Ignotas wrote:
> As suggested by Marek Olšák, we can use single atom to track all scissor
> states. This will allow to simplify dirty atom handling later.
> ---
> v2: rebased, moved dirty_mask set out of the loop
>
> sr
If the user supplies a pixel format of GL_RGB + GL_UNSIGNED_SHORT_5_6_5
and specifies a generic unsized GL_RGB internal format, match that to a
texture format of MESA_FORMAT_B5G6R5 if supported by the hardware.
Noticed while playing with mesa-demos/teximage:
TexImage(RGB/565 256 x 256): 79.8 im
On Thu, Sep 3, 2015 at 6:26 PM, Tom Stellard wrote:
> On Thu, Sep 03, 2015 at 06:15:26PM +0300, Oded Gabbay wrote:
>> round(val*dscale) produces a double result, as val and dscale are double.
>> However, LLVMConstInt receives unsigned long long, so there is an
>> implicit conversion from double to
round(val*dscale) produces a double result, as val and dscale are double.
However, LLVMConstInt receives unsigned long long, so there is an
implicit conversion from double to unsigned long long.
This is an undefined behavior. Therefore, we need to first explicitly
convert the round result to long l
On Thu, Sep 03, 2015 at 06:15:26PM +0300, Oded Gabbay wrote:
> round(val*dscale) produces a double result, as val and dscale are double.
> However, LLVMConstInt receives unsigned long long, so there is an
> implicit conversion from double to unsigned long long.
> This is an undefined behavior. Ther
round(val*dscale) produces a double result, as val and dscale are double.
However, LLVMConstInt receives unsigned long long, so there is an
implicit conversion from double to unsigned long long.
This is an undefined behavior. Therefore, we need to first explicitly
convert the round result to long l
On 09/03/2015 04:56 PM, Samuel Iglesias Gonsálvez wrote:
On 03/09/15 14:08, Tapani Pälli wrote:
On 09/03/2015 03:05 PM, Iago Toral wrote:
On Thu, 2015-09-03 at 13:52 +0300, Tapani Pälli wrote:
On 09/03/2015 01:40 PM, Samuel Iglesias Gonsálvez wrote:
On 03/09/15 12:30, Tapani Pälli wrote:
On 03/09/15 14:08, Tapani Pälli wrote:
>
>
> On 09/03/2015 03:05 PM, Iago Toral wrote:
>> On Thu, 2015-09-03 at 13:52 +0300, Tapani Pälli wrote:
>>>
>>> On 09/03/2015 01:40 PM, Samuel Iglesias Gonsálvez wrote:
On 03/09/15 12:30, Tapani Pälli wrote:
> Hi;
>
> On 07/23/
The point is to avoid having to re-validate all image units when
_NEW_TEXTURE is flagged, which can be expensive if the driver exposes
a large number of image units. This has been reported to fix a 36%
performance regression in the Synmark2 Multithread benchmark on the
i965 driver which exposes 19
gl_image_unit::_Valid will be removed in a future commit.
Tested-by: Ye Tian
CC: "11.0"
---
src/mesa/drivers/dri/i965/brw_gs_surface_state.c | 3 ++-
src/mesa/drivers/dri/i965/brw_vs_surface_state.c | 3 ++-
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 10 ++
3 files changed, 10
The call to _mesa_test_texobj_completeness() is unnecessary if the
texture is already known to be complete. If the texture object is
dirtied in the meantime _BaseComplete and _MipmapComplete will be
reset to false. _mesa_is_image_unit_valid() will start to be called
more frequently in a future co
A future commit will remove all texture object-dependent derived state
from the image unit struct to make validation unnecessary on texture
state changes. Instead of checking gl_image_unit::_Valid drivers will
be required to call this function when needed to find out whether an
image unit is in a
On Thu, 2015-09-03 at 23:23 +1000, Timothy Arceri wrote:
> Looks like an oversight from when this was originally added. Before this
> change it would always end up as std140.
Note this now means linking will fail if the layout qualifier differs between
shaders. The spec only says "having the same
On Thu, 2015-09-03 at 15:37 +0300, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Wed, 2015-09-02 at 14:32 +0300, Francisco Jerez wrote:
> >> Iago Toral writes:
> >>
> >> > On Thu, 2015-07-30 at 16:13 +0300, Francisco Jerez wrote:
> >> >> Iago Toral writes:
> >> >>
> >> >> > On Thu, 201
Looks like an oversight from when this was originally added. Before this
change it would always end up as std140.
Cc: Ian Romanick
---
src/glsl/link_uniform_blocks.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/link_uniform_blocks.cpp b/src/glsl/link_uniform_blo
On Sep 3, 2015 4:09 AM, "Neil Roberts" wrote:
>
> Jason Ekstrand writes:
>
> > We can probably just bail higher up in the stack and never call the
> > driver hook if we have a zero dimension. That would also protect us
> > from silly zero-dim bugs that may exist.
>
> Yes, that already does happen
IVB and VLV hang sporadically when an untyped surface read or write
message is used to access a surface of format other than RAW, as may
happen when there is a mismatch between the format qualifier of the
image uniform and the format of the actual image bound to the
pipeline. According to the spec
Iago Toral writes:
> On Wed, 2015-09-02 at 14:32 +0300, Francisco Jerez wrote:
>> Iago Toral writes:
>>
>> > On Thu, 2015-07-30 at 16:13 +0300, Francisco Jerez wrote:
>> >> Iago Toral writes:
>> >>
>> >> > On Thu, 2015-07-30 at 15:58 +0300, Francisco Jerez wrote:
>> >> >> Iago Toral Quiroga
On 09/03/2015 03:05 PM, Iago Toral wrote:
On Thu, 2015-09-03 at 13:52 +0300, Tapani Pälli wrote:
On 09/03/2015 01:40 PM, Samuel Iglesias Gonsálvez wrote:
On 03/09/15 12:30, Tapani Pälli wrote:
Hi;
On 07/23/2015 09:42 AM, Samuel Iglesias Gonsalvez wrote:
v2:
- Add tessellation shader con
On Thu, 2015-09-03 at 13:52 +0300, Tapani Pälli wrote:
>
> On 09/03/2015 01:40 PM, Samuel Iglesias Gonsálvez wrote:
> >
> >
> > On 03/09/15 12:30, Tapani Pälli wrote:
> >> Hi;
> >>
> >> On 07/23/2015 09:42 AM, Samuel Iglesias Gonsalvez wrote:
> >>> v2:
> >>> - Add tessellation shader constants ass
This applies to OpenGL Core >= 4.5 and OpenGL ES >= 3.1.
Signed-off-by: Tapani Pälli
---
src/glsl/linker.cpp | 19 +++
1 file changed, 19 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 01554bc..bc76af6 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/l
Signed-off-by: Tapani Pälli
---
src/glsl/linker.cpp | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index bc76af6..2be5660 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -3890,10 +3890,33
On Thu, Sep 3, 2015 at 1:17 PM, Jose Fonseca wrote:
> On the flip side, we could remove TGSI_FILE_ADDR, TGSI_OPCODE_ARL, and
> TGSI_OPCODE_ARR.
>
> We already remove all dependencies of these from our internal state tracers.
>
> And it is trivial to do so, at least for HW with native integer suppo
On nv3x we will likely end up using the cpu to do color resolving for msaa
blits. Disable msaa on these cards so that we do not end up using the cpu.
Signed-off-by: Hans de Goede
---
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-
On nv4x with a msaa visual after a while the gpu locks up, attach gdb to
impress shows it is hanging waiting for a fence which never comes.
Killing ooimpress at this point works exactly once, trying to do any
3d operations after killing impress will lockup the entire system.
This needs further in
Note this is not ideal. Since the sifm can only do source sizes upto
1024x1024 we end up using the blitter on nv4x, which is not that fast.
And on nv3x we end up using the cpu which is really slow.
Signed-off-by: Hans de Goede
---
src/gallium/drivers/nouveau/nv30/nv30_miptree.c | 19 --
Hi All,
Here is a bunch of fixes for nv30 cards, the first patch is a resend of
a patch I send a while back. AFAICT that one is ready for merging, but
it is not entirely clear to me what the process is for getting (nouveau)
mesa patches merged.
Should I request commit rights, and push my own patc
Scanout buffers on nv30 must always be non-swizzled and have special
width alignment constraints.
These constrains have been taken from the xf86-video-nouveau
src/nv_accel_common.c: nouveau_allocate_surface() function.
nouveau_allocate_surface() applies these width constraints only when a
tiled a
On the flip side, we could remove TGSI_FILE_ADDR, TGSI_OPCODE_ARL, and
TGSI_OPCODE_ARR.
We already remove all dependencies of these from our internal state tracers.
And it is trivial to do so, at least for HW with native integer support.
Jose
On 01/09/15 23:55, Jose Fonseca wrote:
I'm all fo
Jason Ekstrand writes:
> We can probably just bail higher up in the stack and never call the
> driver hook if we have a zero dimension. That would also protect us
> from silly zero-dim bugs that may exist.
Yes, that already does happen. As mentioned elsewhere in the thread,
_mesa_validate_pbo_ac
Hi,
On 02-09-15 16:44, Ilia Mirkin wrote:
On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede wrote:
Hi Ilia
Of course I don't really see how MS can work at all with nv30 since it
doesn't support a resolve step:
if (info.src.resource->nr_samples > 1 &&
info.dst.resource->nr_sampl
On Thu, 2015-09-03 at 13:15 +0300, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Wed, 2015-09-02 at 17:53 +0300, Francisco Jerez wrote:
> >> Iago Toral writes:
> >>
> >> > On Wed, 2015-09-02 at 14:29 +0300, Francisco Jerez wrote:
> >> >> Iago Toral writes:
> >> >>
> >> >> > Hi Curro,
>
On 09/03/2015 01:40 PM, Samuel Iglesias Gonsálvez wrote:
On 03/09/15 12:30, Tapani Pälli wrote:
Hi;
On 07/23/2015 09:42 AM, Samuel Iglesias Gonsalvez wrote:
v2:
- Add tessellation shader constants assignment
Signed-off-by: Samuel Iglesias Gonsalvez
---
src/mesa/drivers/dri/i965/brw_co
On 03/09/15 12:30, Tapani Pälli wrote:
> Hi;
>
> On 07/23/2015 09:42 AM, Samuel Iglesias Gonsalvez wrote:
>> v2:
>> - Add tessellation shader constants assignment
>>
>> Signed-off-by: Samuel Iglesias Gonsalvez
>> ---
>> src/mesa/drivers/dri/i965/brw_context.c | 12
>> 1 file cha
Hi;
On 07/23/2015 09:42 AM, Samuel Iglesias Gonsalvez wrote:
v2:
- Add tessellation shader constants assignment
Signed-off-by: Samuel Iglesias Gonsalvez
---
src/mesa/drivers/dri/i965/brw_context.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/br
Signed-off-by: Tapani Pälli
---
configure.ac | 5 +
1 file changed, 5 insertions(+)
diff --git a/configure.ac b/configure.ac
index 90ba4fe..0fed26e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1110,6 +1110,11 @@ AC_MSG_RESULT([$with_sha1])
AC_SUBST(SHA1_LIBS)
AC_SUBST(SHA1_CFLAGS)
+#
Patch modifies existing shader source and replace functionality to work
with environment variables rather than enable dumping on compile time.
Also instead of _mesa_str_checksum, _mesa_sha1_compute is used to avoid
collisions.
Functionality is controlled via two environment variables:
MESA_SHADER
Iago Toral writes:
> On Wed, 2015-09-02 at 17:53 +0300, Francisco Jerez wrote:
>> Iago Toral writes:
>>
>> > On Wed, 2015-09-02 at 14:29 +0300, Francisco Jerez wrote:
>> >> Iago Toral writes:
>> >>
>> >> > Hi Curro,
>> >> >
>> >> > I have been a couple of weeks on holidays and have just come
> -Original Message-
> From: Timothy Arceri [mailto:t_arc...@yahoo.com.au]
> Sent: Thursday, September 3, 2015 10:24 AM
> To: Lofstedt, Marta; mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH 16/16] glsl: Allow arrays of arrays in GLSL ES
> 3.10 and GLSL 4.30
>
> On Thu, 201
Hello list,
The candidate for the Mesa 10.6.6 is now available. Currently we have:
- 33 queued
- 12 nominated (outstanding)
- and 1 rejected/obsolete patches
The present queue covers mesa core, i965 (regression fixes), r600
(assertions and r600/sb crashes), radeonsi (workaround for GPU hang
in
These provide a convenient way to do simple variable loads and stores.
Signed-off-by: Kenneth Graunke
---
src/glsl/nir/nir_builder.h | 27 +++
1 file changed, 27 insertions(+)
diff --git a/src/glsl/nir/nir_builder.h b/src/glsl/nir/nir_builder.h
index ba988d7..ffa31c9 100
By performing the vertex counting in NIR, we're able to elide a ton of
useless safety checks around every EmitVertex() call:
total instructions in shared programs: 3952 -> 3720 (-5.87%)
instructions in affected programs: 3491 -> 3259 (-6.65%)
helped:11
HURT:
I left a bunch of code indented a level in the previous patch to make
the diff easier to read. But now we should fix that.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 124 +++---
src/mesa/drivers/dri/i965/gen6_gs_visitor.cpp | 102 +
This makes it possible for NIR shaders to know the number of output
vertices and the number of invocations. Drivers could also access
these directly without going through gl_program.
We should probably add InputType and OutputType here too, but currently
those are stored as GL_* enums, and I want
This patch also introduces a lowering pass to convert the simple GS
intrinsics to the new ones. See the comments above that for the
rationale behind the new intrinsics.
This should be useful for i965; it's a generic enough mechanism that I
could see other drivers potentially using it as well, so
On Thu, 2015-09-03 at 07:55 +, Lofstedt, Marta wrote:
> Hi Timothy,
>
> This patch will unlock a lot of GLES 3.1 AoA related CTS tests. It would be
> nice to see it merged.
>
I'm not sure there is much point merging it since there rest of the series
fixes all the AoA CTS tests. Although the
Hi Timothy,
This patch will unlock a lot of GLES 3.1 AoA related CTS tests. It would be
nice to see it merged.
Reviewed-by: Marta Lofstedt
> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Timothy Arceri
> Sent: Saturday, July 18, 2015
On Wed, 2015-09-02 at 14:32 +0300, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Thu, 2015-07-30 at 16:13 +0300, Francisco Jerez wrote:
> >> Iago Toral writes:
> >>
> >> > On Thu, 2015-07-30 at 15:58 +0300, Francisco Jerez wrote:
> >> >> Iago Toral Quiroga writes:
> >> >>
> >> >> > ---
90 matches
Mail list logo
