 |
forums.ps2dev.org Homebrew PS2, PSP & PS3 Development Discussions
|
| View previous topic :: View next topic |
| Author |
Message |
Calv!n

Joined: 13 Aug 2007 Posts: 18
|
Posted: Sun Apr 17, 2011 2:32 pm Post subject: gprof and being cpu bound |
|
|
For the past month I have been working on a engine to render massive terrains on psp. The technique I have been modeling my approach after is chunked LOD.
site: http://tulrich.com/geekstuff/chunklod.html
paper: http://tulrich.com/geekstuff/sig-notes.pdf
I wrote a recursive quadtree terrain management module that would load a heightmap of 2^n + 1 size and then recursively chunk it into geomipmapped patches where the LODing factor was distance based. Patches further from view from the camera would have a much lower tessellation than patches near the camera. I am using AABB vs view frustum for culling. Right now my draw distance is 700 meters. In my engine 1 unit = 1 meter.
I have found some quite interesting results. The screenshot below does not support a distance based LOD approach. Take note of the FPS, number of draw calls, and number of triangles rendered.
Now, I have implemented a distance based LOD method.
Check FPS, draw calls, and tris... As you can see in the first shot the number of draw calls and tris rendered are much higher than in this second shot, yet the FPS is nearly the same. This led me to believe I was CPU bound.
With a bit of optimization I made some better results. I even went so far as to start writing inline vfpu asm for the aabbInFrustum() check.
Again notice the FPS, number of draw calls, and number of triangles rendered. There are cracks in the terrain where the LOD changes from patch to patch.
Profiling!
| Code: | Jonathan@jjanevski ~/projects/ruoha/source
$ gprof.exe ruoho.elf
Flat profile:
Each sample counts as 0.001 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
88.44 12.23 12.23 21231 0.00 0.00 aabbInFrustum
4.20 12.82 0.58 13319 0.00 0.00 dist3f_fast
1.68 13.05 0.23 181944 0.00 0.00 getHeight
1.16 13.21 0.16 114509 0.00 0.00 getHeightScaled
0.73 13.31 0.10 1 0.10 0.10 loadHeightfield
0.55 13.38 0.08 763 0.00 0.02 renderQuadtree
0.47 13.45 0.07 44687 0.00 0.00 setVertexUVs
0.47 13.52 0.07 44687 0.00 0.00 vfpu_sqrtf
0.41 13.57 0.06 44687 0.00 0.00 setVertexPosition
0.36 13.62 0.05 44687 0.00 0.00 setVertexNormals
0.35 13.67 0.05 763 0.00 0.02 draw
0.19 13.70 0.03 1 0.03 0.03 loadRtxTexture
0.17 13.72 0.02 763 0.00 0.00 updateCamera
0.16 13.74 0.02 126 0.00 0.00 dist3f
0.15 13.76 0.02 13319 0.00 0.00 getCamMatrix
0.15 13.78 0.02 1 0.02 0.02 setupCallbacks
0.09 13.80 0.01 4578 0.00 0.00 extractPlane
0.08 13.81 0.01 799 0.00 0.00 getHeightTerrain
0.07 13.82 0.01 764 0.00 0.00 running
0.04 13.82 0.01 798 0.00 0.00 handleJoy
0.03 13.83 0.00 763 0.00 0.00 calculateFrustum
0.03 13.83 0.00 763 0.00 0.00 update
0.02 13.83 0.00 763 0.00 0.00 handleCamera
0.01 13.84 0.00 41 0.00 0.00 destroyContents
0.00 13.84 0.00 2 0.00 0.06 gameInit
0.00 13.84 0.00 1 0.00 13.71 app_main
0.00 13.84 0.00 1 0.00 0.11 createQuadtree
0.00 13.84 0.00 1 0.00 0.00 gprof_cleanup
0.00 13.84 0.00 1 0.00 0.03 loadTerrainTexture
0.00 13.84 0.00 1 0.00 13.71 main
% the percentage of the total running time of the
time program used by this function.
cumulative a running sum of the number of seconds accounted
seconds for by this function and those listed above it.
self the number of seconds accounted for by this
seconds function alone. This is the major sort for this
listing.
calls the number of times this function was invoked, if
this function is profiled, else blank.
self the average number of milliseconds spent in this
ms/call function per call, if this function is profiled,
else blank.
total the average number of milliseconds spent in this
ms/call function and its descendents per call, if this
function is profiled, else blank.
name the name of the function. This is the minor sort
for this listing. The index shows the location of
the function in the gprof listing. If the index is
in parenthesis it shows where it would appear in
the gprof listing if it were to be printed.
♀
Call graph (explanation follows)
granularity: each sample hit covers 4 byte(s) for 0.01% of 13.84 seconds
index % time self children called name
0.00 13.71 1/1 main [2]
[1] 99.1 0.00 13.71 1 app_main [1]
0.05 13.45 763/763 draw [4]
0.00 0.11 2/2 gameInit [13]
0.00 0.04 763/763 handleCamera [18]
0.01 0.02 798/798 handleJoy [23]
0.02 0.00 1/1 setupCallbacks [25]
0.01 0.00 764/764 running [29]
0.00 0.00 763/763 update [30]
0.00 0.00 1/1 gprof_cleanup [32]
-----------------------------------------------
0.00 13.71 1/1 _main [3]
[2] 99.1 0.00 13.71 1 main [2]
0.00 13.71 1/1 app_main [1]
-----------------------------------------------
<spontaneous>
[3] 99.1 0.00 13.71 _main [3]
0.00 13.71 1/1 main [2]
-----------------------------------------------
0.05 13.45 763/763 app_main [1]
[4] 97.6 0.05 13.45 763 draw [4]
0.08 13.37 763/763 renderQuadtree [5]
-----------------------------------------------
20468 renderQuadtree [5]
0.08 13.37 763/763 draw [4]
[5] 97.2 0.08 13.37 763+20468 renderQuadtree [5]
12.23 0.00 21231/21231 aabbInFrustum [6]
0.58 0.00 13319/13319 dist3f_fast [7]
0.05 0.29 44687/44687 setVertexNormals [8]
0.06 0.06 44687/44687 setVertexPosition [12]
0.07 0.00 44687/44687 setVertexUVs [16]
0.02 0.00 13319/13319 getCamMatrix [24]
0.01 0.00 41/126 dist3f [22]
0.00 0.00 41/41 destroyContents [31]
0.00 0.00 41/114509 getHeightScaled [10]
20468 renderQuadtree [5]
-----------------------------------------------
12.23 0.00 21231/21231 renderQuadtree [5]
[6] 88.4 12.23 0.00 21231 aabbInFrustum [6]
-----------------------------------------------
0.58 0.00 13319/13319 renderQuadtree [5]
[7] 4.2 0.58 0.00 13319 dist3f_fast [7]
-----------------------------------------------
0.05 0.29 44687/44687 renderQuadtree [5]
[8] 2.5 0.05 0.29 44687 setVertexNormals [8]
0.23 0.00 178748/181944 getHeight [9]
0.07 0.00 44687/44687 vfpu_sqrtf [17]
-----------------------------------------------
0.00 0.00 3196/181944 getHeightTerrain [27]
0.23 0.00 178748/181944 setVertexNormals [8]
[9] 1.7 0.23 0.00 181944 getHeight [9]
-----------------------------------------------
0.00 0.00 41/114509 renderQuadtree [5]
0.06 0.00 44687/114509 setVertexPosition [12]
0.10 0.00 69781/114509 createQuadtree [14]
[10] 1.2 0.16 0.00 114509 getHeightScaled [10]
-----------------------------------------------
<spontaneous>
[11] 0.9 0.00 0.13 init [11]
0.10 0.00 1/1 loadHeightfield [15]
0.00 0.03 1/1 loadTerrainTexture [20]
-----------------------------------------------
0.06 0.06 44687/44687 renderQuadtree [5]
[12] 0.9 0.06 0.06 44687 setVertexPosition [12]
0.06 0.00 44687/114509 getHeightScaled [10]
-----------------------------------------------
0.00 0.11 2/2 app_main [1]
[13] 0.8 0.00 0.11 2 gameInit [13]
0.00 0.11 1/1 createQuadtree [14]
0.00 0.00 1/799 getHeightTerrain [27]
-----------------------------------------------
84 createQuadtree [14]
0.00 0.11 1/1 gameInit [13]
[14] 0.8 0.00 0.11 1+84 createQuadtree [14]
0.10 0.00 69781/114509 getHeightScaled [10]
0.01 0.00 85/126 dist3f [22]
84 createQuadtree [14]
-----------------------------------------------
0.10 0.00 1/1 init [11]
[15] 0.7 0.10 0.00 1 loadHeightfield [15]
-----------------------------------------------
0.07 0.00 44687/44687 renderQuadtree [5]
[16] 0.5 0.07 0.00 44687 setVertexUVs [16]
-----------------------------------------------
0.07 0.00 44687/44687 setVertexNormals [8]
[17] 0.5 0.07 0.00 44687 vfpu_sqrtf [17]
-----------------------------------------------
0.00 0.04 763/763 app_main [1]
[18] 0.3 0.00 0.04 763 handleCamera [18]
0.02 0.00 763/763 updateCamera [21]
0.00 0.01 763/763 calculateFrustum [26]
-----------------------------------------------
0.03 0.00 1/1 loadTerrainTexture [20]
[19] 0.2 0.03 0.00 1 loadRtxTexture [19]
-----------------------------------------------
0.00 0.03 1/1 init [11]
[20] 0.2 0.00 0.03 1 loadTerrainTexture [20]
0.03 0.00 1/1 loadRtxTexture [19]
-----------------------------------------------
0.02 0.00 763/763 handleCamera [18]
[21] 0.2 0.02 0.00 763 updateCamera [21]
-----------------------------------------------
0.01 0.00 41/126 renderQuadtree [5]
0.01 0.00 85/126 createQuadtree [14]
[22] 0.2 0.02 0.00 126 dist3f [22]
-----------------------------------------------
0.01 0.02 798/798 app_main [1]
[23] 0.2 0.01 0.02 798 handleJoy [23]
0.01 0.00 798/799 getHeightTerrain [27]
-----------------------------------------------
0.02 0.00 13319/13319 renderQuadtree [5]
[24] 0.2 0.02 0.00 13319 getCamMatrix [24]
-----------------------------------------------
0.02 0.00 1/1 app_main [1]
[25] 0.2 0.02 0.00 1 setupCallbacks [25]
-----------------------------------------------
0.00 0.01 763/763 handleCamera [18]
[26] 0.1 0.00 0.01 763 calculateFrustum [26]
0.01 0.00 4578/4578 extractPlane [28]
-----------------------------------------------
0.00 0.00 1/799 gameInit [13]
0.01 0.00 798/799 handleJoy [23]
[27] 0.1 0.01 0.00 799 getHeightTerrain [27]
0.00 0.00 3196/181944 getHeight [9]
-----------------------------------------------
0.01 0.00 4578/4578 calculateFrustum [26]
[28] 0.1 0.01 0.00 4578 extractPlane [28]
-----------------------------------------------
0.01 0.00 764/764 app_main [1]
[29] 0.1 0.01 0.00 764 running [29]
-----------------------------------------------
0.00 0.00 763/763 app_main [1]
[30] 0.0 0.00 0.00 763 update [30]
-----------------------------------------------
64 destroyContents [31]
0.00 0.00 41/41 renderQuadtree [5]
[31] 0.0 0.00 0.00 41+64 destroyContents [31]
64 destroyContents [31]
-----------------------------------------------
0.00 0.00 1/1 app_main [1]
[32] 0.0 0.00 0.00 1 gprof_cleanup [32]
-----------------------------------------------
This table describes the call tree of the program, and was sorted by
the total amount of time spent in each function and its children.
Each entry in this table consists of several lines. The line with the
index number at the left hand margin lists the current function.
The lines above it list the functions that called this function,
and the lines below it list the functions this one called.
This line lists:
index A unique number given to each element of the table.
Index numbers are sorted numerically.
The index number is printed next to every function name so
it is easier to look up where the function in the table.
% time This is the percentage of the `total' time that was spent
in this function and its children. Note that due to
different viewpoints, functions excluded by options, etc,
these numbers will NOT add up to 100%.
self This is the total amount of time spent in this function.
children This is the total amount of time propagated into this
function by its children.
called This is the number of times the function was called.
If the function called itself recursively, the number
only includes non-recursive calls, and is followed by
a `+' and the number of recursive calls.
name The name of the current function. The index number is
printed after it. If the function is a member of a
cycle, the cycle number is printed between the
function's name and the index number.
For the function's parents, the fields have the following meanings:
self This is the amount of time that was propagated directly
from the function into this parent.
children This is the amount of time that was propagated from
the function's children into this parent.
called This is the number of times this parent called the
function `/' the total number of times the function
was called. Recursive calls to the function are not
included in the number after the `/'.
name This is the name of the parent. The parent's index
number is printed after it. If the parent is a
member of a cycle, the cycle number is printed between
the name and the index number.
If the parents of the function cannot be determined, the word
`<spontaneous>' is printed in the `name' field, and all the other
fields are blank.
For the function's children, the fields have the following meanings:
self This is the amount of time that was propagated directly
from the child into the function.
children This is the amount of time that was propagated from the
child's children to the function.
called This is the number of times the function called
this child `/' the total number of times the child
was called. Recursive calls by the child are not
listed in the number after the `/'.
name This is the name of the child. The child's index
number is printed after it. If the child is a
member of a cycle, the cycle number is printed
between the name and the index number.
If there are any cycles (circles) in the call graph, there is an
entry for the cycle-as-a-whole. This entry shows who called the
cycle (as parents) and the members of the cycle (as children.)
The `+' recursive calls entry shows the number of function calls that
were internal to the cycle, and the calls entry for each member shows,
for that member, how many times it was called from other members of
the cycle.
♀
Index by function name
[6] aabbInFrustum [24] getCamMatrix [2] main
[1] app_main [9] getHeight [5] renderQuadtree
[26] calculateFrustum [10] getHeightScaled [29] running
[14] createQuadtree [27] getHeightTerrain [8] setVertexNormals
[31] destroyContents [32] gprof_cleanup [12] setVertexPosition
[22] dist3f [18] handleCamera [16] setVertexUVs
[7] dist3f_fast [23] handleJoy [25] setupCallbacks
[4] draw [15] loadHeightfield [30] update
[28] extractPlane [19] loadRtxTexture [21] updateCamera
[13] gameInit [20] loadTerrainTexture [17] vfpu_sqrtf |
88.44% of time spent in aabbInFrustum. This is even after optimizations. I did not believe this could be true, especially since my aabbInFrustum() check used hardly any maths. So, I did some personal profiling.
| Code: | // ____________________ G L O B A L _ P R O F I L I N G ____________________
extern int profile_aabbinfrustum;
extern int profile_renderquadtree;
extern int profile_stripquadtreepatch;
#define PROFILE_START \
u64 prof_start_; \
sceRtcGetCurrentTick(&prof_start_)
#define PROFILE_END(name) \
u64 prof_end_; \
sceRtcGetCurrentTick(&prof_end_); \
profile_##name += prof_end_ - prof_start_ |
I placed those PROFILE_START and PROFILE_END(name) macros in the entrance and at the exit of the 3 functions listed and then printed out the accumulated ticks to pspsh to see what the results were.
| Code: | host0:/> ./ruoho.prx
Load/Start host0:/ruoho.prx UID: 0x04253673 Name: Ruoho 3D
host0:/> aabbinfrustum: 881fda0 188
renderquadtree: 881fda4 386204
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 309
renderquadtree: 881fda4 389003
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 463
renderquadtree: 881fda4 391737
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 581
renderquadtree: 881fda4 394437
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 736
renderquadtree: 881fda4 397193
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 944
renderquadtree: 881fda4 399890
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 1154
renderquadtree: 881fda4 402625
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 1369
renderquadtree: 881fda4 405474
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 1485
renderquadtree: 881fda4 408130
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 1603
renderquadtree: 881fda4 411007
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 1779
renderquadtree: 881fda4 413862
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 1899
renderquadtree: 881fda4 416512
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 2016
renderquadtree: 881fda4 419239
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 2226
renderquadtree: 881fda4 421996
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 2377
renderquadtree: 881fda4 424767
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 2499
renderquadtree: 881fda4 427480
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 2618
renderquadtree: 881fda4 430121
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 2734
renderquadtree: 881fda4 432776
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 2853
renderquadtree: 881fda4 435614
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 3036
renderquadtree: 881fda4 438285
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 3155
renderquadtree: 881fda4 441147
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 3334
renderquadtree: 881fda4 444024
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 3517
renderquadtree: 881fda4 446713
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 3680
renderquadtree: 881fda4 449525
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 3799
renderquadtree: 881fda4 452215
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 3915
renderquadtree: 881fda4 454997
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 4037
renderquadtree: 881fda4 457810
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 4218
renderquadtree: 881fda4 460463
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 4336
renderquadtree: 881fda4 463349
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 4508
renderquadtree: 881fda4 466164
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 4688
renderquadtree: 881fda4 468818
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 4902
renderquadtree: 881fda4 471615
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 5022
renderquadtree: 881fda4 474388
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 5142
renderquadtree: 881fda4 477111
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 5263
renderquadtree: 881fda4 479873
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 5473
renderquadtree: 881fda4 482577
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 5593
renderquadtree: 881fda4 485458
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 5718
renderquadtree: 881fda4 488249
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 5898
renderquadtree: 881fda4 490906
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 6013
renderquadtree: 881fda4 493706
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 6132
renderquadtree: 881fda4 496490
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 6251
renderquadtree: 881fda4 499207
rstripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 6366
renderquadtree: 881fda4 501945
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 6489
renderquadtree: 881fda4 504725
stripquadtreepatch: 881fda8 91763
eaabbinfrustum: 881fda0 6609
renderquadtree: 881fda4 507499
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 6788
renderquadtree: 881fda4 510262
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 6905
renderquadtree: 881fda4 512885
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 7024
renderquadtree: 881fda4 515749
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 7147
renderquadtree: 881fda4 518613
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 7322
renderquadtree: 881fda4 521268
stripquadtreepatch: 881fda8 91763
saabbinfrustum: 881fda0 7440
renderquadtree: 881fda4 524120
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 7559
renderquadtree: 881fda4 526937
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 7739
renderquadtree: 881fda4 529588
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 7912
renderquadtree: 881fda4 532397
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 8030
renderquadtree: 881fda4 535140
stripquadtreepatch: 881fda8 91763
eaabbinfrustum: 881fda0 8144
renderquadtree: 881fda4 537868
stripquadtreepatch: 881fda8 91763
taabbinfrustum: 881fda0 8264
renderquadtree: 881fda4 540695
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 8443
renderquadtree: 881fda4 543373
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 8559
renderquadtree: 881fda4 546204
stripquadtreepatch: 881fda8 91763
aabbinfrustum: 881fda0 8676
renderquadtree: 881fda4 549042
stripquadtreepatch: 881fda8 91763
Resetting psplink
host0:/>
|
From the above printout it is my understand that most of the ticks are actually being spent in the renderquadtree function and there is no way that 88.44% of the time is being spent in aabbInFrustum as gprof claims.
Am I understanding something wrong from gprof? Is the PSP's cpu really that terrible? Have I been staring at code too long today? _________________ http://jj.homebrewheaven.net/ |
|
| Back to top |
|
 |
Drakon
Joined: 08 Apr 2008 Posts: 16 Location: Poznan - Poland
|
Posted: Tue Apr 19, 2011 5:09 pm Post subject: |
|
|
After small talk with Calvin we managed to get some decent speed - all we have to do was:
- use vfpu sqrt - 2x-3x faster than normal one
- use mipmapping for textures - it can be very slow to draw one big mesh with repeated texture many times. Using mipmaps helps a lot.
- loading texture to vram - always add some speed
And now starring from 30-50 fps Calvin have 250 - 350 fps :) Probably more optimizations can be done. |
|
| Back to top |
|
 |
Calv!n

Joined: 13 Aug 2007 Posts: 18
|
Posted: Wed Apr 20, 2011 2:05 am Post subject: |
|
|
Yeah. We got some nice speed boosts for sure. I was using vfpu_sqrtf() in my code already, so maybe you found a couple more areas which I used sqrt.
There are definitely more places where possible optimizations can be made. Probably more inlining of vfpu asm would help. I know that in a couple of spots I can add vfpu ops for normalizing and some other things.
Also, another speed optimization I am working on is to change my texture color mode from GU_8888 to using 8-bit indexed textures. This will save on my memory usage and should be better on performance as well.
I will have to add some skirts to the patches to fix the cracks between LOD levels. I will post some more screenshots and results soon enough. _________________ http://jj.homebrewheaven.net/ |
|
| Back to top |
|
 |
dridri
Joined: 31 Jul 2009 Posts: 38
|
Posted: Wed Apr 20, 2011 7:05 am Post subject: |
|
|
| I say that just to be sure, do you swizzle your textures ? |
|
| Back to top |
|
 |
Calv!n

Joined: 13 Aug 2007 Posts: 18
|
|
| Back to top |
|
 |
dridri
Joined: 31 Jul 2009 Posts: 38
|
Posted: Wed Apr 20, 2011 9:42 pm Post subject: |
|
|
Okay, hum.. do you update the GE ccommands list at every draw calls ? Because calling the drawing sync just before the buffers swapping is faster.
But by seeing the framerate, you surely do that.
About the CPU: it is really slow, you have to use more VFPU instructions, and use only VFPU registers, also for the 'if' (I saw some 'cmp' insts). But this implies that you need to program all the algorithm in full ASM
Also, there are maybe too much trees in your LOD..
Just suggesting... |
|
| Back to top |
|
 |
Calv!n

Joined: 13 Aug 2007 Posts: 18
|
Posted: Sun Apr 24, 2011 3:09 pm Post subject: |
|
|
I haven't worked on this for a bit since I have been working on some other aspects. Working on support for different texture formats as well as Studiomdl Data (.smd) loader.
I definitely need to take advantage of the VFPU more. Once I get a chance I will go through and make sure to add VFPU functionality in even more places than before. _________________ http://jj.homebrewheaven.net/ |
|
| Back to top |
|
 |
Calv!n

Joined: 13 Aug 2007 Posts: 18
|
Posted: Sat May 07, 2011 2:28 am Post subject: |
|
|
Hey guys, I am back with some results. The draw distance is 700 meters with a FOV of 45 degrees.
Geomipmapping with distance based LOD, quadtree hierarchical frustum culling, and texture mipmapping all working now. I still need to add some skirts to fix the cracks or else I will have to do some stripping by hand in order to fix the seams. _________________ http://jj.homebrewheaven.net/ |
|
| Back to top |
|
 |
Kreationz
Joined: 18 May 2008 Posts: 54
|
Posted: Mon May 09, 2011 1:00 pm Post subject: On the VFPU Math... |
|
|
Much of our VFPU code in DaedalusX64 is already very optimized.
For the pertininent code:
VFPU Math Functions with notes on speed: Math.h
Faster Memcpy: FastMemcpy.cpp and FastMemcpy.h
You also might be interested in the ASM we use for our Matrix Math in Matrix4x4.cpp
None of those functions are my work, but they are the work of several devs on this site and others. |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|