After reading the GL 1.2.1 spec which supposedly contains a verbatim
copy of the ARB_multitexture spec, It seems to me as if Mesa's
implementation of InterleavedArrays is incorrect.
Currently, specifying an interleaved array with a texcoord part assigns
the texcoords to TMU 0 and disables GL_TEX
Hi,
I've just tried getting a solo Mesa working on 2.4.25, latest DRM
from DRI CVS and top of tree Mesa on r100,
my framebuffer console comes up, but when I start the server the screen is
corrupted, when I run the test app I can see the garbage on screen change
so it looks close to worki
[responding from my personal account to avoid the subscriber-only filter]
On Tue, Mar 09, 2004 at 10:40:28PM +, Keith Whitwell wrote:
> Andy Isaacson wrote:
> > [perhaps DRI / fd.o should consider BitKeeper]
>
> For DRI at least, it's been discussed & rejected.
My apologies for bringing up a
On Tue, 2004-03-09 at 20:57, Felix KÃhling wrote:
> On Tue, 09 Mar 2004 16:25:43 +0100
> Michel DÃnzer <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2004-03-09 at 12:29, Felix KÃhling wrote:
> > >
> > > We discussed this before and it was concluded that there needs to be
> > > some sort of high priori
On Tue, 2004-03-09 at 22:39, Felix KÃhling wrote:
>
> Sorry for spamming ... I just had another idea. Can't we use MMIO for
> buffer swapping?
No. MMIO register writes to FIFO'd registers while the CP is busy are a
sure recipe for a chip lockup, because sooner or later the FIFO will
overflow. So
On Tue, 2004-03-09 at 19:44, Ian Romanick wrote:
>
> Excluding the pageflip case, in the "current" setup we have an
> offscreen backbuffer that needs to be copied to the frontbuffer. This
> happens completely under the control of the 3D driver. With composite,
> are both the backbuffer and th
On Tue, 2004-03-09 at 23:40, Keith Whitwell wrote:
> Andy Isaacson wrote:
> >
> > I feel a little bit like a shill here, but I figure I should throw out
> > my two cents. First, a disclaimer: I work for BitMover but I do not set
> > company policy; if you need to get The Official Word on things
On Mon, Mar 08, 2004 at 12:29:05PM -0800, Keith Packard wrote:
> Stablizing the tree and getting something shipping that people can
> distribute is the first priority. I'm sure lots of people would like to
> see Mesa/DRI development more closely tied to X driver development so that
> there wasn
Andy Isaacson wrote:
On Mon, Mar 08, 2004 at 12:29:05PM -0800, Keith Packard wrote:
Stablizing the tree and getting something shipping that people can
distribute is the first priority. I'm sure lots of people would like to
see Mesa/DRI development more closely tied to X driver development so th
On Tue, 09 Mar 2004 16:25:43 +0100
Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Tue, 2004-03-09 at 12:29, Felix Kühling wrote:
[snip]
>
> > We discussed this before and it was concluded that there needs to be
> > some sort of high priority command queue. IIRC certain hardware (was it
> > i8xx?)
Felix Kühling wrote:
On Mon, 08 Mar 2004 20:28:55 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
[snip]
per-window backbuffers and a bunch of other stuff. Actually, given
enough memory, each time a swap happened the driver could just allocate
a new backbuffer to render to. When the swap happened
Felix Kühling wrote:
On Tue, 09 Mar 2004 16:25:43 +0100
Michel Dänzer <[EMAIL PROTECTED]> wrote:
On Tue, 2004-03-09 at 12:29, Felix Kühling wrote:
I've been thinking about this before and I got stuck at a more practical
problem. Maybe my thoughts are a bit Radeon-centric though. The problem
is tha
On Tue, 09 Mar 2004 16:25:43 +0100
Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Tue, 2004-03-09 at 12:29, Felix Kühling wrote:
> >
> > I've been thinking about this before and I got stuck at a more practical
> > problem. Maybe my thoughts are a bit Radeon-centric though. The problem
> > is that
On Mon, 08 Mar 2004 20:28:55 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
[snip]
> per-window backbuffers and a bunch of other stuff. Actually, given
> enough memory, each time a swap happened the driver could just allocate
> a new backbuffer to render to. When the swap happened the old
> backb
Keith Packard wrote:
Around 18 o'clock on Mar 9, Michel Daenzer wrote:
BTW, the composite extension will require buffer swaps to be handled by
the X server (as well as per-context buffers, ...), so we might as well
start planning how to get there. :)
Ah, Composite isn't as X-centric as it might fi
Around 19 o'clock on Mar 9, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote:
> My point is that the kernel can't do it on its own, as only the
> composite manager knows what the final result should look like.
True enough. Of course, the compositing manager will likely double buffer
the whole screen so
On Tue, 2004-03-09 at 19:18, Keith Packard wrote:
> Around 18 o'clock on Mar 9, Michel Daenzer wrote:
>
> > BTW, the composite extension will require buffer swaps to be handled by
> > the X server (as well as per-context buffers, ...), so we might as well
> > start planning how to get there. :)
>
Around 18 o'clock on Mar 9, Michel Daenzer wrote:
> BTW, the composite extension will require buffer swaps to be handled by
> the X server (as well as per-context buffers, ...), so we might as well
> start planning how to get there. :)
Ah, Composite isn't as X-centric as it might first appear...
On Tue, 2004-03-09 at 17:50, Ian Romanick wrote:
> Michel DÃnzer wrote:
> > On Tue, 2004-03-09 at 05:28, Ian Romanick wrote:
> >
> >>- Keep the queue of pending swaps in the user-space driver. Spawn a
> >>second thread that *only* performs swaps. It blocks on a futuex or
> >>similar the gets upe
On Tue, 2004-03-09 at 17:42, Ian Romanick wrote:
> Mike Mestnik wrote:
>
> > This seams like a no brainer to me. The Xserver! It would be a good
> > place to intercept vblanks, if it dosen't allready, and connects to
> > clients and card any way. A little more beef for the "?2d driver? or X
> >
Felix Kühling wrote:
I'd prefer the kernel implementation. If you do the swapping in
user-space you require a context switch to each client that needs to
swap. However, you need to react to the vblank interrupt as fast as
possible in order to finish the swap during the vertical retrace.
I hadn't t
Michel DÃnzer wrote:
On Tue, 2004-03-09 at 05:28, Ian Romanick wrote:
- Keep the queue of pending swaps in the user-space driver. Add an
ioctl for the kernel to deliver a signal to the app / driver when a
specified vblank has occured.
FWIW, that wouldn't need to be added, it's been in place for a
Mike Mestnik wrote:
This seams like a no brainer to me. The Xserver! It would be a good
place to intercept vblanks, if it dosen't allready, and connects to
clients and card any way. A little more beef for the "?2d driver? or X
server" to keep track of pending swaps for all dri clients, but if i
This got fixed in 2.4, but somehow got missed in 2.6.
http://icat.nist.gov/icat.cfm?cvename=CAN-2004-0003 has more info.
Dave
--- linux-2.6.3/drivers/char/drm/r128_state.c~ 2004-03-09 16:12:59.0 +
+++ linux-2.6.3/drivers/char/drm/r128_state.c 2004-03-09 16:13:42.000
--- Mario Premke <[EMAIL PROTECTED]> wrote:
>
> > > - starting xawtv it says 'no overlay function' (and something
> like:
> > > trouble with v4l-conf) and the content of the xawtv frame is
> > > scrumbled - I haven't had this behaviour before and didn't touch
> the
> > > XF86Config --- any hints
> > - starting xawtv it says 'no overlay function' (and something like:
> > trouble with v4l-conf) and the content of the xawtv frame is
> > scrumbled - I haven't had this behaviour before and didn't touch the
> > XF86Config --- any hints ???
> don't know. What chip do you have? I can't see that w
On Tue, 2004-03-09 at 12:29, Felix KÃhling wrote:
>
> I've been thinking about this before and I got stuck at a more practical
> problem. Maybe my thoughts are a bit Radeon-centric though. The problem
> is that you have rendering commands queued in the ring buffer. When the
> vblank IRQ occurs you
On Tue, 9 Mar 2004 13:59:20 +0100
[EMAIL PROTECTED] wrote:
> Hi,
> I tested the dri savage driver on a Toshiba laptop with
> S3 Inc. 86C270-294 Savage/IX-MV (rev 11) (prog-if 00 [VGA])
> but I had frequent lockups with glxgears and other software.
>
> It appears that:
> - lockups are rarer when
On Tue, 2004-03-09 at 05:28, Ian Romanick wrote:
>
> - Keep the queue of pending swaps in the user-space driver. Add an
> ioctl for the kernel to deliver a signal to the app / driver when a
> specified vblank has occured.
FWIW, that wouldn't need to be added, it's been in place for a while. :)
Dose most DACs have dublebuffering or do you realy only have from the
start of the vtrace to the end to do your update? If you can having from
the start of the vtrace untill the end of the next vtrace todo your
swaping is optimal.
- If you only have one FB. Pad each, or some, commands with enuff
I'd prefer the kernel implementation. If you do the swapping in
user-space you require a context switch to each client that needs to
swap. However, you need to react to the vblank interrupt as fast as
possible in order to finish the swap during the vertical retrace.
If that turns out to be too com
Hi,
Does anyone know if is there any (official or unofficial) pre-compiled 2.6 kernel
already with the necessary
configurations to have savage dri working?
I'm using Fedora Core 1 and I would like to have DRI working on my Prosavage266,
Thanks in advance,
Albert.
_
This seams like a no brainer to me. The Xserver! It would be a good
place to intercept vblanks, if it dosen't allready, and connects to
clients and card any way. A little more beef for the "?2d driver? or X
server" to keep track of pending swaps for all dri clients, but if it were
GLX it would b
33 matches
Mail list logo
