Re: [Openexr-devel] Removing register keyword
I ran some more tests, and with proper CMake flags set for release, and decent optimization, the difference in code generation goes away. So it's gone. Thanks for the PR. On Fri, Sep 30, 2016 at 5:30 PM, Larry Gritz <l...@larrygritz.com> wrote: > I should also point out: it's a higher priority to remove it from public > headers, which are subject to the build flags and language mode of other > apps that use OpenEXR, than it is to remove it from OpenEXR's internals > which are only subject to OpenEXR's own build flags and rules. > > > > On Sep 30, 2016, at 5:09 PM, Larry Gritz <l...@larrygritz.com> wrote: > > > > Don't let me bully you into removing it, if it really does something > useful for performance. > > > > But it will eventually disappear from the language, and it already (even > in C++11 mode, per current VFX Platform specs) is a deprecation warning, > which a lot of software build defaults intentionally turns into > full-fledged errors. > > > > Sorry about the duplicate PR, I should have scanned the list of pending > requests before submitting. > > > > > > -- > Larry Gritz > l...@larrygritz.com > > > -- Ed Hanway R Supervisor // ILM // SF ___ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
[Openexr-devel] Removing register keyword
We have multiple pending pull requests to remove the register keyword from the OpenEXR source. I've looked at the code generated by gcc 4.8 with and without the register keyword, and, despite the claim that compilers don't care about the register keyword any more, the resulting object code for x86-64 is different, and slightly worse without the keyword. That choice of compiler and platform isn't arbitrary -- it's consistent with the VFX reference platform. However, since the difference is relatively small, and may not be present at all for other compilers and target architectures, and people will keep submitting bugs and pull requests as long as the register keyword is there, I'm inclined to go ahead and remove the keyword anyway. If anybody is that concerned about a performance regression on the order of a few percent in the half-from-float constructor, speak now or forever hold your peace. -- Ed Hanway ___ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
Re: [Openexr-devel] EXR texture memory overhead
Regarding OpenEXR pull requests in general, we've been making some slow progress on the backlog, handling the trivial ones first. The develop branch has the latest. Regarding PR 141 specifically, looking back at my notes at the time, there was some concern that the change originally proposed didn't catch all unsupported cases, such as memory-mapped streams, but that doesn't appear to be the case with the PR. Being limited to scan-line files, it won't help in the current case, but it can establish the pattern for another change. I'll merge it now. On Fri, Sep 16, 2016 at 11:55 AM, Larry Gritz <l...@larrygritz.com> wrote: > So it's holding two tiles, per thread, per open tiled input file! > > 2 x RGBA half 64^2 tiles -> 64k per thread per file > x 1000 files x 16 threads -> 1 GB, just for this source of overhead, not > counting anything else like header data or other allocations > > For 64k (two reasonably sized tiles), maybe it would be better to do a > stack allocation just when the extra decode buffer is needed, so there > would be no call to malloc/free and no retained memory. Switch back to a > true malloc only for the rare case of huge tiles where it doesn't seem safe > to do a stack allocation.\? > > > On Sep 16, 2016, at 11:45 AM, Karl Rasche <karlras...@gmail.com> wrote: > > > > But it's not optimal for a use pattern like TextureSystem where the >> typical request is ONE tile, and the next tile it wants may not even be >> adjacent. >> > > Whoops. What I pointed at look like its only the case if you read through > Imf::InputFile. If you use Imf::TiledInputFile (like in exrinput.cpp), I > don't think you hit that buffering. > > > > Wait, I'm not quite sure how threads play into this. Is this allocated >> framebuffer part of the ImageInptut itself? Do threads lock to use it? Or >> is this per thread, per file? >> > > I think the per-thread part is around ImfTiledInputFile.cpp::267 > <https://github.com/openexr/openexr/blob/develop/OpenEXR/IlmImf/ImfTiledInputFile.cpp#L267>. > Each TileBuffer has an uncompressedData ptr which is what the compressor > fills during decode. > > This *should* just be a tile per thread, but it does look like it's held > over the lifetime of the ImfTiledInputFile. > > > > -- > Larry Gritz > l...@larrygritz.com > > > > ___ > Openexr-devel mailing list > Openexr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/openexr-devel > > -- Ed Hanway R Supervisor // ILM // SF ___ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
Re: [Openexr-devel] testOptimizedInterleavePatterns.cpp
It is noted in the comments for this issue:
https://github.com/openexr/openexr/issues/67 Per the latest comment on the
issue thread, the problem is in the test rather than in the library itself.
Sorry that it hasn't been addressed since the issue was filed in 2013 -- it
doesn't show up on the platforms we use regularly build for, which are mainly
64-bit, or we would have cleaned it up long ago.
From: openexr-devel-bounces+ehanway=ilm@nongnu.org
[mailto:openexr-devel-bounces+ehanway=ilm@nongnu.org] On Behalf Of Mathieu
Malaterre
Sent: Sunday, July 05, 2015 9:35 AM
To: openexr-devel@nongnu.org
Cc: 791...@bugs.debian.org
Subject: [Openexr-devel] testOptimizedInterleavePatterns.cpp
Hi all,
I am preparing the debian package for openexr. I am running in the following
issue, when the test suite runs, here is what I get (debian jessie x86/32bits):
[...]
Running testOptimizedInterleavePatterns
Testing SSE optimisation with different interleave patterns (large images)
...
0, 0: RGBHalf read as RGBHalf...OK
0, 1: RGBHalf read as RGBAHalf... OK
0, 2: RGBHalf read as ABGRHalf... OK
0, 3: RGBHalf read as RGBFloat...
error reading back channel B pixel 96,-62 got -nan expected -nan
lt-IlmImfTest: testOptimizedInterleavePatterns.cpp:238: bool
{anonymous}::compare(const Imf_2_2::FrameBuffer, const
Imf_2_2::FrameBuffer, const Box2i, bool): Assertion
`writtenHalf.bits()==readHalf.bits()' failed.
/bin/bash: line 5: 25131 Aborted ${dir}$tst
FAIL: IlmImfTest
==
1 of 1 test failed
==
[...]
This is a hard-failure based on an assert(). Is there an actual issue in
openexr 2.2.0 ?
Thanks much,
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
Re: [Openexr-devel] AC103A8D public key ?
I've published the public key via pgp.mit.edu. It should work now From: openexr-devel-bounces+ehanway=ilm@nongnu.org [mailto:openexr-devel-bounces+ehanway=ilm@nongnu.org] On Behalf Of Piotr Stanczyk Sent: Friday, January 30, 2015 9:34 AM To: Mathieu Malaterre Cc: openexr-devel@nongnu.org openexr-devel@nongnu.org Subject: Re: [Openexr-devel] AC103A8D public key ? Hi Mathieu, How did you get the distro? The keys should be available from here normally http://download.savannah.gnu.org/releases/openexr/ Cheers Piotr On 30 January 2015 at 00:01, Mathieu Malaterre ma...@debian.orgmailto:ma...@debian.org wrote: If this was not clear from my post, I am using the new infrastructure provided by Debian to check upstream source code. Therefore until this public key is accessible somewhere, the following bug cannot be resolved: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776558 Regards, On Thu, Jan 29, 2015 at 8:02 PM, Dillon Bailey shdw...@gmail.commailto:shdw...@gmail.com wrote: Sometimes I will just do: $ wget http://package.tar.gz --no-check-certificate It can bypass it though perhaps you are big into checking and confirming you download. Otherwise just bypass it... On Thu, Jan 29, 2015 at 3:52 AM, Mathieu Malaterre ma...@debian.orgmailto:ma...@debian.org wrote: Hi, I am trying to check ilmbase download: $ wget http://download.savannah.gnu.org/releases/openexr/ilmbase-2.2.0.tar.gz $ wget http://download.savannah.gnu.org/releases/openexr/ilmbase-2.2.0.tar.gz.sig $ gpg --verify ilmbase-2.2.0.tar.gz.sig gpg: assuming signed data in `ilmbase-2.2.0.tar.gz' gpg: Signature made Sun 10 Aug 2014 07:11:49 AM CEST using RSA key ID AC103A8D gpg: Can't check signature: public key not found Where is the public key AC103A8D ? I could not find it anywhere : $ gpg --keyserver pgp.mit.eduhttp://pgp.mit.edu --search-keys AC103A8D gpg: searching for AC103A8D from hkp server pgp.mit.eduhttp://pgp.mit.edu gpg: key AC103A8D not found on keyserver Thanks much ___ Openexr-devel mailing list Openexr-devel@nongnu.orgmailto:Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel ___ Openexr-devel mailing list Openexr-devel@nongnu.orgmailto:Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel ___ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
Re: [Openexr-devel] Virtual destructor for Imath::Frustum.
Imath::Frustum has a virtual destructor. Is this intentional? It's been that way forever, but I see no current usage of it as a polymorphic base class, nor can I envision any, so there's no need for the destructor to be virtual and it probably wasn't intentional. ___ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
Re: [Openexr-devel] Behavioural change in InputPart::readPixels()
I see that check for no slices in several places, some dating back 10 years and
the most recent change being from early to mid 2013, which would have been out
in 2.1, if not earlier. Which prior version are you comparing to?
-Original Message-
From: openexr-devel-bounces+ehanway=ilm@nongnu.org
[mailto:openexr-devel-bounces+ehanway=ilm@nongnu.org] On Behalf Of Halfdan
Ingvarsson
Sent: Thursday, October 30, 2014 1:56 PM
To: openexr-devel@nongnu.org
Subject: [Openexr-devel] Behavioural change in InputPart::readPixels()
Hello
In OpenEXR 2.2, if no slices are specified in a Framebuffer object, when
InputPart::readPixels is called, it throws an exception ('No frame buffer
specified as pixel data destination.'). In prior versions, it would just return
without reading any data.
Before I determine which side of the fence to patch; was this change
intentional?
Thanks,
- ½
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
Re: [Openexr-devel] testOptimizedInterleavePatterns
That's noted in this issue: https://github.com/openexr/openexr/issues/67 though you'd have to dig through the comments to see it. It's apparently in the test program and not in the library, and has only been reported for i386. -Original Message- From: openexr-devel-bounces+ehanway=ilm@nongnu.org [mailto:openexr-devel-bounces+ehanway=ilm@nongnu.org] On Behalf Of Richard PALO Sent: Wednesday, August 13, 2014 2:32 PM To: openexr-devel@nongnu.org Subject: [Openexr-devel] testOptimizedInterleavePatterns Hi, after adding the files missing from the tarball I'm able to get further into the tests... I'm now getting the following (on SunOS 5.11 i386 (32bit) pkgsrc gcc47) === Running testOptimizedInterleavePatterns Testing SSE optimisation with different interleave patterns (large images) ... 0, 0: RGBHalf read as RGBHalf...OK OPTIMISED 0, 1: RGBHalf read as RGBAHalf... OK OPTIMISED 0, 2: RGBHalf read as ABGRHalf... OK 0, 3: RGBHalf read as RGBFloat... error reading back channel B pixel 96,-81 got -NaN expected -NaN Assertion failed: writtenHalf.bits()==readHalf.bits(), file testOptimizedInterleavePatterns.cpp, line 238, function compare Abort (core dumped) FAIL: IlmImfTest sort of green on where to start debugging, but first I'm curious to know if the issue be in the library or perhaps in the test program... thanks for any suggestions ___ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel ___ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
Re: [Openexr-devel] 2.2.0 release plans
I believe it's only when using USE_ZLIB_WINAPI that the min/max issue happens. With that option enabled, zlib.h drags in the windows headers, causing the conflict. There are places in IlmBase that use windows includes directly (IlmThread) already use the #define NOMINMAX prior to the include to avoid this. Question: does anybody really count on the USE_ZLIB_WINAPI option? From: openexr-devel-bounces+ehanway=ilm@nongnu.org [mailto:openexr-devel-bounces+ehanway=ilm@nongnu.org] On Behalf Of Karl Rasche Sent: Wednesday, July 16, 2014 11:08 AM To: Larry Gritz Cc: openexr-devel@nongnu.org Subject: Re: [Openexr-devel] 2.2.0 release plans It sure looks like std::min/max usage is contained to within .cpp files. There's a variety of other places that use the same functions - but only IlmDwaCompressor.cpp was causing problems? That seems a bit wierd. Karl On Wednesday, July 16, 2014, Larry Gritz l...@larrygritz.commailto:l...@larrygritz.com wrote: Another application that uses the OpenEXR libraries will #include the OpenEXR headers, but will not actually use the OpenEXR build system and its command line preprocessor settings. So if this issue extends to any of the header files, you need to fix it in the headers, or it'll be broken in the user's app ___ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
