I wasn't talking specifically about (voodoo) lfb access, but more generally about what you said that only some functions could be offloaded to the GPU. The rest would need to be rendered by the CPU and sent to OpenGL as finished bitmaps so that the final frame could be composited...
yes, you've been clear 😀 I think that just triangle (and maybe fastfill) commands may be offloaded to the gpu.
about direct access, I was hoping of avoiding the writing to a bitmap for 2d. The render-to-buffer technique would in theory allow us to still write triangles to the voodoo back-buffer, as the software renderer, leaving lfb writes as-is, but I was asking for some comments on this because I'm not fully aware of how it works.
I have a question. Forgive me if it's redundant with something mentioned in the numerous pages here..
I assume that the goal here is to create a higher compatibility partially accelerated layer for Glide - i.e., you're implementing more than most Glide wrappers do as far as hardware emulation goes, and also accelerating what you can using CPU/GPU of the host - correct?
This is, of course, as opposed to a pure software emulation in which none of the processing is outsourced beyond DOSBox to the host, which would be a bit less efficient.
As I said, I assume you're doing the former, but just wanted to ask.
Hmm, Kekko, and I have one question. Can you increase the memory limit in your DOSBOX SVN up to 128 MB?
I've launched Ultima IX. Game works, but very slow. Maybe I have too slow processor (I have Athlon64 2GHz)...I want to know, how fast run this DOSBOX SVN on machines other testers?
wrote:Hmm, Kekko, and I have one question. Can you increase the memory limit in your DOSBOX SVN up to 128 MB?
I've launched Ultima IX. Game works, but very slow. Maybe I have too slow processor (I have Athlon64 2GHz)...I want to know, how fast run this DOSBOX SVN on machines other testers?
Good idea, I remember when I played Thief: The Dark Project and Deus Ex on a 64mb machine with a Voodoo 2 card and using Windows 98, and the swapfile had to work like mad, which slowed down things a lot.
On your average 4gig system the swap file of the pmode extender surely is kept in memory.
wrote:I've launched Ultima IX. Game works, but very slow. Maybe I have too slow processor
It's Ultima IX. What are you expecting, stable and proper performance? Today's computers still struggle with it. 😀
Yes...even my computer has problems with this game...but I thought it was caused by Glidewrapper...
kekko, now you're famous 😁
http://games.slashdot.org/story/10/10/20/0026 … oming-To-DOSBox
I just noticed 😀
Well, I'd like to release something really enjoyable, by finally making the triangle rendering faster and releasing a build, so that people could actually play their favorite games.
I was working on pushing that threading experiment forward, even if it's going very slow due to RealLife(tm); that would eventually work, but the cost would be a high code complexity, which means more bugs, and high cpu requirements.
That could be avoided since even many older machines come with a 3d accelerator which is way better than a voodoo1.
Unfortunately I got not much experience with opengl, so I should review some basic concepts first of actually work on dosbox.
To the ones interested, I was thinking of using OpenGL Frame Buffer Object, by rendering to a frame buffer, our voodoo back-buffer, instead of directly to screen.
This way I'd like to preserve compatibility with different output formats, full screen switching and video capturing.
I'm not sure this is the best way, maybe someone has a better idea.
Yeah, I thought you were thinking that way in our earlier discussion 😀 I guess there are two ways to offload rendering to the gpu:
1. drawing triangles on the gpu and pushing the rest as a bitmap to opengl, having opengl compositing the final image (what I was thinking about)
2. rendering triangles on the gpu, retrieving them and rendering the final image through dosbox renderers (what you are thinking about)
No.2 has the advantage of using Dosbox current outputs and basically everything that emulated 2d s3 video does. No.1 would be closer to my glide patch (rendering onto opengl window).
Now what I'm afraid, readbacks are slow, much slower than writes which are already slow. There's a way to have readbacks done asynchronously and that would be a must to get decent framerate. So there'd have to be a way to have render to FBO, initiate a readback, do something (perhaps render a new frame in the meantime to a second FBO) and hopefully by then the readback will be finished. I'm afraid having a simple render->readback will be too slow to be useable....I'm pretty fluent in OpenGL (done a whole 3D engine, with FBOs, shaders and all) 😁
edit: my ATi mobile pushes about 20Mpix/s when reading from a texture. That's only 66fps @640x480 or about 40 @800x600 if I did my math right. So doing 30fps @640x480 would take about 50% cpu...writes are at about 140Mpix/s.
Hello Kekko I don't know if that be help you but
I am under Linux with KDE 4.5 😅
with gallium 0.4 and the SOFTPIPE OpenGL on LLVM 2.8
My CPU is Q6600 at only 2335 Mhz (yes ... motherboard limited 😒 ) and I run Tomb Raider 1 and it's fully playable
between 20 and 30 the cpu is rarely use more that 50% on 4 core.
I think the soft pipe of mesa is in lisence compatible with your need and may be you can use the code of this rasterizer.
I have also test with mesa dri and it lags realy (it's hardly playable) and it's the same with gallium 0.4 without llvm.
Also maybe is more usefull to use llvm as the soft rasterizer I don't know ?
I will try to post screen shot :
You seems like a skilled programmer and I hope you bring a full
3dfx software at the end. Thank you.(excuse if's bad English) 😦
wrote:i used gulikoza's patch and removed all inline words from voodoo files and it works (it has a memory leak btw)
I did this, removed the included SDL-Headers and was able to compile it on my 64bit Ubuntu 10.04. Except for speed and the memory leak it works fine in most games. Finally I know how Fatal Racing looks on 3dfx 😀
Problems i stumbled upon:
wrote:Yeah, I thought you were thinking that way in our earlier discussion :happy: I guess there are two ways to offload rendering to […]
Yeah, I thought you were thinking that way in our earlier discussion 😀 I guess there are two ways to offload rendering to the gpu:
1. drawing triangles on the gpu and pushing the rest as a bitmap to opengl, having opengl compositing the final image (what I was thinking about)
2. rendering triangles on the gpu, retrieving them and rendering the final image through dosbox renderers (what you are thinking about)No.2 has the advantage of using Dosbox current outputs and basically everything that emulated 2d s3 video does. No.1 would be closer to my glide patch (rendering onto opengl window).
Now what I'm afraid, readbacks are slow, much slower than writes which are already slow. There's a way to have readbacks done asynchronously and that would be a must to get decent framerate. So there'd have to be a way to have render to FBO, initiate a readback, do something (perhaps render a new frame in the meantime to a second FBO) and hopefully by then the readback will be finished. I'm afraid having a simple render->readback will be too slow to be useable....I'm pretty fluent in OpenGL (done a whole 3D engine, with FBOs, shaders and all) 😁
edit: my ATi mobile pushes about 20Mpix/s when reading from a texture. That's only 66fps @640x480 or about 40 @800x600 if I did my math right. So doing 30fps @640x480 would take about 50% cpu...writes are at about 140Mpix/s.
I guess reads should not be an issue with "solution 2", since we keep reading from voodoo buffer as current implementation does, right?
Reading from video card buffer may be slow, but system memory should be better.
Maybe I'm missing something, again... 😀
I'm confused 😕
You were thinking about rendering some triangles with OpenGL, right? Well, you'd need to get them back to put them into dosbox render right? 😀
Yes, but I'd like to make opengl render the triangles directly in the voodoo lfb memory, that's why I was thinking about frame buffer object.
Is it possible?
No, FBOs are still allocated on the GPU...you need to do a readback to get that back to system memory 😀
😦 do you think it's feasible, or it would be better to find another idea?
Well, there's really no efficient way of getting data out of OpenGL once you go that way. The system, the hardware...just wasn't designed that way. It was designed to push as much pixels as fast as possible in one direction, anything else stalls the pipeline and is rather slow (like pumping water out of the drain 😀). So I think that the best solution is then to push it forward, not pump it back 😁.
But then again, I do not want to influence you too much...I've already made a system I think is good, having somebody else tackle the problem from a completely different perspective would surely be the best 😀
Ok, if we go for a plain opengl rendering, no strange buffer tricks 😀, and we limit it to dosbox opengl output, would we be able to preserve fullscreen, capturing and all?
