https://bugs.freedesktop.org/show_bug.cgi?id=93188
--- Comment #3 from Jose Fonseca ---
Though we still might want to avoid non-standard C++ constructs regardless.
C++ is not a superset of C99 (though some portions are widely supported), so
NIR needs to take care when mixing both things.
--
Yo
On Wednesday, November 25, 2015 08:55:54 PM Jason Ekstrand wrote:
> It's not really buying us anything at this point. It's just a way of
> remapping one offset namespace onto another. We can just use the location
> namespace the whole way through.
> ---
> src/mesa/drivers/dri/i965/brw_nir.c
https://bugs.freedesktop.org/show_bug.cgi?id=93188
Jose Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=93189
Jose Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=93187
Jose Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 01/12/15 23:26, Vinson Lee wrote:
On Tue, Dec 1, 2015 at 3:07 PM, Jose Fonseca wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=93189
---
configure.ac | 7 +++
1 file changed, 7 insertions(+)
diff --git a/configure.ac b/configure.ac
index 4016871..b6680d0 100644
--- a/configure.ac
On Tue, 2015-12-01 at 13:00 -0800, Jordan Justen wrote:
> On 2015-12-01 04:45:05, Iago Toral wrote:
> > On Tue, 2015-12-01 at 00:19 -0800, Jordan Justen wrote:
> > > Signed-off-by: Jordan Justen
> > > ---
> > > src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 52
> > >
Reviewed-by: Iago Toral Quiroga
On Tue, 2015-12-01 at 14:35 -0800, Jordan Justen wrote:
> v4:
> * Apply similar optimization for shared variable stores as
>0cb7d7b4b7c32246d4c4225a1d17d7ff79a7526d. This was causing a
>OpenGLES 3.1 CTS failure, but
>867c436ca841b4196b4dde4786f5086c76b
Surprisingly, this didn't exist at all.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_gs.c | 58 ++
1 file changed, 58 insertions(+)
We could almost certainly clean this up, and I'm not opposed to that, I just
wanted to fill the feature gap
This appeared in brw_vs.c and brw_wm.c, should have appeared in
brw_gs.c, and was soon going to have to be in brw_tcs.c and brw_tes.c as
well.
So, instead, move it to a central location (which has to know about both
struct brw_context and perf_debug()).
Signed-off-by: Kenneth Graunke
---
src/me
On Tuesday, December 01, 2015 07:40:54 PM Rob Clark wrote:
> Simplify the instructions a bit by setting all the potentially needed
> environment variables in run.c itself.
>
> Made very trivially more complex by the fact that all of the gallium
> drivers are using u_debug stuff, so one env var con
https://bugs.freedesktop.org/show_bug.cgi?id=93203
Bug ID: 93203
Summary: [softpipe] piglit gl30basic regression
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Keywords: bi
This makes the code easier to follow, should be more efficient
and will make it easier to add matching via explicit locations
in a follow up patch.
---
src/glsl/link_interface_blocks.cpp | 145 +++--
1 file changed, 41 insertions(+), 104 deletions(-)
diff --git a/s
For example if there are only returns, the break bb will not end up part
of the CFG. However there will have been a prebreak already emitted for
it, and when hitting the RET that comes after, we will try to insert the
current (i.e. break) BB into the graph even though it will be
unreachable. This m
The algorithm expects the entire CFG to be reachable, so make sure that
we hit every node. Otherwise we will end up with uninitialized data,
memory corruption, etc.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen/nv50_ir_ssa.cpp | 1 +
1 file changed, 1 insertion(+)
diff --gi
On 02.12.2015 07:06, Jose Fonseca wrote:
> On 28/11/15 21:06, Emil Velikov wrote:
>> On 25 November 2015 at 07:20, Jose Fonseca wrote:
>>
>>> BTW, I setup Mesa with Appveyor (like Travis for Windows)
>>>
>>>https://ci.appveyor.com/project/jrfonseca/mesa
>>>
>>> I'll try to get that going and c
SM20-SM50 can't emit a post-factor in the presence of a long immediate.
Make sure to fold it in.
Signed-off-by: Ilia Mirkin
Cc: "11.0 11.1"
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/
On Tue, Dec 1, 2015 at 8:28 PM, Ilia Mirkin wrote:
> On Tue, Dec 1, 2015 at 8:25 PM, Rob Clark wrote:
>> ST_DEBUG=precompile is defn needed.. otherwise *something* (not sure
>> if it is core or mesa-st) decides to not compile things yet..
>
> Actually I don't need it for nouveau, and am fairly su
On Tue, Dec 1, 2015 at 8:25 PM, Rob Clark wrote:
> ST_DEBUG=precompile is defn needed.. otherwise *something* (not sure
> if it is core or mesa-st) decides to not compile things yet..
Actually I don't need it for nouveau, and am fairly sure it's not
needed for radeonsi. You need to expose PIPE_CA
On Tue, Dec 1, 2015 at 8:00 PM, Matt Turner wrote:
> On Tue, Dec 1, 2015 at 4:40 PM, Rob Clark wrote:
>> Simplify the instructions a bit by setting all the potentially needed
>> environment variables in run.c itself.
>>
>> Made very trivially more complex by the fact that all of the gallium
>> dr
On Tue, Dec 1, 2015 at 5:17 PM, Ilia Mirkin wrote:
> On Tue, Dec 1, 2015 at 8:12 PM, Matt Turner wrote:
>> ---
>> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 16 ++--
>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>
On Tue, Dec 1, 2015 at 8:12 PM, Matt Turner wrote:
> ---
> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index 7f58b
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 7f58b44..89ad6cd 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.c
On Tue, Dec 1, 2015 at 4:40 PM, Rob Clark wrote:
> Simplify the instructions a bit by setting all the potentially needed
> environment variables in run.c itself.
>
> Made very trivially more complex by the fact that all of the gallium
> drivers are using u_debug stuff, so one env var contains pote
Simplify the instructions a bit by setting all the potentially needed
environment variables in run.c itself.
Made very trivially more complex by the fact that all of the gallium
drivers are using u_debug stuff, so one env var contains potentially
multiple flags. We don't want to clobber any other
On Tue, Dec 1, 2015 at 11:07 AM, Ian Romanick wrote:
> On 11/30/2015 03:32 PM, Matt Turner wrote:
>> For a select whose condition is any(v), instead of emitting
>>
>>cmp.nz.f0(8)null<1>Dg1<0,4,1>D 0D
>>mov(8) g7<1>.xUD 0xUD
>>(+f0.any4h) mov(8) g
---
I add the true/false variables for clarity since there are some existing
optimizations using ~0 where it actually has nothing to do with true.
I could take it or leave it. We obviously can't use them for feq and
friends. Maybe itrue/ifalse and ftrue/ffalse?
src/glsl/nir/nir_opt_algebraic.py
On Mon, Nov 30, 2015 at 3:32 PM, Matt Turner wrote:
> As in the previous patches, these can be implemented as
>
>any(v) -> any_nequal(v, false)
>all(v) -> all_equal(v, true)
>
> and their removal simplifies the code in the next patch.
> ---
> src/gallium/auxiliary/nir/tgsi_to_nir.c
On Tue, Dec 1, 2015 at 6:26 PM, Samuel Pitoiset
wrote:
> While we are it, apply the same change for Tesla.
Does tesla even have surface ops? I don't see anything in envydis...
Please don't add code that doesn't need to be there.
-ilia
___
mesa-dev ma
On Tue, Dec 1, 2015 at 6:17 PM, Ian Romanick wrote:
> I think even if we add code to st_glsl_to_tgsi to recognize the
> any_nequal(v, false) pattern, it will still be a net reduction on lines
> of code.
That'd be fine with me.
I'm not trying to be difficult... but basically you have 10x the
manp
On Tue, 2015-12-01 at 13:46 +0200, Tapani Pälli wrote:
> On 12/01/2015 02:13 AM, Timothy Arceri wrote:
> > Just because the validation passed the last time is was called
> > doesn't
> > automatically mean it will pass again the next time its called.
>
> This is a rather large hammer though :/ Mayb
On 12/ 1/15 03:07 PM, Jose Fonseca wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=93189
---
configure.ac | 7 +++
1 file changed, 7 insertions(+)
diff --git a/configure.ac b/configure.ac
index 4016871..b6680d0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -197,6 +197,13 @@ if test
On Tue, Dec 1, 2015 at 3:07 PM, Jose Fonseca wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=93189
> ---
> configure.ac | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index 4016871..b6680d0 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@
That texture mask thing doesn't seem to be needed for surface ops, so
just as nve4+, let do that only for texture ops.
This fixes a segfault with 'test_surface_st' from
gallium/tests/trivial/compute.c on Fermi because this test uses sustp.
While we are it, apply the same change for Tesla.
Signed
On 12/01/2015 01:36 PM, Ilia Mirkin wrote:
> On Tue, Dec 1, 2015 at 4:24 PM, Ian Romanick wrote:
>>> So this is the test I came up with:
>>>
>>> FRAG
>>> DCL IN[0], GENERIC[0], PERSPECTIVE
>>> DCL OUT[0], COLOR
>>> DCL TEMP[0..4], LOCAL
>>> IMM[0] UINT32 { 0, 0, 0, 0 }
>>> 0: MOV TEMP[0], IN[0]
>>
Both look good to me. Thanks.
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Dec 1, 2015 at 6:01 PM, Samuel Pitoiset
wrote:
>
>
> On 11/29/2015 04:11 PM, Ilia Mirkin wrote:
>>
>> Under what circumstances can you get into this code and not be a texture
>> op?
>
>
> This only happens with surface ops. In this example, it's related to sustp.
> I don't think we need to
https://bugs.freedesktop.org/show_bug.cgi?id=93189
--- Comment #7 from Jose Fonseca ---
It doesn't make sense to spend time on supporting platforms for which there are
no active developers.
Keeping Mesa compiling across GCC and MSVC is already quite time consuming.
I posted a couple of patches
---
include/c99_compat.h | 6 --
src/gallium/auxiliary/util/u_cpu_detect.c | 10 +-
src/gallium/include/pipe/p_compiler.h | 6 +-
src/gallium/include/pipe/p_config.h | 4
src/glsl/ir_constant_expression.cpp | 8
src/glsl/nir/ni
https://bugs.freedesktop.org/show_bug.cgi?id=93189
---
configure.ac | 7 +++
1 file changed, 7 insertions(+)
diff --git a/configure.ac b/configure.ac
index 4016871..b6680d0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -197,6 +197,13 @@ if test "x$GCC" = xyes -a "x$acv_mesa_CLANG" = xno; th
On 11/29/2015 04:11 PM, Ilia Mirkin wrote:
Under what circumstances can you get into this code and not be a texture op?
This only happens with surface ops. In this example, it's related to
sustp. I don't think we need to add that texture mask for surface ops
because we don't do that for nve
v4:
* Apply similar optimization for shared variable stores as
0cb7d7b4b7c32246d4c4225a1d17d7ff79a7526d. This was causing a
OpenGLES 3.1 CTS failure, but
867c436ca841b4196b4dde4786f5086c76b20dd7 fixes that.
Signed-off-by: Jordan Justen
Cc: Iago Toral Quiroga
---
src/mesa/drivers/dri/i
On 01/12/15 20:52, Eric Anholt wrote:
Since I just broke the scons build, I figured I'd make Travis test that I
don't break it again in the future. The script runs the builds in
parallel across VMs, so it still takes just 5 minutes to turn around
results.
---
.travis.yml | 21 +++--
On 28/11/15 21:06, Emil Velikov wrote:
On 25 November 2015 at 07:20, Jose Fonseca wrote:
BTW, I setup Mesa with Appveyor (like Travis for Windows)
https://ci.appveyor.com/project/jrfonseca/mesa
I'll try to get that going and commited too.
As a person who has broken the Windows build on
AppVeyor doesn't require an appveyor.yml in the repos (in fact it has
some limitations as noted in comments below), but doing so has two great
advantages over the web UI:
- appveyor.yml can be revisioned together with the code, so instructions
should always be in synch with the code
- appveyor.
Same code as nvc0, looks fine.
Reviewed-by: Samuel Pitoiset
On 12/01/2015 09:04 PM, Ilia Mirkin wrote:
There's a post-RA fixup to replace 0's with $r63 (or $r127 if too many
regs are used), so just as nvc0, let an immediate 0 be loaded anywhere.
Signed-off-by: Ilia Mirkin
---
src/gallium/d
On Tue, Dec 1, 2015 at 4:24 PM, Ian Romanick wrote:
>> So this is the test I came up with:
>>
>> FRAG
>> DCL IN[0], GENERIC[0], PERSPECTIVE
>> DCL OUT[0], COLOR
>> DCL TEMP[0..4], LOCAL
>> IMM[0] UINT32 { 0, 0, 0, 0 }
>> 0: MOV TEMP[0], IN[0]
>> 1: USNE TEMP[0], TEMP[0], IMM[0]
>> 2: OR TEMP[0].x,
On Tue, Dec 1, 2015 at 4:24 PM, Ian Romanick wrote:
>> which ends up in:
>>
>> EMIT: mov u32 $r4 0x (8)
>> EMIT: set u32 $r1 ne $r1 $r4 (8)
>> EMIT: set u32 $r2 ne $r2 $r4 (8)
>> EMIT: set u32 $r3 ne $r3 $r4 (8)
>> EMIT: set u32 $r0 ne $r0 $r4 (8)
>> EMIT: or u32 $r1 $r1 $r2 (8)
>> EMIT: o
On 12/01/2015 11:28 AM, Ilia Mirkin wrote:
> On Tue, Dec 1, 2015 at 2:13 PM, Ian Romanick wrote:
>> On 11/30/2015 04:41 PM, Ilia Mirkin wrote:
>>> On Mon, Nov 30, 2015 at 7:15 PM, Matt Turner wrote:
On Mon, Nov 30, 2015 at 3:51 PM, Ilia Mirkin wrote:
> On Mon, Nov 30, 2015 at 6:38 PM, M
https://bugs.freedesktop.org/show_bug.cgi?id=92757
--- Comment #3 from Steinar H. Gunderson ---
Created attachment 120238
--> https://bugs.freedesktop.org/attachment.cgi?id=120238&action=edit
Suggested patch
Hi,
I think the included patch should resolve the problem. I've run with a variant
of
On 12/01/2015 12:04 PM, Brian Paul wrote:
> String literals cannot exceed 65535 characters for MSVC. Instead of
> emiting a string, emit an array of characters.
> ---
> src/mapi/glapi/gen/gl_enums.py | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/src/mapi/glapi
On 2015-12-01 04:45:05, Iago Toral wrote:
> On Tue, 2015-12-01 at 00:19 -0800, Jordan Justen wrote:
> > Signed-off-by: Jordan Justen
> > ---
> > src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 52
> >
> > 1 file changed, 52 insertions(+)
> >
> > diff --git a/src/mesa
Since I just broke the scons build, I figured I'd make Travis test that I
don't break it again in the future. The script runs the builds in
parallel across VMs, so it still takes just 5 minutes to turn around
results.
---
.travis.yml | 21 +++--
1 file changed, 15 insertions(+), 6
Brian Paul writes:
> String literals cannot exceed 65535 characters for MSVC. Instead of
> emiting a string, emit an array of characters.
> ---
> src/mapi/glapi/gen/gl_enums.py | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/src/mapi/glapi/gen/gl_enums.py b/src
On 1 December 2015 at 20:46, Marek Olšák wrote:
> Did the alternative workaround (reserving one SIMD as PS only) not work?
>
Well fglrx was doing this, so I decided to not diverge from that.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.or
Brian Paul writes:
> The commit "mesa: Switch to using the Khronos registry for generating
> enums." updated Makefile.am but no the SConscript file.
I just pushed a fix for this and hopefully the Android.mk at the same
time. I'm working on a Travis build for scons as penance.
signature.asc
De
On Tue, Dec 01, 2015 at 10:44:43AM -0800, Nanley Chery wrote:
From: Nanley Chery
Commit a16ffb743ced9fde80b2485dfc2d86ae74e86f25, which introduced
gl_extensions::Version, updates the field when the context version
is computed and when entering/exiting meta. Update this field when
the version is o
https://bugs.freedesktop.org/show_bug.cgi?id=93189
--- Comment #6 from Matt Turner ---
The point of the ternary magic is to make the macros typeless, like gcc's
atomic ops built-ins
(https://gcc.gnu.org/onlinedocs/gcc-4.4.5/gcc/Atomic-Builtins.html)
The problem is that a bunch of them have to re
There's a post-RA fixup to replace 0's with $r63 (or $r127 if too many
regs are used), so just as nvc0, let an immediate 0 be loaded anywhere.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/
The commit "mesa: Switch to using the Khronos registry for generating
enums." updated Makefile.am but no the SConscript file.
---
src/mapi/glapi/gen/SConscript | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mapi/glapi/gen/SConscript b/src/mapi/glapi/gen/SConscript
index b9
String literals cannot exceed 65535 characters for MSVC. Instead of
emiting a string, emit an array of characters.
---
src/mapi/glapi/gen/gl_enums.py | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/mapi/glapi/gen/gl_enums.py b/src/mapi/glapi/gen/gl_enums.py
index
Hi Eric,
enums.c no longer compiles on MSVC because the enum_string_table[]
string literal is too long. The MSVC limit is 65535 chars.
The ugly work-around is to generate an array of characters:
LONGSTRING static const char enum_string_table[] = {
'G', 'L', '_', 'N', 'O', '_', 'E', 'R', 'R',
Am 01.12.2015 um 20:35 schrieb Brian Paul:
> On 12/01/2015 12:07 PM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> These are implementation-dependent queries, but so far we just
>> returned the
>> value of whatever the current provoking vertex convention was set to,
>> which
>> was c
https://bugs.freedesktop.org/show_bug.cgi?id=93189
--- Comment #5 from Ian Romanick ---
(In reply to Jose Fonseca from comment #2)
> Vinson, Alan,
>
>
> If Oracle itself has no interest on building Mesa with Solaris Sudio
> component, let's save everybody's time by making that dependency crysta
As I recall, I wanted to fix the piglits when doing GS or
ARB_viewport_array for nv50. I believe Ian shot it down. This was ~1-2
years ago, so I don't remember the specifics.
-ilia
On Tue, Dec 1, 2015 at 2:37 PM, Roland Scheidegger wrote:
> Thinking about this, are there really apps out there
Thinking about this, are there really apps out there which get it wrong?
piglits can be fixed easily.
If some app did that seemingly wrong, it might have been due to the
bogus query. That is, if it switched to first provoking vertex
convention, then asked for the provoking vertex layer, it would ha
On 12/01/2015 12:07 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
These are implementation-dependent queries, but so far we just returned the
value of whatever the current provoking vertex convention was set to, which
was clearly wrong.
Just make this a variable in the context constant
s/Don't disallow/Allow/ reads much, much better. The original wording
made my head hurt. :)
On 11/19/2015 07:25 AM, Neil Roberts wrote:
> Previously fast clear was disallowed on Gen9 for MSRTs with the claim
> that some formats don't work but we didn't understand why. On further
> investigation i
On Tue, Dec 1, 2015 at 2:13 PM, Ian Romanick wrote:
> On 11/30/2015 04:41 PM, Ilia Mirkin wrote:
>> On Mon, Nov 30, 2015 at 7:15 PM, Matt Turner wrote:
>>> On Mon, Nov 30, 2015 at 3:51 PM, Ilia Mirkin wrote:
On Mon, Nov 30, 2015 at 6:38 PM, Matt Turner wrote:
> On Mon, Nov 30, 2015 at
The series is
Reviewed-by: Ian Romanick
Patch 1 could probably land right away, but the others should probably
wait until Ilia relaxes his objection.
I'd really like to have Ken or Jason also review patch 6.
On 11/30/2015 03:32 PM, Matt Turner wrote:
> To make it match unop().
> ---
> src/gls
On 11/30/2015 04:41 PM, Ilia Mirkin wrote:
> On Mon, Nov 30, 2015 at 7:15 PM, Matt Turner wrote:
>> On Mon, Nov 30, 2015 at 3:51 PM, Ilia Mirkin wrote:
>>> On Mon, Nov 30, 2015 at 6:38 PM, Matt Turner wrote:
On Mon, Nov 30, 2015 at 3:34 PM, Ilia Mirkin wrote:
> On Mon, Nov 30, 2015 at
On 11/30/2015 03:32 PM, Matt Turner wrote:
> For a select whose condition is any(v), instead of emitting
>
>cmp.nz.f0(8)null<1>Dg1<0,4,1>D 0D
>mov(8) g7<1>.xUD 0xUD
>(+f0.any4h) mov(8) g7<1>.xUD0xUD
>cmp.nz.f0(8)null<1>D
From: Roland Scheidegger
These are implementation-dependent queries, but so far we just returned the
value of whatever the current provoking vertex convention was set to, which
was clearly wrong.
Just make this a variable in the context constants like for other things
which are implementation dep
https://bugs.freedesktop.org/show_bug.cgi?id=36651
Emil Velikov changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
On 11/30/2015 03:51 PM, Ilia Mirkin wrote:
> On Mon, Nov 30, 2015 at 6:38 PM, Matt Turner wrote:
>> On Mon, Nov 30, 2015 at 3:34 PM, Ilia Mirkin wrote:
>>> On Mon, Nov 30, 2015 at 6:32 PM, Matt Turner wrote:
---
src/glsl/builtin_functions.cpp | 15 ++-
1 file changed,
On 12/01/2015 06:49 AM, Marta Lofstedt wrote:
> From: Marta Lofstedt
>
> This adds glsl support of GL_OES_geometry_shader for
> OpenGL ES 3.1.
>
> Signed-off-by: Marta Lofstedt
> ---
> src/glsl/builtin_variables.cpp | 25 +
> src/glsl/glsl_parser.yy | 4 ++--
>
I don't think that will work with draw (can't see why it would), and
don't plan on fixing it (at least not now).
In d3d10, this of course would work (at least if you emit the layer per
prim), because it requires the layer info to be taken from the provoking
(first) vertex. But that doesn't seem to
From: Nanley Chery
Commit a16ffb743ced9fde80b2485dfc2d86ae74e86f25, which introduced
gl_extensions::Version, updates the field when the context version
is computed and when entering/exiting meta. Update this field when
the version is overridden as well.
Cc: Marta Lofstedt
Cc: Emil Velikov
Sign
Irrespective of any spec lawyering you might do, we have some piglit
tests which basically assume that things like
gl_Layer = foo;
gl_Position = ...
EmitVertex();
gl_Position = ...
EmitVertex();
will always work. I believe this was based on the theory that some
applications actually do this, alth
https://bugs.freedesktop.org/show_bug.cgi?id=36651
Alex Perez changed:
What|Removed |Added
Status|VERIFIED|REOPENED
Resolution|FIXED
On Tue, Dec 01, 2015 at 04:41:22PM +, Emil Velikov wrote:
> On 1 December 2015 at 16:03, Lofstedt, Marta wrote:
>
> >> > > - return _mesa_is_desktop_gl(ctx) && ctx->Version >= 32;
> >> > > + return (_mesa_is_gles31(ctx) &&
> >> > > + ctx->Extensions.OES_geometry_shader) ||
> >> >
> >> > P
On Tue, Dec 1, 2015 at 7:49 AM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> Updates the _mesa_has_geometry_shaders function to also look
> for OpenGL ES 3.1 contexts that has OES_geometry_shader enabled.
> ---
> src/mesa/main/context.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(
That's interesting.
Some d3d10 docs list this indeed as 15+1 (and that +1 is really needed
too for the immediates, as you can have indirectly addressed immediates
which are little more than ordinary uniforms for the hw).
So does d3d11:
https://msdn.microsoft.com/en-us/library/windows/desktop/ff8190
On Tue, Dec 01, 2015 at 05:27:19PM +, Neil Roberts wrote:
> "Pohjolainen, Topi" writes:
>
> >> + /* Handle linear???SRGB conversion */
> >> + if (brw->ctx.Color.sRGBEnabled &&
> >> + _mesa_get_srgb_format_linear(mt->format) != mt->format) {
> >
> > Patch five disables fast clear for
On Tue, Dec 01, 2015 at 04:03:22PM +, Lofstedt, Marta wrote:
> > -Original Message-
> > From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> > Behalf Of Lofstedt, Marta
> > Sent: Tuesday, December 1, 2015 4:48 PM
> > To: Emil Velikov; Marta Lofstedt
> > Cc: ML mesa-dev
>
On 12/01/2015 10:43 AM, Roland Scheidegger wrote:
Trying to fix some draw bugs with layer/vp outputs (and clipping), I was
wondering if GL actually guarantees sane results if the layer/vp index
isn't the same on all vertices. And sure it seems it does, albeit it's
implementation-dependent. Specif
On 11/30/2015 05:50 PM, Ian Romanick wrote:
On 11/25/2015 07:10 PM, Eric Anholt wrote:
GL_ALL_ATTRIB_BITS is a thing, and GL_CLIENT_ALL_ATTRIB_BITS, but I don't
see GL_ALL_CLIENT_ATTRIB_BITS in my grepping of khronos XML, GL extension
specs, GL 1.1, GL 2.2, and GL 4.4.
Hm... it is in include/G
Trying to fix some draw bugs with layer/vp outputs (and clipping), I was
wondering if GL actually guarantees sane results if the layer/vp index
isn't the same on all vertices. And sure it seems it does, albeit it's
implementation-dependent. Specifically (from gl 4.4 core, page 388)
"viewport index
"Pohjolainen, Topi" writes:
>> + /* Handle linear→SRGB conversion */
>> + if (brw->ctx.Color.sRGBEnabled &&
>> + _mesa_get_srgb_format_linear(mt->format) != mt->format) {
>
> Patch five disables fast clear for single-sampled if
> brw->ctx.Color.sRGBEnabled is set. How about something li
On Wed, Nov 25, 2015 at 06:23:01PM +0100, Neil Roberts wrote:
> If GL_FRAMEBUFFER_SRGB is enabled when writing to an SRGB-capable
> framebuffer then the color will be converted from linear to SRGB
> before being written. There is no chance for the hardware to do this
> itself because it can't modif
On 30 November 2015 at 22:06, Dave Airlie wrote:
> On 1 December 2015 at 07:18, Emil Velikov wrote:
>> On 30 November 2015 at 20:00, Ian Romanick wrote:
>>> On 11/29/2015 07:21 AM, Emil Velikov wrote:
Hi Giuseppe,
On 28 November 2015 at 15:43, Giuseppe Bilotta
wrote:
> T
On 30 November 2015 at 17:50, Tom Stellard wrote:
> When probing for devices, clover will call pipe_loader_probe() twice.
> The first time to retrieve the number of devices, and then second time
> to retrieve the device structures.
>
> We currently assume that the return value of both calls will b
Hi Jonathan,
On 23 November 2015 at 03:24, Jonathan Gray wrote:
> Use PKG_CHECK_MODULES to get the flags to link libelf.
>
> Signed-off-by: Jonathan Gray
> Cc: "11.0 11.1"
> ---
> configure.ac | 4 +---
> src/gallium/drivers/radeon/Makefile.am | 2 +-
> src/gallium/ta
On 23 November 2015 at 03:22, Jonathan Gray wrote:
> Correct some occurrences of -ldl and -lpthread to use
> $(DLOPEN_LIBS) and $(PTHREAD_LIBS) respectively.
>
> Signed-off-by: Jonathan Gray
> Cc: "11.0 11.1"
> ---
> src/gallium/targets/opencl/Makefile.am | 2 +-
> src/mesa/drivers/dri/i965/Mak
On Wed, Nov 25, 2015 at 06:36:37PM +0100, Neil Roberts wrote:
> SKL can't cope with the CCS buffer for SRGB buffers. Normally the
> hardware won't see the SRGB formats because when GL_FRAMEBUFFER_SRGB
> is disabled these get mapped to their linear equivalents. In order to
> avoid relying on the CCS
On 1 December 2015 at 16:03, Lofstedt, Marta wrote:
>> > > - return _mesa_is_desktop_gl(ctx) && ctx->Version >= 32;
>> > > + return (_mesa_is_gles31(ctx) &&
>> > > + ctx->Extensions.OES_geometry_shader) ||
>> >
>> > Please use the new _mesa_has_##name_str helpers from Nanley. They
>> > alread
On Tue, Dec 1, 2015 at 11:24 AM, Lofstedt, Marta
wrote:
>> > +static const int extra_ARB_viewport_array_or_geometry_shader[] = {
>> > + EXT(ARB_viewport_array),
>> > + EXT(OES_geometry_shader),
>> > + EXTRA_END
>> > +};
>>
>> This won't do what you want... unless drivers only ever set
>> OES
> -Original Message-
> From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of Ilia
> Mirkin
> Sent: Tuesday, December 1, 2015 4:53 PM
> To: Marta Lofstedt
> Cc: mesa-dev@lists.freedesktop.org; Lofstedt, Marta
> Subject: Re: [PATCH v3] mesa: enable enums for OES_geometry_shader
https://bugs.freedesktop.org/show_bug.cgi?id=93189
--- Comment #3 from Alan Coopersmith ---
There was interest in the past, but trying to keep up is too hard and the
benefit too small, so we've just given up and build Mesa with gcc now.
--
You are receiving this mail because:
You are the QA Con
https://bugs.freedesktop.org/show_bug.cgi?id=93189
--- Comment #4 from Alan Coopersmith ---
(In reply to Jose Fonseca from comment #2)
> Anybody knows a reliable way to detect Solaris CC on configure.ac?
Whoops, missed this part. It's easy - autoconf will set $GCC to "no".
A more definitive wa
1 - 100 of 190 matches
Mail list logo
