-
Notifications
You must be signed in to change notification settings - Fork 75
Closed
Description
I don't see why you're diverging from CUDA for no good reason. I noticed a redundancy with the design of the mtgp_engine class.
This is how it's already done in CUDA.
struct curandStateMtgp32 {
unsigned int s[MTGP32_STATE_SIZE];
int offset;
int pIdx;
mtgp32_kernel_params_t * k;
int precise_double_flag;
};
Let's take a look at rocRAND.
Fields of the mtgp32_kernel_params_t class:
public:
// State
mtgp32_state m_state;
// Parameters
unsigned int pos_tbl;
unsigned int param_tbl[MTGP_TS];
unsigned int temper_tbl[MTGP_TS];
unsigned int single_temper_tbl[MTGP_TS];
unsigned int sh1_tbl;
unsigned int sh2_tbl;
unsigned int mask;
Fields of t mtgp32_kernel_params_t:
unsigned int pos_tbl[MTGP_BN_MAX];
unsigned int param_tbl[MTGP_BN_MAX][MTGP_TS];
unsigned int temper_tbl[MTGP_BN_MAX][MTGP_TS];
unsigned int single_temper_tbl[MTGP_BN_MAX][MTGP_TS];
unsigned int sh1_tbl[MTGP_BN_MAX];
unsigned int sh2_tbl[MTGP_BN_MAX];
unsigned int mask[1];
Why not simply define the mtgp_engine class to have a pointer to mtgp32_kernel_params_t?
Example:
public:
// State
mtgp32_state m_state;
// Parameters
mtgp32_kernel_params_t * k;
Reason One
Better object oriented design. I should be able to create a single mtgp32_kernel_params and reuse that object in other hiprandStateMtgp32_t states. Otherwise, you'll have to do bloated things such as
my_state.pos_tbl = mtgp32_kernel_params.pos_tbl;
my_state.param_tbl = mtgp32_kernel_params.param_tbl;
my_state.temper_tbl = mtgp32_kernel_params.temper_tbl;
my_state.single_temper_tbl = mtgp32_kernel_params.single_temper_tbl;
my_state.sh1_tbl = mtgp32_kernel_params.sh1_tbl;
my_state.sh2_tbl = mtgp32_kernel_params.sh2_tbl;
my_state.mask = mtgp32_kernel_params.mask;
Reason Two
Unnecessary divergence from the CUDA API leading to more work to have new frameworks run seamlessly.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels