Re: Optimisation code path for reading images
Piotr Stanczyk <[email protected]> Tue, 18 Jun 2013 16:13:03 +0000
| Newsgroups | gmane.comp.video.openexr.devel,gmane.comp.video.openexr.user |
|---|---|
| Message-ID | <95F01873F66DA54DAD2734EEBF98F86C0110925472@mailbox09.lucas.alllucas.com> |
--===============2208937813317940029== Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_95F01873F66DA54DAD2734EEBF98F86C0110925472mailbox09luca_" --_000_95F01873F66DA54DAD2734EEBF98F86C0110925472mailbox09luca_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hmm - that is interesting, thanks. We typically work with 4.1.2, 4.6.1 and 4.7.1 so it looks like I missed the= versions in between. - Piotr ________________________________ From: Halfdan Ingvarsson [[email protected]] Sent: 18 June 2013 09:06 To: Piotr Stanczyk Cc: [email protected]; [email protected] Subject: Re: [Openexr-devel] Optimisation code path for reading images Also, compiling the EXR2.0 library using gcc 4.2/4.3/4.4 with -O3 results i= n the PIZ compression code producing occasional garbage data (-O3 is the de= fault for cmake release builds). The workaround was to build with -O2. gcc = 4.6 and up seem ok. I didn't test with gcc 4.5. Unfortunately, I didn't have time to dig any deeper as to whether this was = an actual optimizer bug, or whether there are some spurious assumptions in = the code leading to it. Just something to keep in mind. - =BD On 13-06-17 09:35 PM, Piotr Stanczyk wrote: Hi, There have been a few usage cases reported that exercised parts of the opti= mised reading code path which unfortunately revealed erroneous assumptions = in the source. We have a fix for handling these, which also extents to handling more gener= al cases, in a separate branch and will be releasing that once we have bui= lt up more usage cycles. In the meantime, however, a v2.0.1 release will be available shortly, which= disables the optimisation. - Piotr _______________________________________________ Openexr-devel mailing list [email protected]<mailto:[email protected]> https://lists.nongnu.org/mailman/listinfo/openexr-devel --_000_95F01873F66DA54DAD2734EEBF98F86C0110925472mailbox09luca_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> </head> <body ocsi=3D"0" fpstyle=3D"1" bgcolor=3D"#FFFFFF"> <div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: = 10pt;">Hmm - that is interesting, thanks.<br> <br> We typically work with 4.1.2, 4.6.1 and 4.7.1 so it looks like I missed the= versions in between.<br> <div><br> <div style=3D"font-family: Tahoma; font-size: 13px;">- Piotr<br> </div> </div> <div style=3D"font-family: Times New Roman; color: rgb(0, 0, 0); font-size:= 16px;"> <hr tabindex=3D"-1"> <div style=3D"direction: ltr;" id=3D"divRpF240086"><font color=3D"#000000" = face=3D"Tahoma" size=3D"2"><b>From:</b> Halfdan Ingvarsson [halfdan@sidefx.= com]<br> <b>Sent:</b> 18 June 2013 09:06<br> <b>To:</b> Piotr Stanczyk<br> <b>Cc:</b> [email protected]; [email protected]<br> <b>Subject:</b> Re: [Openexr-devel] Optimisation code path for reading imag= es<br> </font><br> </div> <div></div> <div> <div class=3D"moz-cite-prefix">Also, compiling the EXR2.0 library using gcc= 4.2/4.3/4.4 with -O3 results in the PIZ compression code producing occasio= nal garbage data (-O3 is the default for cmake release builds). The workaro= und was to build with -O2. gcc 4.6 and up seem ok. I didn't test with gcc 4.5.<br> <br> Unfortunately, I didn't have time to dig any deeper as to whether this was = an actual optimizer bug, or whether there are some spurious assumptions in = the code leading to it.<br> <br> Just something to keep in mind.<br> <br> - =BD<br> <br> On 13-06-17 09:35 PM, Piotr Stanczyk wrote:<br> </div> <blockquote type=3D"cite"><style id=3D"owaParaStyle" type=3D"text/css">=0A= <!--=0A= p=0A= {margin-top:0;=0A= margin-bottom:0}=0A= -->=0A= BODY {direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;}P = {margin-top:0;margin-bottom:0;}</style> <div style=3D"direction: ltr; font-family: Tahoma; color: rgb(0, 0, 0); fon= t-size: 10pt;"> <font color=3D"black" face=3D"Tahoma" size=3D"2"><span dir=3D"ltr" style=3D= "font-size: 10pt;"><br> Hi, <br> <br> There have been a few usage cases reported that exercised parts of the opti= mised reading code path which unfortunately revealed erroneous assumptions = in the source. <br> <br> We have a fix for handling these, which also extents to handling more gener= al cases, in a separate branch and will be releasing that once we hav= e built up more usage cycles. <br> <br> In the meantime, however, a v2.0.1 release will be available shortly, which= disables the optimisation.<br> <br> <div><br> <br> <div><font size=3D"1"><span style=3D"font-size: 13px;">- Piotr</span></font= ></div> </div> </span></font></div> <br> <fieldset class=3D"mimeAttachmentHeader" target=3D"_blank"></fieldset> <br> <pre>_______________________________________________=0A= Openexr-devel mailing list=0A= <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email protected]= rg" target=3D"_blank">[email protected]</a>=0A= <a class=3D"moz-txt-link-freetext" href=3D"https://lists.nongnu.org/mailman= /listinfo/openexr-devel" target=3D"_blank">https://lists.nongnu.org/mailman= /listinfo/openexr-devel</a>=0A= </pre> </blockquote> <br> </div> </div> </div> </body> </html> --_000_95F01873F66DA54DAD2734EEBF98F86C0110925472mailbox09luca_-- --===============2208937813317940029== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel --===============2208937813317940029==--