There is no different between opengl and dx (speed wise). If the application is badly coded on opengl and correctly coded on DX, it would run faster on DX but that does not mean dx is faster. They are just API.

(12-23-2011 10:15 AM)gregory Wrote:  There is no different between opengl and dx (speed wise). If the application is badly coded on opengl and correctly coded on DX, it would run faster on DX but that does not mean dx is faster. They are just API.

directx can have multithreaded context
opengl cannot.

this does affect speed with certain application of the function.

VBA-M

Opengl can have multiple context and share data between them (you can even transfer data between opencl and opengl). If you create them in different thread. It would be the same. Opengl is lower level than dx. By the way, in the end you have only 1 GPU... So it only for the CPU, totally irrelevant.

Thanks Gregory you got what i was trying to say but whenever i read these comments and post from the devs and you , what i say to my self is damn these guys are awesome . Thanks guys for all the effort you guys have put into this project . PCSX2 really is a living legend of a project.

(12-23-2011 11:42 AM)gregory Wrote:  Opengl can have multiple context and share data between them (you can even transfer data between opencl and opengl). If you create them in different thread. It would be the same. Opengl is lower level than dx. By the way, in the end you have only 1 GPU... So it only for the CPU, totally irrelevant.

Quote:The basic problem with multithreading in OGL is the fact that OGL context, which contains entire state of the OGL, can be at one time bound to only one thread. Because of this you can not simultaneously modify it from two threads. You basically have three options.

You can create one context for each thread and enable sharing of display lists and textures between them. It is likely that this path is not too well supported by the drivers.
You can load and prepare the resources by the second thread and let the main thread do the creation call into OGL.
If the resource type supports it (e.g. VBO), you can map its memory by the main thread. Fill it in the second thread and unmap it by the main thread.

i was reffering to the creation of a single context and modifying it from several threads.

multiple contexts add a whole extra layer of state preservation and complexity, and lets face it, if devs can't even find the numerous reasons to use d3d11 for its multithreading, i doubt they are gunna be bothered with the extremes needed to make opengl multiple contexts work efficiently.

VBA-M

Nowadays you can map most of the opengl object and access from any thread. Opengl is lower level than Directx, so you must do manually more work that does not mean it is slower.

Maybe multithread rendering is useless. You can prepare the data to your GPU with a multithread program, that good for a cpu limited application. But no matter how many thread you create, your gpu will only execute 1 command at a time.

The only speed different is the driver, the directx part of the driver is probably more optimized than the opengl one but I bet the impact is small.

Might be bigger than you think.

r5000 is small time.

Who is going to get the first revision of 2012?