[9fans] shared memory

[9fans] shared memory

[paurea]

I am writing (or trying to :-)) the driver for the sis630 vga card. It
uses shared memory, i.e. the video memory comes from the normal ram of
the computer. At first it seemed to me I had to reserve memory for it
like a dma buffer, but after looking more closely to the linux driver,
it seems to me that something hardware is going on and that the memory
is reserved some way by the bios works as normal video memory. Does
anybody know how this should be treated?. Any pointers to info?.
-- 
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"

Re: [9fans] shared memory

[Ronald G Minnich]

On Mon, 29 Jul 2002 paurea@gsyc.escet.urjc.es wrote:

> I am writing (or trying to :-)) the driver for the sis630 vga card. It
> uses shared memory, i.e. the video memory comes from the normal ram of
> the computer. At first it seemed to me I had to reserve memory for it
> like a dma buffer, but after looking more closely to the linux driver,
> it seems to me that something hardware is going on and that the memory
> is reserved some way by the bios works as normal video memory. Does
> anybody know how this should be treated?. Any pointers to info?.


sis 630 vga card? don't you mean a motherboard with an sis630 chipset?

Anyway, the sis630 integrated vga uses part of main memory for graphics
memory, called SMA (Shared Memory something). You have to see if it is
enabled (always true with normal bios)  and then see how big it is. Also
the SMA can be supplied by any of the DIMM slots.

Here is the linuxbios code for this.

/* find the device */
        if ((pcidev = pci_find_device(PCI_VENDOR_ID_SI,
PCI_DEVICE_ID_SI_630, NULL)) == NULL)
                return 0;

/* see which banks are enabledd */
        pci_read_config_byte(pcidev, SIS630_BANKENABLE, &dram_status);
        dimm_status = dram_status & 0x7;

/* see if shared memory with integrated vga is enabled */
        sma_enable = dram_status & 0x80;

/* see which dimm is being used for the shared memory */
        pci_read_config_byte(pcidev, SIS630_DIMM_LOCATION_FOR_SMA,
&sma_location);
        sma_location &= 0x03;


        /* compute Shared Menory Area (SMA) size in Mega Bytes */
        sma_size_bits = (dram_status >> 4) & 0x7;
        if (sma_size_bits > 5)
                // this is invalid!
                sma_size = 0;
        else {
                sma_size = (2 << sma_size_bits);
        }


at the end of this code fragment sma (an int) has the shared memory sized
in MB.

let me know if you get this going, we're interested here -- I have a fair
number of these motherboards.

ron

Re: [9fans] shared memory

[Ronald G Minnich]

I realized that a lot of code I sent you don't really need.



On Mon, 29 Jul 2002, Ronald G Minnich wrote:

struct pci_device pcidev;
int sma_size_bits;
int sma_size_mbytes;
>
> /* find the device */
>         if ((pcidev = pci_find_device(PCI_VENDOR_ID_SI,
> PCI_DEVICE_ID_SI_630, NULL)) == NULL)
>                 return 0;
>
> /* see which banks are enabledd */
>         pci_read_config_byte(pcidev, SIS630_BANKENABLE, &dram_status);
>         dimm_status = dram_status & 0x7;
>
> /* see if shared memory with integrated vga is enabled */
>         sma_enable = dram_status & 0x80;
>
>         /* compute Shared Menory Area (SMA) size in Mega Bytes */
>         sma_size_bits = (dram_status >> 4) & 0x7;
>         if (sma_size_bits > 5)
>                 // this is invalid!
>                 sma_size = 0;
>         else {
>                 sma_size = (2 << sma_size_bits);
>         }
>

Re: [9fans] shared memory

[andrey mirtchovski]

the real problem with the sis630 is that it lacks hardware cursor...

i have some ocde that will attempt to get the sis630 going but
when i finally figured out the 'no HW cursor' part i gave up...

andrey

On Mon, 29 Jul 2002 paurea@gsyc.escet.urjc.es wrote:

> I am writing (or trying to :-)) the driver for the sis630 vga card. It
> uses shared memory, i.e. the video memory comes from the normal ram of
> the computer. At first it seemed to me I had to reserve memory for it
> like a dma buffer, but after looking more closely to the linux driver,
> it seems to me that something hardware is going on and that the memory
> is reserved some way by the bios works as normal video memory. Does
> anybody know how this should be treated?. Any pointers to info?.
> --
>                  Saludos,
>                          Gorka
>
> "Curiosity sKilled the cat"
>

Re: [9fans] g++

[okamoto]

>>`We' must have been used in exclusive meaning, maybe.
>>
> Boyd wa bakasakagen desu.
> Hito natsukkoi desu. :-)

Yeah, I love his personality, judging from his writing here.
However, if he is more productive, I love him much.☺

Kenji

[9fans] shared memory

[okamoto]

I'm getting familier with g++ on Plan 9.
I stalled by the fact that hpijs uses shared memory.
I remember Dave announced shared memory support on Plan 9,
which could be 3ed, (my memory fades out very quickly these days...)
What is the present status of shared memory for Plan 9?

Kenji

Re: [9fans] shared memory

[Geoff Collyer]

It exists.  segattach(2) and rfork(2) should get you started.  You'll
want to use lock(2), rendezvous(2), or thread(2) to coordinate access.
pool(2) can be used to allocate pieces of it.

Re: [9fans] shared memory

[okamoto]

> It exists.  segattach(2) and rfork(2) should get you started.  You'll
> want to use lock(2), rendezvous(2), or thread(2) to coordinate access.
> pool(2) can be used to allocate pieces of it.

Hmm, I'm an application programmer at most, and want some
more user friendly functions such as shmat() etc.  Isn't it impossible?

kenji

Re: [9fans] shared memory

[Geoff Collyer]

I wouldn't have called shmat `user friendly' and I don't think it's
any easier to use than the Plan 9 machinery.  shmat, shmget, etc.
don't really do much for you; they just do what segattach does, but in
a more complicated way.  You still have to arrange to coordinate
access by the processes sharing the memory.  I think

	char *ss = (char *)segattach(0, "shared", nil, length);

is all you need to allocate a shared segment of size `length', though
you still have to actually share it, probably by forking.

If the processes in question are related, you don't even need
segattach, just be careful to keep per-process data on the stack (in
automatic variables) and when you rfork(), be sure to include the
RFMEM flag.  After the rfork, parent and child will share their data
segment.

If you're looking for a way for unrelated processes to share memory, I
think your best bet is to use the undocumented S option of ramfs:

	ramfs -S shared1

to create a sharable /tmp, then have all the programs that want to
share the memory do:

	mkdir /tmp/shared1
	mount -c /srv/shared1 /tmp/shared1

The 'l' permission bit on files in /tmp/shared1 can implement locks.

How are you trying to share memory (or what are you trying to
accomplish)?  All of the above assumes that you want something like
System V shared memory.

Re: [9fans] shared memory

[Charles Forsyth]

>>If you're looking for a way for unrelated processes to share memory, I
>>think your best bet is to use the undocumented S option of ramfs:

there is also segment(3), when configured.

Re: [9fans] shared memory

[splite]

On Fri, Sep 12, 2003 at 10:30:57AM +0100, Charles Forsyth wrote:
> >>If you're looking for a way for unrelated processes to share memory, I
> >>think your best bet is to use the undocumented S option of ramfs:
>
> there is also segment(3), when configured.

Did anyone else read that and wonder "how do you ment a seg?"

I need more coffee.  Or maybe a frosty Hires "High Resolution" root beer.

Re: [9fans] shared memory

[boyd, rounin]

> I wouldn't have called shmat `user friendly' ...

sysVile IPC was positively hostile; a bolt-on that was very badly engineered.

the message queue implementation seemed to been have done by someone
who didn't understand queues and/or sleep/wakeup.

the shared memory was extremely non portable.  where would you like to
stick the segment in your virtual address  space?  think of a random number,
a large one, but not too large and make sure it's aligned.

rfork make some things very easy.

Re: [9fans] shared memory

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

man segment

I wrote that for a business unit at lucent that needed globally shared
segments for in memory databases.

     EXAMPLE
          Create a one megabyte segment at address 0x10000000:
               % bind '#g' /mnt/segment
               % mkdir /mnt/segment/example
               % echo 'va 0x10000000 0x100000' > /mnt/segment/example/ctl

          Put the string ``hi mom'' at the start of the segment:
               % echo -n hi mom > /mnt/segment/example/data

          Attach the segment to a process:
          {
               ulong va;

               va = segattach(0, "example", 0, 0);
          }

You'll have to make a kernel with devsegment in it.

[-- Attachment #2: Type: message/rfc822, Size: 2128 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] shared memory
Date: Fri, 12 Sep 2003 17:52:08 +0900
Message-ID: <b7dbb55d564e34d09fe59ddea98ca20d@granite.cias.osakafu-u.ac.jp>

> It exists.  segattach(2) and rfork(2) should get you started.  You'll
> want to use lock(2), rendezvous(2), or thread(2) to coordinate access.
> pool(2) can be used to allocate pieces of it.

Hmm, I'm an application programmer at most, and want some
more user friendly functions such as shmat() etc.  Isn't it impossible?

kenji

Re: [9fans] shared memory

[okamoto]

> man segment

Thanks Geoff and David.
I've been in a small holidays, and had time to work with hpijs
for three days.   Tough I had to watch TV of Hansin Tigers
baseball games everyday. ☺

Anyway, shared memory is proved not to be neccessary in the
present case if I neglect the compatibility of older versions of hpijs.
Then, I decided to neglect it.   I'll use your teaching in some another
chance, thank you very much.

By the way, I have now compiled hpijs using Plan 9 g++.  Yes, it worked
very fine with some small band-aids.   I needed hpijs driver, because
I got purchased all-in-one type inkjet printer (HP psc2110, connected
to usb port by Sape), and want to make it work on my home Plan 9 system.

Russ, have you revised the ghostscript to newest version?

kenji

Re: [9fans] shared memory

[okamoto]

> Russ, have you revised the ghostscript to newest version?

Hmm, fntem.ps...

Re: [9fans] shared memory

[Russ Cox]

> Russ, have you revised the ghostscript to newest version?

no.  i did update our internal copy to gs 8.00,
but that seemed to break more than it fixed.
they just released 8.11, "the first stable release
since 8.00", whatever that means.  all i know
is that i can't view the intel architecture
manuals using 8.00.  they're all shifted half
a page up off the screen.

i have not been impressed since peter deutsch
handed over the reins.  there used to be a
mailing list for people interested in announcements
about new releases.  we'd get a mail a month
saying "this just came out and fixes such-and-such."
there's no equivalent now, so i never know when
something is worth trying or not, and i haven't been
very aggressive in watching for new releases.

the instructions for pulling in new source
are in /sys/src/cmd/gs/mkfile.  mk try-8.11
should do most of the work.  you may need to
tweak it.