| |
Conversions (mostly games) |
| |
This is a long thread. Click here to view the threaded list. |
| |
|
Jeffrey Lee |
Message #97264, posted by Phlamethrower at 09:12, 17/1/2007, in reply to message #97260 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Someone broke ar 1.01 in gcc 3.4.6 release 2.  It won't do anything besides print its help when I type "ar" on its own. ar -V doesn't even show the version number.
Edit: libfile works. Who changed that then?  Dunno. I find that one or the other of the two is always broken.
DMA works for 2D!!! (edit: this is for the FX5200, too!) Yay!
Wasn't that hard, was it?  |
| |
 [ Log in to reply ] |
| |
|
Phil Mellor |
Message #97265, posted by monkeyson2 at 09:22, 17/1/2007, in reply to message #97264 |
 Please don't let them make me be a monkey butler
Posts: 12380
|
 |
| |
[ Log in to reply ] |
| |
|
Michael Drake |
Message #97266, posted by tlsa at 09:31, 17/1/2007, in reply to message #97261 |
Posts: 1097
|
DMA works for 2D!!! (edit: this is for the FX5200, too!)
Getting 3D going now!
YAY DMA!
[Edited by ksattic at 03:48, 17/1/2007] Will this work in desktop windows? It would be good if the Gnash port could be sped up using IyonixMesa. |
| |
[ Log in to reply ] |
| |
|
JMB |
Message #97278, posted by jmb at 11:07, 17/1/2007, in reply to message #97260 |
Member
Posts: 467
|
Someone broke ar 1.01 in gcc 3.4.6 release 2. It won't do anything besides print its help when I type "ar" on its own. ar -V doesn't even show the version number. Broke how, exactly? It works fine here. The -V option appears broken, admittedly. Printing the help when invoked with no arguments is expected behaviour (and is the same as GNU ar's behaviour in that circumstance).
Creating a library:
ar -cru lifoo.a file1.o file2.o file3.o
GCCSDK's ar doesn't implement the -u parameter, so it won't update files in the archive with newer ones specified on the command line. (This has always been the case, incidentally, so it's not a regression in 1.01) |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #97387, posted by ksattic at 16:24, 18/1/2007, in reply to message #97278 |
 Finally, an avatar!
Posts: 1291
|
When I say it's broken, I mean it just doesn't generate a library. It appears to do nothing. No error messages are printed.
OK, I still don't have the DMA code drawing 3D. I see the triangles get transformed in Mesa and enter the driver code, but nothing is rendered. At least it doesn't hang the 3D engine like the old FIFO code did with the FX5200. I am also trying this code with the MX card to ensure it's not my FX5200 that is broken. |
| |
[ Log in to reply ] |
| |
|
Dave Brown |
Message #97390, posted by daveb at 18:30, 18/1/2007, in reply to message #97387 |
Member
Posts: 41
|
When I say it's broken, I mean it just doesn't generate a library. It appears to do nothing. No error messages are printed. I had the same problem when getting Q2 building again. I resorted to using libfile directly. |
| |
[ Log in to reply ] |
| |
|
Dave Brown |
Message #97458, posted by daveb at 19:33, 19/1/2007, in reply to message #97390 |
Member
Posts: 41
|
I've just got my first build of Q2 running built with GCC4.1.1 and with soft-float support.
All I can say is "Christ, that's a lot faster"
Attached is a zipped version of the new !RunImage. You'll need a copy of elfloader and to set the type of the file to &e1f. You'll also need a 32bit version of GameUtils which can be found in 32bit Quake at the moment. I'll pack up a better version shortly.
It may also be possible to get a bit more speed out of it quite painlesly as I think that soft-float currently isn't compiled to target the xscale and it has some xscale optimizations available.
Special thanks to John Tygat and John-Mark Bell who helped to get my GCCSDK environment up and running.
Enjoy 
PS. Archive of application wrapped version now attached
I'm off to the pub now to celebrate
[Edited by daveb at 19:59, 19/1/2007] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #97462, posted by Phlamethrower at 20:09, 19/1/2007, in reply to message #97458 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Yay!
...shame I can't run it
[edit]
And for those lucky people who do have a compatible GeForce card, you can find elfloader here. I'm guessing this is the right version to use, as the game did load far enough to try initialising IyonixMesa.
[Edited by Phlamethrower at 20:14, 19/1/2007] |
| |
[ Log in to reply ] |
| |
|
Chris |
Message #97465, posted by cterran at 21:18, 19/1/2007, in reply to message #97458 |
Member
Posts: 163
|
Thanks -- really excellent work from all involved, not least from the GCC team
Have you tried compiling it at (say) 800x600? That might give a further speed boost (fairly substantial, to judge by my own experiments with OpenGL/Mesa). Or can the resolution be changed without recompilation? |
| |
[ Log in to reply ] |
| |
|
Dave Brown |
Message #97468, posted by daveb at 22:51, 19/1/2007, in reply to message #97465 |
Member
Posts: 41
|
Have you tried compiling it at (say) 800x600? That might give a further speed boost (fairly substantial, to judge by my own experiments with OpenGL/Mesa). Or can the resolution be changed without recompilation? I haven't had the chance yet. Currently it's just hard coded to 1024x768 but I'm planning to put in dynamic mode selection code in the not too distant future (probably sometime over the weekend). I'd also like to get sound support in there to make it feel more gamelike
There is still lots of tidying to do as well of course and I need to work on tracking down the crashes when loading new maps. |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #97469, posted by andrew at 23:31, 19/1/2007, in reply to message #97468 |
 Handbag Boi
Posts: 3439
|
This sounds great. Just for the non-savvy, is a StrongARM port looking feasible? |
| |
[ Log in to reply ] |
| |
|
Dave Brown |
Message #97470, posted by daveb at 23:41, 19/1/2007, in reply to message #97469 |
Member
Posts: 41
|
This sounds great. Just for the non-savvy, is a StrongARM port looking feasible? I'm intending to look at producing a software render based version too (which would be strongarm compatible) but don't hold your breath. For the time being I'll largely be working on the IyonixMesa version - it's just too tempting at the moment
Hopefully in the not too distant future I'll get the source hosted somewhere properly and then other people will also be able to help out (if, of course, they feel so inclined).
[Edited by daveb at 23:42, 19/1/2007] |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #97487, posted by ksattic at 08:00, 20/1/2007, in reply to message #97470 |
Finally, an avatar!
Posts: 1291
|
Cool, it runs, and it really is faster! So, how is soft-float faster than the FP emulator?
Also, did you recompile IyonixMesa with soft-float? |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #97489, posted by andrew at 10:36, 20/1/2007, in reply to message #97487 |
Handbag Boi
Posts: 3439
|
Looking forward to it.
So the people who are playing Q2, have you bought the game already? Or where do you get the level files from? |
| |
[ Log in to reply ] |
| |
|
Dave Brown |
Message #97494, posted by daveb at 13:09, 20/1/2007, in reply to message #97487 |
Member
Posts: 41
|
Cool, it runs, and it really is faster! So, how is soft-float faster than the FP emulator?
Also, did you recompile IyonixMesa with soft-float? I did recompile IyonixMesa with gcc, That's probably where the majority of the gains came from.
The main advantage that soft-float has over the FP emulator is that it does all FP operations inline rather than having the processor throw an undefined instruction trap and having the FP module decode the FP instruction end emulate it. I suspect that the FP implementation in soft-float is also better optimized than the one in the FP module. |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #97498, posted by ksattic at 18:40, 20/1/2007, in reply to message #97489 |
Finally, an avatar!
Posts: 1291
|
In my opinion, it's still too slow to be playable. I am spending all my free time right now trying to get DMA working with 3D in IyonixMesa. After that, hopefully a couple of us will be working on fixed point support, and then it'll be playable when we start htting 30fps.
Edit: I am using the demo files.
[Edited by ksattic at 18:41, 20/1/2007] |
| |
[ Log in to reply ] |
| |
|
Dave Brown |
Message #97499, posted by daveb at 19:18, 20/1/2007, in reply to message #97498 |
Member
Posts: 41
|
In my opinion, it's still too slow to be playable. I am spending all my free time right now trying to get DMA working with 3D in IyonixMesa. After that, hopefully a couple of us will be working on fixed point support, and then it'll be playable when we start htting 30fps. It definately needs more speed. I'll try it at a lower resolution to make sure we're not starting to hit the performance limits of the geforce 2 mx (1024x768 may be asking a bit too much of such an old card). After that I want to look at profiling the code a bit to see where the biggest performance gains for the least work can be achieved.
Incidentally, do you know if the geforce2mx supports hardware T&L? I'm pretty sure the accelerator doesn't at the moment but the more work that could be shifted off the processor the better.
[Edited by daveb at 19:21, 20/1/2007] |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #97505, posted by ksattic at 00:24, 21/1/2007, in reply to message #97499 |
Finally, an avatar!
Posts: 1291
|
Incidentally, do you know if the geforce2mx supports hardware T&L? I'm pretty sure the accelerator doesn't at the moment but the more work that could be shifted off the processor the better. Yes, and that's actually pretty much all the driver does. The GeForce 2 MX can also do traingle transformation in hardware but the driver doesn't because of lack of documentation.
The GeForce 2 MX can also do iDCT, which is required for DVD decoding at speed, but we also don't have enough documentation for that. |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #97519, posted by ksattic at 01:56, 22/1/2007, in reply to message #97505 |
Finally, an avatar!
Posts: 1291
|
Er, there's a bit of a problem.
I just found some code in the BeOS 3D accelerant (not the 2D accelerant) that exits if an NV20 or higher is detected (the FX series starts at NV30). Apparently they have not figured out why yet, but NV20 and greater cards just don't work with the 3D accelerant - they get stuck rendering (exactly what I see).
So, we need to find some code that does work, or some decent documentation.
The DMA code doesn't quite work on the GeForce 2 MX yet, but I have a feeling it's close. |
| |
[ Log in to reply ] |
| |
|
JMB |
Message #97521, posted by jmb at 08:16, 22/1/2007, in reply to message #97519 |
Member
Posts: 467
|
So, we need to find some code that does work, or some decent documentation. I wonder if http://nouveau.freedesktop.org/ is of any use to you? |
| |
[ Log in to reply ] |
| |
|
Dave Brown |
Message #97522, posted by daveb at 09:35, 22/1/2007, in reply to message #97521 |
Member
Posts: 41
|
I wonder if http://nouveau.freedesktop.org/ is of any use to you? I've been keeping a close eye on this for the last week or so. It sounds very promising I don't believe it's yet at a state where it's sufficiently complete to work for Q2 (or much else GL based just yet). In the long term I'd much prefer to go for it rather than a 3.x based MESA as it supports a far greater array of hardware accelerated GL functions and is therefore likely to perform considerably better. It'd be especially nice to get vertex/pixel shader functionality.
They do however have some basic 3d acceleration going on NV40 hardware so this may be of use to Simon in order to work out what's going wrong with the NV34.
[Edited by daveb at 09:44, 22/1/2007] |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #97531, posted by ksattic at 16:00, 22/1/2007, in reply to message #97522 |
Finally, an avatar!
Posts: 1291
|
Thanks for the link above - it looks useful. My aim is to implement my own version of OpenGL [ES] in a module, so perhaps the "nouveau" driver is a step in the right direction for that.
Has anyone tried a GeForce 4 MX on the Iyonix yet? It *should* work with IyonixMesa. |
| |
[ Log in to reply ] |
| |
|
Dave Brown |
Message #97536, posted by daveb at 19:42, 22/1/2007, in reply to message #97531 |
Member
Posts: 41
|
Has anyone tried a GeForce 4 MX on the Iyonix yet? It *should* work with IyonixMesa. I don't think the Geforce 4 MX was releaded in a PCI variant. It also didn't add that much over a 2MX. |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #97538, posted by ksattic at 19:51, 22/1/2007, in reply to message #97536 |
Finally, an avatar!
Posts: 1291
|
Has anyone tried a GeForce 4 MX on the Iyonix yet? It *should* work with IyonixMesa. I don't think the Geforce 4 MX was releaded in a PCI variant. It also didn't add that much over a 2MX.
OK, that explains why I didn't find a PCI version on eBay.
I *swear* I saw one in Circuit City a few months back...
Edit: yes, here's the one I saw: http://www.bhphotovideo.com/bnh/controller/home?A=details&kw=PNGF4MX4000&is=REG&Q=&O=productlist&sku=334430
[Edited by ksattic at 19:51, 22/1/2007] |
| |
[ Log in to reply ] |
| |
|
Dave Brown |
Message #97579, posted by daveb at 21:40, 23/1/2007, in reply to message #97538 |
Member
Posts: 41
|
Edit: yes, here's the one I saw: http://www.bhphotovideo.com/bnh/controller/home?A=details&kw=PNGF4MX4000&is=REG&Q=&O=productlist&sku=334430 Cool, hadn't realised The big question tho is whether it supports the apropriate RGB rather than BGR screen modes. If it doesn't you'd need a hardware modded version or a dongle to switch the R&B components, and of course you could pretty much forget about DVI support. |
| |
[ Log in to reply ] |
| |
|
Dave Brown |
Message #97614, posted by daveb at 21:21, 24/1/2007, in reply to message #97519 |
Member
Posts: 41
|
The DMA code doesn't quite work on the GeForce 2 MX yet, but I have a feeling it's close. How's the DMA support going?
It will be interesting to see whether it improves things any further. Quake2 does a fair bit of texture uploading when it's using dynamic lighting so may see a noticable speed up there. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #97617, posted by Phlamethrower at 21:36, 24/1/2007, in reply to message #97614 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
And how are your attempts at fixing the software rendering going? Although I doubt we can get it running at a very playable speed, it'll allow me to help out (If you want me to  ) with other aspects of the port. As well as keep track on your own progress |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #97621, posted by ksattic at 22:20, 24/1/2007, in reply to message #97614 |
Finally, an avatar!
Posts: 1291
|
How's the DMA support going?
It will be interesting to see whether it improves things any further. Quake2 does a fair bit of texture uploading when it's using dynamic lighting so may see a noticable speed up there. It's not going very far... I can't seem to get it to process triangles for some reason.
I think we may be on different wavelengths here. Textures are already rendered using DMA - they are copied into the video card's RAM, and from there the rasteriser blends them with fragment colours.
The DMA support I am referring to is when commands (and vertices) are placed into a buffer in PCI-accessible main memory, rather than having the ARM push them over a FIFO all the time. You can get substantial speedups with that (on x86 systems).
One thing that may be possible is using one of the DMA engines in the XScale to copy the textures over. We could look into that. |
| |
[ Log in to reply ] |
| |
|
Dave Brown |
Message #97651, posted by daveb at 20:12, 25/1/2007, in reply to message #97621 |
Member
Posts: 41
|
One thing that may be possible is using one of the DMA engines in the XScale to copy the textures over. We could look into that. That's specifically what I was referring to. Quake2 dynamic lighting causes lots of new textures to be generated as the light map layer. Each of these new textures then needs to be transferred over to the graphics card (presumably from what you say by the processor writing them to the PCI memory rather than them being presented to the graphics card via the FIFO interface). |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #97658, posted by andrew at 22:29, 25/1/2007, in reply to message #97651 |
Handbag Boi
Posts: 3439
|
Wouldn't it be better to process the pixels' colours or is that what you mean? |
| |
[ Log in to reply ] |
| |
| Pages (5): |< <
3
> >|
|
