..:: PCSX2 Forums ::..

Full Version: [blog] Threading VU1
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Well unless you're really clever about it (I had some ideas, but they're far more complicated than the current MTVU and are of questionable benefit) you have to sync all the time, that's what cotton was getting at. The main reason MTVU works is that you can continue queuing more microprogram calls.
can you make MTVU VU0 and VU1 work together to see any side effect for beta tester to test it to see which when wrong

try first please and see what problem you will encounter when MTVU VU0+VU1 together


no offend

try first see what happen thank you

VU0 handle Results of VU0/FPU sent as another display list via MFIFO (E.G. complex characters/vehichles/etc.) and Results of VU0/FPU sent to VU1 (via 3 methods) and can act as an optional geometry pre-processor that does all base work to update the scene every frame (E.G. camera, perspective, boning and laws of movement such as animations or physics)

VU1 handle lighting and other visual based calculations (Texture matrix able for 2 coordinates (UV/ST)

VU0 you need to figure out this

Results of VU0/FPU sent as another display list via MFIFO?
Results of VU0/FPU sent to VU1 (via 3 methods???)

VU0=Results of VU0/FPU sent as another display list= via MFIFO(E.G. complex characters/vehichles/etc.)
VU0= via 3 methods= Results of VU0/FPU send to VU1(E.G. camera, perspective, boning and laws of movement such as animations or physics)



VU1 you need to figure out this

Texture matrix able for 2 coordinates (UV/ST)???

VU1=texture matrix able for 2 coordinates = UV/ST( lighting and other visual based calculations)
WTF you talking about @hell? learn intelligible english or just get out of the technical threads.

as the devs said there's no point in multithreading VU0. it's bound to the EE as COP2 making it pointless to optimize cause relevant data runs thru it even more depending on writebacks and forth and back reading than VU1.

/edit: one double read later.

ohh and... iirc that programming methods you want to check for multithreading don't really work with how the recompiler reads the binary code of the VU. than means: the recompiler can't really see what the data is used for... so... optimizing chained geometry animation between VU0 (bones) + VU1 (lighting) is really hard.
(10-24-2011, 03:26 PM)pseudonym Wrote: [ -> ]Well unless you're really clever about it (I had some ideas, but they're far more complicated than the current MTVU and are of questionable benefit) you have to sync all the time, that's what cotton was getting at. The main reason MTVU works is that you can continue queuing more microprogram calls.

exactly, with the whole idea of moving the vu to get it away from the ee core to give each more breathing space, but to have it like that would be slow due to all the syncing. so as i originally said, doing so would probably be counter productive.
(10-24-2011, 07:28 PM)refraction Wrote: [ -> ]but to have it like that would be slow due to all the syncing. so as i originally said, doing so would probably be counter productive.

now just as a help to people who arent coders, can you explain more on the whole "syncing and overhead" to us. i understand what your getting at, but i really dont understand the whole picture.
it might help out so when you say these things, everyone has a general idea of what you mean.
When you have something in a thread like mtvu or mtgs, you can't just read or take information from a different thread whenever you like, it has to be passed across, usually by a huge ring buffer which the thread watches for new information. Of course this all comes at a cost and as the vu0 and ee are so tightly linked there could be a lot of access which would result in a lot of delays when passing stuff to and from the vu0 thread.

Not sure how accurate my description Is, this is just how I understand it. I'm sure pseudo or cotton could correct my errors.
good description @refraction. dunno why you don't have faith in yourself. Wink

simple seperation of the memory block a thread is working on. overlapping data causes "syncing data" and "stall thread" issues. heavily switching from cop2 to micro code mode just does copy too much memory for the thread seperation of the VU0 to be efficient.
VU0 typically used for polygon transformations optionally (under parallel or serial connection), physics and other gameplay based things
VU1 typically used for polygon transformations, lighting and other visual based calculations (Texture matrix able for 2 coordinates (UV/ST)

Parallel: Results of VU0/FPU sent as another display list via MFIFO (E.G. complex characters/vehichles/etc.)
Serial: Results of VU0/FPU sent to VU1 (via 3 methods) and can act as an optional geometry pre-processor that does all base work to update the scene every frame (E.G. camera, perspective, boning and laws of movement such as animations or physics)

First thing TO TAKE NOTE!!!

VU0 uses both parallel and serial(via 3 methods) this 2 very important process for Gsdx plugin

even you make VU1 faster than VU0!!!! MTVU STILL MUST WAIT FOR VU0/FPU RESULT
FPU MEANING floating-point unit


TAKE NOTE THIS!!!!!!!

optional geometry pre-processor= does all base work to update the scene every frame!!!

Serial: Results of VU0/FPU sent to VU1 (via 3 methods) and !!!!can act as an optional geometry pre-processor that does all base work to update the scene every frame (E.G. camera, perspective, boning and laws of movement such as animations or physics)!!!!

this 2 handle critical process and very important process over VU1
1.(E.G. complex characters/vehichles/etc.)
2.(E.G. camera, perspective, boning and laws of movement such as animations or physics)

first process
1.VU0((E.G. complex characters/vehichles/etc.)
(E.G. camera, perspective, boning and laws of movement such as animations or physics))

second process
2.VU1( lighting and other visual based calculations)

ETC meaning so on......
example complex weather like winter so on...
another example like spell cast

hell321: you don't know what you're talking about and (potentially) effective VU0 threading isn't something that we can just hack in and benchmark
hmm

is it no way to make VU0 handles parallel and serial(via 3 method)???
Parallel(E.G. complex characters/vehichles/etc.)
Serial+ via 3 method(E.G. camera, perspective, boning and laws of movement such as animations or physics)

VU0/FPU send result then VU1 do work lighting and other visual based calculations they work tightly sync with EE

take note!!!
VU0 Results of VU0/FPU= sent as another display list via MFIFO= Display lists generated are sent to the GIF, which prioritizes them before dispatching them to the Graphics Synthesizer for rendering.

take note!!! The CPU core is tightly coupled to the first VU0, VU1. Together, they are responsible for executing game code and high-level modeling computations.

take note!!!
The second VPU(known as VU0), VPU1(known as VU1), is dedicated to geometry-transformations and lighting and operates !!!independently!!!, parallel to the CPU core, controlled by microcode. !!!VPU0, when not utilized, can also be used for geometry-transformations.!!! Display lists generated are sent to the GIF, which prioritizes them before dispatching them to the Graphics Synthesizer for rendering.

The Emotion Engine consists of eight separate "units", each performing a specific task, integrated onto the same die. These units are: a CPU core, two Vector Processing Units (VPU), a graphics interface (GIF), a 10 channel DMA unit, a memory controller, an Image Processing Unit (IPU) and an input output interface.

example MTVU independently VU0 run own thread and VU1 run ownthread


one more thing you say

The main reason MTVU works is that you can continue queuing more microprogram calls. but still MUST WAIT for VU0/FPU result!!!
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15