On Mon, 2010-07-05 at 13:08 +0300, Maxim Levitsky wrote:
> 2010/7/5 Michel Dänzer <[email protected]>:
> > On Don, 2010-07-01 at 10:32 -0700, Ian Romanick wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Note: I'm sending this reply to [email protected] instead
> >> of the old mailing list.
> >>
> >> Maxim Levitsky wrote:
> >> > On Tue, 2010-06-29 at 15:49 -0700, Ian Romanick wrote:
> >> > Corbin Simpson wrote:
> >> >>>> Curious. Admittedly I can't look at the content of that commit, but
> >> >>>> they
> >> >>>> can't be too useless if compiz selects them. IIRC the point was to
> >> >>>> limit
> >> >>>> the runtime of Intel internal tests; can't those tests be amended
> >> >>>> instead? The number of configs will only grow; r300g has over 200 now
> >> >>>> thanks to multisampling.
> >> > The configs are useless. Applications can only ask for "bits >= X".
> >> > There are still 24-bit depth / 8-bit stencil configs, and, last time I
> >> > checked, 8 >= 0. There is no way to ask for a 24/0 config that wouldn't
> >> > instead give a 24/8 config.
> >> >
> >> >>>> Posting from a mobile, pardon my terseness. ~ C.
> >> >>>>
> >> >>>>> On Jun 29, 2010 1:28 PM, "Maxim Levitsky" <[email protected]
> >> >>>>> <mailto:[email protected]>> wrote:
> >> >>>>>
> >> >>>>> On Tue, 2010-06-29 at 20:34 +0300, Maxim Levitsky wrote:
> >> >>>>>> On Sun, 2010-06-27 at 19:07 +0300, Maxim ...
> >> >>>>> Bisected this to
> >> >>>>>
> >> >>>>> 73e24cd5a7a0760726a681dda5b88805ddcf1555 is first bad commit
> >> >>>>> commit 73e24cd5a7a0760726a681dda5b88805ddcf1555
> >> >>>>> Author: Ian Romanick <[email protected]
> >> >>>>> <mailto:[email protected]>>
> >> >>>>> Date: Mon Feb 8 10:34:52 2010 -0800
> >> >>>>>
> >> >>>>> intel: Stop exposing useless 24 depth/0 stencil configs
> >> > I need two pieces of information:
> >> >
> >> > - A diff of the output of glxinfo immediately before and immediately
> >> > after this commit.
> >> >
> >> > - A list of what config attributes compiz is requesting. It should
> >> > be easy enough to instrument choose_visual in glxcmds.c to dump out
> >> > attribList.
> >> >
> >> > It should be pretty easy to root-cause this problem with that data.
> >>
> >> [snip]
> >>
> >> > What is interesting is this:
> >> >
> >> > -0x62 32 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None
> >>
> >> Yup. That has to be it. The fix will have two parts. First, make the
> >> 3D driver a this specific visual.
> >
> > -ENOPARSE :)
> >
> >> That will make "new" 3D drivers work with "old" 2D drivers. Second,
> >> make the 2D driver mark this visual has having stencil.
> >
> > The X driver is no longer involved in GLX visuals. (However, the Mesa
> > driver loaded by the X server is involved. Maxim, did the X server load
> > your self-built i965_dri.so for each test?)
> No. I just compile the mesa (and of course includes i965_dri.so) with
> or without commit
> change is instant.
>
> However. both good and bad behavior is persistent over X restarts,
> when it does load new i965_dri.so
>
>
> Wait a minute....
>
> (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so
> (II) GLX: Initialized DRISWRAST GL provider for screen 0
>
>
> I disabled AIGLX in x server long time ago, because it makes me
> recompile the server each time mesa changes, and otherwise is useless.
>
> So I try with AIGLX next.
So thats was it, yep, server without --disable-aiglx works just fine
with unpached mesa...
This still should be fixed, because --disable-aiglx helps debbuging a
lot by decoupling xserver and mesa.
Best regards,
Maxim Levitsky
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
