On Fri, Aug 13, 2010 at 8:03 PM, Luca Barbieri wrote:
>> #if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64)
>> #define PIPE_ARCH_LITTLE_ENDIAN
>> #elif defined(PIPE_ARCH_PPC) || defined(PIPE_ARCH_PPC_64)
>> #define PIPE_ARCH_BIG_ENDIAN
>> #else
>> #define PIPE_ARCH_UNKNOWN_ENDIAN
>> #endif
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
> I propose that we merge master to glsl2 on *Friday, August 13th* (one
> week from today). Barring unforeseen issues, I propose that we merge
> glsl2 to master on *Monday, August 16th*.
The master -> glsl2 merge is complete. The
Changes in v4:
- Use x86_target() and x86_target_caps()
- Enable translate_sse in x86-64, but not in Win64
Changes in v3:
- Win64 support (untested)
- Use u_cpu_detect.h constants instead of #ifs
Changes in v2:
- Minimize #ifs
- Give a name to magic number CHANNELS_0001
- Add support for CPUs wit
This logic duplicates the one in p_config.h, so remove it and adjust
the only two places that were using it.
---
src/gallium/auxiliary/gallivm/lp_bld_pack.c |7 +++
src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c |6 +-
src/gallium/auxiliary/util/u_cpu_detect.c |
Changes in v3:
- Add target and target caps functions, so that they could be different in
principle from the current CPU and they don't need #ifs to check
Changes in v2:
- Win64 support (untested)
- Use u_cpu_detect.h constants instead of #ifs
This commit adds minimal x86-64 support: only movs
This new version replaces direct use of u_cpu_detect.h with rtasm-provided
helpers to check the target and caps.
This seems the cleanest solution, as it allows to target other CPUs than the
running one in theory, and avoids both #ifdefs and duplicating the p_config.h
logic.
The u_cpu_detect.h pat
https://bugs.freedesktop.org/show_bug.cgi?id=29572
Ian Romanick changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|mesa-...@list
https://bugs.freedesktop.org/show_bug.cgi?id=29573
Ian Romanick changed:
What|Removed |Added
AssignedTo|mesa-...@lists.freedesktop. |e...@anholt.net
|org
https://bugs.freedesktop.org/show_bug.cgi?id=29573
Summary: [glsl2] struct within a struct causes an assertion
failure
Product: Mesa
Version: git
Platform: All
OS/Version: All
Status: NEW
Severity: normal
> #if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64)
> #define PIPE_ARCH_LITTLE_ENDIAN
> #elif defined(PIPE_ARCH_PPC) || defined(PIPE_ARCH_PPC_64)
> #define PIPE_ARCH_BIG_ENDIAN
> #else
> #define PIPE_ARCH_UNKNOWN_ENDIAN
> #endif
Note that this isn't really correct: there endianness must be k
I came up with yet another solution, which I believe is the right one.
We remove the arch/abi/endianness in u_cpu_detect.h, but add them as
inline function helpers in rtasm.
Currently they would return a constant, but could be changed if we
ever want rtasm to target anything but the current runnin
https://bugs.freedesktop.org/show_bug.cgi?id=29572
Summary: [glsl] MSVC build fails with some C99 math functions
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Windows (All)
Status: NEW
Severity: blocker
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Bug 29044 depends on bug 29500, which changed state.
Bug 29500 Summary: [glsl2]Mesa demo shadow_sampler fail to run with error:
`shadow2DRectProj' undeclared
https://bugs.freedesktop.org/show_bug.cgi?id=29500
What|Old Value
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Bug 29044 depends on bug 29537, which changed state.
Bug 29537 Summary: [glsl2] texture2DLod() should not be accepted by fragment
programs
https://bugs.freedesktop.org/show_bug.cgi?id=29537
What|Old Value |New V
> There's no merit in duplicating in util_caps what's already provided by
> p_config.h / p_compiler.h
Indeed it's not a great thing.
However, Keith wanted to be able to check those with ifs instead of
#ifdefs, and it does indeed make the code a bit nicer.
But the current definitions in p_config.h
https://bugs.freedesktop.org/show_bug.cgi?id=29571
Ian Romanick changed:
What|Removed |Added
AssignedTo|e...@anholt.net |mesa-...@lists.freedesktop.
https://bugs.freedesktop.org/show_bug.cgi?id=29545
Ian Romanick changed:
What|Removed |Added
AssignedTo|mesa-...@lists.freedesktop. |cwo...@cworth.org
|org
https://bugs.freedesktop.org/show_bug.cgi?id=29545
Ian Romanick changed:
What|Removed |Added
OS/Version|Linux (All) |All
Component|Drivers/DRI/i965
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Bug 29044 depends on bug 29540, which changed state.
Bug 29540 Summary: [glsl2] problem with vertex attribute locations and
draw-time validation
https://bugs.freedesktop.org/show_bug.cgi?id=29540
What|Old Value
Just looked at your modifications. I will try to be more GL/mesa style
compliant for the variable types.
Thanks for your help
Ben
From: Brian Paul [bri...@vmware.com]
Sent: Friday, August 13, 2010 4:01 PM
To: Segovia, Benjamin
Cc: mesa-dev@lists.freedeskto
On 08/11/2010 09:21 PM, Segovia, Benjamin wrote:
Corrected.
I rescaned the whole code and tried to perform more aggressive checks.
I rerun all the tests, warsow and nexuiz.
Please find the updated patch attached.
Committed. Thanks.
-Brian
___
mesa
Chia-I Wu wrote:
>> Fixes a fatal build error when compiling just OpenGL ES libraries, since
>> FEATURE_EXT_framebuffer_blit is disabled then, so the BlitFramebuffer
>> member doesn't exist.
> Is this change enough to make dri_r300 function as a GLES only driver?
>
> To be honest, I am a little re
On Fri, 2010-08-13 at 21:41 +0100, José Fonseca wrote:
> On Fri, 2010-08-13 at 06:47 -0700, Luca Barbieri wrote:
> > A few related changes:
> > 1. Make x86-64 its own architecture (nothing was using so
> >util_cpu_caps.arch, so nothing can be affected)
>
> Just remove util_cpu_caps.arch. It's
Luca,
This is great stuff.
But one request: if Win64 is untested, please make sure it is disabled
by default until somebody had opportunity to test it. Unfortunately I'm
really busy with other stuff ATM and don't have the time.
Jose
On Fri, 2010-08-13 at 06:47 -0700, Luca Barbieri wrote:
> Cha
On Fri, 2010-08-13 at 06:47 -0700, Luca Barbieri wrote:
> A few related changes:
> 1. Make x86-64 its own architecture (nothing was using so
>util_cpu_caps.arch, so nothing can be affected)
Just remove util_cpu_caps.arch. It's there simply due to its historical
ancestry. We have PIPE_ARCH alre
https://bugs.freedesktop.org/show_bug.cgi?id=29460
Jon TURNEY changed:
What|Removed |Added
CC||jon.tur...@dronecode.org.uk
--- Comment #3
Changes in v3:
- Win64 support (untested)
- Use u_cpu_detect.h constants instead of #ifs
Changes in v2:
- Minimize #ifs
- Give a name to magic number CHANNELS_0001
- Add support for CPUs without SSE (only memcpy and swizzles, like non SSE2)
- Fixed comments
translate_sse is currently very limited
Changes in v2:
- Minimize #ifs
- Give a name to magic number CHANNELS_0001
- Add support for CPUs without SSE (only memcpy and swizzles, like non SSE2)
- Fixed comments
translate_sse is currently very limited to the point of
being useless in essentially all cases.
In particular, it only support s
https://bugs.freedesktop.org/show_bug.cgi?id=29540
Ian Romanick changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|mesa-...@list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
José Fonseca wrote:
> I've pushed a new branch glsl2-win32 that includes Aras' patch, and all
> necessary fixes to get at least MinGW build successfully.
I merged all of these.
> I had to rename some tokens in order to avoid collisions with windows.
On Fri, Aug 13, 2010 at 11:35 PM, Keith Whitwell wrote:
> On Fri, 2010-08-13 at 08:09 -0700, Chia-I Wu wrote:
>> On Fri, Aug 13, 2010 at 10:51 PM, Keith Whitwell wrote:
>> > On Fri, 2010-08-13 at 07:46 -0700, Chia-I Wu wrote:
>> >> On Fri, Aug 13, 2010 at 10:14 PM, Keith Whitwell
>> >> wrote:
>
On Fri, 2010-08-13 at 08:09 -0700, Chia-I Wu wrote:
> On Fri, Aug 13, 2010 at 10:51 PM, Keith Whitwell wrote:
> > On Fri, 2010-08-13 at 07:46 -0700, Chia-I Wu wrote:
> >> On Fri, Aug 13, 2010 at 10:14 PM, Keith Whitwell wrote:
> >> > On Fri, 2010-08-13 at 07:04 -0700, Chia-I Wu wrote:
> >> >> Hi,
On Fri, Aug 13, 2010 at 11:09 PM, Chia-I Wu wrote:
> On Fri, Aug 13, 2010 at 10:51 PM, Keith Whitwell wrote:
>> On Fri, 2010-08-13 at 07:46 -0700, Chia-I Wu wrote:
>>> On Fri, Aug 13, 2010 at 10:14 PM, Keith Whitwell wrote:
>>> > On Fri, 2010-08-13 at 07:04 -0700, Chia-I Wu wrote:
>>> >> Hi,
>>>
https://bugs.freedesktop.org/show_bug.cgi?id=29540
--- Comment #2 from Brian Paul 2010-08-13 08:10:00 PDT
---
Created an attachment (id=37848)
View: https://bugs.freedesktop.org/attachment.cgi?id=37848
Review: https://bugs.freedesktop.org/review?bug=29540&attachment=37848
Patch to fix glDrawA
On Fri, Aug 13, 2010 at 10:51 PM, Keith Whitwell wrote:
> On Fri, 2010-08-13 at 07:46 -0700, Chia-I Wu wrote:
>> On Fri, Aug 13, 2010 at 10:14 PM, Keith Whitwell wrote:
>> > On Fri, 2010-08-13 at 07:04 -0700, Chia-I Wu wrote:
>> >> Hi,
>> >>
>> >> There are two primitive transformations in galliu
https://bugs.freedesktop.org/show_bug.cgi?id=29540
--- Comment #1 from Brian Paul 2010-08-13 08:09:05 PDT
---
The new piglit test glsl-getattriblocation test returns attrib_loc=0 for the
old compiler and attrib_loc=1 for the new compiler.
This causes the glDrawArrays/Elements() validation test
On Fri, 2010-08-13 at 07:46 -0700, Chia-I Wu wrote:
> On Fri, Aug 13, 2010 at 10:14 PM, Keith Whitwell wrote:
> > On Fri, 2010-08-13 at 07:04 -0700, Chia-I Wu wrote:
> >> Hi,
> >>
> >> There are two primitive transformations in gallium draw module. In
> >> varray, primitives are "split"ted. When
On Fri, Aug 13, 2010 at 10:14 PM, Keith Whitwell wrote:
> On Fri, 2010-08-13 at 07:04 -0700, Chia-I Wu wrote:
>> Hi,
>>
>> There are two primitive transformations in gallium draw module. In
>> varray, primitives are "split"ted. When a primitive has more vertices
>> than the middle end can handle
> I had to rename some tokens in order to avoid collisions with windows.h
> defines. Aras didn't mention this problem before.
I mentioned this to Eric in private conversation, but on this list I
only talked about talloc specific changes.
Yeah, in the glsl2 parser some tokens clash with windows he
> #define symbols are usually uppercase. Is there a reason why you're using
> lowercase? I'd prefer the code to follow typical conventions.
Currently they can't be used in preprocessor directives because they
evaluate to enums, so it seems better to treat them as variables, and
thus lowercase.
On Fri, 2010-08-13 at 07:04 -0700, Chia-I Wu wrote:
> Hi,
>
> There are two primitive transformations in gallium draw module. In
> varray, primitives are "split"ted. When a primitive has more vertices
> than the middle end can handle, varray splits the primitive and calls
> the middle end multip
Hi,
There are two primitive transformations in gallium draw module. In
varray, primitives are "split"ted. When a primitive has more vertices
than the middle end can handle, varray splits the primitive and calls
the middle end multiple times.
In vcache, primitives are "decompose"d. More advance
On Fri, 2010-08-13 at 06:47 -0700, Luca Barbieri wrote:
> This is a new version of just the rtasm/translate_sse patches.
>
> This version has the Win64 support built-in.
>
> In addition, it follows Keith's idea to use constants instead of #ifs.
>
> To achieve this, u_cpu_detect.h is enhanced
On 08/13/2010 07:47 AM, Luca Barbieri wrote:
A few related changes:
1. Make x86-64 its own architecture (nothing was using so
util_cpu_caps.arch, so nothing can be affected)
2. Turn the CPU arch and endianness into macros, so that the compiler
can evaluate that at constant time and elimin
Changes in v3:
- Win64 support (untested)
- Use u_cpu_detect.h constants instead of #ifs
Changes in v2:
- Minimize #ifs
- Give a name to magic number CHANNELS_0001
- Add support for CPUs without SSE (only memcpy and swizzles, like non SSE2)
- Fixed comments
translate_sse is currently very limited
> What about just making things prettier by converting the #if's into
> regular if statements? It would be easier to read if nothing else,
> though it would mean compiling at least a stub version of the x86-64
> opcode emitters on x86.
>
> In fact there's nothing preventing us compiling the entire
Changes in v2:
- Win64 support (untested)
- Use u_cpu_detect.h constants instead of #ifs
This commit adds minimal x86-64 support: only movs between registers
are supported for r8-r15, and x64_rexw() must be used to ask for 64-bit
operations.
It also adds several new instructions for the new trans
A few related changes:
1. Make x86-64 its own architecture (nothing was using so
util_cpu_caps.arch, so nothing can be affected)
2. Turn the CPU arch and endianness into macros, so that the compiler
can evaluate that at constant time and eliminate dead code
3. Add util_cpu_abi to know about n
This is a new version of just the rtasm/translate_sse patches.
This version has the Win64 support built-in.
In addition, it follows Keith's idea to use constants instead of #ifs.
To achieve this, u_cpu_detect.h is enhanced so that architecture and
endianness are now compile time constants (and t
On Thu, 2010-08-12 at 14:46 -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> José Fonseca wrote:
>
> > OK.
> >
> > What about this:
> >
> > For GLUT, GLEW, LLVM and all other dependencies I'll just make a SDK
> > with the binaries, with debug & release, 32 & 64 b
What does all these errors that the X11 Nouveau driver spews out in
my /var/log/message mean? They don't seem to do any harm but I was
wondering whether it might be having an impact on the driver's
performance?
Aug 13 13:05:54 lithium kernel: [drm] nouveau :01:00.0: Allocating FIFO
number 3
On Fri, 2010-08-13 at 04:46 -0700, Luca Barbieri wrote:
> > Is it possible to use an explicit flag for the (out_chans == 5) case?
>
> Gave it the name CHANNELS_0001 and added a comment.
>
> > Is it possible to do this without all the #ifdefs? Even if statements
> > based on a preprocessor variab
I just discovered that Microsoft wisely decided to use their own
calling convention on Win64...
This hasn't actually been tested on Win64 though.
---
src/gallium/auxiliary/rtasm/rtasm_x86sse.c | 15 +++
src/gallium/auxiliary/translate/translate_sse.c | 21 +---
> In this change you've got an int value (copy_size) which has some
> special meaning when negative -- can you add comments explaining what
> the meaning of a negative size is? Is there a way to use some more
> explicit flag value to indicate this condition?
I think it makes sense, since -1 stand
Changes in v2:
- Minimize #ifs
- Give a name to magic number CHANNELS_0001
- Add support for CPUs without SSE (only memcpy and swizzles, like non SSE2)
- Fixed comments
translate_sse is currently very limited to the point of
being useless in essentially all cases.
In particular, it only support s
> Is it possible to use an explicit flag for the (out_chans == 5) case?
Gave it the name CHANNELS_0001 and added a comment.
> Is it possible to do this without all the #ifdefs? Even if statements
> based on a preprocessor variable would be easier to read, but better
> still would be some sort of
This commit adds minimal x86-64 support: only movs between registers
are supported for r8-r15, and x64_rexw() must be used to ask for 64-bit
operations.
It also adds several new instructions for the new translate_sse code.
---
src/gallium/auxiliary/rtasm/rtasm_cpu.c|6 +-
src/gallium/auxi
Currently, only 32-bit indices are supported, but some use cases
translate needs support for all types.
---
src/gallium/auxiliary/rtasm/rtasm_x86sse.c | 14
src/gallium/auxiliary/rtasm/rtasm_x86sse.h |2 +
src/gallium/auxiliary/translate/translate.h| 12
.
Currently translate_sse puts two trivial wrappers in the translate vtable.
These slow it down and enlarge the source code for no gain, except perhaps
the ability to set a breakpoint there, so remove them.
Breakpoints can be set on the caller of the translate functions, with no
loss of functionali
This moves the common code into a separate ALWAYS_INLINE function.
---
.../auxiliary/translate/translate_generic.c| 177 +++-
1 files changed, 62 insertions(+), 115 deletions(-)
diff --git a/src/gallium/auxiliary/translate/translate_generic.c
b/src/gallium/auxiliary/tran
Changes in v2:
- Add comment regarding copy_size
When used in GPU drivers, translate can be used to simultaneously
perform a gather operation, and convert away from unsupported formats.
In this use case, input and output formats will often be identical: clearly
it would make sense to use a memcpy
This patchset addresses review comments, and adds support for running
on CPUs lacking any SSE support, but only for format pairs that are
identical or swizzles of each other.
Luca Barbieri (6):
translate_generic: use memcpy if possible (v2)
translate_generic: factor out common code between lin
On Fri, 2010-08-13 at 02:03 -0700, Dave Airlie wrote:
> On Fri, Aug 13, 2010 at 4:58 PM, Aras Pranckevicius wrote:
> >> > But I perceive talloc as different from all above: it's very low level
> >> > and low weight library, providing very basic functionality, and upstream
> >> > never showed inter
On Thu, 2010-08-12 at 10:22 -0700, Luca Barbieri wrote:
> translate_sse is currently very limited to the point of
> being useless in essentially all cases.
>
> In particular, it only support some float32 and unorm8
> formats and doesn't work on x86-64.
>
> This commit rewrites it to support:
> 1.
Luca,
In this change you've got an int value (copy_size) which has some
special meaning when negative -- can you add comments explaining what
the meaning of a negative size is? Is there a way to use some more
explicit flag value to indicate this condition?
Keith
On Thu, 2010-08-12 at 10:08 -070
> > Like I said before, "full port" of talloc seems to be not needed for
> > compiling on Visual C++; just drop in talloc.h & talloc.c into the project
> > and that's it. Same for Mac with Xcode.
> Be careful about LGPLv3 rules,
> If you are distributing anything linked with an LGPL library without
On Fri, Aug 13, 2010 at 4:58 PM, Aras Pranckevicius wrote:
>> > But I perceive talloc as different from all above: it's very low level
>> > and low weight library, providing very basic functionality, and upstream
>> > never showed interest for Windows portability. I'd really prefer to see
>> > the
Ok, I used opengl extension viewer from realtechvr to identify some
parameters values, (used some data from win/osx ati drivers) also identified
most of limits by its normal name.
the patch conatins some new values and comments for them.
2010/8/10 Marek Olšák
> I've already committed some of the
68 matches
Mail list logo
