On Mon, Aug 10, 2015 at 9:52 AM, Jason Ekstrand wrote:
> For those of you tracking the big-endian stuff, I've pushed a couple
> patches to a branch:
>
> http://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/be-fixes
>
> I've removed the patch to change the way gallium converts PIPE_FORMAT
> to ME
For those of you tracking the big-endian stuff, I've pushed a couple
patches to a branch:
http://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/be-fixes
I've removed the patch to change the way gallium converts PIPE_FORMAT
to MESA_FORMAT because it was clearly wrong. As I work on this, I'll
try
The swizzle defines where in the format you should look for any given
channel. When we flip the format around for BE targets, we need to change
the destinations of the swizzles, not the sources. For example, say the
format is an RGBX format with a swizzle of xyz1 on LE. Then it should be
wzy1 on
https://bugs.freedesktop.org/show_bug.cgi?id=90264
xpue changed:
What|Removed |Added
CC||r9k...@gmail.com
--
You are receiving this mail
This better ensures that the src_bits == dst_bits case gets optimized away.
---
src/mesa/main/format_utils.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/format_utils.h b/src/mesa/main/format_utils.h
index 00ec777..65314e6 100644
--- a/src/mesa/main/for
On Sun, Aug 9, 2015 at 6:46 AM, Roland Scheidegger wrote:
> Am 09.08.2015 um 12:11 schrieb Oded Gabbay:
>> On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote:
>>> On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote:
On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand
wrote:
If
On Sun, Aug 9, 2015 at 3:11 AM, Oded Gabbay wrote:
> On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote:
>> On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote:
>>> On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand
>>> wrote:
>>>
>>> If I understand your patch, instead of using the endian-depend
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #48 from Michel Dänzer ---
I think Chris' patch is a superior replacement of Heiko's patch, not a revision
of it. Chris, please submit your patch to the mesa-dev mailing list for review.
--
You are receiving this mail because:
You a
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #47 from Furkan ---
Heiko, do you think you could send out your patch (with Chris' revision?) onto
the mailing list? Perhaps it could be merged for 11.0.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Yo
On Tuesday, August 04, 2015 02:28:01 PM Eric Anholt wrote:
> They're used by glsl_to_nir.cpp, and I want to use them in TGSI-to-NIR as
> well (our use of the var->index slot to store slot properties no longer
> works since it got truncated).
>
> The *_MAX defines are left in mtypes.h, because they
Hi Emil,
Thank you for your answer. Sorry about my answer. I hoped that it could
fix our 3D acceleration problems with new graphics cards but you're
right I misread it. I will test it as soon as possible. Many thanks for
this patch.
Rgds,
Christian
On 07 August 2015 at 8:03 PM, Emil Veliko
https://bugs.freedesktop.org/show_bug.cgi?id=91591
--- Comment #6 from Vinson Lee ---
mesa: 1eaa29cb300e927409281ef0a9413072766eaa3d (11.0.0-devel)
Build failure on CentOS 7.
CXXglsl_types.lo
In file included from ../../src/mesa/main/macros.h:36,
from ../../src/mesa/main/
LGTM
Reviewed-by: Edward O'Callaghan
--
Edward O'Callaghan
edward.ocallag...@koparo.com
On Sat, Aug 8, 2015, at 10:05 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> MESA_LLVM_VERSION_PATCH is undefined.
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 9 +
> 1 file change
On Sun, Aug 09, 2015 at 04:29:33PM -0700, Kenneth Graunke wrote:
> On Friday, August 07, 2015 01:58:37 PM Ben Widawsky wrote:
> > We do not want bug reports from this early stepping of SKL. Few if any were
> > ever
> > shipped outside of Intel to early enabling partners, and none will be sold.
> >
On Friday, August 07, 2015 01:58:37 PM Ben Widawsky wrote:
> We do not want bug reports from this early stepping of SKL. Few if any were
> ever
> shipped outside of Intel to early enabling partners, and none will be sold.
>
> There is a functional change here. If you're using new mesa on an old
>
On 09/08/15 23:30, Matt Turner wrote:
On Sun, Aug 9, 2015 at 2:40 PM, Jose Fonseca wrote:
More portable. Based on Roland Scheidegger's idea.
Tested with roundevent_test on Linux, MinGW, and MSVC.
https://bugs.freedesktop.org/show_bug.cgi?id=91591
---
src/util/rounding.h | 15 +++---
On Sun, 2015-08-09 at 11:11 -0400, Ilia Mirkin wrote:
>
> On Aug 9, 2015 1:35 AM, "Timothy Arceri" wrote:
> >
> > This applies on top of my V3 ARB_arrays_of_arrays GLSL ES series
> >
> > If useful the series is in the 'desktop_AoA_no_interface' branch of the
> repo here:
> > https://github.com/t
On Sun, Aug 9, 2015 at 2:40 PM, Jose Fonseca wrote:
> More portable. Based on Roland Scheidegger's idea.
>
> Tested with roundevent_test on Linux, MinGW, and MSVC.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=91591
> ---
> src/util/rounding.h | 15 +++
> 1 file changed, 11 insert
Indeed, given these are Mesa internal functions, we could indeed have
then return int32 or int64 and side-step this problem completely.
Especially because the callers of these function might care about those
things too.
Nothing prevents we do that in the medium term, but in the short term
th
Looks good to me. Would have been much less trouble if we'd just
returned an int, to hell with lrintf's long return type no callers will
care about the long returned anyway...
Reviewed-by: Roland Scheidegger
Am 09.08.2015 um 23:40 schrieb Jose Fonseca:
> More portable. Based on Roland Scheideg
r600 currently has 73 atoms and looping through their dirty flags has
become costly because checking each flag requires a pointer
dereference before the read. To avoid having to do that add additional
bitfield which can be checked really quickly thanks to tzcnt instruction.
id field was added to s
This is analogous to r300_mark_atom_dirty() used by r300, and will
be used by later patches. For common radeon code, appropriate helper
is called through a function pointer.
No functional changes.
---
src/gallium/drivers/r600/evergreen_compute.c| 2 +-
src/gallium/drivers/r600/evergreen_stat
Instead of writing to rctx->atoms directly use a helper to take
advantage of assert checks.
---
src/gallium/drivers/r600/evergreen_state.c | 4 ++--
src/gallium/drivers/r600/r600_pipe.h | 1 +
src/gallium/drivers/r600/r600_state.c| 4 ++--
src/gallium/drivers/r600/r600_state_c
On evergreen config_state is not used, so don't mark it dirty.
---
src/gallium/drivers/r600/r600_hw_context.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index d67fdfd..c048a71 10064
https://bugs.freedesktop.org/show_bug.cgi?id=91591
Jose Fonseca changed:
What|Removed |Added
Assignee|matts...@gmail.com |jfons...@vmware.com
--- Comment #5 from J
More portable. Based on Roland Scheidegger's idea.
Tested with roundevent_test on Linux, MinGW, and MSVC.
https://bugs.freedesktop.org/show_bug.cgi?id=91591
---
src/util/rounding.h | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/util/rounding.h b/src/uti
On 09/08/15 21:30, Jose Fonseca wrote:
On 09/08/15 21:21, Roland Scheidegger wrote:
Am 09.08.2015 um 20:08 schrieb Jose Fonseca:
On 09/08/15 17:47, Matt Turner wrote:
On Sun, Aug 9, 2015 at 3:57 AM, Jose Fonseca
wrote:
Neither MSVC nor MinGW defines LONG_BIT. For MSVC this was not a
problem
https://bugs.freedesktop.org/show_bug.cgi?id=91591
--- Comment #4 from Alexander von Gluck ---
LONG_BIT really isn't standard at all. It isn't defined here on ArchLinux nor
is it defined on Haiku.
I've seen mentions of doing the following:
CHAR_BIT * sizeof(long)
Archiving build/haiku-x86_
On 09/08/15 21:21, Roland Scheidegger wrote:
Am 09.08.2015 um 20:08 schrieb Jose Fonseca:
On 09/08/15 17:47, Matt Turner wrote:
On Sun, Aug 9, 2015 at 3:57 AM, Jose Fonseca wrote:
Neither MSVC nor MinGW defines LONG_BIT. For MSVC this was not a
problem as
it doesn't define __x86_64__ macro (
https://bugs.freedesktop.org/show_bug.cgi?id=91591
--- Comment #3 from Jose Fonseca ---
(In reply to Jose Fonseca from comment #2)
> There was a discussion about on Stack Overflow, but is not very conclusive.
Forgot to paste the link:
http://stackoverflow.com/questions/15817380/long-bit-in-li
https://bugs.freedesktop.org/show_bug.cgi?id=91591
Jose Fonseca changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |matts...@gmail.com
|org
Am 09.08.2015 um 20:08 schrieb Jose Fonseca:
> On 09/08/15 17:47, Matt Turner wrote:
>> On Sun, Aug 9, 2015 at 3:57 AM, Jose Fonseca wrote:
>>> Neither MSVC nor MinGW defines LONG_BIT. For MSVC this was not a
>>> problem as
>>> it doesn't define __x86_64__ macro (it's GCC specific.)
>>>
>>> Howev
https://bugs.freedesktop.org/show_bug.cgi?id=91591
Vinson Lee changed:
What|Removed |Added
Keywords||bisected
--- Comment #1 from Vinson Lee --
https://bugs.freedesktop.org/show_bug.cgi?id=91591
Bug ID: 91591
Summary: rounding.h:102:2: error: #error "Unsupported or
undefined LONG_BIT"
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (Al
On 09/08/15 19:08, Jose Fonseca wrote:
On 09/08/15 17:47, Matt Turner wrote:
On Sun, Aug 9, 2015 at 3:57 AM, Jose Fonseca wrote:
Neither MSVC nor MinGW defines LONG_BIT. For MSVC this was not a
problem as
it doesn't define __x86_64__ macro (it's GCC specific.)
However on Windows long type is
On 09/08/15 17:47, Matt Turner wrote:
On Sun, Aug 9, 2015 at 3:57 AM, Jose Fonseca wrote:
As currently only GCC x86_64 builds where using it.
---
src/util/rounding.h | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/util/rounding.h b/src/util/rounding.
On 09/08/15 17:47, Matt Turner wrote:
On Sun, Aug 9, 2015 at 3:57 AM, Jose Fonseca wrote:
Neither MSVC nor MinGW defines LONG_BIT. For MSVC this was not a problem as
it doesn't define __x86_64__ macro (it's GCC specific.)
However on Windows long type is guaranteed to be 32bits.
Also add an #
Forgot to mention, strictly speaking only __SSE__ is necessary for
_mesa_lroundevenf, so it would work on these shiny Pentium 3 and Athlon
XP... The double version (though it's unused) however requires __SSE2__.
Roland
Am 09.08.2015 um 19:23 schrieb Roland Scheidegger:
> Am 09.08.2015 um 18:47 sc
Am 09.08.2015 um 18:47 schrieb Matt Turner:
> On Sun, Aug 9, 2015 at 3:57 AM, Jose Fonseca wrote:
>> As currently only GCC x86_64 builds where using it.
>> ---
>> src/util/rounding.h | 16 +---
>> 1 file changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/util/rounding.h
On Sun, 2015-08-09 at 15:39 +0200, Zoltan Gilian wrote:
> There is no MDOperand in llvm 3.5.
>
> v2: Check if kernel metadata is present to avoid crash (EdB).
still builds for me.
thanks,
Jan
> ---
> .../state_trackers/clover/llvm/invocation.cpp | 22
> +-
> 1 file ch
On Sun, Aug 9, 2015 at 3:57 AM, Jose Fonseca wrote:
> As currently only GCC x86_64 builds where using it.
> ---
> src/util/rounding.h | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/src/util/rounding.h b/src/util/rounding.h
> index ec31b47..38c1c2f 10064
On Sun, Aug 9, 2015 at 3:57 AM, Jose Fonseca wrote:
> Neither MSVC nor MinGW defines LONG_BIT. For MSVC this was not a problem as
> it doesn't define __x86_64__ macro (it's GCC specific.)
>
> However on Windows long type is guaranteed to be 32bits.
>
> Also add an #error, as GCC will just warn, n
From: Roland Scheidegger
This code (lifted straight from the extension) was doing things the most
inefficient way you could think of.
This drops some of the more expensive float operations, in particular
- int-cast floors (pointless, values always positive)
- 2 raised to (signed) integers (replac
From: Roland Scheidegger
I used this as some testing ground for investigating some compiler
bits initially (e.g. lrint calls etc.), figured I could do much better
in the end just for fun...
This is mathematically equivalent, but uses some tricks to avoid
doubles and also replaces some float math
On Aug 9, 2015 1:35 AM, "Timothy Arceri" wrote:
>
> This applies on top of my V3 ARB_arrays_of_arrays GLSL ES series
>
> If useful the series is in the 'desktop_AoA_no_interface' branch of the
repo here:
> https://github.com/tarceri/Mesa_arrays_of_arrays.git
>
> This series:
> - Adds support for
Am 09.08.2015 um 12:11 schrieb Oded Gabbay:
> On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote:
>> On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote:
>>> On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand
>>> wrote:
>>>
>>> If I understand your patch, instead of using the endian-dependent
>>>
There is no MDOperand in llvm 3.5.
v2: Check if kernel metadata is present to avoid crash (EdB).
---
.../state_trackers/clover/llvm/invocation.cpp | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
Am 09.08.2015 um 12:57 schrieb Jose Fonseca:
> Neither MSVC nor MinGW defines LONG_BIT. For MSVC this was not a problem as
> it doesn't define __x86_64__ macro (it's GCC specific.)
>
> However on Windows long type is guaranteed to be 32bits.
>
> Also add an #error, as GCC will just warn, not thr
https://bugs.freedesktop.org/show_bug.cgi?id=69101
--- Comment #30 from Markus S. ---
(In reply to viktor from comment #29)
> As I know current mesa drivers for intel IGP doesn't support DRI3 by default
> for Fedora 22... but I can be wrong. Any ways to enable DRI3?
http://cgit.freedesktop.org/x
Neither MSVC nor MinGW defines LONG_BIT. For MSVC this was not a problem as
it doesn't define __x86_64__ macro (it's GCC specific.)
However on Windows long type is guaranteed to be 32bits.
Also add an #error, as GCC will just warn, not throw any error, when no
value is returned.
Trivial.
---
s
As currently only GCC x86_64 builds where using it.
---
src/util/rounding.h | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/util/rounding.h b/src/util/rounding.h
index ec31b47..38c1c2f 100644
--- a/src/util/rounding.h
+++ b/src/util/rounding.h
@@ -27,7 +27
---
src/util/SConscript | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/util/SConscript b/src/util/SConscript
index 9e4d481..3dbe70a 100644
--- a/src/util/SConscript
+++ b/src/util/SConscript
@@ -54,3 +54,10 @@ u_atomic_test = env.Program(
)
alias = env.Alias("u_atomic_test", u_at
On Sun, Aug 9, 2015 at 12:14 PM, Oded Gabbay wrote:
> On Sun, Aug 9, 2015 at 12:56 PM, Marek Olšák wrote:
>> He was probably talking about the gallium swrast (softpipe/llvmpipe).
>> I don't know of anybody using classic swrast (except classic drivers
>> as software fallback).
>>
>> All Gallium fo
On Sun, Aug 9, 2015 at 12:56 PM, Marek Olšák wrote:
> He was probably talking about the gallium swrast (softpipe/llvmpipe).
> I don't know of anybody using classic swrast (except classic drivers
> as software fallback).
>
> All Gallium formats are array-based except those which can't be arrays
> l
On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote:
> On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote:
>> On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand wrote:
>>
>> If I understand your patch, instead of using the endian-dependent
>> defines, you use the LE defines all the time when conver
He was probably talking about the gallium swrast (softpipe/llvmpipe).
I don't know of anybody using classic swrast (except classic drivers
as software fallback).
All Gallium formats are array-based except those which can't be arrays
like 332, 565, 5551, , 10_10_10_2, 11_11_10, 24_8, 8_24, 32_8
2015-08-09 6:46 GMT+02:00 Timothy Arceri :
> ---
> src/glsl/ast_to_hir.cpp | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index 9385922..f67c951 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.
57 matches
Mail list logo
