| |
Are you bored? |
| |
This is a long thread. Click here to view the threaded list. |
| |
|
Adrian Lees |
Message #56844, posted by adrianl at 14:39, 11/7/2004 |
Member
Posts: 1637
|
So was I. So I wrote this:
http://freespace.virgin.net/a.m.lees/downloads/RedrawCache.zip
It may amuse you for a few minutes. Let me know what you think, politely please  |
| |
 [ Log in to reply ] |
| |
|
John D |
Message #56845, posted by john at 15:03, 11/7/2004, in reply to message #56844 |
Member
Posts: 261
|
Now that's a useful bit of code :)
No source code? (and shouldn't this be in another forum, e.g. Programming?)
Does it cache the whole work area, including that which can't be seen(off screen/covered /and/ out of scroll limits)? That would speed up scrolling complex files (obviously at the expense of memory)
Apart from that, a good piece of coding, assuming it works (I don't want to try it just now) I'd like it more if I could read the source code :) |
| |
[ Log in to reply ] |
| |
|
Chris |
Message #56846, posted by cterran at 15:58, 11/7/2004, in reply to message #56844 |
Member
Posts: 163
|
Great idea -- I've been wondering if I would ever get close to filling 512MB, but this should help!
Didn't seem to do much here though, apart from stopping PhotoFiler working 
I'll try again later; working ATM. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #56847, posted by adrianl at 16:14, 11/7/2004, in reply to message #56845 |
Member
Posts: 1637
|
Now that's a useful bit of code The idea (and prototype code) dates back to 1997 when I had an ARM610 
No source code? Not yet, no, sorry. I'm not actually sure whether I'm allowed to publish it because Castle hasn't described the NVidia module's API publicly (they didn't *say* it was under NDA, but I ought to check). It's a prototype, anyway; I'd rather not publish source until it's clean/elegant enough that I'd be happy for newbie programmers to read & perhaps learn from it. 
(and shouldn't this be in another forum, e.g. Programming?) Nah, nobody reads them.... you all come here, right?!
Does it cache the whole work area, including that which can't be seen Only up to a point ATM, but it will do that, to speed up scrolling as you said. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #56848, posted by adrianl at 16:22, 11/7/2004, in reply to message #56846 |
Member
Posts: 1637
|
Great idea -- I've been wondering if I would ever get close to filling 512MB, but this should help!
Well, IMHO, all the spare memory should be used for:
* cacheing window contents (a la this module)
* cacheing disc contents (Windows does this, at least, which is why VRPC gives higher figures for the RISC OS mark benchmark; I don't think the disc access is actually any faster than the Iyonix)
* cacheing font bitmaps (cf existing Font Cache
but larger & transparent in use)
All of this data can be thrown away at zero cost when the memory's needed for something else.
RO really underuses modern hardware; we've got large/fast discs & memory because Windows is grotesquely inefficienct in everything it does. With a bit of effort RO could really shine on that hardware! 
Didn't seem to do much here though, apart from stopping PhotoFiler working It's fussy ATM, proof of concept and no more, but if you follow the instructions it should be quite visible.
Which OS version are you using?
BTW, on the Iyonix the cache is effectively free because the NVidia card has 32MB of RAM and most of that is wasted without this module because your screen will be just 2-8MB.
working ATM. On a Sunday?! Dear me 
I'm Muslim on Friday, Jewish on Saturday and Christian on Sundays
[Edited by adrianl at 17:33, 11/7/2004] |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #56852, posted by ksattic at 17:14, 11/7/2004, in reply to message #56848 |
 Finally, an avatar!
Posts: 1291
|
It doesn't appear to work here either. Nice idea though!
Using:
* RISC OS 5.06
* 512MB
* Clean reboot
I even tried removing my large backdrop. I'll try a shift-reboot in a minute and some different resolutions. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #56853, posted by Phlamethrower at 17:21, 11/7/2004, in reply to message #56848 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
There is not enough memory to perform this operation. Quit any unwanted applications or see the RISC OS User Guide for ways to maximise memory. (Memory cannot be moved) 
Changing the 16384K to 4096K in the Reset file allows it to load, but it still doesn't want to do anything. (Apart from wipe the title bar text on a StrongED window )
I'm using RISC OS 3.7, with 32MB of RAM - get fixing! |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #56854, posted by ksattic at 17:31, 11/7/2004, in reply to message #56852 |
Finally, an avatar!
Posts: 1291
|
OK, works partially in 32K colours.
Doesn't accelerate O2 windows at all. Acceleration of the Artworks apple looks amazing though! |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #56856, posted by adrianl at 18:13, 11/7/2004, in reply to message #56854 |
Member
Posts: 1637
|
OK, works partially in 32K colours.
Doesn't accelerate O2 windows at all. Acceleration of the Artworks apple looks amazing though! The idea works especially well on the Iyonix because the NVidia can be used to just DMA the rendered image to some off-screen memory and then DMA it back when later asked to redraw it. We already know that rectangle copying is very fast on the Iyonix.
You're right about O2....interesting. I'd guess it's doing something a bit sneaky (like everything else it does!), rather than using the normal APIs. I'll take a look at that because it could definitely use a kick up the butt in the rendering department |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #56858, posted by adrianl at 18:21, 11/7/2004, in reply to message #56853 |
Member
Posts: 1637
|
Changing the 16384K to 4096K in the Reset file allows it to load, but it still doesn't want to do anything. I guess a bit more info would help -
for each window that it tries to cache it currently sets up a buffer of w x 2h where w,h are the screen dimensions and the bit depth is (naturally) that of the screen.... so if you've only got 4MB to play with you're going to have to use a low screen res/depth for the moment. You'll probably want to have room for 4-8 windows because it caches indiscriminately ATM (obv for pre-Iyonix machines with limited memory release code would time the rendering & make better use of its cache).
If you can give it 8-16MB that'd be best for now.
Code incomplete, fixed numbers for convenience, blah, blah, blah....
(Apart from wipe the title bar text on a StrongED window )
Oh, BTW, it will only redraw from cache if the whole rectangle is cached ATM because the code for decomposing into smaller rectangles and redrawing only the uncached bits is horribly broken! (Used to work in an earlier prototype) |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #56859, posted by ksattic at 18:39, 11/7/2004, in reply to message #56858 |
Finally, an avatar!
Posts: 1291
|
for each window that it tries to cache it currently sets up a buffer of w x 2h So 16-bit colour only at the moment?
I probably should say that I'm *very* impressed with this module, and this is exactly the type of thing that RISC OS should have by default now we have this much memory to play with. Well done!
[Edited by ksattic at 19:40, 11/7/2004] |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #56860, posted by adrianl at 18:50, 11/7/2004, in reply to message #56859 |
Member
Posts: 1637
|
So 16-bit colour only at the moment? No. In fact I've never run the code in 16bpp! I've tried it in 8bpp on my RPC and 32bpp on the Iyonix. Must be an interaction with your screen res I guess; what are you using? Does it work if you drop to 1024 x 768 x 32bpp? I'm still using an archaic monitor
I probably should say that I'm *very* impressed with this module.... Thanks
and this is exactly the type of thing that RISC OS should have by default now we have this much memory to play with. Agreed. And finished code needn't demand all that much memory anyway, I think; there's not much point cacheing StrongED views, for example... just windows that are slow to redraw - the code for those apps should, of course, be tuned too; I can't help with the initial redraw.
Is now the time to make another suggestion, that I haven't (yet) prototyped? The Wimp Sprite Pool (all your Filer icons, background textures & toolsprites) ought to be in the NVidia memory and be plotted in the same way!
I know how to do this, just haven't done all the work yet; will prob try to implement this in the same module soon. |
| |
[ Log in to reply ] |
| |
|
Annraoi |
Message #56861, posted by ams at 19:19, 11/7/2004, in reply to message #56860 |
Member
Posts: 56
|
The Wimp Sprite Pool (all your Filer icons, background textures & toolsprites) ought to be in the NVidia memory and be plotted in the same way!
That would really be neat, nice one Adrian ! |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #56862, posted by adrianl at 19:34, 11/7/2004, in reply to message #56861 |
Member
Posts: 1637
|
The Wimp Sprite Pool (all your Filer icons, background textures & toolsprites) ought to be in the NVidia memory and be plotted in the same way!
That would really be neat, nice one Adrian !
Gonna code it then?
Whilst we're discussing it, can anyone think of a way to accelerate font plotting? That'll be the weakest link if we can get all of the above working. |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #56864, posted by ksattic at 19:50, 11/7/2004, in reply to message #56862 |
Finally, an avatar!
Posts: 1291
|
Hmm. Works in 1024x768x32bpp the second time I tried it. I normally max out my 17" monitor with 1152x864x32bppx78Hz.
I'd love to speed up font plotting with O2, but that's out of the question because it uses its own font renderer.
For RISC OS fonts, render all chars in all fonts/sizes used by apps (loaded with Font_FindFont) to a surface in NVidia memory with an alpha channel. Blit chars to the screen when necessary. You can probably get away with using raster operators in the NVidia core to render different colour fonts.
ATI cards have specific functions in their 2D drivers for caching and rendering fonts. Not sure if NVidia provide something similar to developers. |
| |
[ Log in to reply ] |
| |
|
John D |
Message #56867, posted by john at 22:33, 11/7/2004, in reply to message #56856 |
Member
Posts: 261
|
I'd say don't worry about O2, from my limited experience of it it does just about everything wrong, from crashing in the wrong colour depths to stopping normal window interactions working properly then the computer is busy (until you rmkill InteractorUtils) and it reads the mouse buttons from KeyV by the looks of it, the programmers obviously saw no need to listen to wimp events. |
| |
[ Log in to reply ] |
| |
|
John D |
Message #56868, posted by john at 22:41, 11/7/2004, in reply to message #56847 |
Member
Posts: 261
|
How about you cut out all of the nvidia stuff and just release that. It doesn't have to compile, I just like to bring it up on screen and go, "Mmm interesting," and then cross it off again.
I've just tried it and it seems really good, now I can interpolate something silly in draw. Also when something's redraw loop is crashed I hope this would help with the error loop that sometimes happens. |
| |
[ Log in to reply ] |
| |
|
John D |
Message #56869, posted by john at 22:45, 11/7/2004, in reply to message #56844 |
Member
Posts: 261
|
It seems to slow things drawing for the first time, especially if I'm drawing curves in a large draw window, the "ghost" curve that follows the mouse is slow. This is in 8bpp on a RPC (with the window covering half of a 1600x1200 screen). |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #56870, posted by adrianl at 23:03, 11/7/2004, in reply to message #56869 |
Member
Posts: 1637
|
It seems to slow things drawing for the first time, especially if I'm drawing curves in a large draw window, the "ghost" curve that follows the mouse is slow. This is in 8bpp on a RPC (with the window covering half of a 1600x1200 screen).
This prototype code caches everything, even if it took next to no time to redraw. Clearly that's silly on the RPC machines because it takes time to read back from the screen memory. Even more so if you're using RO3.7 (correct?) which doesn't have the cacheable screen memory introduced with RO4.
Finished code would time the application's redraw code and then decide whether cacheing is actually going to help for that window (region), eg. an interpolated area in Draw could benefit, whereas the window background wouldn't. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #56871, posted by adrianl at 06:11, 12/7/2004, in reply to message #56864 |
Member
Posts: 1637
|
You seem to know a fair bit about the NVidia's capabilities, and I'm not sure whether I've asked you this question directly before -
Do you have any docs other than the Linux XFree86 driver source? Castle can't/won't give us the docs that they have because they obtained them under NDA from NVidia. NVidia won't help us. If you have any more info that would help accelerate the desktop (and/or Pro/Cino of course!), please tell! |
| |
[ Log in to reply ] |
| |
|
John D |
Message #56874, posted by john at 09:24, 12/7/2004, in reply to message #56870 |
Member
Posts: 261
|
Even more so if you're using RO3.7 (correct?) No, it's quite noticable using Select (3i2). However although it was noticable it wasn't exactly productivity-inhibiting. |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #56875, posted by ksattic at 13:35, 12/7/2004, in reply to message #56871 |
Finally, an avatar!
Posts: 1291
|
Do you have any docs other than the Linux XFree86 driver source? Castle can't/won't give us the docs that they have because they obtained them under NDA from NVidia. NVidia won't help us. If you have any more info that would help accelerate the desktop (and/or Pro/Cino of course!), please tell! I'm under an NDA with ATI for one of their cores, and I only know what capabilities the NVidia desktop processors have to be able to compete with ATI's offerings.
I presume that what you could really do with is a way to use the accelerated IDCT routine, as well as hardware motion compensation? Are you already using the overlay feature to convert from YUV to RGB? Some GeForce 4 GPUs have full hardware MPEG-2 decode. I'm not sure about the GeForce 2.
I find it hard to believe that noone in the world has figured out how to do anything besides overlays with NVidia cores. 
I wonder what the legalities are in reverse-engineering released NVidia drivers, or pushing values into registers to figure out the capabilites of the cards.
Does anyone know if it's any easier to get details of hardware acceleration in ATI cores? It might be easier to write a new display driver for a Radeon. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #56890, posted by Phlamethrower at 17:39, 12/7/2004, in reply to message #56858 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Oh, BTW, it will only redraw from cache if the whole rectangle is cached ATM because the code for decomposing into smaller rectangles and redrawing only the uncached bits is horribly broken! (Used to work in an earlier prototype) Ah, I see now. The apple picture wasn't caching at 1280x1024 because the window wasn't initially opening full size. Making it full size and then F12'ing to redraw the whole screen gets it working though. Very spiffy
(And it really does seem that 4MB is the maximum it can allocate on my machine - even dragging the dynamic area slider around won't make it go any higher) |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #56893, posted by adrianl at 19:33, 12/7/2004, in reply to message #56890 |
Member
Posts: 1637
|
(And it really does seem that 4MB is the maximum it can allocate on my machine - even dragging the dynamic area slider around won't make it go any higher)
A consequence of silliness in my code (it used to take a different approach in 1997 when I started working on it! ) and a change in the kernel's behaviour I think - if you asked for a DA of size x it was asking for an initial size (R2 = x) that was bigger than the max size (R5 = always 4MB ). It would appear that RO3.7 gives you only 4MB, but RO4 and later bump up the max size.
[Edited by adrianl at 20:34, 12/7/2004] |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #56894, posted by adrianl at 20:58, 12/7/2004, in reply to message #56893 |
Member
Posts: 1637
|
OK, take two. (same URL). No change for pre-Iyonix machines (well, excepting that  can now use more than 4MB, hopefully)...but on the Iyonix, I've prototyped acceleration of textures, toolsprites & optionally filer icons.
It's noticably smoother displaying, say, the TaskManager window at full size, or a Filer display with > 100 icons. Note that filer icons are normally plotted with a mask and, ATM, I can only accelerate this by screwing up the display (see ReadMe and Reset), so the default settings don't do this.
Also, it'll go wrong if your Wimp sprite pool changes because, for example, the Filer spots another app. As before - save your work, load, play and stop before something goes horribly wrong!
Interesting?
[Edited by adrianl at 22:01, 12/7/2004] |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #56922, posted by ksattic at 16:05, 13/7/2004, in reply to message #56894 |
Finally, an avatar!
Posts: 1291
|
Cool!
Caching now works in 1152x864! It does some odd things with certain icons (such as !AMPlayer), but at least the module quits gracefully.
Unlike the first module I ever wrote last night... |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #56928, posted by Phlamethrower at 17:48, 13/7/2004, in reply to message #56922 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
No change for pre-Iyonix machines (well, excepting that can now use more than 4MB, hopefully) Yup - now working fine with 16MB
Unlike the first module I ever wrote last night... The one you emailed me about, I take it? |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #56935, posted by ksattic at 19:07, 13/7/2004, in reply to message #56928 |
Finally, an avatar!
Posts: 1291
|
The one you emailed me about, I take it? When I did an *rmkill pcitv, the results were...interesting.
I couldn't tell you what the output was, because it was paging by so quickly on the machine, but an Alt-Break fixed it. Well, until the Filer went wrong and started showing garbage in directory displays! |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #56945, posted by adrianl at 09:13, 14/7/2004, in reply to message #56922 |
Member
Posts: 1637
|
It does some odd things with certain icons (such as !AMPlayer) It does lots of odd things with a load of icons, mainly because it sometimes just guesses a palette!
I just wanted to a get a feel for the speed increase that's possible.
Unlike the first module I ever wrote last night... Want any help?
I'm stunned that you've managed to write PCITV but you've never written a module before!
Didn't you need to handle DMA, IRQs and the likes? |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #56971, posted by ksattic at 15:38, 14/7/2004, in reply to message #56945 |
Finally, an avatar!
Posts: 1291
|
I'm stunned that you've managed to write PCITV but you've never written a module before!
Didn't you need to handle DMA, IRQs and the likes? Yes (DMA) and no (IRQs). The DMA controller is inside the BT878 in the TV card, and that's programmed with simple RISC instructions. I would like to handle IRQs, though.
I've plenty of knowledge of everything I need to do to make PCITV better, but to do this I need to write modules. Unfortunately, I've not found a "how-to" guide for writing modules in C. It seems to be a black art, at least for a newcomer to module programming.
At the moment, I can't justify shelling out $350 for the C/C++ development suite. Jeffrey Lee helped me out with a test version of lcc, but I somehow managed to break it.
One thing I've never "got" is assembly. I guess it's because I've never looked much into it, but I don't understand how to keep track of multiple variables, loops, etc, when all you have is 16 registers to play with.
How do you write modules? Is Aemulor all assembly? How did you learn? I'd love some help. |
| |
[ Log in to reply ] |
| |
| Pages (2): 1
> >|
|
