Re: [Openexr-devel] Optimisation code path for reading images
Piotr Stanczyk <[email protected]> Tue, 18 Jun 2013 16:15:52 +0000
| Newsgroups | gmane.comp.video.openexr.user,gmane.comp.video.openexr.devel |
|---|---|
| Message-ID | <95F01873F66DA54DAD2734EEBF98F86C011092548E@mailbox09.lucas.alllucas.com> |
--===============9035515685446579987== Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_95F01873F66DA54DAD2734EEBF98F86C011092548Emailbox09luca_" --_000_95F01873F66DA54DAD2734EEBF98F86C011092548Emailbox09luca_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is this something that was quite deterministic in behaviour? (Does anyone have an example of a corrupted image?) - Piotr ________________________________ From: Juri Abramov [[email protected]] Sent: 18 June 2013 09:13 To: Halfdan Ingvarsson; Piotr Stanczyk Cc: [email protected]; [email protected] Subject: RE: [Openexr-devel] Optimisation code path for reading images Hi Halfdan, Yep, we ran into this one too. Was already the case for OpenEXR 1.6/1.7. Would be good to know if it is fixed in 4.5. Juri From: [email protected] [mailto:openex= [email protected]] On Behalf Of Halfdan Ingv= arsson Sent: 18 June, 2013 18: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 ________________________________ This email message is for the sole use of the intended recipient(s) and may= contain confidential information. Any unauthorized review, use, disclosur= e or distribution is prohibited. If you are not the intended recipient, pl= ease contact the sender by reply email and destroy all copies of the origin= al message. ________________________________ --_000_95F01873F66DA54DAD2734EEBF98F86C011092548Emailbox09luca_ 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"> <style>=0A= <!--=0A= @font-face=0A= {font-family:PMingLiU}=0A= @font-face=0A= {font-family:PMingLiU}=0A= @font-face=0A= {font-family:Tahoma}=0A= @font-face=0A= {font-family:Verdana}=0A= @font-face=0A= {font-family:Consolas}=0A= p.MsoNormal, li.MsoNormal, div.MsoNormal=0A= {margin:0in;=0A= margin-bottom:.0001pt;=0A= font-size:12.0pt;=0A= font-family:"Times New Roman","serif";=0A= color:black}=0A= a:link, span.MsoHyperlink=0A= {color:blue;=0A= text-decoration:underline}=0A= a:visited, span.MsoHyperlinkFollowed=0A= {color:purple;=0A= text-decoration:underline}=0A= p=0A= {margin:0in;=0A= margin-bottom:.0001pt;=0A= font-size:12.0pt;=0A= font-family:"Times New Roman","serif";=0A= color:black}=0A= pre=0A= {margin:0in;=0A= margin-bottom:.0001pt;=0A= font-size:10.0pt;=0A= font-family:"Courier New";=0A= color:black}=0A= span.HTMLPreformattedChar=0A= {font-family:"Consolas","serif";=0A= color:black}=0A= span.EmailStyle20=0A= {font-family:"Verdana","sans-serif";=0A= color:#17365D;=0A= font-weight:bold}=0A= .MsoChpDefault=0A= {font-size:10.0pt}=0A= @page WordSection1=0A= {margin:1.0in 1.0in 1.0in 1.0in}=0A= -->=0A= </style><style id=3D"owaParaStyle" type=3D"text/css">P {margin-top:0;margin= -bottom:0;}</style> </head> <body ocsi=3D"0" fpstyle=3D"1" bgcolor=3D"white" lang=3D"EN-US" link=3D"blu= e" vlink=3D"purple"> <div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: = 10pt;">Is this something that was quite deterministic in behaviour?<br> (Does anyone have an example of a corrupted image?)<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"divRpF863779"><font color=3D"#000000" = face=3D"Tahoma" size=3D"2"><b>From:</b> Juri Abramov [[email protected]]<= br> <b>Sent:</b> 18 June 2013 09:13<br> <b>To:</b> Halfdan Ingvarsson; 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"WordSection1"> <p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: &quo= t;Verdana","sans-serif"; color: rgb(23, 54, 93);">Hi Halfdan= ,</span></b></p> <p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: &quo= t;Verdana","sans-serif"; color: rgb(23, 54, 93);"> </sp= an></b></p> <p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: &quo= t;Verdana","sans-serif"; color: rgb(23, 54, 93);">Yep, we ra= n into this one too. Was already the case for OpenEXR 1.6/1.7.</span></b></= p> <p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: &quo= t;Verdana","sans-serif"; color: rgb(23, 54, 93);">Would be g= ood to know if it is fixed in 4.5.</span></b></p> <p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: &quo= t;Verdana","sans-serif"; color: rgb(23, 54, 93);"> </sp= an></b></p> <p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: &quo= t;Verdana","sans-serif"; color: rgb(23, 54, 93);">Juri</span= ></b></p> <p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: &quo= t;Verdana","sans-serif"; color: rgb(23, 54, 93);"> </sp= an></b></p> <div> <div style=3D"border-width: 1pt medium medium; border-style: solid none non= e; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color= ; -moz-border-top-colors: none; -moz-border-right-colors: none; -moz-border= -bottom-colors: none; -moz-border-left-colors: none; -moz-border-image: non= e; padding: 3pt 0in 0in;"> <p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: &quo= t;Tahoma","sans-serif"; color: windowtext;">From:</span></b>= <span style=3D"font-size: 10pt; font-family: "Tahoma","sans-= serif"; color: windowtext;"> openexr-devel-bounces+gabramov=3Dnvid= [email protected] [mailto:openexr-devel-bounces+[email protected]] <b>On = Behalf Of </b> Halfdan Ingvarsson<br> <b>Sent:</b> 18 June, 2013 18: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</span></p> </div> </div> <p class=3D"MsoNormal"> </p> <div> <p class=3D"MsoNormal">Also, compiling the EXR2.0 library using gcc 4.2/4.3= /4.4 with -O3 results in the PIZ compression code producing occasional garb= age data (-O3 is the default 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.<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:</p> </div> <blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt;"> <div> <p class=3D"MsoNormal" style=3D"margin-bottom: 12pt;"><span style=3D"font-s= ize: 10pt; font-family: "Tahoma","sans-serif";"><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.</span></p> <div> <p class=3D"MsoNormal" style=3D"margin-bottom: 12pt;"><span style=3D"font-s= ize: 10pt; font-family: "Tahoma","sans-serif";"> <= /span></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: "T= ahoma","sans-serif";">- Piotr</span></p> </div> </div> </div> <p class=3D"MsoNormal"><br> <br> <br> </p> <pre>_______________________________________________</pre> <pre>Openexr-devel mailing list</pre> <pre><a href=3D"mailto:[email protected]" target=3D"_blank">Openexr-= [email protected]</a></pre> <pre><a href=3D"https://lists.nongnu.org/mailman/listinfo/openexr-devel" ta= rget=3D"_blank">https://lists.nongnu.org/mailman/listinfo/openexr-devel</a>= </pre> </blockquote> <p class=3D"MsoNormal"> </p> </div> <div> <hr> </div> <div>This email message is for the sole use of the intended recipient(s) an= d may contain confidential information. Any unauthorized review, use,= disclosure or distribution is prohibited. If you are not the intende= d recipient, please contact the sender by reply email and destroy all copies of the original message. </div> <div> <hr> </div> <p></p> </div> </div> </div> </body> </html> --_000_95F01873F66DA54DAD2734EEBF98F86C011092548Emailbox09luca_-- --===============9035515685446579987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Openexr-user mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-user --===============9035515685446579987==--