Haven't I read in many places that the Linux port of NS2 is extremely
crappy?
Perhaps you shouldn't pay too much attention to that... Then again, maybe
it's a good torture test. :-)
Regards
//Ernst
2016-09-01 18:11 GMT+02:00 Marek Olšák :
> On Aug 31, 2016 11:31 AM, "Eero Tamminen"
> wrote:
> >
On Aug 31, 2016 11:31 AM, "Eero Tamminen" wrote:
>
> Hi,
>
>
> On 31.08.2016 08:03, Kenneth Graunke wrote:
>>
>> On Tuesday, August 30, 2016 3:52:12 PM PDT Ian Romanick wrote:
>> [snip]
>>>
>>> I don't recall any native Linux games encountering this, but my memory
>>> may have faded. There were s
Am Mittwoch, 31. August 2016, 22:07:48 CEST schrieb Emil Velikov:
> On 31 August 2016 at 17:39, Marek Olšák wrote:
> > On Wed, Aug 31, 2016 at 4:39 PM, Eero Tamminen
> >
> > wrote:
> >> Hi,
> >>
> >> On 31.08.2016 16:37, Marek Olšák wrote:
> >> ...
> >>
> >>> OK. I'm afraid malloc/calloc/reall
On 31 August 2016 at 17:39, Marek Olšák wrote:
> On Wed, Aug 31, 2016 at 4:39 PM, Eero Tamminen
> wrote:
>> Hi,
>>
>> On 31.08.2016 16:37, Marek Olšák wrote:
>> ...
>>>
>>> OK. I'm afraid malloc/calloc/realloc/free from libjemalloc.so will
>>> conflict with libc and Steam.
>>
>>>
>>>
>>> When bui
On Wed, Aug 31, 2016 at 4:39 PM, Eero Tamminen
wrote:
> Hi,
>
> On 31.08.2016 16:37, Marek Olšák wrote:
> ...
>>
>> OK. I'm afraid malloc/calloc/realloc/free from libjemalloc.so will
>> conflict with libc and Steam.
>
>>
>>
>> When building jemalloc from source, there is an option to add a functio
On Wed, Aug 31, 2016 at 05:39:20PM +0300, Eero Tamminen wrote:
> Hi,
Hi,
>
> On 31.08.2016 16:37, Marek Olšák wrote:
> ...
> > OK. I'm afraid malloc/calloc/realloc/free from libjemalloc.so will
> > conflict with libc and Steam.
> >
> > When building jemalloc from source, there is an option to ad
Hi,
On 31.08.2016 16:37, Marek Olšák wrote:
...
OK. I'm afraid malloc/calloc/realloc/free from libjemalloc.so will
conflict with libc and Steam.
>
When building jemalloc from source, there is an option to add a function prefix.
There are basically two options at the moment:
- my allocator: is
On 31 August 2016 at 14:37, Marek Olšák wrote:
> On Wed, Aug 31, 2016 at 3:02 PM, Emil Velikov
> wrote:
>> On 31 August 2016 at 13:40, Marek Olšák wrote:
>>> On Aug 31, 2016 5:02 AM, "Michel Dänzer" wrote:
On 30/08/16 06:51 PM, Marek Olšák wrote:
>
> If we don't care about
On Wed, Aug 31, 2016 at 3:02 PM, Emil Velikov wrote:
> On 31 August 2016 at 13:40, Marek Olšák wrote:
>> On Aug 31, 2016 5:02 AM, "Michel Dänzer" wrote:
>>>
>>> On 30/08/16 06:51 PM, Marek Olšák wrote:
>>> >
>>> > If we don't care about memory usage, let's use my allocator. If we do,
>>> > let's
On 31 August 2016 at 13:40, Marek Olšák wrote:
> On Aug 31, 2016 5:02 AM, "Michel Dänzer" wrote:
>>
>> On 30/08/16 06:51 PM, Marek Olšák wrote:
>> >
>> > If we don't care about memory usage, let's use my allocator. If we do,
>> > let's import jemalloc into the Mesa tree and use it for ralloc.
>>
HI,
On 31.08.2016 15:40, Marek Olšák wrote:
On Aug 31, 2016 5:02 AM, "Michel Dänzer" wrote:
On 30/08/16 06:51 PM, Marek Olšák wrote:
If we don't care about memory usage, let's use my allocator. If we do,
let's import jemalloc into the Mesa tree and use it for ralloc.
Instead of importing
On Aug 31, 2016 5:02 AM, "Michel Dänzer" wrote:
>
> On 30/08/16 06:51 PM, Marek Olšák wrote:
> >
> > If we don't care about memory usage, let's use my allocator. If we do,
> > let's import jemalloc into the Mesa tree and use it for ralloc.
>
> Instead of importing jemalloc into Mesa, could we use
NS2 causes mmap failures on radeonsi. My guess is that there is a memory
leak somewhere. I have no evidence that the compiler is responsible for
that.
Marek
On Aug 31, 2016 11:31 AM, "Eero Tamminen" wrote:
> Hi,
>
> On 31.08.2016 08:03, Kenneth Graunke wrote:
>
>> On Tuesday, August 30, 2016 3:
On 08/31/2016 08:03 AM, Kenneth Graunke wrote:
On Tuesday, August 30, 2016 3:52:12 PM PDT Ian Romanick wrote:
[snip]
I don't recall any native Linux games encountering this, but my memory
may have faded. There were some Windows DirectX games that would
exhaust VMA when run inside VMware. Once
Hi,
On 31.08.2016 08:03, Kenneth Graunke wrote:
On Tuesday, August 30, 2016 3:52:12 PM PDT Ian Romanick wrote:
[snip]
I don't recall any native Linux games encountering this, but my memory
may have faded. There were some Windows DirectX games that would
exhaust VMA when run inside VMware. Onc
On Tuesday, August 30, 2016 3:52:12 PM PDT Ian Romanick wrote:
[snip]
> I don't recall any native Linux games encountering this, but my memory
> may have faded. There were some Windows DirectX games that would
> exhaust VMA when run inside VMware. Once we got to the point where the
> GLSL IR was
On 30/08/16 06:51 PM, Marek Olšák wrote:
>
> If we don't care about memory usage, let's use my allocator. If we do,
> let's import jemalloc into the Mesa tree and use it for ralloc.
Instead of importing jemalloc into Mesa, could we use the shared
libjemalloc.so.1?
--
Earthling Michel Dänzer
On Tue, 2016-08-30 at 15:52 -0700, Ian Romanick wrote:
> On 08/30/2016 07:06 AM, Marek Olšák wrote:
> >
> > On Tue, Aug 30, 2016 at 3:21 PM, Eero Tamminen
> > wrote:
> > >
> > > Hi,
> > >
> > >
> > > On 30.08.2016 12:51, Marek Olšák wrote:
> > > >
> > > >
> > > > Recently I discovered that o
On Tue, 2016-08-30 at 16:14 -0400, Connor Abbott wrote:
> On Tue, Aug 30, 2016 at 10:06 AM, Marek Olšák
> wrote:
> >
> > On Tue, Aug 30, 2016 at 3:21 PM, Eero Tamminen
> > wrote:
> > >
> > > Hi,
> > >
> > >
> > > On 30.08.2016 12:51, Marek Olšák wrote:
> > > >
> > > >
> > > > Recently I dis
On 08/30/2016 07:06 AM, Marek Olšák wrote:
> On Tue, Aug 30, 2016 at 3:21 PM, Eero Tamminen
> wrote:
>> Hi,
>>
>>
>> On 30.08.2016 12:51, Marek Olšák wrote:
>>>
>>> Recently I discovered that our GLSL compiler spends a lot of time in
>>> rzalloc_size, so I looked at possible options to optimize th
On Tue, Aug 30, 2016 at 10:06 AM, Marek Olšák wrote:
> On Tue, Aug 30, 2016 at 3:21 PM, Eero Tamminen
> wrote:
>> Hi,
>>
>>
>> On 30.08.2016 12:51, Marek Olšák wrote:
>>>
>>> Recently I discovered that our GLSL compiler spends a lot of time in
>>> rzalloc_size, so I looked at possible options to
On Tue, Aug 30, 2016 at 4:06 PM, Marek Olšák wrote:
> On Tue, Aug 30, 2016 at 3:21 PM, Eero Tamminen
> wrote:
>> Hi,
>>
>>
>> On 30.08.2016 12:51, Marek Olšák wrote:
>>>
>>> Recently I discovered that our GLSL compiler spends a lot of time in
>>> rzalloc_size, so I looked at possible options to o
On Tue, Aug 30, 2016 at 3:21 PM, Eero Tamminen
wrote:
> Hi,
>
>
> On 30.08.2016 12:51, Marek Olšák wrote:
>>
>> Recently I discovered that our GLSL compiler spends a lot of time in
>> rzalloc_size, so I looked at possible options to optimize that. It's
>> worth noting that too many existing alloca
Hi,
On 30.08.2016 12:51, Marek Olšák wrote:
Recently I discovered that our GLSL compiler spends a lot of time in
rzalloc_size, so I looked at possible options to optimize that. It's
worth noting that too many existing allocations slow down subsequent
malloc calls, which in turn slows down the GL
Results for single-threaded shader-db (using shaders from one game
only) including LLVM compilation:
Default:
real0m59.606s
user0m59.488s
sys0m0.104s
Only ralloc is using jemalloc:
real0m55.284s (7.2% less time)
user0m55.032s
sys0m0.244s
Ralloc is using my linear allocato
Hi,
Recently I discovered that our GLSL compiler spends a lot of time in
rzalloc_size, so I looked at possible options to optimize that. It's
worth noting that too many existing allocations slow down subsequent
malloc calls, which in turn slows down the GLSL compiler. When I kept
5 instances of LL
26 matches
Mail list logo
