Re: 32bit
> please view http://www.erikyyy.de/noshine/ggi/ Here we go ...: : do not do anything with directbuffers, it's useless. Well - for your exact problem, you are right. Directbuffer is for apps that update only small portions of the screen. Full screen changes are slow on some targets, due to the reasons you outline very nicely. Also note, that for the X target, the directbuffer _is_ in main memory, so that you could as well use it. (However as you can't probe, if you are in X, ...) : - if you do 32bit or 16bit access, some hardware cannot do this. Note, that this also applies to most host memories. If I do _unaligned_ accesses on Alpha or Sparc, I get SIGBUS. x86 is the only architecture that goes to excessive complications in the PCI and memory interface of the CPU to work around such misconcepted software. Linux/Alpha will work around on demand using a CPU exception, but this will be _very_ slow. So the message is: Don't do unaligned accesses. Never. AFAIK there is no hardware that cannot do a given width (of the form 8^n), as long as it it is aligned. This is due to the simplicity of splitting larger transfers and the commonness of having byte-accesses. : why not use a mem-target instead of the mainmem buffer and : do a ggiCrossBlit with it ? : because this is exactly the same thing. it is exactly the same speed. : but it is more complicated to code, so why should you do it. This depends on how your code is organized. It sometimes is convenient to have the highlevel functions available, if the code is structured to make use of them (then it is simpler to code using the memtarget), but for many games codes, you have code that uses direct access to a membuffer for everything anyway, so then it would be more complicated to code as you say. : why use palemu target if visual is not 8 bit, why not use : the not 8 bit visual and do a ggiCrossBlit from my 8bit mem-target visual : to the not 8 bit visual ? : because palemu is faster. Is it ? It shouldn't make much difference actually, but maybe. Got to check the sources on that one ... Is the difference significant ? CU, ANdy -- = Andreas Beck| Email : <[EMAIL PROTECTED]> =
Re: 32bit
> i am especially interested in if > ggiPutBox from memory(malloc) to visual > is equally fast then > ggiCrossBlit from memory-target to visual > (memory(malloc) and memory-target and visual are all > the same format. 640x480x8 linear) This shouldn't make much difference, as long as format is the same. The CrossBlit function first checks, if the Directbuffers are compatible, and if so, it will try to memcpy between them. Potentially CrossBlit should also have the possibility for accelerated transfers (DMA), but this isn't implemented for any target AFAIK. CU, ANdy -- = Andreas Beck| Email : <[EMAIL PROTECTED]> =
Re: 32bit
On Tue, Feb 01, 2000 at 10:40:10AM +0100, Erik Thiele wrote: > i'd like to contribute a little bit of GGI documentation. > > please view > > http://www.erikyyy.de/noshine/ggi/ > > and please correct me if i am wrong! > i am especially interested in if ggiPutBox from memory(malloc) to visual is equally fast then ggiCrossBlit from memory-target to visual (memory(malloc) and memory-target and visual are all the same format. 640x480x8 linear) cu erik -- Name: Erik Thiele Email: [EMAIL PROTECTED]o `QQ'_ IRC: erikyyy/ __8 WWW: http://www.erikyyy.de/ ' `
Re: 32bit
On Mon, Jan 31, 2000 at 11:43:52PM +0100, Andreas Beck wrote: > > if directbuffer fill it with memcpy but memcpy does 32 bit stuff. > > (rep movsl) but directbuffer maybe 16bit limited on old vga hardware > > how to deal with this. > > First of all, check the "align" and "noaccess" members. > If no restrictions are set, go ahead, use memcpy. > > > do not have memcpy 16bit. for(...)... is very bad code if you look at the > > asm. > > how deal with this issue ? > > Call higher level primitives. The common cases are erasing the screen or > drawing scanlines. Especially erasing the screen shouldn't be done by > DB-access, as it is commonly accelerated. Drawing scanlines might be o.k., > but if they aren't very short, the overhead for calling hline isn't > very high. sure but i have software rendered buffer. cannot accelerate. this buffer shall be shown on screen after calculation. not possible to do hline or other accelerated stuff. so.. in the end, it might be true, that a memtarget and then a crossblit are the fastest solution, and always working. but ggiPutBox are exactly equal fast. i'd like to contribute a little bit of GGI documentation. please view http://www.erikyyy.de/noshine/ggi/ and please correct me if i am wrong! cu erik -- Name: Erik Thiele Email: [EMAIL PROTECTED]o `QQ'_ IRC: erikyyy/ __8 WWW: http://www.erikyyy.de/ ' `
Re: 32bit
> if directbuffer fill it with memcpy but memcpy does 32 bit stuff. > (rep movsl) but directbuffer maybe 16bit limited on old vga hardware > how to deal with this. First of all, check the "align" and "noaccess" members. If no restrictions are set, go ahead, use memcpy. > do not have memcpy 16bit. for(...)... is very bad code if you look at the > asm. > how deal with this issue ? Call higher level primitives. The common cases are erasing the screen or drawing scanlines. Especially erasing the screen shouldn't be done by DB-access, as it is commonly accelerated. Drawing scanlines might be o.k., but if they aren't very short, the overhead for calling hline isn't very high. CU, ANdy -- = Andreas Beck| Email : <[EMAIL PROTECTED]> =
32bit
hi if directbuffer fill it with memcpy but memcpy does 32 bit stuff. (rep movsl) but directbuffer maybe 16bit limited on old vga hardware how to deal with this. do not have memcpy 16bit. for(...)... is very bad code if you look at the asm. how deal with this issue ? cu erik -- Name: Erik Thiele Email: [EMAIL PROTECTED]o `QQ'_ IRC: erikyyy/ __8 WWW: http://www.erikyyy.de/ ' `
