eic-opticks/sysrap/sstate.h

0001 #pragma once
0002
0003 #if defined(__CUDACC__) || defined(__CUDABE__)
0004    #define SSTATE_METHOD __device__
0005 #else
0006    #define SSTATE_METHOD
0007 #endif
0008
0009 /**
0010 sstate.h
0011 =========
0012
0013 This was formerly qstate.h but as no CUDA specifics it
0014 belongs down in sysrap not up in QUDARap.
0015
0016 Populated by qsim::fill_state from texture and buffer lookups
0017 using photon wavelength and the boundary obtained from geometry
0018 intersect.
0019
0020 Old version of this in OptiXRap/cu also copied things from "PRD" into here ...
0021 BUT seems no point doing that, can just directly use them from PRD.
0022
0023 **/
0024
0025 struct sstate
0026 {
0027     float4 material1 ;    // refractive_index/absorption_length/scattering_length/reemission_prob
0028     float4 m1group2 ;     // group_velocity/spare1/spare2/spare3
0029     float4 material2 ;
0030     float4 surface ;      // detect/absorb/reflect_specular/reflect_diffuse
0031
0032     uint4  optical ;      // x/y/z/w index/type/finish/value
0033     uint4  index ;        // indices of m1/m2/surf/sensor
0034
0035 #ifdef WAY_ENABLED
0036     float4 way0 ;
0037     float4 way1 ;
0038 #endif
0039
0040 #if defined(__CUDACC__) || defined(__CUDABE__)
0041 #else
0042     void save(const char* dir) const ;
0043 #endif
0044
0045
0046 };
0047
0048 #if defined(__CUDACC__) || defined(__CUDABE__)
0049 #else
0050 #include "NP.hh"
0051 inline void sstate::save(const char* dir) const
0052 {
0053     NP* st = NP::Make<float>(1, 6, 4 );
0054     st->read2( (float*)&material1.x  );
0055     st->save(dir, "s.npy");
0056     // see QState::Save for a more fussy alternative
0057 }
0058 #endif
0059
0060
0061
0062
0063
0064 #if defined(__CUDACC__) || defined(__CUDABE__)
0065 #else
0066 inline std::ostream& operator<<(std::ostream& os, const sstate& s )
0067 {
0068     os << "sstate"
0069        << std::endl
0070        << " material1 " << s.material1
0071        << " (refractive_index/absorption_length/scattering_length/reemission_prob) "
0072        << std::endl
0073        << " m1group2 " << s.m1group2
0074        << " (group_velocity/spare1/spare2/spare3) "
0075        << std::endl
0076        << " material2 " << s.material2
0077        << " (refractive_index/absorption_length/scattering_length/reemission_prob) "
0078        << std::endl
0079        << " surface   " << s.surface
0080        << " (detect/absorb/reflect_specular/reflect_diffuse) "
0081        << std::endl
0082        << " optical   " << s.optical
0083        << " (x/y/z/w index/type/finish/value) "
0084        << std::endl
0085        << " index     " << s.index
0086        << " (indices of m1/m2/surf/sensor) "
0087        << std::endl
0088        ;
0089     return os;
0090 }
0091 #endif
0092
0093
0094
0095
0096
0097
0098
0099
0100
0101 /**
0102 https://stackoverflow.com/questions/252552/why-do-we-need-c-unions
0103
0104 https://forums.developer.nvidia.com/t/handling-structures-with-bitfields/60628
0105
0106    njuffa April 24, 2018, 7:02pm #3 : My advice, based on experience gathered over 25 years: Avoid bitfields.
0107
0108
0109 See sysrap/tests/squadUnionTest.cc for idea to have cake and eat it too, ie easy access and easy persisting::
0110
0111     union qstate2
0112     {
0113         struct
0114         {
0115             float m1_refractive_index ;
0116             float m1_absorption_length ;
0117             float m1_scattering_length ;
0118             float m1_reemission_prob ;
0119
0120             float m2_refractive_index ;
0121             float m2_absorption_length ;
0122             float m2_scattering_length ;
0123             float m2_reemission_prob ;
0124
0125         } field ;
0126
0127         quad2 q ;
0128     };
0129
0130 Actually persisting is not much of a reason as can just cast the
0131 entire qstate to a quad6 for example.
0132
0133 But if decide to pursure streamlined qstate with mixed up fields
0134 the named field access would be helpful to isolate user code from changes to the struct.
0135
0136 **/
0137
0138
0139