From: Maxim Levitsky <maximlevitsky@gmail.com>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: "mesa-dev@lists.freedesktop.org" <mesa-dev@lists.freedesktop.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Subject: Re: [Mesa-dev] [Mesa3d-dev] mesa doesn't work with compiz (i965 + tips of all branches)
Date: Mon, 05 Jul 2010 18:22:07 +0300 [thread overview]
Message-ID: <1278343327.30711.2.camel@localhost.localdomain> (raw)
In-Reply-To: <AANLkTikF6ZkpyHdQzWczegShO3knT24JTtPzblWGaE9H@mail.gmail.com>
On Mon, 2010-07-05 at 13:08 +0300, Maxim Levitsky wrote:
> 2010/7/5 Michel Dänzer <michel@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@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@gmail.com
> >> >>>>> <mailto:maximlevitsky@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@intel.com
> >> >>>>> <mailto:ian.d.romanick@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.
Best regards,
Maxim Levitsky
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2010-07-05 15:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-27 16:07 mesa doesn't work with compiz (i965 + tips of all branches) Maxim Levitsky
2010-06-29 17:34 ` Maxim Levitsky
2010-06-29 20:27 ` [Mesa3d-dev] " Maxim Levitsky
2010-06-29 20:47 ` Corbin Simpson
2010-06-29 22:49 ` Ian Romanick
2010-06-30 23:13 ` Maxim Levitsky
2010-07-01 17:32 ` Ian Romanick
2010-07-03 23:32 ` Maxim Levitsky
2010-07-05 9:07 ` Michel Dänzer
2010-07-05 10:08 ` Maxim Levitsky
2010-07-05 15:22 ` Maxim Levitsky [this message]
2010-07-05 15:57 ` [Intel-gfx] " Kristian Høgsberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1278343327.30711.2.camel@localhost.localdomain \
--to=maximlevitsky@gmail.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mesa-dev@lists.freedesktop.org \
--cc=michel@daenzer.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.