There are a few regression problems for GIL running on some more exotic platforms - OSF1, SunOS, HP-UX. http://beta.boost.org/development/tests/trunk/developer/gil_release.html We don't have access to these platforms. Perhaps someone who does could give us a hand in fixing these issues? Thanks, Lubomir
Lubomir Bourdev wrote:
We don't have access to these platforms. Perhaps someone who does could give us a hand in fixing these issues?
If you're able to get a HP Testdrive account (testdrive.hp.com) then you can test the aCC failure yourself, but the debugger backtrace is: Starting program: /house/maddock/libs/gil/test/../../../bin.v2/libs/gil/test/main.test/acc/debug/main Program received signal SIGBUS, Bus error si_code: 1 - BUS_ADRALN - Invalid address alignment. 0x4000000000903ac0:0 in boost::gil::packed_channel_reference<unsigned short, ( this=0x9fffffffffffedf0, value=31 '\037') at ../../../boost/gil/extension/dynamic_image/../../channel.hpp:384 384 void set_unsafe(integer_t value) const { this->data() = (this->const_data() & ~channel_mask) | (value<<FirstBit); } (gdb) bt #0 0x4000000000903ac0:0 in boost::gil::packed_channel_reference<unsigned short, (this=0x9fffffffffffedf0, value=31 '\037') at ../../../boost/gil/extension/dynamic_image/../../channel.hpp:384 #1 0x40000000008d75c0:0 in boost::gil::packed_channel_reference<unsigned short, (this=0x9fffffffffffedf0, value=31 '\037') at ../../../boost/gil/extension/dynamic_image/../../channel.hpp:374 #2 0x4000000000b10c60:0 in packed_reference_core<boost::gil::packed_channel_ref erence<unsigned short, (this=0x9fffffffffffee10) at channel.cpp:194 #3 0x4000000000b10f00:0 in packed_reference_core<boost::gil::packed_channel_ref erence<unsigned short,(int)0,(int)5,(bool)1>,boost::gil::packed_channel_referenc e<unsigned short,(int)0,(int)5,(bool)1> >::packed_reference_core()+0x20 () #4 0x4000000000b11000:0 in do_test<packed_reference_core<boost::gil::packed_cha nnel_reference<unsigned short, (this=0x9fffffffffffee10) at channel.cpp:47 #5 0x4000000000b0b040:0 in do_test<packed_reference_core<boost::gil::packed_cha nnel_reference<unsigned short,(int)0,(int)5,(bool)1>,boost::gil::packed_channel_ reference<unsigned short,(int)0,(int)5,(bool)1> > >::do_test()+0x20 () #6 0x4000000000b0acd0:0 in void test_packed_channel_reference<boost::gil::packe d_channel_reference<unsigned short, () at channel.cpp:230 #7 0x4000000000b0a900:0 in test_packed_channel_reference () at channel.cpp:320 #8 0x4000000000b0bf20:0 in test_channel () at channel.cpp:352 #9 0x400000000082d150:0 in main (argc=1, argv=0x9ffffffffffff530) at main.cpp:25 So... it's a data alignment error: I wonder are you trying to write to an integer on a char boundary or something? HTH, John Maddock.
John Maddock wrote:
Lubomir Bourdev wrote:
We don't have access to these platforms. Perhaps someone who does could give us a hand in fixing these issues?
If you're able to get a HP Testdrive account (testdrive.hp.com) then you can test the aCC failure yourself, but the debugger backtrace is:
[...]
So... it's a data alignment error: I wonder are you trying to write to an integer on a char boundary or something?
FWIW, this backtrace points to the same location where I get the unaligned access warnings on Tru64: line 383 (get()) and line 384 (set_unsafe()) in the file channel.hpp. HTH, Markus
John Maddock wrote:
So... it's a data alignment error: I wonder are you trying to write to an integer on a char boundary or something?
John, thanks for your help. I believe this is indeed the problem. GIL needs to read/write a type bigger than a byte that starts at a char* address, so it is possibly not aligned. One approach is to special-case platforms which cannot dereference at a non-byte boundary (I couldn't find a config flag that detects this, anyone?) and provide a special solution for such platforms. The solution I imagine will involve static recursion that reads/writes each byte and shifts it in place. Is there such a code in Boost? My search resulted only in references to a "Boost.Endian" proposal by Darin Adler / Beman Dawes but I couldn't find the code and I don't know if it has a solution to the above problem. Lubomir
Lubomir Bourdev wrote:
John Maddock wrote:
So... it's a data alignment error: I wonder are you trying to write to an integer on a char boundary or something?
John, thanks for your help. I believe this is indeed the problem. GIL needs to read/write a type bigger than a byte that starts at a char* address, so it is possibly not aligned.
One approach is to special-case platforms which cannot dereference at a non-byte boundary (I couldn't find a config flag that detects this, anyone?) and provide a special solution for such platforms. The solution I imagine will involve static recursion that reads/writes each byte and shifts it in place. Is there such a code in Boost? My search resulted only in references to a "Boost.Endian" proposal by Darin Adler / Beman Dawes but I couldn't find the code and I don't know if it has a solution to the above problem.
No I don't believe we have any such code or a config macro: one of the problems I believe is that whether or not the code will trigger a hardware signal may depend upon whether certain hardware flags are set or not: for example but I seem to remember that even Intel hardware can signal on unaligned access if the right flag is set :-( You could use memcpy, or std::copy to copy the bytes I guess, but that doesn't seem all that efficient? Or it shouldn't be too hard to roll your own "byte copier" for some type T? Regards, John.
Lubomir Bourdev wrote: [...]
I believe this is indeed the problem. GIL needs to read/write a type bigger than a byte that starts at a char* address, so it is possibly not aligned.
One approach is to special-case platforms which cannot dereference at a non-byte boundary (I couldn't find a config flag that detects this, anyone?) and provide a special solution for such platforms. The solution I imagine will involve static recursion that reads/writes each byte and shifts it in place.
[...] For Tru64/CXX there is an easy workaround available, please refer to the attached patch for this. Of course this isn't a general solution, although I would think that acc supports something similar, which then could be wrapped into a macro hiding the platform dependency. But you should be aware that unaligned accesses usually hurt performance a lot, even on platforms where the hardware is able to deal with it. HTH, Markus Index: channel.hpp =================================================================== --- channel.hpp (revision 41078) +++ channel.hpp (working copy) @@ -292,8 +292,8 @@ data_ptr_t operator &() const {return _data_ptr;} protected: static const integer_t max_val = (1<<NumBits) - 1; - const bitfield_t& const_data() const { return *static_cast<const bitfield_t*>(_data_ptr); } - bitfield_t& data() const { return *static_cast< bitfield_t*>(_data_ptr); } + __unaligned const bitfield_t& const_data() const { return *static_cast<const bitfield_t*>(_data_ptr); } + __unaligned bitfield_t& data() const { return *static_cast< bitfield_t*>(_data_ptr); } private: void set(integer_t value) const { // can this be done faster?? const integer_t num_values = max_val+1; @@ -383,7 +383,7 @@ integer_t get() const { return integer_t((this->const_data()&channel_mask) >> FirstBit); } void set_unsafe(integer_t value) const { this->data() = (this->const_data() & ~channel_mask) | (value<<FirstBit); } private: - void set_from_reference(const BitField& other_bits) const { this->data() = (this->const_data() & ~channel_mask) | (other_bits & channel_mask); } + void set_from_reference(__unaligned const BitField& other_bits) const { this->data() = (this->const_data() & ~channel_mask) | (other_bits & channel_mask); } }; } } // namespace boost::gil
Markus Schoepflin wrote:
For Tru64/CXX there is an easy workaround available, please refer to the attached patch for this. Of course this isn't a general solution, although I would think that acc supports something similar, which then could be wrapped into a macro hiding the platform dependency.
aCC supports #pragma unalign [1|2|4|8|16] which is not as convenient, in my opinion, as __unaligned type specifier in cxx compiler. With aCC, you'd have to do something like: #pragma unalign 1 typedef bitfield_t ua_bitfield_t; // bitfield_t with 1 byte alignment ua_bitfield_t& data() const { ... } Thanks, Boris ----- Original Message ----- From: "Markus Schöpflin" <markus.schoepflin@comsoft.de> To: <boost@lists.boost.org> Sent: Wednesday, November 14, 2007 7:46 AM Subject: Re: [boost] [GIL] 64-bit alignment issue
Lubomir Bourdev wrote:
[...]
I believe this is indeed the problem. GIL needs to read/write a type bigger than a byte that starts at a char* address, so it is possibly not aligned.
One approach is to special-case platforms which cannot dereference at a non-byte boundary (I couldn't find a config flag that detects this, anyone?) and provide a special solution for such platforms. The solution I imagine will involve static recursion that reads/writes each byte and shifts it in place.
[...]
For Tru64/CXX there is an easy workaround available, please refer to the attached patch for this. Of course this isn't a general solution, although I would think that acc supports something similar, which then could be wrapped into a macro hiding the platform dependency.
But you should be aware that unaligned accesses usually hurt performance a lot, even on platforms where the hardware is able to deal with it.
HTH, Markus
--------------------------------------------------------------------------------
Index: channel.hpp =================================================================== --- channel.hpp (revision 41078) +++ channel.hpp (working copy) @@ -292,8 +292,8 @@ data_ptr_t operator &() const {return _data_ptr;} protected: static const integer_t max_val = (1<<NumBits) - 1; - const bitfield_t& const_data() const { return *static_cast<const bitfield_t*>(_data_ptr); } - bitfield_t& data() const { return *static_cast< bitfield_t*>(_data_ptr); } + __unaligned const bitfield_t& const_data() const { return *static_cast<const bitfield_t*>(_data_ptr); } + __unaligned bitfield_t& data() const { return *static_cast< bitfield_t*>(_data_ptr); } private: void set(integer_t value) const { // can this be done faster?? const integer_t num_values = max_val+1; @@ -383,7 +383,7 @@ integer_t get() const { return integer_t((this->const_data()&channel_mask) >> FirstBit); } void set_unsafe(integer_t value) const { this->data() = (this->const_data() & ~channel_mask) | (value<<FirstBit); } private: - void set_from_reference(const BitField& other_bits) const { this->data() = (this->const_data() & ~channel_mask) | (other_bits & channel_mask); } + void set_from_reference(__unaligned const BitField& other_bits) const { this->data() = (this->const_data() & ~channel_mask) | (other_bits & channel_mask); } };
} } // namespace boost::gil
--------------------------------------------------------------------------------
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Lubomir Bourdev wrote:
There are a few regression problems for GIL running on some more exotic platforms - OSF1, SunOS, HP-UX.
http://beta.boost.org/development/tests/trunk/developer/gil_release.html
We don't have access to these platforms. Perhaps someone who does could give us a hand in fixing these issues?
Attached patches make the tests compile and execute OK on Tru64/CXX, _but_ there is a flood of unaligned access warning when the test is executed. I'll try to obtain a backtrace of those. Regards, Markus Index: color_convert.hpp =================================================================== --- color_convert.hpp (revision 41054) +++ color_convert.hpp (working copy) @@ -32,7 +32,6 @@ #include "rgb.hpp" #include "rgba.hpp" #include "cmyk.hpp" -#include "image_view_factory.hpp" #include "metafunctions.hpp" #include "utilities.hpp" #include "color_base_algorithm.hpp" Index: pixel_iterator.cpp =================================================================== --- pixel_iterator.cpp (revision 41054) +++ pixel_iterator.cpp (working copy) @@ -22,6 +22,7 @@ #include <boost/gil/step_iterator.hpp> #include <boost/gil/typedefs.hpp> #include <boost/gil/color_convert.hpp> +#include <boost/gil/image_view_factory.hpp> #include <boost/mpl/vector.hpp> using namespace boost::gil;
participants (4)
-
Boris Gubenko -
John Maddock -
Lubomir Bourdev -
Markus Schöpflin