[Intel-gfx] [Mesa-dev] [Mesa3d-dev] mesa doesn't work with compiz (i965 + tips of all branches)

[Kristian Høgsberg]

2010/7/5 Maxim Levitsky <maximlevitsky at gmail.com>:
> On Mon, 2010-07-05 at 13:08 +0300, Maxim Levitsky wrote:
>> 2010/7/5 Michel Dänzer <michel at daenzer.net>:
>> > 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 mesa-dev at lists.freedesktop.org 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" <maximlevitsky at gmail.com
>> >> >>>>> <mailto:maximlevitsky at gmail.com>> 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 <ian.d.romanick at intel.com
>> >> >>>>> <mailto:ian.d.romanick at intel.com>>
>> >> >>>>> 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.

This hasn't been the case in a long time.  The DRI driver is ABI
stable and always backwards compatible.

Kristian