Hi everybody!

(I m used to reading comp.lang.asm.x86 but at school we arent allowed to post there (they dont want the name of school to appear in a potential flamer mail address huh) and its my only net access so i finally registered here, so dont strike too hard if its not SOO win-related pliiize)

I just was wondering, lets say you ve got the ddraw lpsurface pointer to acces the vram directly (just to make it win32-related hehe) or, like I like to do, youve got the pointer to the lfb returned by a vesa2.0 int0x10 setmode func under plain old dos, and you re able to use it ^_^ for example by changin seg sizes yourself and returnin to realmode... so you ve got a pointer , IN THE ADDR SPACE of cpu, and you want to use it, and it points to a mem cell, just like any other in the ram chips.

Then (okay it goes though segs to compute linear addr) , you read a pixel, and write it back. I dont see why the surrounding vram wouldnt go into the cache, and so when you write it just after, i wouldnt travel again through the bus but it would stay in the cache...
I mean, THERE ARE some parts of addr space that we might want to be effectively modified...
I know there is no entry in the seg descr describing such an attribute ("not to be cached??" maybe ) and i thought it would perhaps be in the paging system... but i realized that in flatrealmode you havent set up ANYTHING such... and linear=physical... so I m lost. I didnt find it in intel docs (but heck maybe I didnt search long enough ^_^)
Dont think the bios int0x10 setmode would go so far as to set PM and enable a page there...
And windows drivers??

could it be that little parts of addr space have attributes stored somewhere else? btw what happens for the place where there is nothing at all? haha... the 48MB+1byte of my P133 would surely return 0(or TRUE RANDOM ? GREAT hehe) even after I wrote 1 to it... gotta test!

could you enlighten me on that please, maybe i m misundertanding cache right now...

Also, I saw a demo that achieved 30+ fps in 640.480.8 on my 133's S3Trio 1MB... and heck how did they do? I cant think of ANY faster way of refreshin screen than doing rep movsd from ram to lfb withoutt simd, or did they build the frame in vram, and flip, so I wondered, is mov slower in vram than in ram? (<-question ^_^) ; another thing, they said they used pci optimization, have you guys a clue?

Well, that will be all for today...
I m sure you will show me the light of knowlege folks :)
Bye!
Posted on 2003-10-30 10:37:37 by HeLLoWorld
Well,

Yes accessing video RAm is much slower when compared to system main RAM.
This is because the CPU and the video board's GPU have to share this memory. theortically the speed should be at least 1/2 when compared with system ram.

The reads from video RAM are the worst case scenario in curent video boards.
This is why if you intend to use video RAm directly either via LFB or DirectX's pointers after Surface::Lock in DX7
My advice: You should never read from Video RAM just write to it!
(yes i know this is pathetic -- but then again such is humman race on this planet ...so who cares?)

CPU will indeed cache video ram as any other RAM and this might help or (usually) hurt a lot.
The help can come from either the PCI (are there still PCI video boards out there :grin: ?
Or (more likely) the AGP controller .
All this stuff is in the motherboard ICs -- i guess the North bridge

Depending on each motherboard manufacturer you could indeed optimise such things : like setting the video ram area as write combining or none.

Theoretically you could get more help from the videoboard itself...
if you know its internal registers/ports and operations :grin:

With the CPU you could use MOVQNT or such stuff but not on old P1/P2

Also the final single rep movsd (or optimised variant) can be quite fast ...
if you make all other operations in a system backbuffer

The only help you can get from paging in this video ram quest is moving the LFB out of the way of the rest of the OS. Since the LFB is fixed by video mode and board manufacturer...

However the manufacturers have been inteligent enough to place this LFB address near the end of 4Gbytes RAM limit... so this help is welcomme but... somehow useless :tongue:

So again "read my lips" never READ a pixel from video ram just WRITE it !

I guess this line of questions is more likely related to "OS construction" or heap but since you have NOT expressed such intrests i will leave it hang here... for a while
Posted on 2003-10-30 13:15:27 by BogdanOntanu
Thank you so much BogdanOntanu.

I dont read from vram in fact, but what I wanted to know was wether vram was cached or not.
So if I understand, its not stored in paging system.
Maybe you could configure this, but you would need a windows motherboard driver, isnt it?

So: if by default after bios sequence, for example plain RMode dos, all gets cached, then when you write from vram then write to it, the pixel stays UNCHANGED until the cache flushes??? right??
And after all, data go into the cache even after a write, right? (or not?) so when you
mov,red
mov ,blue
the pix is still red until cache line is flushed? could this be?

Also, didnt think of it at first, but all this is exactly the same for vga at 0xA0000 isnt it?
its mapped by the system chipset?

And the real mem cells of ram that were intended to be at 0xA0000 , are they reported at the end of the free addr space by systm chipset?? (same thing goes for bios eeprom in cpu addr space if you dont use shadowing)...does it mean there is 64K free ram after the 48M on a PC with 48M because of vga?
A first I thought this was done by paging but heck in flatreal mode you havent got paging enabled. (you cant use paging with cr0.prot_enable disabled can you?)
So there really is ANOTHER level of addr translation done by motherboard hardware??

btw I m not writing an OS, but I would like to understand how things are done.
In fact I 'd like to write a software Hi-res 3d engine in full asm one of this days...

I personally think hardware standards are a wondeful thing; I guess for backward comp/ modularity/ evolution, its necessary to have drivers/api in software, but heck... thats very sad for os/lowlevel writers...
with vesa2.0, keyb controller, intr controller, ps2 or serial mouse you can do wonderful things WITHOUT an OS ... but things change, usb is a zillion times harder if possible at all, to access(thins includes mice, webcams...), sound was dead long ago outside an recent OS, etc :( ... well enough ranting and sighing for today:grin:

maybe my 3d thing will be directdray after all... haha

take care:
Posted on 2003-10-31 10:09:23 by HeLLoWorld
Bassically BIOS setups A000 video ram range(s) as uncached at startup :grin:
So your assumptions are wrong

Also the LFB or standard VGA addresses are relocated/reported / abused etc by the video board.
Unless video board is integrated into mainboard chipset ...

Vram memory "cells" (we use to call those bytes or words or dwords) are not assumed to be fixed other but by an VGA "standard" in all other VESA modes the video board is "free" to place vram at whatever address place it likes :tongue: -- and this is not very hard to do in hardware

Yes you might have some extra RAM available in your PC because of vram, if you do not need the screen that is (however ths ram is extra slow)

Yes there can be memory translations done by motherboard and/or video board, but also there can be no translation at all

There is no such thing as "hardware standards" today -- humman race is pathetic

Most so called "standards" are a fluid "agreement" between the manufacturers that hold the most of the market share at a given time.

Standards eventually alow your competitors to make the same product even better or costing less --> although preached a lot --> this is not acceptable in a capitalistic/competition oriented world.

And when it is finnaly happening via dissemination: the big guys that another patent out of their gadget store and the world goes on happy vithe the NEW and improved "you name it"

USB is very easy to do, i have seen many USB drivers in ASM (NDA prevents me from talking)

Unfortunately / usually new "modern" hardware is a pathetic clone of some lost old stupid idea, polished up to a nice new shineing coating.

The only thing that keeps everybody from easy doing drivers and applications from it are: patents, secret docs, NDA's signed, fear, etc

I doubt you could do any 3D libs and/or software renderer that will beat modern 3D hardware -- you might have a chance at 2D :grin: ...no matter if you used ASM or Java

You might well implement a new ideea like raytracing eventually but without the help of hardware manufacturers -- actually with they beeing against you -- ....

Today everybody wants the same triangle scanline hardware algorithm maybe add some pixel level shaders lately -- like it was in software 10 years ago :tongue:

I never take care
Posted on 2003-10-31 11:26:26 by BogdanOntanu
huh... so ... that would be the cause of all it... you really think it could be THAT much simplier interfacing devices and apps, if protocols lasted longer, were better designed and were handled by chips and firmwares on the devices... I dont know. But that would be really great (imo at least)

thank you for sharing your knowledge of pc architecture. I m a curious guy :D

I would love to know how to intrface a usb mouse from scratch.
Maybe even get the video frames from a webcam?dont think its possible...
Of course, in the list of driver-powered devices, I forgot the most important ones: hard disks.Well, not really if you use bios to write sectors, true.

Quote:
////I doubt you could do any 3D libs and/or software renderer that will beat modern 3D hardware -- you
//// might have a chance at 2D ...no matter if you used ASM or Java

haha I absolutely nevr said that was a goal of mine! I want to prove myself that, with a machine that can do logical ops on memory, and a device that displays this memory, I can do a system that shows a 3d world... Quite common I know, but you see, I ve been learning and gathering info for too long now, and I havent really produced something consistent. I know how to do it, but I dont know all the problems I m gonna face while implementing it, so... I ve got to do it to see MY thing working, even if its flat-shaded. :)

You might well implement a new ideea like raytracing eventually but without the help of hardware manufacturers -- actually with they beeing against you -- ....

///Today everybody wants the same triangle scanline hardware algorithm
/// maybe add some pixel level shaders lately -- like it was in software 10 years ago

btw I recently discovered that there have been people trying to do realtimeraytracing for very long now. There even is a German research team building a hardware architecture(SaarCor) to achieve this. maybe rasterizers days are over...
there is an "openRT" api too!

/// I never take care
huh... for me "to take care" was meaning "to be careful" or somthng like that.Hope I didnt say somethin wrong, didnt want to.


regards,
Posted on 2003-10-31 12:21:02 by HeLLoWorld