Hi,
Sorry for these late response. I am in the middle of moving to a new
appartements coordinating work in the new one and so on.
It might even be that I do have no good network access for a few days ...
On Wednesday, May 01, 2013 17:56:33 Tom Stellard wrote:
> Thanks for pointing this out, I'l
On Wed, May 01, 2013 at 04:11:51PM +0200, Mathias Fröhlich wrote:
>
> Tom, Jose,
>
> On Tuesday, April 30, 2013 16:56:56 Tom Stellard wrote:
> > I took the linker script from your email and took at shot at creating
> > libMesaLLVM.so within Mesa. I've pushed my initial code here:
> > http://cgit
Tom, Jose,
On Tuesday, April 30, 2013 16:56:56 Tom Stellard wrote:
> I took the linker script from your email and took at shot at creating
> libMesaLLVM.so within Mesa. I've pushed my initial code here:
> http://cgit.freedesktop.org/~tstellar/mesa/log/?h=libmesallvm
Thank you very much and sorry
On Sat, Apr 27, 2013 at 10:33:29AM +0200, Mathias Fröhlich wrote:
>
> Hi,
>
> On Thursday, April 25, 2013 10:29:27 Jose Fonseca wrote:
> > - There are a bunch of options that need to be set via globals, (see
> > lp_set_target_options), so app/drivers could tamper with each other
> > options.
> >
- Original Message -
>
> Hi,
>
> On Thursday, April 25, 2013 10:29:27 Jose Fonseca wrote:
> > - There are a bunch of options that need to be set via globals, (see
> > lp_set_target_options), so app/drivers could tamper with each other
> > options.
> >
> > - llvm::cl::ParseCommandLineOpt
Hi,
On Thursday, April 25, 2013 10:29:27 Jose Fonseca wrote:
> - There are a bunch of options that need to be set via globals, (see
> lp_set_target_options), so app/drivers could tamper with each other
> options.
>
> - llvm::cl::ParseCommandLineOptions will complain if called multiple times
> --
Jose,
On Thursday, April 25, 2013 03:52:44 Jose Fonseca wrote:
> There is no paradox. To be clear:
Ok, thanks!
Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
- Original Message -
> On Wed, Apr 24, 2013 at 09:54:02PM -0700, Jose Fonseca wrote:
> > - Original Message -
> > > On Wed, Apr 24, 2013 at 09:40:44PM +0200, Mathias Fröhlich wrote:
> > > >
> > > > Hi Tom,
> > > >
> > > > On Tuesday, April 23, 2013 20:47:24 Tom Stellard wrote:
>
Am 25.04.2013 19:08, schrieb Tom Stellard:
[SNIP]
I think this is a good approach, however before we make big changes to
Mesa I want to make sure we know what problems we are trying to solve
with these changes. As far as I understand it, the current problems
are:
1. If an application is using
On Wed, Apr 24, 2013 at 09:54:02PM -0700, Jose Fonseca wrote:
> - Original Message -
> > On Wed, Apr 24, 2013 at 09:40:44PM +0200, Mathias Fröhlich wrote:
> > >
> > > Hi Tom,
> > >
> > > On Tuesday, April 23, 2013 20:47:24 Tom Stellard wrote:
> > > > First of all, thanks for investigating
- Original Message -
>
> Jose,
>
> On Thursday, April 25, 2013 01:38:46 Jose Fonseca wrote:
> > What I'm suggesting doesn't require huge effort.
> >
> > In detail, I'm suggesting:
> >
> > (1) have a custom build of LLVM libraries with -fvisibility=hidden
> >
> > (2) have a src/mesall
Jose,
On Thursday, April 25, 2013 01:38:46 Jose Fonseca wrote:
> What I'm suggesting doesn't require huge effort.
>
> In detail, I'm suggesting:
>
> (1) have a custom build of LLVM libraries with -fvisibility=hidden
>
> (2) have a src/mesallvm/mesallvm.c containing wrappers
>
> #include
>
- Original Message -
>
> Hi,
>
> On Wednesday, April 24, 2013 21:54:02 Jose Fonseca wrote:
> > I don't see how this would work -- llvmpipe/draw has LLVMBuildXxxx calls
> > too. So to prevent symbol collision with apps that use them, we'd need to
> > expose all LLVM calls we need under
Hi,
On Wednesday, April 24, 2013 21:54:02 Jose Fonseca wrote:
> I don't see how this would work -- llvmpipe/draw has LLVMBuildXxxx calls
> too. So to prevent symbol collision with apps that use them, we'd need to
> expose all LLVM calls we need under nome unique prefix.
>
> Also note that galli
Hi,
On Wednesday, April 24, 2013 14:15:06 Tom Stellard wrote:
> I've thought about this some more, and I think that the best solution
> might be to move all LLVM API calls into gallivm and build it as a
> shared object with it's own private copy of LLVM statically linked. This
> way we would sti
- Original Message -
> On Wed, Apr 24, 2013 at 09:40:44PM +0200, Mathias Fröhlich wrote:
> >
> > Hi Tom,
> >
> > On Tuesday, April 23, 2013 20:47:24 Tom Stellard wrote:
> > > First of all, thanks for investigating this. The information you've
> > > provided has helped me a lot.
> > Good
On Wed, Apr 24, 2013 at 09:40:44PM +0200, Mathias Fröhlich wrote:
>
> Hi Tom,
>
> On Tuesday, April 23, 2013 20:47:24 Tom Stellard wrote:
> > First of all, thanks for investigating this. The information you've
> > provided has helped me a lot.
> Good to hear that it helps.
>
> > I took a shot a
Hi Tom,
On Tuesday, April 23, 2013 20:47:24 Tom Stellard wrote:
> First of all, thanks for investigating this. The information you've
> provided has helped me a lot.
Good to hear that it helps.
> I took a shot at implementing it this way with private static copies of
> llvm. I've pushed the in
On Sat, Apr 20, 2013 at 09:27:16AM +0200, Mathias Fröhlich wrote:
>
> Hi Tom,
>
> May be I need to tell where the problem really appears in real life.
> OpenSceneGraph has some nifty features regarding multi channel rendering.
> Assume a setup of multiple full screen views running on different gr
Hi all,
On Monday, April 22, 2013 00:39:57 Tom Stellard wrote:
[...]
The only pro for further investigating the dlopen flags is that I fear the
distribution builders who invented dynamic linking in the drivers. That change
destroyed symbol isolation in the drivers at that point. They will prob
On Sat, Apr 20, 2013 at 02:20:23PM +0200, Christian König wrote:
> Am 20.04.2013 09:27, schrieb Mathias Fröhlich:
> > Hi Tom,
> >
> > May be I need to tell where the problem really appears in real life.
> > OpenSceneGraph has some nifty features regarding multi channel rendering.
> > Assume a setup
Am 20.04.2013 09:27, schrieb Mathias Fröhlich:
Hi Tom,
May be I need to tell where the problem really appears in real life.
OpenSceneGraph has some nifty features regarding multi channel rendering.
Assume a setup of multiple full screen views running on different graphics
boards into a single ma
Hi Tom,
May be I need to tell where the problem really appears in real life.
OpenSceneGraph has some nifty features regarding multi channel rendering.
Assume a setup of multiple full screen views running on different graphics
boards into a single mashine composing a view into a single scene.
Now
On Wed, Apr 17, 2013 at 07:54:32AM +0200, Mathias Fröhlich wrote:
>
> Tom,
>
> > -class LLVMEnsureMultithreaded {
> > -public:
> > - LLVMEnsureMultithreaded()
> > - {
> > - llvm_start_multithreaded();
> > - }
> > -};
> > -
> > -static LLVMEnsureMultithreaded lLVMEnsureMultithreaded;
>
Am 17.04.2013 01:13, schrieb Tom Stellard:
From: Tom Stellard
The LLVM C API is considered stable and should never change, so it
is much more desirable to use than the LLVM C++ API, which is constantly in
flux.
Looks good on first glance, but I would separate the initialization and
finding t
Tom,
> -class LLVMEnsureMultithreaded {
> -public:
> - LLVMEnsureMultithreaded()
> - {
> - llvm_start_multithreaded();
> - }
> -};
> -
> -static LLVMEnsureMultithreaded lLVMEnsureMultithreaded;
Removing this leads to crashes in llvm with applications that concurrently
work on differe
From: Tom Stellard
The LLVM C API is considered stable and should never change, so it
is much more desirable to use than the LLVM C++ API, which is constantly in
flux.
---
src/gallium/drivers/radeon/Makefile.am | 2 -
src/gallium/drivers/radeon/Makefile.sources | 4 +-
src/galli
27 matches
Mail list logo
