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,
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 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:
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::ParseCommandLineOptions will
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
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
-- I
- 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 to hear that it
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 still
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 gallivm
- 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 nome
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 -
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
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 this. The
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
- 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:
First of all,
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
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
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 of
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
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.
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
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;
Removing this leads
Tom,
-class LLVMEnsureMultithreaded {
-public:
- LLVMEnsureMultithreaded()
- {
- llvm_start_multithreaded();
- }
-};
-
-static LLVMEnsureMultithreaded lLVMEnsureMultithreaded;
Removing this leads to crashes in llvm with applications that concurrently
work on different gl
Am 17.04.2013 01:13, schrieb Tom Stellard:
From: Tom Stellard thomas.stell...@amd.com
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
From: Tom Stellard thomas.stell...@amd.com
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
26 matches
Mail list logo
