On Friday 03 January 2014, Marek Olšák wrote:
> On Fri, Jan 3, 2014 at 2:04 PM, Marek Olšák wrote:
> > On Fri, Jan 3, 2014 at 1:27 AM, Maxence Le Doré
> > wrote:
> >> ---
> >> src/mesa/main/texobj.c | 52
> >> ++
> >> src/mesa/main/texobj.h | 3 +
Fixes a bug where then branch operates with ivec4 while else uses vec4.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72379
Signed-off-by: Tapani Pälli
---
src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i
Not sure this is 100% the correct way to do this, since it may be a change
at the glsl->tgsi level that is required, either way open discussions!
fixes piglit tests/spec/glsl-1.50/execution/geometry/primitive-id-in.shader_test
with llvmpipe with fake MSAA
Signed-off-by: Dave Airlie
---
src/gall
On Tue, 7 Jan 2014 00:22:08 +0100
Marek Olšák wrote:
> Is the logging really needed apart from initial debugging and
> validation of the code? I don't see a reason to have this in master.
Yes, it's there to allow users to submit traces, which then means much
better coverage (private apps, commer
On Tue, 7 Jan 2014 01:44:28 +0100
Marek Olšák wrote:
> On Mon, Jan 6, 2014 at 12:17 PM, Lauri Kasanen wrote:
> > These will be used later on for optimizing the VRAM placement.
> >
> > No measurable overhead (glxgears).
>
> I recommend testing torcs (the Forza track) next time. glxgears is not
>
Commit 9119269ca14ed42b51c7d8e2e662500311b29fa3 moved the texel
buffer allocation to _swrast_texture_span(), however, when compiled
with OpenMP support this code already runs multi-threaded so a
critical section is required to prevent multiple allocations and
rendering errors.
---
src/mesa/swrast/
Hi,
This patch fixes a bug in swrast OpenMP code which was introduced with the
delayed buffer allocation. It caused rendering errors and a memory leak.
Andreas Fänger (1):
swrast: fix delayed texel buffer allocation regression for OpenMP
src/mesa/swrast/s_texcombine.c | 12
1
https://bugs.freedesktop.org/show_bug.cgi?id=69101
--- Comment #12 from Alexander Mezin ---
I see only comments about intel+radeon here.
It would be interesting to know if there are same problems with intel+nouveau
or radeon+radeon
--
You are receiving this mail because:
You are the assignee fo
On Tue, Jan 7, 2014 at 11:14 AM, Lauri Kasanen wrote:
> On Tue, 7 Jan 2014 01:44:28 +0100
> Marek Olšák wrote:
>
>> On Mon, Jan 6, 2014 at 12:17 PM, Lauri Kasanen wrote:
>> > These will be used later on for optimizing the VRAM placement.
>> >
>> > No measurable overhead (glxgears).
>>
>> I recom
On 6 January 2014 17:05, Chad Versace wrote:
> In solving a HiZ hang before Christmas vacation, I discovered that Mesa
> wasn't
> emitting sufficient workaround flushes. That bug was solved in commit
> 1a92881.
>
> This series, prompted by Ken, adds some more carefully placed flushes to
> pre-em
On 6 January 2014 17:05, Chad Versace wrote:
> Set brw->need_workaround_flush immediately after each 3D_CMD_PRIM. This
> may prevent undiscovered difficult-to-diagnose gpu hangs, according to
> Ken.
>
> The art of emitting workaround flushes on Sandybridge is mysterious and
> not fully understood
On 6 January 2014 17:05, Chad Versace wrote:
> Unconditionally set brw->need_workaround_flush at the top of gen6 blorp
> state emission. This is an extra safety measure to prevent undiscovered
> difficult-to-diagnose gpu hangs.
>
> The art of emitting workaround flushes on Sandybridge is mysterio
https://bugs.freedesktop.org/show_bug.cgi?id=69101
--- Comment #13 from Armin K ---
(In reply to comment #5)
> > And without DRI_PRIME=1 everything works everywhere, with or without
> > compositing, windowed or fullscreen.
>
> I would imagine this is because you're not offloading anything at tha
On 6 January 2014 17:05, Chad Versace wrote:
> Commit 1a92881 added extra flushes to fix a HiZ hang in
> WebGL Google Maps. With the extra flushes emitted by the previous two
> patches, the flushes added by 1a92881 are redundant.
>
> Tested with the same criteria as in 1a92881: by zooming in and
https://bugs.freedesktop.org/show_bug.cgi?id=69101
--- Comment #14 from Alex Deucher ---
Prime only works with compositing, so you have to have compositing enabled.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev
On 01/06/2014 05:22 PM, Erik Faye-Lund wrote:
On Tue, Jan 7, 2014 at 12:12 AM, Brian Paul wrote:
Evidently, there's some other definition of "min" and "max" that
causes MSVC to choke on these function names. Renaming to min2()
and max2() fixes things.
Wouldn't it be easier to just make sure
On 01/07/2014 03:10 AM, Andreas Fänger wrote:
Commit 9119269ca14ed42b51c7d8e2e662500311b29fa3 moved the texel
buffer allocation to _swrast_texture_span(), however, when compiled
with OpenMP support this code already runs multi-threaded so a
critical section is required to prevent multiple allocat
On Tue, Jan 7, 2014 at 3:59 PM, Brian Paul wrote:
> On 01/06/2014 05:22 PM, Erik Faye-Lund wrote:
>>
>> On Tue, Jan 7, 2014 at 12:12 AM, Brian Paul wrote:
>>>
>>> Evidently, there's some other definition of "min" and "max" that
>>> causes MSVC to choke on these function names. Renaming to min2()
https://bugs.freedesktop.org/show_bug.cgi?id=69101
--- Comment #15 from Jan Vesely ---
(In reply to comment #12)
> I see only comments about intel+radeon here.
> It would be interesting to know if there are same problems with
> intel+nouveau or radeon+radeon
On my nvd9 + snb (gnome3):
glxgears w
https://bugs.freedesktop.org/show_bug.cgi?id=69101
--- Comment #16 from Mike Lothian ---
If you're running the lastest verion of Heaven or running Valley on drivers
that don't yet have OpenGL 3.2 it'll fail to render (SNB doesn't) - try passing
MESA_GL_VERSION_OVERRIDE=3.2 MESA_GLSL_VERSION_OVERR
On 01/07/2014 08:03 AM, Erik Faye-Lund wrote:
On Tue, Jan 7, 2014 at 3:59 PM, Brian Paul wrote:
On 01/06/2014 05:22 PM, Erik Faye-Lund wrote:
On Tue, Jan 7, 2014 at 12:12 AM, Brian Paul wrote:
Evidently, there's some other definition of "min" and "max" that
causes MSVC to choke on these fu
On 01/07/2014 12:49 AM, Fredrik Höglund wrote:
Maxence, while I think it's great that you're interested in working
on this extension, I'm afraid I have another implementation in
a branch in my mesa tree:
https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/~fredrik/mesa/log/?h%
- Original Message -
> On Tue, Jan 7, 2014 at 3:59 PM, Brian Paul wrote:
> > On 01/06/2014 05:22 PM, Erik Faye-Lund wrote:
> >>
> >> On Tue, Jan 7, 2014 at 12:12 AM, Brian Paul wrote:
> >>>
> >>> Evidently, there's some other definition of "min" and "max" that
> >>> causes MSVC to choke o
>From section 4.4.4 (Framebuffer Completeness) of the GL 3.2 spec:
If any framebuffer attachment is layered, all populated
attachments must be layered. Additionally, all populated color
attachments must be from textures of the same target.
We weren't checking that the attachments were
Previously, Mesa enforced the following rule (from
ARB_geometry_shader4's list of criteria for framebuffer completeness):
* If any framebuffer attachment is layered, all attachments must have
the same layer count. For three-dimensional textures, the layer count
is the depth of the attac
On Tue, Jan 7, 2014 at 4:11 PM, Brian Paul wrote:
> On 01/07/2014 08:03 AM, Erik Faye-Lund wrote:
>> Why was this pushed out prematurely, then? Reviewing within two hours
>> seems to be reasonable, no?
>
>
> I got Kenneth's R-b so I pushed it. I saw no reason to wait. Also, I don't
> like build
We have talked on IRC meanwhile:
"Everywhere" was supposed to mean file names and data structures.
I have made a patch series (git link because file renames produce huge
diffs) that renames *everything* away from r600 (and also radeonsi)
to si, where it is actually about SI. In the such modified c
You are absolutly right. I followed the way specification illustrate
implementation for simplicity reasons but had always in mind that this
was not the way to get any performance
benefit and hoped that I are somebody else could improve this later.
That's a great thing you already did this and don't
This packed floating point format only stores positive values.
---
src/mesa/main/formats.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index eb2a07e..7e0ec23 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/f
Don't worry to much about history keeping, anybody who really needs that
should be capable of digging that up anyway.
I would just squash together the changes "Apply si_ file naming scheme
in src/gallium/drive…" and "Fix up file renaming: change file names in
commen…". Also please change the s
If a channel has zero bits it's not signed.
---
src/mesa/main/get.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index c45a8d1..bb138c8 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -76
Thanks Fredrik,
I was nearly sure this was ok from what I read of the specs. And
you're also right again : I totally forget a case where a texture has
never been bound !
2014/1/7 Maxence Le Doré :
> Thanks Fredrik,
> I was nearly sure this was ok from what I read of the specs. And
> you're also ri
I agree with everything except these two:
"Rename the commonly occurring rctx/r600 to now more suitable sctx."
"Rename the commonly occurring rscreen to now more suitable sscreen."
It's too much for my eye to handle.
Marek
On Tue, Jan 7, 2014 at 5:27 PM, Andreas Hartmetz wrote:
> We have talke
Reviewed-by: Marek Olšák
Marek
On Tue, Jan 7, 2014 at 5:35 PM, Brian Paul wrote:
> This packed floating point format only stores positive values.
> ---
> src/mesa/main/formats.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/formats.c b/src/mesa/
On Tue, Jan 7, 2014 at 5:37 PM, Christian König wrote:
> Don't worry to much about history keeping, anybody who really needs that
> should be capable of digging that up anyway.
>
> I would just squash together the changes "Apply si_ file naming scheme in
> src/gallium/drive…" and "Fix up file rena
Thanks Ian, I got this after a rebase. Didn't know were it comes from.
2014/1/6 Ian Romanick :
> On 01/02/2014 05:18 PM, Maxence Le Doré wrote:
>> ---
>> src/mesa/drivers/dri/i915/i830_state.c | 12
>> src/mesa/drivers/dri/i965/brw_util.c | 24 +---
>> 2 files c
On Tuesday 07 January 2014 17:37:07 Christian König wrote:
> Don't worry to much about history keeping, anybody who really needs that
> should be capable of digging that up anyway.
>
> I would just squash together the changes "Apply si_ file naming scheme
> in src/gallium/drive…" and "Fix up file
Indeed, this patch compiles on linux but may break complilation at
least on MSVC version < 1400.
I'm planing to install visual studio 2005 on a ms xp or seven virtual
machine to check the behavior when compiling in microsoft windows
environment.
2014/1/6 Erik Faye-Lund :
> On Sun, Jan 5, 2014 at 1
Do you think it's too much change in general or that the patches are
too large? They were honestly simple find / sed jobs, so I could fairly
easily redo them file by file.
I'm not sure how to even argue about that, but I think suitable names
are very important. rctx goes as "mysterious name" /
"his
Thanks Brian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
v2: Moved the high priority check to r600_texture_create_object
Signed-off-by: Lauri Kasanen
---
src/gallium/drivers/r600/r600_state_common.c| 2 +-
src/gallium/drivers/radeon/r600_buffer_common.c | 6 --
src/gallium/drivers/radeon/r600_pipe_common.h | 3 ++-
src/gallium/drivers/radeon
No measurable overhead when off (glxgears within 0.5%).
v2: Cosmetic changes.
v3: Moved file handling into winsys
Signed-off-by: Lauri Kasanen
---
src/gallium/drivers/radeon/r600_pipe_common.c | 5
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
src/gallium/winsys/radeon/drm
These will be used later on for optimizing the VRAM placement.
No measurable overhead (glxgears, torcs).
v2: Get accurate stats by taking dirty_masks into account
Marek: I'm not sure I was testing torcs right; I started a race on Forza, drove
around, and looked at the fps. Doesn't seem to do ti
v2: Move to a timing thread to minimize overhead.
Signed-off-by: Lauri Kasanen
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 25 +++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.h | 10 +
2 files changed, 35 insertions(+)
diff --git a/src/gallium/winsys/
For this reason, GLSL 4.0 introduces the 'precise' qualifier. I invite
you to take a look at this article.
2014/1/6 Roland Scheidegger :
> Am 05.01.2014 01:34, schrieb Maxence Le Doré:
>> FMA(a,b,c) keeps extra precision (usually 1 more bit of mantissa,
>> afaik) for the result a*b and add this to
I forgot the link :
http://www.geeks3d.com/20120106/precise-qualifier-in-glsl-and-nvidia-geforce-cards/
2014/1/7 Maxence Le Doré :
> For this reason, GLSL 4.0 introduces the 'precise' qualifier. I invite
> you to take a look at this article.
>
> 2014/1/6 Roland Scheidegger :
>> Am 05.01.2014 01:3
Well we were using a system value for prim id in gs, hence this was not
necessary. I'm always confused though about system value / normal
semantic usage though, Zack might know better.
Roland
Am 07.01.2014 09:55, schrieb Dave Airlie:
> Not sure this is 100% the correct way to do this, since it ma
Am 07.01.2014 17:35, schrieb Brian Paul:
> If a channel has zero bits it's not signed.
> ---
> src/mesa/main/get.c | 28 +---
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
> index c45a8d1..bb138c8 100644
> -
On Tue, Jan 07, 2014 at 05:41:56AM -0800, Paul Berry wrote:
> On 6 January 2014 17:05, Chad Versace wrote:
>
> In solving a HiZ hang before Christmas vacation, I discovered that Mesa
> wasn't
> emitting sufficient workaround flushes. That bug was solved in commit
> 1a92881.
>
>
Yes that is certainly related. I'm actually not entirely sure what is
allowed in glsl by default as OpenGL seems to have some lax rules
regarding precision in any case (float calculations not required but
allowed to use denorms, at least earlier versions weren't required to
support Infs neither and
On Tue, Jan 7, 2014 at 6:46 PM, Maxence Le Doré
wrote:
> Indeed, this patch compiles on linux but may break complilation at
> least on MSVC version < 1400.
> I'm planing to install visual studio 2005 on a ms xp or seven virtual
> machine to check the behavior when compiling in microsoft windows
>
https://bugs.freedesktop.org/show_bug.cgi?id=73371
Priority: medium
Bug ID: 73371
Assignee: mesa-dev@lists.freedesktop.org
Summary: EGL_NOK_texture_from_pixmap is advertised but not
properly set.
Severity: normal
Classifi
https://bugs.freedesktop.org/show_bug.cgi?id=73371
Gustavo Sverzut Barbieri changed:
What|Removed |Added
CC||barbi...@gmail.com
--
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=73371
Gustavo Sverzut Barbieri changed:
What|Removed |Added
CC||ras...@rasterman.com
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=73371
Gustavo Sverzut Barbieri changed:
What|Removed |Added
URL||https://git.enlightenment.o
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=73371
Iván Briano changed:
What|Removed |Added
CC||sachi...@gmail.com
--- Comment #1 from Ivá
On 01/07/2014 08:35 AM, Brian Paul wrote:
> If a channel has zero bits it's not signed.
> ---
> src/mesa/main/get.c | 28 +---
> 1 file changed, 21 insertions(+), 7 deletions(-)
Series is:
Reviewed-by: Kenneth Graunke
___
mes
Very nice. I originally thought about conditionnaly defining a fmaf
for MSVC < 1400 like Cygwin and opensource apple code, but I think
this is pushing the problem to later, with double fma(double), that
will be required with ARB_gpu_shader_fp64 : In that case, we'll have
to use long doubles (80 bit
On Tue, Jan 7, 2014 at 12:25 AM, Tapani Pälli wrote:
> Fixes a bug where then branch operates with ivec4 while else uses vec4.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72379
>
> Signed-off-by: Tapani Pälli
> ---
> src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp | 6 ++
>
FYI, Evergreen has dedicated instructions for both MAD and FMA. FMA
seems to be available on DX11 chips only.
Marek
On Tue, Jan 7, 2014 at 8:20 PM, Roland Scheidegger wrote:
> Yes that is certainly related. I'm actually not entirely sure what is
> allowed in glsl by default as OpenGL seems to ha
From: Marek Olšák
Copied from the i965 driver, including the big comment.
Cc: 9.2 10.0
---
src/mesa/state_tracker/st_cb_blit.c | 32
1 file changed, 32 insertions(+)
diff --git a/src/mesa/state_tracker/st_cb_blit.c
b/src/mesa/state_tracker/st_cb_blit.c
index
---
common.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common.py b/common.py
index 1d618e6..22c1725 100644
--- a/common.py
+++ b/common.py
@@ -100,4 +100,4 @@ def AddOptions(opts):
opts.Add(BoolOption('quiet', 'DEPRECATED: profile build', 'yes'))
opts.Add(Bool
---
common.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common.py b/common.py
index 1d618e6..22c1725 100644
--- a/common.py
+++ b/common.py
@@ -100,4 +100,4 @@ def AddOptions(opts):
opts.Add(BoolOption('quiet', 'DEPRECATED: profile build', 'yes'))
opts.Add
This fixes the following compile error:
src\glsl\ir_constant_expression.cpp(1405) : error C2666: 'copysign' : 3
overloads have similar conversions
---
src/glsl/ir_constant_expression.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/ir_constant_expression.cpp
b/src
MSVC 2013 version of math.h includes an fma() function.
---
src/glsl/builtin_functions.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index 10127f3..b3e407a 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/sr
This small rearrangement avoids MSVC 2013 ICE. Also, this should be a better
memory access order.
---
src/gallium/drivers/softpipe/sp_quad_blend.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_quad_blend.c
b/src/gallium/drivers/softpipe/
On 01/07/2014 01:31 PM, Thomas Sondergaard wrote:
---
common.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common.py b/common.py
index 1d618e6..22c1725 100644
--- a/common.py
+++ b/common.py
@@ -100,4 +100,4 @@ def AddOptions(opts):
opts.Add(BoolOption('quiet',
On 2014-01-07 22:37, Brian Paul wrote:
On 01/07/2014 01:31 PM, Thomas Sondergaard wrote:
---
common.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common.py b/common.py
index 1d618e6..22c1725 100644
--- a/common.py
+++ b/common.py
@@ -100,4 +100,4 @@ def AddOptions(opt
On 01/07/2014 12:31 PM, Thomas Sondergaard wrote:
> This small rearrangement avoids MSVC 2013 ICE. Also, this should be a better
> memory access order.
Can you explain this better? As far as I can tell, this just changes
the order the indices are visited (and has a spurious, incorrect
whitespace
In my early preparations for working on compute shaders, I've run into
some stumbling blocks due to the way the GLSL compiler keeps track of
which pipeline stage a given shader is being compiled for.
In some places, it uses a GLenum to store values like
GL_VERTEX_SHADER, GL_GEOMETRY_SHADER, or GL_
---
src/glsl/glsl_parser_extras.cpp| 29 -
src/glsl/glsl_parser_extras.h | 3 ---
src/mesa/main/uniform_query.cpp| 2 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +-
4 files changed, 2 insertions(+), 34 deletions(-)
diff --
---
src/glsl/lower_clip_distance.cpp | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/glsl/lower_clip_distance.cpp b/src/glsl/lower_clip_distance.cpp
index bb4f6ab..2d6138d 100644
--- a/src/glsl/lower_clip_distance.cpp
+++ b/src/glsl/lower_clip_distance.cpp
---
src/glsl/link_varyings.cpp | 48 +++---
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index da97e9f..eefd725 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cp
Previously, we had an enum called gl_shader_type which represented
pipeline stages in the order they occur in the pipeline
(i.e. MESA_SHADER_VERTEX=0, MESA_SHADER_GEOMETRY=1, etc), and several
inconsistently named functions for converting between it and other
representations:
- _mesa_shader_type_t
---
src/glsl/glsl_parser_extras.cpp | 12 +---
src/glsl/glsl_parser_extras.h| 2 +-
src/glsl/main.cpp| 2 +-
src/glsl/test_optpass.cpp| 2 +-
src/glsl/tests/builtin_variable_test.cpp | 2 +-
src/mesa/main/ff_fragment_shader.c
---
src/glsl/ir.h | 2 +-
src/glsl/ir_set_program_inouts.cpp | 29 +++--
src/mesa/drivers/dri/i965/brw_shader.cpp | 2 +-
src/mesa/program/ir_to_mesa.cpp| 2 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +-
5 files
This reduces confusion since gl_shader::Type is sometimes
GL_SHADER_PROGRAM_MESA but is more frequently
GL_SHADER_{VERTEX,GEOMETRY,FRAGMENT}. It also has the advantage that
when switching on gl_shader::Stage, the compiler will alert if one of
the possible enum types is unhandled. Finally, many fu
Hi Marek,
Since it seems no one else have any comments on this, maybe you could
commit it for me?
//Martin
On Thu, Dec 26, 2013 at 1:15 PM, Marek Olšák wrote:
> Reviewed-by: Marek Olšák
>
> Marek
>
> On Thu, Dec 26, 2013 at 10:33 AM, Martin Andersson wrote:
>> Fixes wayland regression on r600
On Tue, Jan 7, 2014 at 2:05 PM, Ian Romanick wrote:
> On 01/07/2014 12:31 PM, Thomas Sondergaard wrote:
>> This small rearrangement avoids MSVC 2013 ICE. Also, this should be a better
>> memory access order.
>
> Can you explain this better? As far as I can tell, this just changes
> the order the
On 01/07/2014 02:22 PM, Thomas Sondergaard wrote:
> On 2014-01-07 23:05, Ian Romanick wrote:
>> On 01/07/2014 12:31 PM, Thomas Sondergaard wrote:
>>> This small rearrangement avoids MSVC 2013 ICE. Also, this should be a
>>> better
>>> memory access order.
>>
>> Can you explain this better? As far
There are fixes on top of this fix. When they get picked over to the
stable branch, I think at least this and the one from 050961.html should
get squashed together.
http://lists.freedesktop.org/archives/mesa-dev/2014-January/050961.html
http://lists.freedesktop.org/archives/mesa-dev/2014-January/
On 01/07/2014 12:31 PM, Thomas Sondergaard wrote:
> MSVC 2013 version of math.h includes an fma() function.
> ---
> src/glsl/builtin_functions.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
> index 10127
On 01/07/2014 02:13 PM, Paul Berry wrote:
> Previously, we had an enum called gl_shader_type which represented
> pipeline stages in the order they occur in the pipeline
> (i.e. MESA_SHADER_VERTEX=0, MESA_SHADER_GEOMETRY=1, etc), and several
> inconsistently named functions for converting between it
On 01/07/2014 03:13 PM, Paul Berry wrote:
This reduces confusion since gl_shader::Type is sometimes
GL_SHADER_PROGRAM_MESA but is more frequently
GL_SHADER_{VERTEX,GEOMETRY,FRAGMENT}. It also has the advantage that
when switching on gl_shader::Stage, the compiler will alert if one of
the possibl
On 01/07/2014 03:13 PM, Paul Berry wrote:
Previously, we had an enum called gl_shader_type which represented
pipeline stages in the order they occur in the pipeline
(i.e. MESA_SHADER_VERTEX=0, MESA_SHADER_GEOMETRY=1, etc), and several
inconsistently named functions for converting between it and o
On 01/07/2014 03:13 PM, Paul Berry wrote:
---
src/glsl/glsl_parser_extras.cpp | 12 +---
src/glsl/glsl_parser_extras.h| 2 +-
src/glsl/main.cpp| 2 +-
src/glsl/test_optpass.cpp| 2 +-
src/glsl/tests/builtin_variable_tes
On 01/07/2014 03:13 PM, Paul Berry wrote:
---
src/glsl/link_varyings.cpp | 48 +++---
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index da97e9f..eefd725 100644
--- a/src/glsl/lin
On 01/07/2014 03:30 PM, Ian Romanick wrote:
On 01/07/2014 02:22 PM, Thomas Sondergaard wrote:
On 2014-01-07 23:05, Ian Romanick wrote:
On 01/07/2014 12:31 PM, Thomas Sondergaard wrote:
This small rearrangement avoids MSVC 2013 ICE. Also, this should be a
better
memory access order.
Can you e
MSVC 2013 version of math.h includes an fma() function.
---
src/glsl/builtin_functions.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index 10127f3..b3e407a 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/sr
On 2014-01-07 23:45, Kenneth Graunke wrote:
On 01/07/2014 12:31 PM, Thomas Sondergaard wrote:
MSVC 2013 version of math.h includes an fma() function.
---
src/glsl/builtin_functions.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/gls
This small rearrangement avoids MSVC 2013 ICE. Also, this should be a better
memory access order.
---
src/gallium/drivers/softpipe/sp_quad_blend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_quad_blend.c
b/src/gallium/drivers/softpipe/sp
This fixes the following compile error:
src\glsl\ir_constant_expression.cpp(1405) : error C2666: 'copysign' : 3
overloads have similar conversions
---
src/glsl/ir_constant_expression.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/ir_constant_expression.cpp
b/src
On 2014-01-07 23:05, Ian Romanick wrote:
On 01/07/2014 12:31 PM, Thomas Sondergaard wrote:
This small rearrangement avoids MSVC 2013 ICE. Also, this should be a better
memory access order.
Can you explain this better? As far as I can tell, this just changes
the order the indices are visited (
---
common.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common.py b/common.py
index 1d618e6..22c1725 100644
--- a/common.py
+++ b/common.py
@@ -100,4 +100,4 @@ def AddOptions(opts):
opts.Add(BoolOption('quiet', 'DEPRECATED: profile build', 'yes'))
opts.Add
On 01/07/2014 02:13 PM, Paul Berry wrote:
> This reduces confusion since gl_shader::Type is sometimes
> GL_SHADER_PROGRAM_MESA but is more frequently
> GL_SHADER_{VERTEX,GEOMETRY,FRAGMENT}. It also has the advantage that
> when switching on gl_shader::Stage, the compiler will alert if one of
> the
https://bugs.freedesktop.org/show_bug.cgi?id=73371
--- Comment #2 from Carsten Haitzler ---
oh - thanks gustavo. someone else was filing a bug too.
i've also prepared a workaround for now where we blacklist mesa + intel drvires
in egl mode from detecting this extension. i will need to know when
Unconditionally set brw->need_workaround_flush at the top of gen6 blorp
state emission.
The art of emitting workaround flushes on Sandybridge is mysterious and
not fully understood. Ken and I believe that
intel_emit_post_sync_nonzero_flush() may be required when switching from
regular drawing to b
In solving a HiZ hang before Christmas vacation, I discovered that Mesa wasn't
emitting sufficient workaround flushes. That bug was solved in commit 1a92881.
This series, prompted by Ken, adds some more carefully placed flushes to
pre-emptively fix undiscovered gpu hangs. Gpu hangs are difficult
1 - 100 of 108 matches
Mail list logo
