.
The other is trying to get the scheduler to run the process
promptly at a certain ray positions.
I think there is an easy solution for the first thing. Why don't you
share a flag variable between the kernel and the process, that becomes 1 at
the vertical retrace and 0 when
On 1999/Oct/22, Niklas Höglund wrote:
I think there is an easy solution for the first thing. Why don't you
share a flag variable between the kernel and the process, that becomes 1 at
the vertical retrace and 0 when it finishes? It would be for programmers
even more efficient than
On Fri, 22 Oct 1999, Brian S. Julin wrote:
On Fri, 22 Oct 1999, [iso-8859-1] Rubén wrote:
On 1999/Oct/22, Niklas Höglund wrote:
It'd be even better to increase a value every vblank so applications
can find out if it has missed any frames, and also to make sure
applications don't
there is an easy solution for the first thing. Why don't you
share a flag variable between the kernel and the process, that becomes 1 at
the vertical retrace and 0 when it finishes? It would be for programmers
even more efficient than reading from the IO port directly (which is
impossible under Linux
is trying to get the scheduler to run the process
promptly at a certain ray positions.
I think there is an easy solution for the first thing. Why don't you
share a flag variable between the kernel and the process, that becomes 1 at
the vertical retrace and 0 when it finishes? It would
For the latter, there is no elegant solution under standard Linux.
The closest interval a periodic task can be run at to check the
ray position without hacking the kernel (on i386) is 100 times a
second. This can hardly give an accurate reading/signal. So we are
stuck with either losing
On Wed, 6 Oct 1999, Andreas Beck wrote:
struct kgi_3dtriangle {int x0,y0,z0,x1,y1,z1,x2,y2,z2};
What about the exta fields (W, specular/diffuse color, texture
coords, vertex fog)?
Extra commands (i.e. DRAW3DTRIANGLE_TEXTURED, *_GORAUD). We'd need to take
up too much
On 1999/Oct/06, Andreas Beck wrote:
screen blinking a lot, I think. Anyway, there is another bigger problem,
IMO, that switching to kernel mode, copying data structures, and returning
back into user mode, may be too much time, and maybe when the ioctl returns,
you haven't enough time to
On Tue, 5 Oct 1999, Andreas Beck wrote:
struct kgi_3dtriangle {int x0,y0,z0,x1,y1,z1,x2,y2,z2};
Comments please !
I don't like this kind of 3dtriangle at all, it needs 9 copies of
data to draw a triangle, maybe it's insignificant when you must call later
ioctl, which surely
struct kgi_3dtriangle {int x0,y0,z0,x1,y1,z1,x2,y2,z2};
What about the exta fields (W, specular/diffuse color, texture
coords, vertex fog)?
Extra commands (i.e. DRAW3DTRIANGLE_TEXTURED, *_GORAUD). We'd need to take
up too much bandwidth on PingPong or similar, if we always
On Mon, 4 Oct 1999, Jos Hulzink wrote:
On Fri, 1 Oct 1999, [iso-8859-1] Rubén wrote:
Ah, ok, well, it does what I want, its enough for me. Anyway, I will
continue reading docs and learning how to include vertical retrace support
into KGIcon, it's best (I have readed the GGI tech
On Mon, 4 Oct 1999, [iso-8859-1] Rubén wrote:
On 1999/Oct/04, Jos Hulzink wrote:
into KGIcon, it's best (I have readed the GGI tech. docs, and it seems to be
a bit difficult).
The ViRGE has completely functional vertical retrace interrupt code, but
at the moment, nothing is done
12 matches
Mail list logo
