flat assembler
Message board for the users of flat assembler.

Index > Main > what is faster?

Goto page Previous  1, 2, 3  Next
Author
Thread Post new topic Reply to topic
edfed



Joined: 20 Feb 2006
Posts: 4354
Location: Now
edfed 27 Feb 2011, 16:13
sure its slow (very slow compared to HW acceleration), but it works.
for faster execution, maybe use a different algorithm to fill a rectangle can be good.
Post 27 Feb 2011, 16:13
View user's profile Send private message Visit poster's website Reply with quote
Teehee



Joined: 05 Aug 2009
Posts: 570
Location: Brazil
Teehee 28 Feb 2011, 00:26
Question: Is it a good practice to save the value of the registers that you change inside a function? or thats not important?
Post 28 Feb 2011, 00:26
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 28 Feb 2011, 00:37
Teehee wrote:
Question: Is it a good practice to save the value of the registers that you change inside a function? or thats not important?
Follow your calling convention. For STDCALL, you can trash EAX,ECX,EDX.

_________________
carpe noctem
Post 28 Feb 2011, 00:37
View user's profile Send private message Reply with quote
Teehee



Joined: 05 Aug 2009
Posts: 570
Location: Brazil
Teehee 28 Feb 2011, 11:24
Do you mean follow my own calling convention, or just in case if i was follow one? I don't even know if i want to follow one.
Post 28 Feb 2011, 11:24
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4354
Location: Now
edfed 28 Feb 2011, 14:07
it juste depend, do you want your programm to be easy for you to debug, or do you want to deal with existing conventions, inducing a lot of learning, need to read a lot of documentation, and try, try, try again.

in both cases, your program will work, in the case of custom calling convention, you just have to "invent" a way you find easy to understand.
if you "invention" is like an existing convention, use that convention, else, developp your convention.

but wich is fastest?
if you want to know, you can use the tricktest pseudo-application i wrote to compare many snippets one by one.
http://board.flatassembler.net/topic.php?p=119650#119650
Post 28 Feb 2011, 14:07
View user's profile Send private message Visit poster's website Reply with quote
Teehee



Joined: 05 Aug 2009
Posts: 570
Location: Brazil
Teehee 28 Feb 2011, 16:05
JohnFound wrote:
using putpixes is not a good idea especially in order to fill big areas with the same collor.
Use dword chunks of data. For 24 bit color this is not very convenient, but still can be implemented - use 4pixel array, that is exactly 3 dwords load them in 3 registers and then fill the area on dword basis.
edfed wrote:
yep.

use a double buffer in 32 bits.
and just transfer pixels for 24 bpp with dwords.

basically, you can create a virtual screen, of any resolution (very big is possible), in 32 bpp, and only vsync will do the refresh to the target resolution and bpp.

----

double buffer fixed resolution and bpp > vsync > resolution and bpp convert to screen

this can be a method.

Guys, im a lil bit lost on this. Help me understand this buffer thing. Isn't the VBE buffer fixed? so how can i change that buffer?


this is how i rewrote the drawfillrect function (faster now), but i get the pixels in a different color (overlaps Sad );
Code:
    drawfillrect:
        mov  eax,[esp+2*4] ;y
        add  eax,[esp+4*4] ;h
        mov  ebx,[esp+1*4] ;x
        call moveTo
        mov  eax,[esp+5*4] ;c
        ;shl  eax,8  ; if i uncomment this line i got right colors, except the last one.
        mov  edx,[esp+3*4] ;w
        shl  edx,1
        add  edx,[esp+3*4] ;w   edx = w * 3bytes
        mov  ecx,[esp+4*4] ;h
  .for: mov  ebx,edx
    @@: mov  dword[edi+ebx],eax ;c
        sub  ebx,3
        jnz  @b
        sub  edi,1280*3
        dec  ecx
        jnz  .for
        ret  5*4     

_________________
Sorry if bad english.
Post 28 Feb 2011, 16:05
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 28 Feb 2011, 16:39
I wrote about using 32bit chunks to write 24bit pixels.

Let say you want to use 24bit color $112233 (in memory: $33 $22 $11)
Then you need to construct 3 dwords (that will contains 4 pixels). Something like this:
Code:
mov  eax, $33112233
mov  ebx, $22331122
mov  ecx, $11332211
    

Then you can write pixels like this:
Code:
mov  [edi], eax
mov  [edi+4], ebx
mov  [edi+8], ecx
    


With 3 instructions (memory writes) you write 4 pixels of color $112233

Of course you have to check the size of the rectangle (line) and if it is not multiply of 4 to make some different processing of the last pixels, but it concerns only 1..3 pixels and will not slow down the algorithm.
Post 28 Feb 2011, 16:39
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4354
Location: Now
edfed 28 Feb 2011, 18:53
the double buffer means:
1: you don't use directlly the Screen Memory
2: you write pixel anywhere in memory but screen memory
3: you transfert pixels from buffer to screen memory periodically
4: you can read pixel without reading to screen memory
etc...
john found: nice trick, i will try it one day.. Very Happy
Post 28 Feb 2011, 18:53
View user's profile Send private message Visit poster's website Reply with quote
Teehee



Joined: 05 Aug 2009
Posts: 570
Location: Brazil
Teehee 28 Feb 2011, 19:12
edfed wrote:
3: you transfert pixels from buffer to screen memory periodically

it seems slower. (me and my speed obsession Razz )
edfed wrote:
4: you can read pixel without reading to screen memory
there is any advantage?

Quote:
john found: nice trick, i will try it one day.. Very Happy

I tried, but no sucess yet. Razz

_________________
Sorry if bad english.
Post 28 Feb 2011, 19:12
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 28 Feb 2011, 19:14
Reading GPU memory is überslow, so if you want to do software post-processing, double-buffering can be a win.

Outside of toy OS tinkering, try to go for GPU acceleration, in which case you don't want double buffering.
Post 28 Feb 2011, 19:14
View user's profile Send private message Reply with quote
Teehee



Joined: 05 Aug 2009
Posts: 570
Location: Brazil
Teehee 28 Feb 2011, 19:32
whats GPU and überslow?
Post 28 Feb 2011, 19:32
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 28 Feb 2011, 19:38
GPU = Graphics Processing Unit, semi-modern term for a capable graphics card.

überslow = super slow, very slow, crazy-ass slow, <insert your own term> Smile
Post 28 Feb 2011, 19:38
View user's profile Send private message Reply with quote
Teehee



Joined: 05 Aug 2009
Posts: 570
Location: Brazil
Teehee 28 Feb 2011, 19:48
and what would be the GPU acceleration?
Post 28 Feb 2011, 19:48
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4354
Location: Now
edfed 28 Feb 2011, 20:02
GPU acceleration is a set of instructions and data structures used in the GPU, exactlly as instructions and datas for the CPU, but close to the video DAC (digital to analog converter), and very different because it is a purpose specific processor, just made to compute faster the pixels in 3D, and fill faster the screen in 2D.

the 2D HW acceleration is a set of basic commands, passed to the GPU.
for example to draw a line, fill a rectangle, put a bitmap,write font... and is specific to each model of GPU, not like the instruction set of X86.

if you want to exploit the HW acceleration, it is better to use OPENGL, direct draw, win32, X, GTK, QT within an OS like windows or linux. for the moment, maybe latter, there will be a good way in BOOT asm.
Post 28 Feb 2011, 20:02
View user's profile Send private message Visit poster's website Reply with quote
Teehee



Joined: 05 Aug 2009
Posts: 570
Location: Brazil
Teehee 28 Feb 2011, 20:07
edfed wrote:
the 2D HW acceleration is a set of basic commands, passed to the GPU. and is specific to each model of GPU, not like the instruction set of X86.
Sad i want to learn more about it. Is there any link?

Quote:
if you want to exploit the HW acceleration, it is better to use OPENGL, direct draw, win32, X, GTK, QT within an OS like windows or linux. for the moment, maybe latter, there will be a good way in BOOT asm.

Sad why or how? I did use OpenGL years ago.

_________________
Sorry if bad english.
Post 28 Feb 2011, 20:07
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4354
Location: Now
edfed 28 Feb 2011, 20:11
1:google.com, osdev.org, osdever...etc.
2:fasm example named OPENGL in the official FASMW package.
Post 28 Feb 2011, 20:11
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 28 Feb 2011, 21:06
edfed wrote:
GPU acceleration is a set of instructions and data structures used in the GPU, exactlly as instructions and datas for the CPU, but close to the video DAC (digital to analog converter), and very different because it is a purpose specific processor, just made to compute faster the pixels in 3D, and fill faster the screen in 2D.

the 2D HW acceleration is a set of basic commands, passed to the GPU.
for example to draw a line, fill a rectangle, put a bitmap,write font... and is specific to each model of GPU, not like the instruction set of X86.

if you want to exploit the HW acceleration, it is better to use OPENGL, direct draw, win32, X, GTK, QT within an OS like windows or linux. for the moment, maybe latter, there will be a good way in BOOT asm.


AFAIK, there is some VESA enhanced functions for dealing with HW accelerated video. But the last time I looked for it (5 years ago) it was closed specification that one have to buy from VESA.
It was named VESA/AF of something similar.
Post 28 Feb 2011, 21:06
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 28 Feb 2011, 21:13
I dunno if there were ever any video cards supporting that, JohnFound? (Except perhaps for a few expensive ones) - it seemed to come at too late a time, when things headed towards Windows/whatever very fast, and that became the place for accelerated graphics.

The univbe driver supported the spec, but that might have been software emulation rather than hardware supported. And it was all rather messy if you wanted to use it from pmode.
Post 28 Feb 2011, 21:13
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 28 Feb 2011, 21:23
So, what is the conclusion? Every OS maker must begin with decent video driver interface it he wants its OS to have any future. Very Happy
Post 28 Feb 2011, 21:23
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4354
Location: Now
edfed 28 Feb 2011, 22:10
Mode 13h is good enough. Laughing
Post 28 Feb 2011, 22:10
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.