2010/7/5 Maxim Levitsky <maximlevit...@gmail.com>: > On Mon, 2010-07-05 at 13:08 +0300, Maxim Levitsky wrote: >> 2010/7/5 Michel Dänzer <mic...@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-...@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" <maximlevit...@gmail.com >> >> >>>>> <mailto:maximlevit...@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.roman...@intel.com >> >> >>>>> <mailto:ian.d.roman...@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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
