Menu
▾
▴
mesa3d-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(10) |
Apr
(28) |
May
(41) |
Jun
(91) |
Jul
(63) |
Aug
(45) |
Sep
(37) |
Oct
(80) |
Nov
(91) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(48) |
Feb
(121) |
Mar
(126) |
Apr
(16) |
May
(85) |
Jun
(84) |
Jul
(115) |
Aug
(71) |
Sep
(27) |
Oct
(33) |
Nov
(15) |
Dec
(71) |
| 2002 |
Jan
(73) |
Feb
(34) |
Mar
(39) |
Apr
(135) |
May
(59) |
Jun
(116) |
Jul
(93) |
Aug
(40) |
Sep
(50) |
Oct
(87) |
Nov
(90) |
Dec
(32) |
| 2003 |
Jan
(181) |
Feb
(101) |
Mar
(231) |
Apr
(240) |
May
(148) |
Jun
(228) |
Jul
(156) |
Aug
(49) |
Sep
(173) |
Oct
(169) |
Nov
(137) |
Dec
(163) |
| 2004 |
Jan
(243) |
Feb
(141) |
Mar
(183) |
Apr
(364) |
May
(369) |
Jun
(251) |
Jul
(194) |
Aug
(140) |
Sep
(154) |
Oct
(167) |
Nov
(86) |
Dec
(109) |
| 2005 |
Jan
(176) |
Feb
(140) |
Mar
(112) |
Apr
(158) |
May
(140) |
Jun
(201) |
Jul
(123) |
Aug
(196) |
Sep
(143) |
Oct
(165) |
Nov
(158) |
Dec
(79) |
| 2006 |
Jan
(90) |
Feb
(156) |
Mar
(125) |
Apr
(146) |
May
(169) |
Jun
(146) |
Jul
(150) |
Aug
(176) |
Sep
(156) |
Oct
(237) |
Nov
(179) |
Dec
(140) |
| 2007 |
Jan
(144) |
Feb
(116) |
Mar
(261) |
Apr
(279) |
May
(222) |
Jun
(103) |
Jul
(237) |
Aug
(191) |
Sep
(113) |
Oct
(129) |
Nov
(141) |
Dec
(165) |
| 2008 |
Jan
(152) |
Feb
(195) |
Mar
(242) |
Apr
(146) |
May
(151) |
Jun
(172) |
Jul
(123) |
Aug
(195) |
Sep
(195) |
Oct
(138) |
Nov
(183) |
Dec
(125) |
| 2009 |
Jan
(268) |
Feb
(281) |
Mar
(295) |
Apr
(293) |
May
(273) |
Jun
(265) |
Jul
(406) |
Aug
(679) |
Sep
(434) |
Oct
(357) |
Nov
(306) |
Dec
(478) |
| 2010 |
Jan
(856) |
Feb
(668) |
Mar
(927) |
Apr
(269) |
May
(12) |
Jun
(13) |
Jul
(6) |
Aug
(8) |
Sep
(23) |
Oct
(4) |
Nov
(8) |
Dec
(11) |
| 2011 |
Jan
(4) |
Feb
(2) |
Mar
(3) |
Apr
(9) |
May
(6) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(1) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Dave A. <ai...@gm...> - 2010-03-06 08:30:38
|
So in classic drivers we can hit swrast fallbacks for things like ReadPixels where we know we aren't going to have to want to touch textures at all. This would be useful for the r300 driver where Maciej is working on texture tiling will allow us to avoid the untiling overheads that mapping textures requires for most sw fallbacks. There may be other operations where we can do this also. For render to texture scenarios the driver should still map the textures via the FBOs anyways. Dave. |
|
From: Zack R. <za...@vm...> - 2010-03-06 01:38:58
|
On Wednesday 03 March 2010 10:51:13 ol...@lu... wrote:
> From: Chia-I Wu <ol...@lu...>
>
> When the paint is color, paint_bind_samplers binds a dummy sampler
> without a texture. It causes demos requiring a sampler (those use a
> mask or an image) to crash.
> ---
> src/gallium/state_trackers/vega/paint.c | 3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/state_trackers/vega/paint.c
> b/src/gallium/state_trackers/vega/paint.c index caf0c14..cdb87d3 100644
> --- a/src/gallium/state_trackers/vega/paint.c
> +++ b/src/gallium/state_trackers/vega/paint.c
> @@ -639,9 +639,6 @@ VGint paint_bind_samplers(struct vg_paint *paint,
> struct pipe_sampler_state **sa }
> break;
> default:
> - samplers[0] = &paint->pattern.sampler; /* dummy */
> - textures[0] = 0;
> - return 0;
> break;
> }
> return 0;
>
Yea, that's fine. The semantics for which of those need or don't have to be set
seem to change from release to release, so whatever works currently is ok. I
didn't have a working vg build since the egl rework ("Error: couldn't get an
EGL visual config" which I just didn't have time to even look at), so if it
works for you, feel free to commit.
z
|
|
From: Marek O. <ma...@gm...> - 2010-03-06 00:27:37
|
I can see this extension in ATI Catalyst 9.3. -Marek On Sat, Mar 6, 2010 at 1:16 AM, Ian Romanick <id...@fr...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jose Fonseca wrote: > > Module: Mesa > > Branch: master > > Commit: 744994a9c6b972a737e432cf1b699f232e2c5bfd > > URL: > http://cgit.freedesktop.org/mesa/mesa/commit/?id=744994a9c6b972a737e432cf1b699f232e2c5bfd > > > > Author: José Fonseca <jfo...@vm...> > > Date: Sat Feb 13 15:10:24 2010 +0000 > > > > mesa: Export GL_EXT_texture_cube_map. > > > > Still used by some applications. > > Holy smokes. Just out of curiosity, which applications? I didn't think > anyone ever actually shipped this extension. I guess Nvidia might have.. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkuRnucACgkQX1gOwKyEAw/IDwCcCTnVTTHB2QOLZbDEVZmniYq/ > mHkAmwaXt1ZzjGigifaqdyhkzf3/fxQ8 > =umX/ > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Mesa3d-dev mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > |
|
From: Ian R. <id...@fr...> - 2010-03-06 00:17:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jose Fonseca wrote: > Module: Mesa > Branch: master > Commit: 744994a9c6b972a737e432cf1b699f232e2c5bfd > URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=744994a9c6b972a737e432cf1b699f232e2c5bfd > > Author: José Fonseca <jfo...@vm...> > Date: Sat Feb 13 15:10:24 2010 +0000 > > mesa: Export GL_EXT_texture_cube_map. > > Still used by some applications. Holy smokes. Just out of curiosity, which applications? I didn't think anyone ever actually shipped this extension. I guess Nvidia might have.. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuRnucACgkQX1gOwKyEAw/IDwCcCTnVTTHB2QOLZbDEVZmniYq/ mHkAmwaXt1ZzjGigifaqdyhkzf3/fxQ8 =umX/ -----END PGP SIGNATURE----- |
|
From: Ian R. <id...@fr...> - 2010-03-06 00:10:20
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, I just created the Mesa 7.8 release branch. It is called "7.8" instead of "mesa_7_8_branch". Please return to the process of committing bug fixes to the release branch and merging to master. My current plan is to have release candidates for *both* 7.7.1 and 7.8 as follows: * RC1: 3/12 * RC2: 3/19 * final: 3/26 Thanks. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuRnT8ACgkQX1gOwKyEAw/llwCeO5BlavXSQLl+PVOKgmeuguOX 73QAoJa8DtAu1djWwTNbSPYrEnRJ4VmY =SC7o -----END PGP SIGNATURE----- |
|
From: <bug...@fr...> - 2010-03-06 00:03:10
|
http://bugs.freedesktop.org/show_bug.cgi?id=26904 --- Comment #1 from Brian Paul <bri...@gm...> 2010-03-05 16:03:01 PST --- The Xt GL drawing area widget is created with the function GLwCreateDrawingArea() and the Motif version is called GLwCreateMDrawingArea(). There's no "M2" version that I'm aware of. Perhaps you're using a customized version of the widget code? You could go into mesa/src/glw/ and hack up an M2 version for yourself. Maybe that'll work. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: Stephane M. <ste...@gm...> - 2010-03-05 23:49:12
|
2010/3/5 <ran...@gm...>: > В сообщении от Friday 05 March 2010 16:55:20 Jesse Barnes написал(а): >> make realclean and configure and make again. > > > Removing all new functions and reverting to mainstream mesa works OK, even > without realclean ... So, it is purely my fault, as coder. But what exactly I > forgot? Init current_primitive = -1 on context creation? State management in > nouveau changed since first dri1 attempt .... > > As far as i understand this code - you plug in not just fev line functions > but two big function tables, filled with many functions (pointers at > functions). This way one can plug in much more optimized (for different > OpenGL cases) render functions, if hw permits this. So, you plug inly > one "Chooser" function into mesa's TNL module, and keep current primitive > type somewhere in your context data ..... > > Ideally, various fixups (like polygonOffset) will be layred on top of this, > making nv04.render.c a bit hard for reading ... > > Thanks Jesse and Francisco for your time, you spended reading my mails and > trying to figure out what was my fault .... > As discussed on irc, and for posterity: 00:35 < marcheu> you have a 16 or 8 (with multitexture) vertex cache 00:35 < marcheu> these number you see (0xFEDCBA) are not magic 00:35 < marcheu> these are the index of the vertices we want to emit 00:36 < marcheu> so FEDCBA emits vertices 15,14,13,12,11 and 10 00:36 < marcheu> but that means you have to actually place data at these locations 00:37 < marcheu> which means that if you want to do a single-pass emission you have to place the first vertex at spot 10 00:37 < marcheu> so basically the layout of the nv4 3D object is like that: 00:37 < marcheu> - vertex 0 00:37 < marcheu> - vertex 1 00:37 < marcheu> ... 00:37 < marcheu> - vertex 15 00:38 < marcheu> - vertex indices that we want fired 00:38 < marcheu> so if you want to do a 1-swoop submission, you have to start from 10 or so 00:38 < marcheu> that also means you _place_ vertex data at the right spot. right now you place it at 0 00:39 < marcheu> also you reserve one too little places on the fifo (6 instead of 7 on line 206) 00:39 < marcheu> becuase you need one spot for the FEDCBA 00:39 < marcheu> so you need 3 things: 00:39 < marcheu> - start emitting at the right place, which probably means an extra argument to BEGIN_PRIMITIVE to tell which place 00:40 < marcheu> - increase the size of the BEGIN_PRIMITIVE 00:40 < marcheu> - that was only two things :) Stephane |
|
From: <ran...@gm...> - 2010-03-05 23:00:47
|
В сообщении от Friday 05 March 2010 16:55:20 Jesse Barnes написал(а):
> make realclean and configure and make again.
Removing all new functions and reverting to mainstream mesa works OK, even
without realclean ... So, it is purely my fault, as coder. But what exactly I
forgot? Init current_primitive = -1 on context creation? State management in
nouveau changed since first dri1 attempt ....
As far as i understand this code - you plug in not just fev line functions
but two big function tables, filled with many functions (pointers at
functions). This way one can plug in much more optimized (for different
OpenGL cases) render functions, if hw permits this. So, you plug inly
one "Chooser" function into mesa's TNL module, and keep current primitive
type somewhere in your context data .....
Ideally, various fixups (like polygonOffset) will be layred on top of this,
making nv04.render.c a bit hard for reading ...
Thanks Jesse and Francisco for your time, you spended reading my mails and
trying to figure out what was my fault ....
>
> On Fri, 5 Mar 2010 19:24:13 +0000
>
> ran...@gm... wrote:
> > It segfaults right after start ....
> >
> > #0 0x00000000 in ?? ()
> > No symbol table info available.
> > #1 0xb701b037 in _tnl_render_quad_strip_verts (ctx=0x88dba88, start=0,
> > count=42, flags=56) at tnl/t_vb_rendertmp.h:431
> > j = 3
> > tnl = <value optimized out>
> > QuadFunc = (const tnl_quad_func) 0
> > stipple = 0 '\0'
> > #2 0xb701c2cd in run_render (ctx=0x88dba88, stage=0x892edd8)
> > at tnl/t_vb_render.c:320
> > prim = <value optimized out>
> > start = 0
> > length = <value optimized out>
> > i = 0
> > tnl = (TNLcontext *) 0x892ebc8
> > tab = (tnl_render_func *) 0xb71821a0
> > pass = 0
> > __PRETTY_FUNCTION__ = "run_render"
> > #3 0xb7010467 in _tnl_run_pipeline (ctx=0x88dba88) at
> > tnl/t_pipeline.c:153 tnl = (TNLcontext *) 0x892ec88
> > __tmp = 895
> > i = 8
> > #4 0xb701133e in _tnl_draw_prims (ctx=0x88dba88, arrays=0x891ce94,
> > prim=0x891b968, nr_prims=2, ib=0x0, min_index=0, max_index=83)
> > at tnl/t_draw.c:478
> > this_nr_prims = <value optimized out>
> > bo = {0xb7180bb4, 0x88dba88, 0x30, 0xbf9e0928, 0xb6f73ddc,
> > 0x80000000, 0x1, 0x8c28218, 0xb6f700de, 0x8c1afd8, 0x0, 0x2, 0x40,
> > 0x88dba88, 0x88f2718, 0xbf9e0968, 0xb6f701f7, 0x88dba88, 0x400000,
> > 0xbf9e0968, 0xb6f7017e, 0x88dba88, 0x400000, 0xb769b50c, 0xb717fa80,
> > 0xb769b65c, 0x88d0544, 0x60121df, 0xb7180bb4, 0x88dba88, 0x0, 0xbf9e09c8,
> > 0xb6fdf83e} nr_bo = 0
> > max_basevertex = <value optimized out>
> > i = <value optimized out>
> > __PRETTY_FUNCTION__ = "_tnl_draw_prims"
> > #5 0xb70116a9 in _tnl_vbo_draw_prims (ctx=0x88dba88, arrays=0x891ce94,
> > prim=0x891b968, nr_prims=2, ib=0x0, index_bounds_valid=1 '\001',
> > min_index=0, max_index=83) at tnl/t_draw.c:384
> > No locals.
> > #6 0xb7007913 in vbo_exec_vtx_flush (exec=0x891b838, unmap=1 '\001')
> > at vbo/vbo_exec_draw.c:384
> > ctx = (GLcontext *) 0x88dba88
> > #7 0xb70050ee in vbo_exec_FlushVertices_internal (ctx=0x88dba88,
> > unmap=136 '\210') at vbo/vbo_exec_api.c:872
> > exec = (struct vbo_exec_context *) 0x891b838
> > #8 0xb700518b in vbo_exec_FlushVertices (ctx=0x88dba88, flags=1)
> > at vbo/vbo_exec_api.c:906
> > No locals.
> > #9 0xb6fd49bc in _mesa_PopMatrix () at main/matrix.c:285
> > stack = (struct gl_matrix_stack *) 0x88dbfb4
> > #10 0x08049d89 in DrawCrankshaft (eng=0x8073f60) at engine.c:511
> > phiStep = 120
> > phi = -90
> > i = 0
> > z = 0.400000006
> > #11 0x0804b4b7 in Draw () at engine.c:528
> > rot = {{0.457617939, -0.388804674, 0.799635649, 0},
> > {-0.00557587016, 0.898054183, 0.439849645, 0}, {-0.889131725,
> > -0.205741853, 0.408797771, 0}, {0, 0, 0, 1}}
> > #12 0xb771a537 in processWindowWorkList (window=0x88c9ba8) at
> > glut_event.c:1307
> > workMask = 4
> > __PRETTY_FUNCTION__ = "processWindowWorkList"
> > #13 0xb771b519 in glutMainLoop () at glut_event.c:1358
> > No locals.
> > #14 0x0804ae39 in main (argc=1, argv=0xbf9e0f54) at engine.c:1340
> > No locals.
|
|
From: <bug...@fr...> - 2010-03-05 21:59:54
|
http://bugs.freedesktop.org/show_bug.cgi?id=22561 Brian Paul <bri...@gm...> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Brian Paul <bri...@gm...> 2010-03-05 13:59:47 PST --- Committed. Thanks. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: Maxim L. <max...@gm...> - 2010-03-05 21:48:59
|
On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: > On Fri, 05 Mar 2010 23:18:07 +0200 > Maxim Levitsky <max...@gm...> wrote: > > > On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: > > > On Fri, 05 Mar 2010 22:42:21 +0200 > > > Maxim Levitsky <max...@gm...> wrote: > > > > > > > After quite long period of inactivity, I updated graphical stack on my > > > > desktop/server. > > > > > > > > To say the truth, I did such update about month ago, but found out that > > > > X refuses flatly to use DRI modules. I assumed that it was my mistake in > > > > compilation process (although it is automated). > > > > > > That generally indicates a build or config problem of some kind. Did > > > you ever narrow it down? > > Because the same compile process works now, I suspect that wasn't build > > failure. > > Well something weird is going on; maybe you didn't build X after Mesa > or with the right Mesa includes? I am very sure that this issue isn't relevant now. I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in that order, compiling everything from scratch (doing git clean -dfx in all directories) > > > I now compiled same stack, but reverted mesa to > > > > commit 465fee75ee8991349da742e5a1a5be3cd179bb62 > > Author: Roland Scheidegger <sr...@vm...> > > Date: Sat Nov 21 04:39:30 2009 -0800 > > > > intel: make CopyTex[Sub]Image fallback debug messages more > > consistent > > > > > > > > And compiled the xserver with --disable-aiglx > > (I will always use that option from now on, because I hate the way X and > > mesa are tied otherwise. For example X won't build if I compile it > > against old mesa, etc...) > > If you can't get AIGLX to work then it may indicate a bigger problem. > X needs to load a DRI driver to perform acceleration for indirect > clients, I'm not sure what in that is hate-worthy. > > > And now all 3D problems are gone. > > > > I now doing a bisect, although I am not sure if it will help much. > > Probably not. It sounds like your configuration is pretty custom and > something is seriously broken, so it'll be hard to help further. I don't think so. Older mesa works, new one works too but with bugs. New mesa just contains a lot of bugs. Best regards, Maxim Levitsky |
|
From: Jesse B. <jb...@vi...> - 2010-03-05 21:36:57
|
On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitsky <max...@gm...> wrote: > On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: > > On Fri, 05 Mar 2010 22:42:21 +0200 > > Maxim Levitsky <max...@gm...> wrote: > > > > > After quite long period of inactivity, I updated graphical stack on my > > > desktop/server. > > > > > > To say the truth, I did such update about month ago, but found out that > > > X refuses flatly to use DRI modules. I assumed that it was my mistake in > > > compilation process (although it is automated). > > > > That generally indicates a build or config problem of some kind. Did > > you ever narrow it down? > Because the same compile process works now, I suspect that wasn't build > failure. Well something weird is going on; maybe you didn't build X after Mesa or with the right Mesa includes? > I now compiled same stack, but reverted mesa to > > commit 465fee75ee8991349da742e5a1a5be3cd179bb62 > Author: Roland Scheidegger <sr...@vm...> > Date: Sat Nov 21 04:39:30 2009 -0800 > > intel: make CopyTex[Sub]Image fallback debug messages more > consistent > > > > And compiled the xserver with --disable-aiglx > (I will always use that option from now on, because I hate the way X and > mesa are tied otherwise. For example X won't build if I compile it > against old mesa, etc...) If you can't get AIGLX to work then it may indicate a bigger problem. X needs to load a DRI driver to perform acceleration for indirect clients, I'm not sure what in that is hate-worthy. > And now all 3D problems are gone. > > I now doing a bisect, although I am not sure if it will help much. Probably not. It sounds like your configuration is pretty custom and something is seriously broken, so it'll be hard to help further. -- Jesse Barnes, Intel Open Source Technology Center |
|
From: Maxim L. <max...@gm...> - 2010-03-05 21:18:17
|
On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote:
> On Fri, 05 Mar 2010 22:42:21 +0200
> Maxim Levitsky <max...@gm...> wrote:
>
> > After quite long period of inactivity, I updated graphical stack on my
> > desktop/server.
> >
> > To say the truth, I did such update about month ago, but found out that
> > X refuses flatly to use DRI modules. I assumed that it was my mistake in
> > compilation process (although it is automated).
>
> That generally indicates a build or config problem of some kind. Did
> you ever narrow it down?
Because the same compile process works now, I suspect that wasn't build
failure.
I now compiled same stack, but reverted mesa to
commit 465fee75ee8991349da742e5a1a5be3cd179bb62
Author: Roland Scheidegger <sr...@vm...>
Date: Sat Nov 21 04:39:30 2009 -0800
intel: make CopyTex[Sub]Image fallback debug messages more
consistent
And compiled the xserver with --disable-aiglx
(I will always use that option from now on, because I hate the way X and
mesa are tied otherwise. For example X won't build if I compile it
against old mesa, etc...)
And now all 3D problems are gone.
I now doing a bisect, although I am not sure if it will help much.
Best regards,
Maxim Levitsky
>
> > Now I repeat same process and find out that OpenGL does work, but once
> > again it became very buggy, so buggy that it is almost unusable.
> >
> >
> >
> > Neverball. - Now it hangs when I switch to full screen mode.
> > - Also, once again frames appear to be rendered
> > in batches
> > In fact full screen mode leads to a hang always
> >
> >
> > Sauerbraten. - Hangs early with 'Loading'
> > Nexuiz - Same as above
> >
> > Compiz. - Hangs now after start
> >
> > GoogleEarth - No change, works, but in street view, one on screen label
> > 'jumps'
> >
> > Xmoto, Torcs. Full screen mode hangs.
>
> I just pushed a few fixes to the xf86-video-intel code that might
> help...
>
|
|
From: Jesse B. <jb...@vi...> - 2010-03-05 20:56:00
|
On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky <max...@gm...> wrote: > After quite long period of inactivity, I updated graphical stack on my > desktop/server. > > To say the truth, I did such update about month ago, but found out that > X refuses flatly to use DRI modules. I assumed that it was my mistake in > compilation process (although it is automated). That generally indicates a build or config problem of some kind. Did you ever narrow it down? > Now I repeat same process and find out that OpenGL does work, but once > again it became very buggy, so buggy that it is almost unusable. > > > > Neverball. - Now it hangs when I switch to full screen mode. > - Also, once again frames appear to be rendered > in batches > In fact full screen mode leads to a hang always > > > Sauerbraten. - Hangs early with 'Loading' > Nexuiz - Same as above > > Compiz. - Hangs now after start > > GoogleEarth - No change, works, but in street view, one on screen label > 'jumps' > > Xmoto, Torcs. Full screen mode hangs. I just pushed a few fixes to the xf86-video-intel code that might help... -- Jesse Barnes, Intel Open Source Technology Center |
|
From: Maxim L. <max...@gm...> - 2010-03-05 20:42:33
|
After quite long period of inactivity, I updated graphical stack on my
desktop/server.
To say the truth, I did such update about month ago, but found out that
X refuses flatly to use DRI modules. I assumed that it was my mistake in
compilation process (although it is automated).
Now I repeat same process and find out that OpenGL does work, but once
again it became very buggy, so buggy that it is almost unusable.
Neverball. - Now it hangs when I switch to full screen mode.
- Also, once again frames appear to be rendered
in batches
In fact full screen mode leads to a hang always
Sauerbraten. - Hangs early with 'Loading'
Nexuiz - Same as above
Compiz. - Hangs now after start
GoogleEarth - No change, works, but in street view, one on screen label
'jumps'
Xmoto, Torcs. Full screen mode hangs.
Environment:
------------------------libdrm :-----------------------------
commit 1d4d1e6b138aac8bd734c4c20617a43fb3337c63
Author: Eric Anholt <er...@an...>
Date: Thu Mar 4 16:09:40 2010 -0800
intel: Only align Y-tiling pitch to the Y tile width.
Fixes piglit depth-tex-modes on gen4.
------------------------mesa :-----------------------------
commit 2b15f4fc6840b4bb5ca81d3ed0137c31f63725e8
Author: Michal Krol <mi...@vm...>
Date: Fri Mar 5 18:42:42 2010 +0100
progs: Add arbocclude2 demo.
------------------------xserver :-----------------------------
commit bbae92795c7eab062e6722c42fa7915e0cee5d69
Author: Matt Turner <mat...@gm...>
Date: Mon Feb 15 20:08:09 2010 -0500
Replace assembly with generic unaligned access code
Removes Alpha assembly, and probably works around unaligned accesses
on
other sensitive platforms.
------------------------xf86-video-intel :-----------------------------
commit 54ac4e2df987b72529a523ffbde357bec27e3658
Author: Chris Wilson <ch...@ch...>
Date: Thu Mar 4 21:34:52 2010 +0000
Rate limit batch buffer error.
Once we hit this error it's unlikely that we're coming back - so
don't
flood the logs with redundant information.
Signed-off-by: Chris Wilson <ch...@ch...>
kernel:
commit 9ddabb6700f82a033a76bcf7a547204fa12aaa17
Merge: bf0c346 3ce2f76
Author: Linus Torvalds <tor...@li...>
Date: Fri Jan 15 14:53:24 2010 -0800
Merge branch 'for-linus/samsung' of
git://git.fluff.org/bjdooks/linux
* 'for-linus/samsung' of git://git.fluff.org/bjdooks/linux:
ARM: MINI2440: Fixup __initdata usage
ARM: MINI2440: Fix crash on boot due to improper __initdata
qualifier
ARM: SMDK6410: Specify no GPIO for B_PWR_5V regulator
ARM: S3C: NAND: Check the existence of nr_map before copying
Best regards,
Maxim Levitsky
|
|
From: <bug...@fr...> - 2010-03-05 19:31:41
|
http://bugs.freedesktop.org/show_bug.cgi?id=22561 Jon TURNEY <jon...@dr...> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #29975|0 |1 is obsolete| | --- Comment #4 from Jon TURNEY <jon...@dr...> 2010-03-05 11:31:33 PST --- Created an attachment (id=33793) --> (http://bugs.freedesktop.org/attachment.cgi?id=33793) Patch to move initialization of ext_list_first_time to where it's storage is allocated Refreshed patch for git master -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: Ian R. <id...@fr...> - 2010-03-05 18:48:19
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chris Wilson wrote:
> Thanks to Intel QA providing a few piglit cases to test the API, this has
> had a cursory test and identified the silly cases of using the wrong
> lookup functions.
>
> The ugly part is that I've used 3 different driver functions to handle
> each of the 3 object variants - the alternative would be pass in a void
> pointer and a type id. If we acquire more distinct object types, then
> multiplexing a single driver function would be preferable to adding
> multiple stubs.
>
> Please review and include in 7.7! :)
^^^ 7.8, naturally.
Should also add something to the 7.8 release notes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuRUcMACgkQX1gOwKyEAw8byQCgip4+vxWlSHkeJXNTxwmLsH0n
6KQAoJMZjrZ3OVwLhp1TNhP//dHKWAAc
=+fTs
-----END PGP SIGNATURE-----
|
|
From: Ian R. <id...@fr...> - 2010-03-05 18:47:05
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Wilson wrote: > On Fri, 05 Mar 2010 07:48:06 -0700, Brian Paul <br...@vm...> wrote: >> Chris Wilson wrote: >>> Please review and include in 7.7! :) >> This will go into Mesa 7.8, actually. >> >> I see patches 1/4, 3/4 and 4/4 but not 2/4. Are the patches >> misnumbered or did 2/4 not get posted? > > As Michael pointed out, the changes to the autogenerated files were rather > large. > >> Can you commit these, Chris? > > Ok, pushed to master. Thanks. > >> Are the new piglit tests going into the fd.o repository? I don't see >> them yet. > > I shall ping Shuang He and ask for the tests to go upstream. That's my fault. I was supposed to commit those for him about a month ago. I'll take care of that today. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuRUXEACgkQX1gOwKyEAw+kpgCeNN7Iauq5Gf8xltcbrGjX1tTQ Dz8AnioB2EjcRFuGDTjViNgmQD8J2Y3Y =jxej -----END PGP SIGNATURE----- |
|
From: Jesse B. <jb...@vi...> - 2010-03-05 16:55:12
|
make realclean and configure and make again.
On Fri, 5 Mar 2010 19:24:13 +0000
ran...@gm... wrote:
> It segfaults right after start ....
>
> #0 0x00000000 in ?? ()
> No symbol table info available.
> #1 0xb701b037 in _tnl_render_quad_strip_verts (ctx=0x88dba88, start=0,
> count=42, flags=56) at tnl/t_vb_rendertmp.h:431
> j = 3
> tnl = <value optimized out>
> QuadFunc = (const tnl_quad_func) 0
> stipple = 0 '\0'
> #2 0xb701c2cd in run_render (ctx=0x88dba88, stage=0x892edd8)
> at tnl/t_vb_render.c:320
> prim = <value optimized out>
> start = 0
> length = <value optimized out>
> i = 0
> tnl = (TNLcontext *) 0x892ebc8
> tab = (tnl_render_func *) 0xb71821a0
> pass = 0
> __PRETTY_FUNCTION__ = "run_render"
> #3 0xb7010467 in _tnl_run_pipeline (ctx=0x88dba88) at tnl/t_pipeline.c:153
> tnl = (TNLcontext *) 0x892ec88
> __tmp = 895
> i = 8
> #4 0xb701133e in _tnl_draw_prims (ctx=0x88dba88, arrays=0x891ce94,
> prim=0x891b968, nr_prims=2, ib=0x0, min_index=0, max_index=83)
> at tnl/t_draw.c:478
> this_nr_prims = <value optimized out>
> bo = {0xb7180bb4, 0x88dba88, 0x30, 0xbf9e0928, 0xb6f73ddc, 0x80000000,
> 0x1, 0x8c28218, 0xb6f700de, 0x8c1afd8, 0x0, 0x2, 0x40, 0x88dba88, 0x88f2718,
> 0xbf9e0968, 0xb6f701f7, 0x88dba88, 0x400000, 0xbf9e0968, 0xb6f7017e,
> 0x88dba88, 0x400000, 0xb769b50c, 0xb717fa80, 0xb769b65c, 0x88d0544,
> 0x60121df, 0xb7180bb4, 0x88dba88, 0x0, 0xbf9e09c8, 0xb6fdf83e}
> nr_bo = 0
> max_basevertex = <value optimized out>
> i = <value optimized out>
> __PRETTY_FUNCTION__ = "_tnl_draw_prims"
> #5 0xb70116a9 in _tnl_vbo_draw_prims (ctx=0x88dba88, arrays=0x891ce94,
> prim=0x891b968, nr_prims=2, ib=0x0, index_bounds_valid=1 '\001',
> min_index=0, max_index=83) at tnl/t_draw.c:384
> No locals.
> #6 0xb7007913 in vbo_exec_vtx_flush (exec=0x891b838, unmap=1 '\001')
> at vbo/vbo_exec_draw.c:384
> ctx = (GLcontext *) 0x88dba88
> #7 0xb70050ee in vbo_exec_FlushVertices_internal (ctx=0x88dba88,
> unmap=136 '\210') at vbo/vbo_exec_api.c:872
> exec = (struct vbo_exec_context *) 0x891b838
> #8 0xb700518b in vbo_exec_FlushVertices (ctx=0x88dba88, flags=1)
> at vbo/vbo_exec_api.c:906
> No locals.
> #9 0xb6fd49bc in _mesa_PopMatrix () at main/matrix.c:285
> stack = (struct gl_matrix_stack *) 0x88dbfb4
> #10 0x08049d89 in DrawCrankshaft (eng=0x8073f60) at engine.c:511
> phiStep = 120
> phi = -90
> i = 0
> z = 0.400000006
> #11 0x0804b4b7 in Draw () at engine.c:528
> rot = {{0.457617939, -0.388804674, 0.799635649, 0}, {-0.00557587016,
> 0.898054183, 0.439849645, 0}, {-0.889131725, -0.205741853, 0.408797771,
> 0}, {0, 0, 0, 1}}
> #12 0xb771a537 in processWindowWorkList (window=0x88c9ba8) at
> glut_event.c:1307
> workMask = 4
> __PRETTY_FUNCTION__ = "processWindowWorkList"
> #13 0xb771b519 in glutMainLoop () at glut_event.c:1358
> No locals.
> #14 0x0804ae39 in main (argc=1, argv=0xbf9e0f54) at engine.c:1340
> No locals.
--
Jesse Barnes, Intel Open Source Technology Center
|
|
From: <ran...@gm...> - 2010-03-05 16:25:32
|
It segfaults right after start ....
#0 0x00000000 in ?? ()
No symbol table info available.
#1 0xb701b037 in _tnl_render_quad_strip_verts (ctx=0x88dba88, start=0,
count=42, flags=56) at tnl/t_vb_rendertmp.h:431
j = 3
tnl = <value optimized out>
QuadFunc = (const tnl_quad_func) 0
stipple = 0 '\0'
#2 0xb701c2cd in run_render (ctx=0x88dba88, stage=0x892edd8)
at tnl/t_vb_render.c:320
prim = <value optimized out>
start = 0
length = <value optimized out>
i = 0
tnl = (TNLcontext *) 0x892ebc8
tab = (tnl_render_func *) 0xb71821a0
pass = 0
__PRETTY_FUNCTION__ = "run_render"
#3 0xb7010467 in _tnl_run_pipeline (ctx=0x88dba88) at tnl/t_pipeline.c:153
tnl = (TNLcontext *) 0x892ec88
__tmp = 895
i = 8
#4 0xb701133e in _tnl_draw_prims (ctx=0x88dba88, arrays=0x891ce94,
prim=0x891b968, nr_prims=2, ib=0x0, min_index=0, max_index=83)
at tnl/t_draw.c:478
this_nr_prims = <value optimized out>
bo = {0xb7180bb4, 0x88dba88, 0x30, 0xbf9e0928, 0xb6f73ddc, 0x80000000,
0x1, 0x8c28218, 0xb6f700de, 0x8c1afd8, 0x0, 0x2, 0x40, 0x88dba88, 0x88f2718,
0xbf9e0968, 0xb6f701f7, 0x88dba88, 0x400000, 0xbf9e0968, 0xb6f7017e,
0x88dba88, 0x400000, 0xb769b50c, 0xb717fa80, 0xb769b65c, 0x88d0544,
0x60121df, 0xb7180bb4, 0x88dba88, 0x0, 0xbf9e09c8, 0xb6fdf83e}
nr_bo = 0
max_basevertex = <value optimized out>
i = <value optimized out>
__PRETTY_FUNCTION__ = "_tnl_draw_prims"
#5 0xb70116a9 in _tnl_vbo_draw_prims (ctx=0x88dba88, arrays=0x891ce94,
prim=0x891b968, nr_prims=2, ib=0x0, index_bounds_valid=1 '\001',
min_index=0, max_index=83) at tnl/t_draw.c:384
No locals.
#6 0xb7007913 in vbo_exec_vtx_flush (exec=0x891b838, unmap=1 '\001')
at vbo/vbo_exec_draw.c:384
ctx = (GLcontext *) 0x88dba88
#7 0xb70050ee in vbo_exec_FlushVertices_internal (ctx=0x88dba88,
unmap=136 '\210') at vbo/vbo_exec_api.c:872
exec = (struct vbo_exec_context *) 0x891b838
#8 0xb700518b in vbo_exec_FlushVertices (ctx=0x88dba88, flags=1)
at vbo/vbo_exec_api.c:906
No locals.
#9 0xb6fd49bc in _mesa_PopMatrix () at main/matrix.c:285
stack = (struct gl_matrix_stack *) 0x88dbfb4
#10 0x08049d89 in DrawCrankshaft (eng=0x8073f60) at engine.c:511
phiStep = 120
phi = -90
i = 0
z = 0.400000006
#11 0x0804b4b7 in Draw () at engine.c:528
rot = {{0.457617939, -0.388804674, 0.799635649, 0}, {-0.00557587016,
0.898054183, 0.439849645, 0}, {-0.889131725, -0.205741853, 0.408797771,
0}, {0, 0, 0, 1}}
#12 0xb771a537 in processWindowWorkList (window=0x88c9ba8) at
glut_event.c:1307
workMask = 4
__PRETTY_FUNCTION__ = "processWindowWorkList"
#13 0xb771b519 in glutMainLoop () at glut_event.c:1358
No locals.
#14 0x0804ae39 in main (argc=1, argv=0xbf9e0f54) at engine.c:1340
No locals.
|
|
From: Brian P. <br...@vm...> - 2010-03-05 15:57:47
|
Chris Wilson wrote: > On Fri, 05 Mar 2010 07:48:06 -0700, Brian Paul <br...@vm...> wrote: >> Chris Wilson wrote: >>> Please review and include in 7.7! :) >> This will go into Mesa 7.8, actually. >> >> I see patches 1/4, 3/4 and 4/4 but not 2/4. Are the patches >> misnumbered or did 2/4 not get posted? > > As Michael pointed out, the changes to the autogenerated files were rather > large. > >> Can you commit these, Chris? > > Ok, pushed to master. Thanks. Thanks, Chris. I'm just going to make some minor clean-ups in bufferobj.c (not just your code). -Brian |
|
From: Chris W. <ch...@ch...> - 2010-03-05 15:23:13
|
On Fri, 05 Mar 2010 07:48:06 -0700, Brian Paul <br...@vm...> wrote: > Chris Wilson wrote: > > Please review and include in 7.7! :) > > This will go into Mesa 7.8, actually. > > I see patches 1/4, 3/4 and 4/4 but not 2/4. Are the patches > misnumbered or did 2/4 not get posted? As Michael pointed out, the changes to the autogenerated files were rather large. > Can you commit these, Chris? Ok, pushed to master. Thanks. > Are the new piglit tests going into the fd.o repository? I don't see > them yet. I shall ping Shuang He and ask for the tests to go upstream. -ickle -- Chris Wilson, Intel Open Source Technology Centre |
|
From: Michel D. <mi...@da...> - 2010-03-05 14:51:37
|
On Fri, 2010-03-05 at 07:48 -0700, Brian Paul wrote: > Chris Wilson wrote: > > Thanks to Intel QA providing a few piglit cases to test the API, this has > > had a cursory test and identified the silly cases of using the wrong > > lookup functions. > > > > The ugly part is that I've used 3 different driver functions to handle > > each of the 3 object variants - the alternative would be pass in a void > > pointer and a type id. If we acquire more distinct object types, then > > multiplexing a single driver function would be preferable to adding > > multiple stubs. > > > > Please review and include in 7.7! :) > > This will go into Mesa 7.8, actually. > > I see patches 1/4, 3/4 and 4/4 but not 2/4. Are the patches > misnumbered or did 2/4 not get posted? It's larger than half a megabyte and only contains changes for autogenerated files, so I discarded it from the list moderation queue. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer |
|
From: Brian P. <br...@vm...> - 2010-03-05 14:48:16
|
Chris Wilson wrote: > Thanks to Intel QA providing a few piglit cases to test the API, this has > had a cursory test and identified the silly cases of using the wrong > lookup functions. > > The ugly part is that I've used 3 different driver functions to handle > each of the 3 object variants - the alternative would be pass in a void > pointer and a type id. If we acquire more distinct object types, then > multiplexing a single driver function would be preferable to adding > multiple stubs. > > Please review and include in 7.7! :) This will go into Mesa 7.8, actually. I see patches 1/4, 3/4 and 4/4 but not 2/4. Are the patches misnumbered or did 2/4 not get posted? Can you commit these, Chris? Are the new piglit tests going into the fd.o repository? I don't see them yet. -Brian |
|
From: Chris W. <ch...@ch...> - 2010-03-05 12:04:38
|
Thanks to Intel QA providing a few piglit cases to test the API, this has had a cursory test and identified the silly cases of using the wrong lookup functions. The ugly part is that I've used 3 different driver functions to handle each of the 3 object variants - the alternative would be pass in a void pointer and a type id. If we acquire more distinct object types, then multiplexing a single driver function would be preferable to adding multiple stubs. Please review and include in 7.7! :) Thanks, -ickle |
|
From: Chris W. <ch...@ch...> - 2010-03-05 12:04:35
|
Signed-off-by: Chris Wilson <ch...@ch...>
---
src/mesa/glapi/gen/APPLE_object_purgeable.xml | 37 +++++++++++++++++++++++++
src/mesa/glapi/gen/Makefile | 1 +
src/mesa/glapi/gen/gl_API.xml | 1 +
3 files changed, 39 insertions(+), 0 deletions(-)
create mode 100644 src/mesa/glapi/gen/APPLE_object_purgeable.xml
diff --git a/src/mesa/glapi/gen/APPLE_object_purgeable.xml b/src/mesa/glapi/gen/APPLE_object_purgeable.xml
new file mode 100644
index 0000000..62fa64a
--- /dev/null
+++ b/src/mesa/glapi/gen/APPLE_object_purgeable.xml
@@ -0,0 +1,37 @@
+<?xml version="1.0"?>
+<!DOCTYPE OpenGLAPI SYSTEM "gl_API.dtd">
+
+<OpenGLAPI>
+<category name="GL_APPLE_object_purgeable" number="371">
+ <enum name="RELEASED_APPLE" value="0x8A19"/>
+ <enum name="VOLATILE_APPLE" value="0x8A1A"/>
+ <enum name="RETAINED_APPLE" value="0x8A1B"/>
+ <enum name="UNDEFINED_APPLE" value="0x8A1C"/>
+ <enum name="PURGEABLE_APPLE" count="1" value="0x8A1D">
+ <size name="GetObjectParameterivAPPLE" count="1" mode="get"/>
+ </enum>
+
+ <enum name="BUFFER_OBJECT_APPLE" value="0x85B3"/>
+
+ <function name="ObjectPurgeableAPPLE" offset="assign">
+ <param name="objectType" type="GLenum"/>
+ <param name="name" type="GLuint"/>
+ <param name="option" type="GLenum"/>
+ <return type="GLenum"/>
+ </function>
+
+ <function name="ObjectUnpurgeableAPPLE" offset="assign">
+ <param name="objectType" type="GLenum"/>
+ <param name="name" type="GLuint"/>
+ <param name="option" type="GLenum"/>
+ <return type="GLenum"/>
+ </function>
+
+ <function name="GetObjectParameterivAPPLE" offset="assign">
+ <param name="objectType" type="GLenum"/>
+ <param name="name" type="GLuint"/>
+ <param name="pname" type="GLenum"/>
+ <param name="value" type="GLint *" output="true"/>
+ </function>
+</category>
+</OpenGLAPI>
diff --git a/src/mesa/glapi/gen/Makefile b/src/mesa/glapi/gen/Makefile
index 8e9c909..8aa74ce 100644
--- a/src/mesa/glapi/gen/Makefile
+++ b/src/mesa/glapi/gen/Makefile
@@ -79,6 +79,7 @@ API_XML = \
ARB_seamless_cube_map.xml \
ARB_sync.xml \
ARB_vertex_array_object.xml \
+ APPLE_object_purgeable.xml \
APPLE_vertex_array_object.xml \
EXT_draw_buffers2.xml \
EXT_framebuffer_object.xml \
diff --git a/src/mesa/glapi/gen/gl_API.xml b/src/mesa/glapi/gen/gl_API.xml
index 0b3d57b..4a4d0d5 100644
--- a/src/mesa/glapi/gen/gl_API.xml
+++ b/src/mesa/glapi/gen/gl_API.xml
@@ -11978,6 +11978,7 @@
</function>
</category>
+<xi:include href="APPLE_object_purgeable.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="APPLE_vertex_array_object.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<category name="GL_APPLE_ycbcr_422" number="275">
--
1.7.0
|
102 messages has been excluded from this view by a project administrator.
