Mesa Looks At Switching To Jemalloc For Faster Performance

[marek]

I tried playing with glibc's flags to no avail.

It might not be possible to detect jemalloc that is linked statically in apps. (Firefox)

[Hi-Angel]

I reported a bug to Archlinux package for Firefox, will see.

[schmidtbag]

so you have irrational fear of something which you even did not bother to look up, therefore you will choose 10% slower shader compiler. nice

It's not an irrational fear... Linus himself feels uncomfortable when the kernel gets bigger by a few hundred kilobytes. Mesa is miniscule in comparison, so a few hundred KB for one feature could cascade. It's not a hard concept to grasp. Sure, I could have done my research to discover that jmalloc isn't that big, but I didn't think I should have had to deal with people like you pestering me for so long over something so petty.

Anyway, it's an opinion - you don't have to like it. I really don't understand why you get so worked up and waste so much time bitching about the most minor things (not just toward me, but anyone).

[cj.wijtmans]

It's not an irrational fear... Linus himself feels uncomfortable when the kernel gets bigger by a few hundred kilobytes. Mesa is miniscule in comparison, so a few hundred KB for one feature could cascade. It's not a hard concept to grasp. Sure, I could have done my research to discover that jmalloc isn't that big, but I didn't think I should have had to deal with people like you pestering me for so long over something so petty.

Anyway, it's an opinion - you don't have to like it. I really don't understand why you get so worked up and waste so much time bitching about the most minor things (not just toward me, but anyone).

To be honest though they could implement their own memory management pool and have the same gains if not more than using jemalloc.

[sdack]

To be honest though they could implement their own memory management pool and have the same gains if not more than using jemalloc.

I thought the same, but when I consider they're compiling shader code then they won't have much control nor information over the memory demand, because this will depend largely on the code they're going to compile. So the allocator needs to scale, but doesn't need diagnostic features, because of the unknown factor. I don't think anyone will want to tweak the allocator for some piece of shader code, when in the end the compiled shader ends up in the cache anyway.

[pal666]

It's not an irrational fear...

it is

Linus himself feels uncomfortable when the kernel gets bigger by a few hundred kilobytes. Mesa is miniscule in comparison

kernel is used on routers with few megabytes of storage. mesa is used on desktops with few terabytes or many gigabytes of storage

[bridgman]

Isn't mesa being used on raspberry pi and similar systems as well (the ones Eric A is working on) ?

[raster]

it iskernel is used on routers with few megabytes of storage. mesa is used on desktops with few terabytes or many gigabytes of storage

Raspberry Pi with 1GB of RAM ... or less. 512MB. In fact many devices like smart watches, and low end smart phones ship with something like 512MB or perhaps even less. Why should mesa NOt be used ... and instead a proprietary binary be required. Mesa has the etnaviv driver for example for vivante GPUs with can ship on SoC's with only a few hundred MB or RAM or even under 100. The world of 3D GFX is more than just hulking huge workstations with gigabytes of RAM.

[dungeon]

Isn't mesa being used on raspberry pi and similar systems as well (the ones Eric A is working on) ?

Used but experimentaly, Raspabian ship mesa driver but is disabled by default... maybe because it is Pi2+, not for Pi1 or Pi Zero (those are low mem anyway)

[pal666]

Raspberry Pi with 1GB of RAM ... or less. 512MB.

i said storage, you replied with ram

Why should mesa NOt be used

correct question is why the fuck whine about jemalloc dependency, considering

$ rpm -q --qf '%{SIZE} %{NAME}\n' mesa-dri-drivers.x86_64 llvm-libs.x86_64 jemalloc
38501303 mesa-dri-drivers
43403008 llvm-libs
604751 jemalloc