From aschaffe Tue Mar 29 13:54:45 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403291354.ZM18805@holodeck.asd.sgi.com> Resent-Date: Tue, 29 Mar 1994 13:54:45 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Date: Fri, 25 Mar 94 16:09:38 EST From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9403252109.AA15088@ldsa.com> To: info-performer@sgi.sgi.com Status: OR On an Indigo2 Extreme (IRIX 4.0 and Performer 1.0) I need to be able to direct the Performer image output to an NTSC video type display (specifically RS-170 video format). We will probably be using a Galaleo video board. How does one cause the graphic output to be routed to the video board (assuming that it is possible)? I do know that there is a broadcast video option (BVO) available which will scan convert the console image to NTSC, but we would rather use the video board if possible. Also, does anyone know anything about the internals of the pfDraw? Does the draw go directly to the video memory, such that the image is updated immediately, or is the video buffered such that the image will not appear until the next video frame? We have a latency requirement of 150 milisec that we must meet and are trying to account for each step of the process. Email responses can be sent to: mwilliam@ldsa.com Tnx Ken Slezak 216/796-5907 7:30am-4:30pm EST From guest Tue Mar 29 15:08:53 1994 From: peterk@foetus.sydney.sgi.com (Peter Kerney) Message-Id: <9403300857.ZM1371@foetus.sydney.sgi.com> Date: Wed, 30 Mar 1994 08:57:53 -0500 In-Reply-To: mwilliam@ldsa.com (Micheal J. Williams) "" (Mar 25, 16:09) References: <9403252109.AA15088@ldsa.com> X-Face: $5b3RM{:c7HBWke?Q2ED_pDjVz%hll)C'(@AA0J5eHMZ5Icz/Uf'EXR)HME!M?R*7KasG3ks/\2=1\e_1`Z(0GV<;Kj#hQ>HYn_lC/rW3x6YboDE\9+u;'[CnK(ueOqBFqLL=WAkY.SZvMaQT*'%R^!=x;HU4a7pw,HbY5OB=HSHq$Y)wzTW#v# X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: mwilliam@ldsa.com (Micheal J. Williams) Cc: info-performer@sgi.sgi.com Subject: Galileo Video with Performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR I have done some stuff with this here in our office. When you get the Galileo, you will be forced to upgrade to 5.x (probably 2) to make the thing work. I would also imagine that you will have to upgrade your version of Performer as well as all you other products. The Galileo board simply take an NTSC/PAL movable region of your frame buffer and outputs that to video in several formats. It will also output the entire framebuffer using scan conversion if you want. The BVO that you speak of was only available on VGX systems and as such will not enter into the discussion. In order to get the output happenning, you simply invoke the 'videoout' program and move the output window to where you want it. Depending upon you application you could also purchase the Digital Media Developers option which will allow you to call the video library directly and make the application startup a bit simpler. You don't *have* to do anything to your application at all (neat eh!). I am not sure of the answer to your question about the delays associated with the Galileo but I know that the board communicates with the Extreme graphics across the video bus and probably just looks at the frontbuffer and you will get whatever is there are the time. I would say that there is some sort of syncronisation that would stop a swapbuffer occurring on the middle of a video retrace. Hope that answers some of your questions. On Mar 25, 16:09, Micheal J. Williams wrote: > Subject: > On an Indigo2 Extreme (IRIX 4.0 and Performer 1.0) I need to be able to direct > the Performer image output to an NTSC video type display (specifically RS-170 > video format). We will probably be using a Galaleo video board. How does one > cause the graphic output to be routed to the video board (assuming that it is > possible)? I do know that there is a broadcast video option (BVO) available > which will scan convert the console image to NTSC, but we would rather use the > video board if possible. > > Also, does anyone know anything about the internals of the pfDraw? Does the > draw go directly to the video memory, such that the image is updated > immediately, or is the video buffered such that the image will not appear > until the next video frame? We have a latency requirement of 150 milisec that > we must meet and are trying to account for each step of the process. > > Email responses can be sent to: mwilliam@ldsa.com > > Tnx > Ken Slezak > 216/796-5907 > 7:30am-4:30pm EST > >-- End of excerpt from Micheal J. Williams -- -------------------------------------------------------------------------- Peter Kerney. Silicon Graphics, Sydney, Australia. (peterk@sydney.sgi.com) 'Everybody wants a rock to wind a piece of string around.' They Might Be Giants -------------------------------------------------------------------------- From guest Wed Mar 30 08:49:10 1994 From: "Michael Jones" Message-Id: <9403300848.ZM6265@babar.asd.sgi.com> Date: Wed, 30 Mar 1994 08:48:57 -0800 In-Reply-To: peterk@foetus.sydney.sgi.com (Peter Kerney) "Galileo Video with Performer" (Mar 30, 8:57am) References: <9403252109.AA15088@ldsa.com> <9403300857.ZM1371@foetus.sydney.sgi.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: peterk@foetus.sydney.sgi.com (Peter Kerney), mwilliam@ldsa.com (Micheal J. Williams) Subject: Re: Galileo Video with Performer Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Mar 30, 8:57am, Peter Kerney wrote: > Subject: Galileo Video with Performer :I have done some stuff with this here in our office. : :When you get the Galileo, you will be forced to upgrade to 5.x (probably 2) :to make the thing work. I would also imagine that you will have to upgrade :your version of Performer as well as all you other products. You can use any version of IRIS Performer on IRIX 5.2 systems, although the new IRIS Performer 1.2 is the recommended choice. -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Wed May 25 03:48:55 1994 Date: Wed, 25 May 94 18:54:39+080 From: fair@iss.nus.sg (Kim Michael Fairchild) Message-Id: <9405251054.AA18362@bochap.iss.nus.sg> To: info-performer@sgi.sgi.com Subject: real-time video in texture memory Content-Length: 254 Status: OR Hi, Is it possible to get video into texture memory on a reality-engine? I would like do something like you see in "the 7th guest" cd-rom game, so I would like to be able to take a video source and "play" it into a texture. possible? thanks, Kim. From guest Wed May 25 05:56:10 1994 Message-Id: <9405251255.AA22816@merl.com> Organization: Mitsubishi Electric Research Laboratories, Inc. Cambridge, Massachusetts, USA X-Sender: barrus@mailhost.merl.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 May 1994 08:55:54 -0400 To: fair@iss.nus.sg (Kim Michael Fairchild) From: barrus@merl.com (John W. Barrus) Subject: Re: real-time video in texture memory Cc: info-performer@sgi.sgi.com, stro@merl.com Status: O >Hi, > >Is it possible to get video into texture memory on a reality-engine? I >would like do something like you see in "the 7th guest" cd-rom game, >so I would like to be able to take a video source and "play" it into a >texture. > >possible? > >thanks, Kim. We were told that the Sirius video board from SGI (~$25,000) would allow video in texture. Unfortunately, the board we ordered more than 6 months ago still has not shipped because they are still ironing out hardware bugs. The latest date given for shipment is the end of May, but I'm not holding my breath. I don't believe there are any other options for SGI hardware. John B. ------------------------- John Barrus barrus@merl.com Mitsubishi Electric Research Laboratories 617.621.7535 (VOICE) 201 Broadway 617.621.7550 (FAX) Cambridge, MA 02139 From guest Wed Jun 1 15:37:48 1994 From: "Wade Olsen" Message-Id: <9406011536.ZM3519@fnord.asd.sgi.com> Date: Wed, 1 Jun 1994 15:36:37 -0700 In-Reply-To: fair@iss.nus.sg (Kim Michael Fairchild) "real-time video in texture memory" (May 25, 6:54pm) References: <9405251054.AA18362@bochap.iss.nus.sg> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: fair@iss.nus.sg (Kim Michael Fairchild), info-performer@sgi.sgi.com Subject: Re: real-time video in texture memory Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR On May 25, 6:54pm, Kim Michael Fairchild wrote: > Subject: real-time video in texture memory > Hi, > > Is it possible to get video into texture memory on a reality-engine? I > would like do something like you see in "the 7th guest" cd-rom game, > so I would like to be able to take a video source and "play" it into a > texture. > > possible? > > thanks, Kim. > > > >-- End of excerpt from Kim Michael Fairchild Yes. How depends on where the video comes from: If the video comes from an external source (e.g. a camera, vcr...) and you want brodcast quality video resolution, then the Sirius board is what you want. Video can be read from a source, change color spaces (like betacam -> rgb), and load directly into texture memory. If the video comes from memory, like little animation sequences, then no extra hardware need be purchased. There are two demos that show this effect. "tele" shows digital video effects applied to video from Sirius, memory and disk. "camcorder" shows a model of a camera with a working view finder. The view finder texture is updated everyframe and shows whatever the camera is pointing at. Pester your sales rep if you want to see this work. The relevant GL man pages are: texdef2d (use the FASTDEFINE token) and subtexload. For performer, see: pfTexFormat, pfGetGLHandle. Wade -- ------------------------------------------------------------------------------- Wade Olsen, wade@sgi.com, 415-390-1023, Silicon Graphics Computer Systems From guest Fri Jun 3 07:36:35 1994 From: "Michael Jones" Message-Id: <9406030736.ZM29887@babar.asd.sgi.com> Date: Fri, 3 Jun 1994 07:36:16 -0700 In-Reply-To: barrus@merl.com (John W. Barrus) "Re: real-time video in texture memory" (May 25, 8:55am) References: <9405251255.AA22816@merl.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: barrus@merl.com (John W. Barrus), fair@iss.nus.sg (Kim Michael Fairchild) Subject: Re: real-time video in texture memory Cc: info-performer@sgi.sgi.com, stro@merl.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR On May 25, 8:55am, John W. Barrus wrote: > Subject: Re: real-time video in texture memory :We were told that the Sirius video board from SGI (~$25,000) would allow :video in texture. Unfortunately, the board we ordered more than 6 months :ago still has not shipped because they are still ironing out hardware bugs. :The latest date given for shipment is the end of May, but I'm not holding :my breath. Since I can't hold my breath for more than four minutes, I'd have to agree with you. On the other hand, I do know that we've been swamped with orders for Sirius and that the factory is working (quite literally) around the clock to assemble and test over 150 of these boards for shipment this month. Such are the problems with popularity--it seems that everybody wants a Sirius video board, and wants it right now. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Fri Jun 3 11:47:55 1994 From: "Wade Olsen" Message-Id: <9406031137.ZM7526@fnord.asd.sgi.com> Date: Fri, 3 Jun 1994 11:37:22 -0700 In-Reply-To: fraser@BanffCentre.AB.CA (Glen Fraser) "Re: real-time video in texture memory" (Jun 3, 10:59am) References: <9406031659.AA11938@moose.BanffCentre.AB.CA> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: fraser@BanffCentre.AB.CA (Glen Fraser) Subject: Re: real-time video in texture memory Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 3, 10:59am, Glen Fraser wrote: > Subject: Re: real-time video in texture memory > > Yes. How depends on where the video comes from: > > > > If the video comes from an external source (e.g. a camera, vcr...) and you > < stuff deleted > > > > If the video comes from memory, like little animation sequences, then no > < stuff deleted > > > > What about if the video comes from disk? Is there some suitable way > of getting long pre-generated animations from disk into texture memory > in or near real-time? Is there an SGI animation format which would > facilitate this? > > Thanks, > Glen. Video from disk is dealt with the same way as video from memory, with the added task of reading the frames from disk to memory. There are a number of tools availble to deal with video. Check out the dmedia (digital media) development stuff. Unfortunatly, I don't know much about it. One thing to think about when choosing how to store the data on disk is it should be read into memory in the format expected by texdef2d or subtexload (i.e. scanlines are padded to 4 bytes, see "pixmode" also). The best way to do video from disk to graphics is to "sproc" another process to do disk I/O or to use the asynchronous I/O commands (see "man aio_init"). The disk process should be busy reading the next frame or frames while the graphics process is using a frame that has already been loaded. The processes could be synchronized using semaphores (see "man usnewsema"). Here is a c++ library I used to do fast disk I/O for video. It sets up a another process to read ahead: ----------------------------------file_io.h-------------------------------- class file_io { public: file_io(char * file_name, int mode); ~file_io(); virtual void read(void * buffer, int start_block, int num_blocks); virtual void write(void * buffer, int start_block, int num_blocks); protected: int file_handle; char * file_name; }; class raw_file_io : public file_io { public: raw_file_io(char * file_name, int mode, int first_block); virtual void read(void * buffer, int start_block, int num_blocks); virtual void write(void * buffer, int start_block, int num_blocks); private: int first_block; }; file_io * open_a_file(char * name, int start_block); file_io * create_a_file(char * name, int start_block); ----------------------------------file_io.c++------------------------------ #include #include #include #include #include #include #include #include #include #include "file_io.h" #define BLOCKSIZE 512 static char * raw_name = "/dev/rdsk/"; file_io * open_a_file(char * name, int start_block) { file_io * f; if (strncmp(raw_name, name, strlen(raw_name)) == 0) f = new raw_file_io(name, O_RDONLY, start_block); else f = new file_io(name, O_RDONLY); return f; } file_io * create_a_file(char * name, int start_block) { file_io * f; if (strncmp(raw_name, name, strlen(raw_name)) == 0) f = new raw_file_io(name, O_WRONLY|O_CREAT, start_block); else f = new file_io(name, O_WRONLY|O_CREAT); return f; } file_io::file_io(char * name, int mode) { file_name = name; file_handle = open(file_name, mode, 0644); if (file_handle < 0) { fprintf(stderr, "Can't open file %s: %s.\n", file_name, strerror(errno)); exit(1); } } file_io::~file_io() { close(file_handle); } raw_file_io::raw_file_io(char * name, int mode, int start) : file_io(name, mode) { first_block = start; } void file_io::read(void * buffer, int block, int blocks) { long err = lseek(file_handle, block * BLOCKSIZE, SEEK_SET); if (err == -1) { fprintf(stderr, "Can't seek to block %0d in %s: %s.\n", block, file_name, strerror(errno)); exit(1); } err = ::read(file_handle, buffer, blocks * BLOCKSIZE); if (err == -1) { fprintf(stderr, "Can't read from block %0d in %s: %s.\n", block, file_name, strerror(errno)); exit(1); } } void file_io::write(void * buffer, int block, int blocks) { long err = lseek(file_handle, block * BLOCKSIZE, SEEK_SET); if (err == -1) { fprintf(stderr, "Can't seek to block %0d in %s: %s.\n", block, file_name, strerror(errno)); exit(1); } err = ::write(file_handle, buffer, blocks * BLOCKSIZE); if (err == -1) { fprintf(stderr, "Can't write from block %0d in %s: %s.\n", block, file_name, strerror(errno)); exit(1); } } void raw_file_io::read(void * buffer, int block, int blocks) { long err = syssgi(SGI_READB, file_handle, buffer, block + first_block, blocks); if (err == -1) { fprintf(stderr, "Can't read to block %0d in %s: %s.\n", block, file_name, strerror(errno)); exit(1); } } void raw_file_io::write(void * buffer, int block, int blocks) { long err = syssgi(SGI_WRITEB, file_handle, buffer, block + first_block, blocks); if (err == -1) { fprintf(stderr, "Can't write to block %0d in %s: %s.\n", block, file_name, strerror(errno)); exit(1); } } ----------------------------------reader.h------------------------------- #include #include #include #include "file_io.h" class reader { public: reader(int numbuffers, int buffer_size, file_io * file, int transfers); unsigned long * read(); private: usema_t * produce_sema; usema_t * consume_sema; int produce_buffer; int consume_buffer; file_io * file_handle; int num_buffers; unsigned long ** buffers; void read_data(); pid_t reader_task; pid_t parent_task; int transfers; // image buffer parameters int blocks_per_transfer; }; -----------------------------------reader.c++------------------------------ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include "reader.h" reader::reader(int numbuffers, int buffer_size, file_io * file, int trans) { transfers = trans; usptr_t * arena = usinit("/usr/tmp/raw_arena"); produce_sema = usnewsema(arena, 0); consume_sema = usnewsema(arena, 0); produce_buffer = 0; consume_buffer = 0; file_handle = file; blocks_per_transfer = buffer_size; if (blocks_per_transfer == 0) { fprintf(stderr, "reader: transfer size is zero!\n"); exit(1); } num_buffers = numbuffers; int bytes_per_transfer = blocks_per_transfer * 512; fprintf(stderr, "Allocating %0d buffers of %0d bytes\n", num_buffers, bytes_per_transfer); buffers = (unsigned long **) malloc(sizeof(unsigned long *) * num_buffers); for (int i = 0; i < num_buffers; i++) { buffers[i] = (unsigned long *) malloc(sizeof(unsigned long) * bytes_per_transfer); if (mpin (buffers[i], bytes_per_transfer)) fprintf(stderr, "Can't pin %0d bytes for buffer %0d: %s\n", bytes_per_transfer, i, strerror(errno)); } usinitsema(produce_sema, num_buffers -1); parent_task = getpid(); reader_task = sproc((void (*)(void *))reader::read_data, PR_SALL, this); } unsigned long * reader::read() { if (ustestsema(produce_sema) == 0) fprintf(stderr, "Waiting for disk reader!\n"); uspsema(consume_sema); /* Wait until the next buffer is available. */ unsigned long * buffer = buffers[consume_buffer]; consume_buffer = (consume_buffer + 1) % num_buffers; usvsema(produce_sema); /* Wake the reader. */ return buffer; } void reader::read_data() { prctl(PR_TERMCHILD); while (1) for (int i = 0; i < transfers; i++) { uspsema(produce_sema); /* Wait for an empty buffer. */ int read_block = (i + 1) * blocks_per_transfer; file_handle->read(buffers[produce_buffer], read_block, blocks_per_transfer); usvsema(consume_sema); /* Wake the consumer, the frame is ready. */ produce_buffer = (produce_buffer +1) % num_buffers; } } --------------------------------------------------------------------------- Wade -- ------------------------------------------------------------------------------- Wade Olsen, wade@sgi.com, 415-390-1023, Silicon Graphics Computer Systems