Hi.
Or this one:
commit ffbec14de21b0d3cf0b77e040308134c49632c22
Author: Roman Lebedev <lebedev...@gmail.com>
Date: Fri Sep 5 23:04:22 2014 +0400
Use size_t to store buffer sizes. With this (and probably following),
DT can open 26770x13385 TIFF
diff --git a/src/common/mipmap_cache.c b/src/common/mipmap_cache.c
index d5e9e98..c0007fb 100644
--- a/src/common/mipmap_cache.c
+++ b/src/common/mipmap_cache.c
@@ -53,7 +53,10 @@ struct dt_mipmap_buffer_dsc
{
uint32_t width;
uint32_t height;
- uint32_t size;
+ size_t size;
+ uint32_t padding1; //
+ uint32_t padding2; // FIXME: any better way ?
+ uint32_t padding3; //
uint32_t flags;
/* NB: sizeof must be a multiple of 4*sizeof(float) */
} __attribute__((packed));
@@ -533,8 +536,7 @@ dt_mipmap_cache_alloc(dt_image_t *img, dt_mipmap_size_t
size, dt_mipmap_cache_al
int32_t wd = img->width;
int32_t ht = img->height;
int32_t bpp = img->bpp;
- const uint32_t buffer_size =
- ((wd*ht*bpp) + sizeof(**dsc));
+ const size_t buffer_size = (((size_t)wd*ht*bpp) + sizeof(**dsc));
// buf might have been alloc'ed before,
// so only check size and re-alloc if necessary:
diff --git a/src/common/mipmap_cache.h b/src/common/mipmap_cache.h
index b69d3e7..b3e483f 100644
--- a/src/common/mipmap_cache.h
+++ b/src/common/mipmap_cache.h
@@ -79,7 +79,7 @@ typedef struct dt_mipmap_cache_one_t
// due to aspect ratio)
uint32_t max_width, max_height;
// size of an element inside buf
- uint32_t buffer_size;
+ size_t buffer_size;
// 1) no memory fragmentation:
// - fixed slots with fixed size (could waste a few bytes for extreme
// aspect ratios)
But yes, most likely one of those.
On Sat, Sep 13, 2014 at 9:57 PM, Pascal Obry <pas...@obry.net> wrote:
>
> My darktable is rebuilding all the cache, this is annoying when having
> more than 40k images. I've checked in the commit what could have
> invalidated the cache, maybe:
>
> commit 3fc5cd4c6c2536689c4d9566b618f5ace49be520
> Author: Roman Lebedev <lebedev...@gmail.com>
> Date: Mon Sep 8 02:34:21 2014 +0400
>
> struct dt_mipmap_buffer_dsc: use __attribute__((packed,aligned(16)))
> for padding
> Type size_ะต may have different size on 32-bit machines, so let's try
> to make compiler do the padding.
>
> diff --git a/src/common/mipmap_cache.c b/src/common/mipmap_cache.c
> index c0007fb..493db53 100644
> --- a/src/common/mipmap_cache.c
> +++ b/src/common/mipmap_cache.c
> @@ -54,12 +54,9 @@ struct dt_mipmap_buffer_dsc
> uint32_t width;
> uint32_t height;
> size_t size;
> - uint32_t padding1; //
> - uint32_t padding2; // FIXME: any better way ?
> - uint32_t padding3; //
> uint32_t flags;
> /* NB: sizeof must be a multiple of 4*sizeof(float) */
> -} __attribute__((packed));
> +} __attribute__((packed,aligned(16)));
>
> // last resort mem alloc for dead images. sizeof(dt_mipmap_buffer_dsc) +
> dead image pixels (8x8)
> // __m128 type for sse alignment.
>
> Is that it?
>
> --
> Pascal Obry / Magny Les Hameaux (78)
>
> The best way to travel is by means of imagination
>
> http://v2p.fr.eu.org
> http://www.obry.net
>
> gpg --keyserver keys.gnupg.net --recv-key F949BD3B
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> darktable-devel mailing list
> darktable-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/darktable-devel
>
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
darktable-devel mailing list
darktable-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/darktable-devel
