--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Mon, 2004-05-24 at 01:04, Mike Mestnik wrote:
> > --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > > The 3D driver already handles several cliprects for when a window is
> > > partially obscured, SHAPE windows, ... That would just need to be
> > > e
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Assembly dispatch stubs are only generated for x86 and SPARC. It looks
> like the #if test in dispatch.c is wrong, so that stubs don't even get
> used on SPARC. In any case, Jakub's patch did modify the x86 assembly,
> not the C version. I wasn't
On Mon, 2004-05-24 at 01:04, Mike Mestnik wrote:
> --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > The 3D driver already handles several cliprects for when a window is
> > partially obscured, SHAPE windows, ... That would just need to be
> > extended to multiplex the cliprects on boundaries of mult
Keith Whitwell wrote:
Ian Romanick wrote:
One thing about Jakub's patch is that, on x86, it eliminates the need
for the specialized _ts_* versions of the dispatch functions. It
basically converts the DISPATCH macro (as used in
src/mesa/main/dispatch.c) from:
#define DISPATCH(FUNC, ARGS, MESSAG
--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> > On Gwe, 2004-05-21 at 17:48, Jon Smirl wrote:
> >
> >>There are two types of VTs - text and graphical. It is only practical
> to have a
> >>single graphical VT because of the complexity of state swapping a
> graphical VT
> >>at V
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Sun, 2004-05-23 at 11:32, Mike Mestnik wrote:
> > I think I finaly get it. When we have a window grater then 2048, we
> need
> > to run a GL command move the cliprect and run it again? The only way
> to
> > find out where we need is to SW render
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> >
> > --- Alex Deucher <[EMAIL PROTECTED]> wrote:
> > >
> > > --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > > > Thank you for your informative reply.
> > > >
> > > > --- Alex Deucher <[EMAIL PROTECT
Alan Cox wrote:
On Gwe, 2004-05-21 at 17:48, Jon Smirl wrote:
There are two types of VTs - text and graphical. It is only practical to have a
single graphical VT because of the complexity of state swapping a graphical VT
at VT swap.
Could have fooled me. I can switch between multiple DRI using X s
On Gwe, 2004-05-21 at 17:48, Jon Smirl wrote:
> There are two types of VTs - text and graphical. It is only practical to have a
> single graphical VT because of the complexity of state swapping a graphical VT
> at VT swap.
Could have fooled me. I can switch between multiple DRI using X servers
and
Am Mittwoch, 12. Mai 2004 23:09 schrieb Dieter Nützel:
> SunWave1 progs/demos# ./gears
> Mesa: software DXTn compression/decompression available
> Speicherschutzverletzung (core dumped)
More on this with latest CVS:
(gdb) r
Starting program: /opt/Mesa/progs/demos/gears
[New Thread 1079078016 (LWP
Keith Whitwell wrote:
Andrà Ventura Lemos wrote:
Not at all...
This only happens with 2.6 kernels. Prior do the lockup, everything
works (I can see it through ssh), but the display gets blank, and never
comes back.
On Fri, 2004-05-21 at 18:07, Keith Whitwell wrote:
Do you mind if I take this to dri
--- Mike Mestnik <[EMAIL PROTECTED]> wrote:
>
> --- Alex Deucher <[EMAIL PROTECTED]> wrote:
> >
> > --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > > Thank you for your informative reply.
> > >
> > > --- Alex Deucher <[EMAIL PROTECTED]> wrote:
> > > >
> > > > --- Mike Mestnik <[EMAIL PROTECTED
On Sun, 2004-05-23 at 12:05, Nicolai Haehnle wrote:
>
> > This sounds like an idea for you to play with, but I'm afraid it won't
> > be useful very often in my experience:
> >
> > * getting rid of the offending client doesn't help with a wedged
> > chip (some way to recover from tha
On Sun, 2004-05-23 at 11:32, Mike Mestnik wrote:
> I think I finaly get it. When we have a window grater then 2048, we need
> to run a GL command move the cliprect and run it again? The only way to
> find out where we need is to SW render the cmd. Won't this cut our
> framerate in half? Plus mo
The attached patch provides s3tc (and broken fxt) texture compression
support on the i8xx (x>30) chipsets,
You need to apply the radeon/r200 patch from Roland first, Roland do you
want to merge this patch into yours?
So far I've tested this with texcmp - thats how I know FXT doesn't work,
do we
Ian Romanick wrote:
One thing about Jakub's patch is that, on x86, it eliminates the need
for the specialized _ts_* versions of the dispatch functions. It
basically converts the DISPATCH macro (as used in
src/mesa/main/dispatch.c) from:
#define DISPATCH(FUNC, ARGS, MESSAGE) \
(_glapi_Dispa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 22 May 2004 16:04, Michel DÃnzer wrote:
> On Sat, 2004-05-22 at 14:04, Nicolai Haehnle wrote:
> > It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking
> > whether the caller actually holds the global lock. There is no
>
I think I finaly get it. When we have a window grater then 2048, we need
to run a GL command move the cliprect and run it again? The only way to
find out where we need is to SW render the cmd. Won't this cut our
framerate in half? Plus moving the cliprect for most of the drawing cmds,
what abou
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > Thank you for your informative reply.
> >
> > --- Alex Deucher <[EMAIL PROTECTED]> wrote:
> > >
> > > --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > > >
> > > > The problem I have is that my settup
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
> Mike Mestnik wrote:
>
> >Thank you for your informative reply.
> >
> >--- Alex Deucher <[EMAIL PROTECTED]> wrote:
> >
> >
> >>--- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>I'm currently unable to define a clone mode where one scre
--- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> Thank you for your informative reply.
>
> --- Alex Deucher <[EMAIL PROTECTED]> wrote:
> >
> > --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > > I'm currently unable to define a clone mode where one screen is
> > > smaller
> > > then the other. My th
Mike Mestnik wrote:
Thank you for your informative reply.
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
--- Mike Mestnik <[EMAIL PROTECTED]> wrote:
I'm currently unable to define a clone mode where one screen is
smaller
then the other. My thoughts are "1024x768_1024x768" == "1024x768" vs
"10
Thank you for your informative reply.
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > I'm currently unable to define a clone mode where one screen is
> > smaller
> > then the other. My thoughts are "1024x768_1024x768" == "1024x768" vs
> > "1024x768
23 matches
Mail list logo