-m64 was not set to ARCH_FLAGS.
Signed-off-by: Pauli Nieminen
---
I noticed that there was difference in -m32 handling compare to -m64. I suspect
that -m64 would need same but I don't know if there is some reason not to add
the flag same way.
configure.ac |1 +
1 files changed, 1 insertion
-m32 and -m64 were missing from linker flags which caused linking errors with
dri river linking test. Adding correct flag to linker paramters fixes the
linking.
Signed-off-by: Pauli Nieminen
---
Does this look correct way of passing the flags to the build system?
configure.ac
Luca Barbieri writes:
> In fact, given the Gallium architecture, it may even make sense to
> support a variant of DirectX 10 as the main Mesa/Gallium API on all
> platfoms, instead of OpenGL.
The apparent benefit would seem to be greater compatibility with
software written for windows -- but that
On Wed, Mar 31, 2010 at 04:34:48AM +0200, Marek Olšák wrote:
> On Tue, Mar 30, 2010 at 10:26 AM, Nicolai Haehnle wrote:
> >
> > Note that my Git repository already contains an implementation of
> > branch emulation and some additional optimizations, see here:
> > http://cgit.freedesktop.org/~nh/mes
From: Ben Skeggs
---
src/mesa/state_tracker/st_atom_rasterizer.c |2 +-
src/mesa/state_tracker/st_program.c |6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_rasterizer.c
b/src/mesa/state_tracker/st_atom_rasterizer.c
index 9
On Tue, Mar 30, 2010 at 10:26 AM, Nicolai Haehnle wrote:
> On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák wrote:
> > Another idea was to convert TGSI to a SSA form. That would make unrolling
> > branches much easier as the Phi function would basically become a linear
> > interpolation, loops and su
An interesting option could be to provide a DirectX 10 implementation
using TGSI text as the shader interface, which should be much easier
than one would think at first.
DirectX 10 + TGSI text would provide a very thin binary compatible
layer over Gallium, unlike all existing state trackers.
It c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Corbin Simpson wrote:
> On Mon, Mar 29, 2010 at 5:50 PM, Ian Romanick wrote:
>> Philipp Klaus Krause wrote:
>>
>>> Well, there is TexSubImage2D. Assuming we have a compressed texture
>>> stored internally as some S3TC format and then the application r
> On Tue, 2010-03-30 at 09:52 -0700, Luca Barbieri wrote:
>> > There are several deep challenges in making TGSI <-> LLVM IR translation
>> > lossless -- I'm sure we'll get around to overcome them -- but I don't
>> > think that using LLVM is a requirement for this module. Having a shared
>> > IR for
On Tue, 2010-03-30 at 09:52 -0700, Luca Barbieri wrote:
> > There are several deep challenges in making TGSI <-> LLVM IR translation
> > lossless -- I'm sure we'll get around to overcome them -- but I don't
> > think that using LLVM is a requirement for this module. Having a shared
> > IR for simpl
On Tuesday 30 March 2010 12:52:54 Luca Barbieri wrote:
> > There are several deep challenges in making TGSI <-> LLVM IR translation
> > lossless -- I'm sure we'll get around to overcome them -- but I don't
> > think that using LLVM is a requirement for this module. Having a shared
> > IR for simple
This is getting off-topic, but anyway...
Luca Barbieri wrote:
>> There are several deep challenges in making TGSI <-> LLVM IR translation
>> lossless -- I'm sure we'll get around to overcome them -- but I don't
>> think that using LLVM is a requirement for this module. Having a shared
>> IR for si
On Tue, Mar 30, 2010 at 10:05 AM, Luca Barbieri wrote:
> DDX/DDY could cause miscompilation, but I think that only happens if
> LLVM clones or causes some paths to net execute them.
>
> Someone proposed some time ago on llvmdev to add a flag to tell llvm
> to never duplicate an intrinsic, not sure
On Tue, Mar 30, 2010 at 8:37 AM, Luca Barbieri wrote:
>> Another idea was to convert TGSI to a SSA form. That would make unrolling
>> branches much easier as the Phi function would basically become a linear
>> interpolation, loops and subroutines with conditional return statements
>> might be tric
On Sun, 2010-03-28 at 23:56 -0700, Chia-I Wu wrote:
> On Mon, Mar 29, 2010 at 1:51 AM, Keith Whitwell
> wrote:
> > I've just pushed a variation on a theme a couple of people have
> > explored in the past, ie. an interface to gallium without an
> > intervening state-tracker.
> > The purpose of this
DDX/DDY could cause miscompilation, but I think that only happens if
LLVM clones or causes some paths to net execute them.
Someone proposed some time ago on llvmdev to add a flag to tell llvm
to never duplicate an intrinsic, not sure if that went through (iirc,
it was for a barrier instruction tha
> There are several deep challenges in making TGSI <-> LLVM IR translation
> lossless -- I'm sure we'll get around to overcome them -- but I don't
> think that using LLVM is a requirement for this module. Having a shared
> IR for simple TGSI optimization module would go a long way by itself.
What
On Tue, 2010-03-30 at 08:37 -0700, Luca Barbieri wrote:
> > Another idea was to convert TGSI to a SSA form. That would make unrolling
> > branches much easier as the Phi function would basically become a linear
> > interpolation, loops and subroutines with conditional return statements
> > might be
> Another idea was to convert TGSI to a SSA form. That would make unrolling
> branches much easier as the Phi function would basically become a linear
> interpolation, loops and subroutines with conditional return statements
> might be trickier. The r300 compiler already uses SSA for its optimizati
Reply to all this time...
On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák wrote:
>> > 1) Branching and looping
>> >
>> > This is the most important one and there are 3 things which need to be
>> > done.
>> > * Unrolling loops and converting conditionals to multiplications. This
>> > is
>> > crucial
20 matches
Mail list logo
