xtra-computing / thundergp Goto Github PK
View Code? Open in Web Editor NEWHLS-based Graph Processing Framework on FPGAs
License: Apache License 2.0
thundergp's Issues
Supporting Vitis and XRT recent versions
As indicated in the README, the current platform and tools under evaluation exclusively support the 2019 version of SDAccel. However, I am interested in understanding whether there are plans in place to update this setup to accommodate Vitis and more recent versions of XRT.
My attempts to install SDAccel 2019 have proven unsuccessful, primarily due to the fact that the platform I'm using is setup for XRT 2022, a version that SDAccel 2019 does not recognize.
Is there any indication or possibility of recompiling the code using Vitis 2022? I've made an attempt in this direction, but I encountered errors related to some of the generated IPCores. It appears that a comprehensive and thorough revision of the code may be necessary to align it with the new environment.
I appreciate any hint and help,
Best regards
The exploration of resources in the u50 version
Hi~ I wonder why SubpartitionNum(KernelNum) is a fixed value in the u50 version, is it because there is something in the vitis version that limits the exploration of resources?
Possible bug with specific application, CModel gives correct results
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 and MEM_ID_PUSHIN_PROP_MAPPED. Note that some vertices are also missing from MEM_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.
$ ./host_graph_fpga_dc1 xclbin_dc1/*.xclbin dataset/rmat-14-32.txt
Found 1 platforms!
Found 1 devices!
file is xclbin_dc1/graph_fpga.hw.xilinx_u250_xdma_201830_2.xclbin xclbin_dc1/graph_fpga.hw.xilinx_u250_xdma_201830_2.xclbin
INFO: Importing xclbin_dc1/graph_fpga.hw.xilinx_u250_xdma_201830_2.xclbin
INFO: Loaded file
INFO: Created Binary
INFO: Built Program
Graph dataset/rmat-14-32.txt is loaded.
vertex num: 16384
edge num: 524288
unpad edge_tuple_range 524288
ratio 12501 / 16384 is 0.763000
ratio 12501 / 16384 is 0.763000
ratio 12501 / 16384 is 0.763000
ratio 12501 / 16384 is 0.763000
[EST]: 1 is expected to exe in 0.401833ms
[EST]: 0 is expected to exe in 0.401825ms
[EST]: 2 is expected to exe in 0.401783ms
[EST]: 3 is expected to exe in 0.401734ms
[EST]: finalOrder 3 total exe: 0.401734ms
[EST]: finalOrder 2 total exe: 0.401783ms
[EST]: finalOrder 0 total exe: 0.401825ms
[EST]: finalOrder 1 total exe: 0.401833ms
[SIZE] 526336 cur_edge_num sub 131072
[SIZE] 526336 cur_edge_num sub 131072
[SIZE] 526336 cur_edge_num sub 131072
[SIZE] 526336 cur_edge_num sub 131072
----------------------------------------------------------------------------------
[PART] subPartitions 0 info :
[PART] edgelist from 0 to 131072
[PART] dst. vertex from 0 to 12500
[PART] src. vertex from 9600 to 12500
[PART] dump: 9600 - 12500
[PART] scatter cache ratio 0.000000
[PART] v/e 0.095367
[PART] v: 12500 e: 131072
[PART] est. efficient 10.484921
[PART] compressRatio 0.763000
[SCHE] 0 with 526336 @ 0
transfer base mem start
transfer base mem
transfer subPartitions mem
transfer cu mem
data transfer 5.678447
cmodel error 0 0x00000004 hw: 0x00000000 diff 0x00000004 !!!!
cmodel error 1 0x00000006 hw: 0x00000000 diff 0x00000006 !!!!
cmodel error 2 0x0000000a hw: 0x00000000 diff 0x0000000a !!!!
cmodel error 3 0x0000000e hw: 0x00000000 diff 0x0000000e !!!!
cmodel error 5 0x00000012 hw: 0x00000000 diff 0x00000012 !!!!
cmodel error 6 0x00000016 hw: 0x00000000 diff 0x00000016 !!!!
cmodel error 7 0x00000018 hw: 0x00000000 diff 0x00000018 !!!!
cmodel error 8 0x0000001a hw: 0x00000000 diff 0x0000001a !!!!
cmodel error 9 0x0000001c hw: 0x00000000 diff 0x0000001c !!!!
cmodel error 10 0x0000001e hw: 0x00000000 diff 0x0000001e !!!!
cmodel error 11 0x00000020 hw: 0x00000000 diff 0x00000020 !!!!
cmodel error 12 0x00000022 hw: 0x00000000 diff 0x00000022 !!!!
cmodel error 15 0x0000002a hw: 0x00000000 diff 0x0000002a !!!!
cmodel error 16 0x0000002c hw: 0x00000000 diff 0x0000002c !!!!
cmodel error 17 0x0000002e hw: 0x00000000 diff 0x0000002e !!!!
cmodel error 19 0x00000032 hw: 0x00000000 diff 0x00000032 !!!!
cmodel error 20 0x00000034 hw: 0x00000000 diff 0x00000034 !!!!
cmodel error 22 0x0000003a hw: 0x00000000 diff 0x0000003a !!!!
cmodel error 23 0x0000003c hw: 0x00000000 diff 0x0000003c !!!!
cmodel error 24 0x00000040 hw: 0x00000000 diff 0x00000040 !!!!
cmodel error 26 0x00000044 hw: 0x00000000 diff 0x00000044 !!!!
cmodel error 27 0x00000048 hw: 0x00000000 diff 0x00000048 !!!!
cmodel error 28 0x0000004a hw: 0x00000000 diff 0x0000004a !!!!
cmodel error 29 0x0000004c hw: 0x00000000 diff 0x0000004c !!!!
cmodel error 31 0x00000052 hw: 0x00000000 diff 0x00000052 !!!!
cmodel error 32 0x00000054 hw: 0x00000000 diff 0x00000054 !!!!
cmodel error 34 0x00000058 hw: 0x00000000 diff 0x00000058 !!!!
cmodel error 35 0x0000005a hw: 0x00000000 diff 0x0000005a !!!!
cmodel error 36 0x0000005c hw: 0x00000000 diff 0x0000005c !!!!
cmodel error 37 0x0000005e hw: 0x00000000 diff 0x0000005e !!!!
cmodel error 38 0x00000060 hw: 0x00000000 diff 0x00000060 !!!!
cmodel error 39 0x00000062 hw: 0x00000000 diff 0x00000062 !!!!
cmodel error 40 0x00000064 hw: 0x00000000 diff 0x00000064 !!!!
cmodel error 41 0x00000068 hw: 0x00000000 diff 0x00000068 !!!!
cmodel error 42 0x0000006a hw: 0x00000000 diff 0x0000006a !!!!
cmodel error 43 0x0000006c hw: 0x00000000 diff 0x0000006c !!!!
cmodel error 44 0x0000006e hw: 0x00000000 diff 0x0000006e !!!!
cmodel error 45 0x00000072 hw: 0x00000000 diff 0x00000072 !!!!
cmodel error 47 0x0000007a hw: 0x00000000 diff 0x0000007a !!!!
cmodel error 48 0x0000007c hw: 0x00000000 diff 0x0000007c !!!!
cmodel error 50 0x00000080 hw: 0x00000000 diff 0x00000080 !!!!
cmodel error 51 0x00000082 hw: 0x00000000 diff 0x00000082 !!!!
cmodel error 52 0x00000084 hw: 0x00000000 diff 0x00000084 !!!!
cmodel error 53 0x00000086 hw: 0x00000000 diff 0x00000086 !!!!
cmodel error 54 0x00000088 hw: 0x00000000 diff 0x00000088 !!!!
cmodel error 55 0x0000008c hw: 0x00000000 diff 0x0000008c !!!!
cmodel error 56 0x0000008e hw: 0x00000000 diff 0x0000008e !!!!
cmodel error 57 0x00000090 hw: 0x00000000 diff 0x00000090 !!!!
cmodel error 58 0x00000092 hw: 0x00000000 diff 0x00000092 !!!!
total cmodel error: 11352
Property for "first 10" vertices:
1
2
3
4
5
6
7
8
9
10
Number of vertices with non-null property:16384
Property for "first 10" vertices:
2
3
5
7
8
9
11
12
13
14
Buffer Allocation Failed on U280 when Running on Larger Graphs
Description
Hi! I cloned the code from branch 'v_HBM' and attempted to execute BFS on U280 FPGA. The execution went smoothly with the provided dataset (rmat-14-32.txt). However, when I tried to run it with larger graphs——specifically, using soc-LiveJournal1.txt downloaded from the Stanford Network Dataset Collection——the program crashed during buffer allocation on the U280. Below is the error log:
[XRT] ERROR: std::bad_alloc
./main.cpp:86 Error calling edge_buffers.emplace_back(cl::Buffer(context, flags, edgesHeadArrays[i].size, &(edgesHeadArrays[i].ext_attr), &status)), error code is: -5
I've made a few adjustments to the host code by rewriting it using OpenCL2, but it's not the cause of the error. It appears that the issue lies in XRT's inability to allocate a buffer larger than 256MB with HBM.
Referrence:
- https://support.xilinx.com/s/question/0D52E00006hpYHiSAM/when-i-use-clcreatebuffer-for-physical-memory-but-this-function-return-error-code6?language=en_US
- https://support.xilinx.com/s/question/0D52E00007ECLNySAP/how-to-configure-data-layout-across-multiple-hbm-channels?language=en_US
So, I'm wondering it may be hard for the accelerator to support large graph processing as long as the size of edgesHeadArray exceeds 256 MB.
To Reproduce
Steps to reproduce the behavior:
- Clone the
v_HBMcode. - Compile the project.
- Download graph
soc-LiveJournalfrom SNAP, extract it to dataset folder. - Run command
./host_graph_fpga_bfs xclbin_hw_bfs/graph_fpga.hw.xilinx_u280_gen3x16_xdma_1_202211_1.xclbin dataset/soc-LiveJournal1.txt. - See error.
Platform:
- Device: U280 FPGA
- OS: Ubuntu 18.04.6 LTS
Your assistance in resolving this issue is greatly appreciated!
Example of implementing the accelerator for PageRank on Alveo U250 platform
While running the commands as listed in the github page for pagerank application on u250 platform, the make process fails
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
- Run the commands as :
- git clone https://github.com/Xtra-Computing/ThunderGP.git
$ cd ./
$ vim ThunderGP.mk
$ # configure the DEVICE as DEVICES := xilinx_u250_xdma_201830_2; configure TARGETS := hw
$ make app=pr all
3
error.txt
. See error
Expected behavior
The make process should pass.
Screenshots
The resulting logs have been attached to this issue.
Desktop :
- OS: Ubuntu 18.04
- Xilinx SDx 2018.3
- Gcc version 7.5(this might be the problem that might be causing since required is 9.3)
- Device-Alveo u250
Thank you
Questions on EDGE_NUM and PE_NUM.
Unless I'm misunderstanding, ThunderGP accesses EDGE_NUM edges and shuffles them to PE_NUM PEs in each cycle.
Is there any reason that the number of PEs is set as twice as that of edges?
Moreover, I also wonder whether the DRAM bandwidth can be fully utilized with 8 edges and 16 PEs since U200 provides up to 77GB/s bandwidth.
Accessing Properties of Vertices with Null Out-Degree
Hi everyone.
I'm wondering about accessing the property of vertices with out-degree equal to 0.
I understand these are somehow filtered out of certain computations since they generate no updates, but they should still receive updates so I'd like to access their property after some number of supersteps.
I would also appreciate an explanation on the various MEM_ID pointers.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.