Closed pf-un closed 3 years ago
Just to be clear, acceleratorQueryProperty(0)
gives the same results as MEM_ID_PUSHIN_PROP_MAPPED
.
I just found out that if I run acceleratorCModelSuperStep()
twice I get non-null values for hw
:
acceleratorSuperStep(0, &graphDataInfo);
acceleratorCModelSuperStep(0, &graphDataInfo);
acceleratorCModelSuperStep(1, &graphDataInfo);
cmodel error 0 0x00000008 hw: 0x00000002 diff 0x00000006 !!!!
cmodel error 1 0x0000000c hw: 0x00000003 diff 0x00000009 !!!!
cmodel error 2 0x00000014 hw: 0x00000005 diff 0x0000000f !!!!
cmodel error 3 0x0000001c hw: 0x00000007 diff 0x00000015 !!!!
cmodel error 4 0x00000000 hw: 0x00000008 diff 0xfffffff8 !!!!
cmodel error 5 0x00000024 hw: 0x00000009 diff 0x0000001b !!!!
[...]
So this might be an issue with the ping-pong mechanism, no? Regardless the issue of the vertex properties not doubling remains.
Actually, regarding my last comment, vertex 7 (with value 8) has value 0 in the CModel, when it should be 8*2*2=0x20
. I checked the dataset and 7 has in-degree 0, which might explain that. Nonetheless this is a different issue.
@HongshiTan, I've uploaded a compressed archive of the xclbin folder here.
I also tried:
inline prop_t scatterFunc(prop_t srcProp, prop_t edgeProp)
{
return (edgeProp);
}
inline prop_t gatherFunc(prop_t ori, prop_t update)
{
return (update);
}
and
inline prop_t scatterFunc(prop_t srcProp, prop_t edgeProp)
{
return 0+edgeProp;
}
inline prop_t gatherFunc(prop_t ori, prop_t update)
{
return 0+update;
}
The results are the same.
After analyzing your code and the simulation waveform, I think it is the problem of the gatherFunc. Can I confirm with you that you are going to gather the latest update (only one update from the neighbour) of a vertex rather than the sum of all the update from its neighbour?
Exactly. For this test, I'm only interested in the last update/last neighbour to be processed.
The expected outcome is to double the property of each vertex, so I set all edge properties to 2 and only propagate the edge properties during the scatter phase.
OK, I changed the gatherFunc as follows (that may not be the final solution):
inline prop_t gatherFunc(prop_t ori, prop_t update) { return update>ori? update:ori; }
The problem comes from the HLS compiler, if ori is not used, the entire function and the logic that relies on this function would be over-simplification by LLVM, which leads to a wrong result (e.g, the update is directly connected to the initial register which is zero)
the above code is only applied to the cases that all edge property is the same value.
Some details you might be interested in: In fpga_application.h, you can see the gatherFunc is used in three modules: RAW solver, gather, and property merging. The compiler can not handle your code well in the RAW solver and property merging modules.
I suspected as much but didn't come up with an adequate test for the scenario unfortunately! Thanks for looking into it. For future reference: beware of over-optimisation/optimising out by the compiler!
P.S. I'll probably update #8 soon with an example application (SSSP) showing the discrepancy between vertex properties accessed via acceleratorQueryProperty
and what I'd expect are the correct vertex properties -- hopefully you can have a look at that as well.
OK, we can provide an API to access the property as you expected
I believe there may be a bug running this specific application, which is meant to double the property of all vertices (via edge properties).
When executing a superstep, the vertex properties remain unaltered. CModel reports what I would expect to be the correct result, but additionally seems to think the vertex properties are all 0 when they are not (since they are unaltered!).
Note that I set the vertex property to i+1 (so vertex 0 has property 1).
See below the results of a run. After the CModel verification I print the first 10 entries for
MEM_ID_PUSHIN_PROP
andMEM_ID_PUSHIN_PROP_MAPPED
. Note that some vertices are also missing fromMEM_ID_PUSHIN_PROP_MAPPED
as per #8 but this is not the issue at hand here. None of the vertices have had their property doubled.I am running on a U250 and using SDAccel 2018.3.