/!\ NOTE TO ALL: If you use make_multichannel_2d_array(), this fix may break your code. An extraneous reformat to Fortran order was left in the routine, which your code may be relying on implicitly. This reformat has been removed.
(continue below) On Sonntag 15 März 2009, Ahmed Fasih wrote: > ### Start code snippet > (snip) > ### End code snippet > > So I run this using C-style ordering in the 4-channel array. The > outputs are *garbage*. > > Third, I change the relevant line to "use_c_style = False", so it uses > Fortran-style ordering and rerun the script, and surprisingly, *all is > well*: exactly what I expect is printed out. > > Fourth: just changing it *back* to C-style ordering (and not > changing/doing anything else) and re-running the script, it works > fine!?! > > So it appears that whenever I run the C-style ordering *after* the > Fortran-style ordering, the former works fine. If I run the C-ordered > snippet first, garbage is printed out. And all this is repeatable on > my Quadro FX 5600 by running test/test_driver.py in between these C > vs. Fortran-style orderings. > > Coincidentally, if I take care to use Fortran-style orderings (or > C-style orderings after running with Fortran-style orderings), > make_multichannel_2d_array() handles 1D arrays just fine :) > > Any insights are as always greatly appreciated! You're right, this was a bug. Fixed in current git. You need to modify two things in your own code, too: - Preserve the array returned by drv.make_multichannel_2d_array(my_a, order=my_order). Otherwise, the Array's lifetime ends sooner than you think and it may be overwritten by other allocations. - Don't assume that what comes out of dstack has C layout. (It didn't in my experience.) Also see the doc update here: http://is.gd/nzOT Andreas _______________________________________________ PyCuda mailing list [email protected] http://tiker.net/mailman/listinfo/pycuda_tiker.net
