mesa3d-dev

[Mesa3d-dev] nv04 line emulation - closer to working version

[<ran...@gm...>]

Francisco, thanks for your help. It draws lines! But code as-is of cource not 
acceptable, i need to shrink it a lot and cleanup .... Thanks for initial 
idea, i'm very bad C coder, but even me can sometimes code something!

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Jesse B. <jb...@vi...>]

It would help to know what the server is doing at this point with the
client.  It may be that it put the client to sleep and hasn't woken it
up yet, or there could be something wrong with our getbuffers code in
the new scheme.

Jesse

On Sat, 06 Mar 2010 18:02:51 +0100
Stephan Raue <mai...@op...> wrote:

> looks this like my problems that i have reported some days ago with 
> Subject "Problem using an Mesa based App with recent 
> xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?
> 
> i have still this issue, but i dont know what you need for informations 
> to fix the issues?
> 
> with ati driver i dont have problems, only here with intel driver on my 
> Thinkpad X200t with intel HDA Graphics card
> 
> Stephan
> 
> Am 06.03.2010 17:46, schrieb Maxim Levitsky:
> > On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote:
> >    
> >> On Sat, 06 Mar 2010 16:40:27 +0200
> >> Maxim Levitsky<max...@gm...>  wrote:
> >>
> >>      
> >>> On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote:
> >>>        
> >>>> On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote:
> >>>>          
> >>>>> On Fri, 05 Mar 2010 23:48:48 +0200
> >>>>> Maxim Levitsky<max...@gm...>  wrote:
> >>>>>
> >>>>>            
> >>>>>> 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)
> >>>>>>              
> >>>>> if you just want a working setup, perhaps you should try using
> >>>>> something that got (probably) tested by at least some people:
> >>>>>   	http://intellinuxgraphics.org/2009Q4.html
> >>>>> cheers,
> >>>>> Flo
> >>>>>            
> >>>> Well, I now have a working setup with mesa
> >>>> ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5
> >>>>
> >>>> The problem is that I hoped that once all heavy work in regard to KMS
> >>>> was done, there will be no serious regressions in 3D stack, but only bug
> >>>> fixes, because it is very hard to track and fix bugs there.
> >>>>
> >>>> However, once again 3D stack is in bad shape, and this is not good.
> >>>>          
> >>>
> >>> More testing shows the following behaviour:
> >>>
> >>>
> >>>
> >>> Full screen mode is completely busted. As soon as any 3D application
> >>> switches to full screen mode, even without changing the resolution, it
> >>> hangs (note that I didn't see GPU hangs due to that)
> >>>
> >>> Compiz is broken (its also a full screen app...). As soon as it starts,
> >>> it draws few windows, and then stalls.
> >>>
> >>> In window mode all applications do work.
> >>>
> >>>
> >>> Now I guess this is worth a bugzilla entry.
> >>> (If this isn't there yet...)
> >>>        
> >> I'm not seeing this on GM45.  I just installed a totally fresh stack on
> >> a new F12 installation and compiz and games work well.  But please file
> >> a bug and include everything needed (see intellinuxgraphics.org for the
> >> list); hope we can find the issue.
> >>      
> >
> > Here, gdb backtrace while running sauerbraten full screen:
> >
> >
> > #2  0xb6e93d80 in ?? () from /usr/lib/libxcb.so.1
> > #3  0xb6e959d2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
> > #4  0xb7387e7e in _XReply (dpy=0x9023938, rep=0xbfc6a4dc, extra=0, discard=0) at xcb_io.c:454
> > #5  0xb772ba30 in DRI2GetBuffersWithFormat (dpy=0x9023938, drawable=62914575, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2,
> >      outCount=0xbfc6a608) at dri2.c:428
> > #6  0xb7729f62 in dri2GetBuffersWithFormat (driDrawable=0x93eed50, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, out_count=0xbfc6a608,
> >      loaderPrivate=0x93eecb0) at dri2_glx.c:435
> > #7  0xb6557bf3 in intel_update_renderbuffers (context=0x905c678, drawable=0x93eed50) at intel_context.c:253
> > #8  0xb65581d5 in intel_prepare_render (intel=0x90c6c50) at intel_context.c:395
> > #9  0xb657a423 in brw_try_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001',
> >      min_index=0, max_index=3) at brw_draw.c:340
> > #10 brw_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3)
> >      at brw_draw.c:441
> > #11 0xb663ea64 in vbo_exec_vtx_flush (exec=0x9102b30, unmap=1 '\001') at vbo/vbo_exec_draw.c:384
> > #12 0xb663a42a in vbo_exec_FlushVertices_internal (ctx=0xfffffdfc, unmap=255 '\377') at vbo/vbo_exec_api.c:872
> > #13 0xb663c230 in vbo_exec_FlushVertices (ctx=0x90c6c50, flags=1) at vbo/vbo_exec_api.c:906
> > #14 0xb65daea5 in _mesa_set_enable (ctx=0x90c6c50, cap=3042, state=1 '\001') at main/enable.c:283
> > #15 0xb65db1bf in _mesa_Enable (cap=3042) at main/enable.c:1007
> > #16 0x080abf08 in ?? ()
> > #17 0x080ad3fc in ?? ()
> > #18 0xb7479b56 in __libc_start_main (main=0x80ad0a0, argc=3, ubp_av=0xbfc6abb4, init=0x824a9f0, fini=0x824a9e0, rtld_fini=0xb789cd20<_dl_fini>,
> >
> >
> > Best regards,
> > 	Maxim Levitsky
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Int...@li...
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >    
> 
> 


-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Török Edwin wrote:
> Hi Andre,
> 
> I've been using your patch that enables pbo on r600:
> http://cgit.freedesktop.org/~andrem/mesa/commit/?h=r600-test&id=6ee755760d124c85bdfd121fd491f68fccca84f7
> 
> Are you considering enabling it in Mesa 7.8?

At this point the 7.8 branch is open for bug fixes *only*.  The
announcement that the 7.8 branch would be created on March 5th went out
on February 23th, and the release plan was discussed quite a few times
before that.  That was plenty of time to nominate patches for inclusion.

It's probably okay to just enable ARB_pixel_buffer_object, but I'd be a
bit nervous about the rest.  OpenGL 2.1 is more than just PBOs and GLSL
1.20.  Do the piglit and glean PBO tests pass on r600 with this patch?

> Some games won't even start without pbo support (for example Heroes of
> Newerth).
> 
> Even if gameplay isn't perfect (there are some rendering artifacts[1],
> and some effects are slow [2]) at least the game starts with that patch.
> 
> [1] which is not related to your pbo patch, I see artifacts w/o it too
> in other games, and blender:
> https://bugs.freedesktop.org/show_bug.cgi?id=26735
> [2] which can be turned off, like refraction
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuS3nMACgkQX1gOwKyEAw/jjQCcCT12MRnmcyzXT9T/KtxTPzA/
j6YAn00kNPUt/gFAwbfY+cBFojGj/oEk
=3PRS
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Florian M. <fl...@mi...>]

On Sun, 07 Mar 2010 00:24:24 +0200
Maxim Levitsky <max...@gm...> wrote:

> On Sun, 2010-03-07 at 00:05 +0200, Maxim Levitsky wrote:
> > On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote:
> > > On Sat, 06 Mar 2010 18:02:51 +0100
> > > Stephan Raue <mai...@op...> wrote:
> > > 
> > > > looks this like my problems that i have reported some days ago with 
> > > > Subject "Problem using an Mesa based App with recent 
> > > > xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?
> > > > 
> > > > i have still this issue, but i dont know what you need for informations 
> > > > to fix the issues?
> > > > 
> > > > with ati driver i dont have problems, only here with intel driver on my 
> > > > Thinkpad X200t with intel HDA Graphics card
> > > > 
> > 
> > I now see that compiz hangs in same way.
> > 
> > Attached are backtrace of the compiz, and backtrace of etracer which did
> > start full screen but became hung on resolution change.
> > 
> > Best regards,
> > 	Maxim Levitsky
> 
> Other info that might help:
> 
> I took a look at X and found that it was in normal waiting state
> sleeping waiting for input.
> 
> Also, I found when 'unstable' mesa would appear to work when I start the
> X while 'stable' one is used. It was compiz. When compiz is running
> using stable mesa, an game does change the resolution 'usualy' without
> hang even if uses unstable mesa.
> 
> Best regards,
> 	Maxim Levitsky

i found that the kernel updates for 2.6.34-rc1 did make the hang time
out... this has to be some vblank issue, i assume...

Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?

[Török E. <edw...@gm...>]

On 2010-03-06 23:42, Alex Deucher wrote:
> 2010/3/6 Corbin Simpson <mos...@gm...>:
>> HoN needs PBOs? How annoying.
>>
>> I'll pull in the patch if nobody else says anything, but I'd much
>> prefer that Alex or somebody else more familiar with r600 do it.
>>
> 
> Is that patch all that's needed for pbos?  I was under the impression
> there was more work involved, but I haven't really had a chance to
> look into it further.

Mesa 7.8 branch from git + that patch makes the game start [1]
w/o that patch it dies saying it needs pbo.

I don't know if pbo is HW accelerated or not (it probably isn't),
but it is "good enough" for this game if I turn refractions off.
orm=pbuffer doesn't work in wine though (black screen) (orm=fbo either,
only orm=backbuffer), but it can't work without this patch either.

[1] just confirmed that it works with 7.8 too, not just master.
After remembering to remove libtxc_dxtn.so, which I installed for
testing. (libtxc_dxtn doesn't work:
unsupported texture format in setup_hardware_state
failed to validate texture for unit 0).

Best regards,
--Edwin

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Maxim L. <max...@gm...>]

On Sun, 2010-03-07 at 00:05 +0200, Maxim Levitsky wrote:
> On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote:
> > On Sat, 06 Mar 2010 18:02:51 +0100
> > Stephan Raue <mai...@op...> wrote:
> > 
> > > looks this like my problems that i have reported some days ago with 
> > > Subject "Problem using an Mesa based App with recent 
> > > xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?
> > > 
> > > i have still this issue, but i dont know what you need for informations 
> > > to fix the issues?
> > > 
> > > with ati driver i dont have problems, only here with intel driver on my 
> > > Thinkpad X200t with intel HDA Graphics card
> > > 
> 
> I now see that compiz hangs in same way.
> 
> Attached are backtrace of the compiz, and backtrace of etracer which did
> start full screen but became hung on resolution change.
> 
> Best regards,
> 	Maxim Levitsky

Other info that might help:

I took a look at X and found that it was in normal waiting state
sleeping waiting for input.

Also, I found when 'unstable' mesa would appear to work when I start the
X while 'stable' one is used. It was compiz. When compiz is running
using stable mesa, an game does change the resolution 'usualy' without
hang even if uses unstable mesa.

Best regards,
	Maxim Levitsky

[Mesa3d-dev] [PATCH] nouveau/nv04: GL_EXT_secondary_color

[<ran...@gm...>]

Requres updated libdrm header (nouveau_class.h)

Tested with progs/demos/spectex and progs/tests/seccol

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Maxim L. <max...@gm...>]

On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote:
> On Sat, 06 Mar 2010 18:02:51 +0100
> Stephan Raue <mai...@op...> wrote:
> 
> > looks this like my problems that i have reported some days ago with 
> > Subject "Problem using an Mesa based App with recent 
> > xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?
> > 
> > i have still this issue, but i dont know what you need for informations 
> > to fix the issues?
> > 
> > with ati driver i dont have problems, only here with intel driver on my 
> > Thinkpad X200t with intel HDA Graphics card
> > 

I now see that compiz hangs in same way.

Attached are backtrace of the compiz, and backtrace of etracer which did
start full screen but became hung on resolution change.

Best regards,
	Maxim Levitsky

Re: [Mesa3d-dev] Probably, i monkeyed in wrong direction .....

[<ran...@gm...>]

В сообщении от Friday 05 March 2010 23:49:03 Stephane Marchesin написал(а):
> 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

New patch is here, tested with trivial/tri, DANGEROUS, may lock up your 
machine hard with anything else!

Strange thing about code - in function swtnl_render_triangles_verts it was 
going on and on, causing segfault, until i added

if (count == 3)
	{
	swtnl_triangle(ctx, i+0,i+1,i+2);
	return;
	}


Was found under gdb

=======

swtnl_render_triangles_verts (ctx=0x950ca88, start=0, count=3, flags=52)
    at nv04_render.c:285
285             for(i=start;i<count-5;i+=6)
(gdb) print i
$1 = 18

=======

Please, someone, enlight me on this small C secret, what was wrong in this 
for() ? 

Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?

[Alex D. <ale...@gm...>]

2010/3/6 Corbin Simpson <mos...@gm...>:
> HoN needs PBOs? How annoying.
>
> I'll pull in the patch if nobody else says anything, but I'd much
> prefer that Alex or somebody else more familiar with r600 do it.
>

Is that patch all that's needed for pbos?  I was under the impression
there was more work involved, but I haven't really had a chance to
look into it further.

Alex

> ~ C.
>
> 2010/3/6 Török Edwin <edw...@gm...>:
>> Hi Andre,
>>
>> I've been using your patch that enables pbo on r600:
>> http://cgit.freedesktop.org/~andrem/mesa/commit/?h=r600-test&id=6ee755760d124c85bdfd121fd491f68fccca84f7
>>
>> Are you considering enabling it in Mesa 7.8?
>>
>> Some games won't even start without pbo support (for example Heroes of
>> Newerth).
>>
>> Even if gameplay isn't perfect (there are some rendering artifacts[1],
>> and some effects are slow [2]) at least the game starts with that patch.
>>
>> [1] which is not related to your pbo patch, I see artifacts w/o it too
>> in other games, and blender:
>> https://bugs.freedesktop.org/show_bug.cgi?id=26735
>> [2] which can be turned off, like refraction
>>
>> Best regards,
>> --Edwin
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; 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
>>
>
>
>
> --
> Only fools are easily impressed by what is only
> barely beyond their reach. ~ Unknown
>
> Corbin Simpson
> <Mos...@gm...>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Florian M. <fl...@mi...>]

On Sat, 06 Mar 2010 18:02:51 +0100
Stephan Raue <mai...@op...> wrote:

> looks this like my problems that i have reported some days ago with 
> Subject "Problem using an Mesa based App with recent 
> xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?
> 
> i have still this issue, but i dont know what you need for informations 
> to fix the issues?
> 
> with ati driver i dont have problems, only here with intel driver on my 
> Thinkpad X200t with intel HDA Graphics card
> 
> Stephan
> 
> Am 06.03.2010 17:46, schrieb Maxim Levitsky:
> > Here, gdb backtrace while running sauerbraten full screen:
> >
> >
> > #2  0xb6e93d80 in ?? () from /usr/lib/libxcb.so.1
> > #3  0xb6e959d2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
> > #4  0xb7387e7e in _XReply (dpy=0x9023938, rep=0xbfc6a4dc, extra=0, discard=0) at xcb_io.c:454
> > #5  0xb772ba30 in DRI2GetBuffersWithFormat (dpy=0x9023938, drawable=62914575, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2,
> >      outCount=0xbfc6a608) at dri2.c:428
> > #6  0xb7729f62 in dri2GetBuffersWithFormat (driDrawable=0x93eed50, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, out_count=0xbfc6a608,
> >      loaderPrivate=0x93eecb0) at dri2_glx.c:435
> > #7  0xb6557bf3 in intel_update_renderbuffers (context=0x905c678, drawable=0x93eed50) at intel_context.c:253
> > #8  0xb65581d5 in intel_prepare_render (intel=0x90c6c50) at intel_context.c:395
> > #9  0xb657a423 in brw_try_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001',
> >      min_index=0, max_index=3) at brw_draw.c:340
> > #10 brw_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3)
> >      at brw_draw.c:441
> > #11 0xb663ea64 in vbo_exec_vtx_flush (exec=0x9102b30, unmap=1 '\001') at vbo/vbo_exec_draw.c:384
> > #12 0xb663a42a in vbo_exec_FlushVertices_internal (ctx=0xfffffdfc, unmap=255 '\377') at vbo/vbo_exec_api.c:872
> > #13 0xb663c230 in vbo_exec_FlushVertices (ctx=0x90c6c50, flags=1) at vbo/vbo_exec_api.c:906
> > #14 0xb65daea5 in _mesa_set_enable (ctx=0x90c6c50, cap=3042, state=1 '\001') at main/enable.c:283
> > #15 0xb65db1bf in _mesa_Enable (cap=3042) at main/enable.c:1007
> > #16 0x080abf08 in ?? ()
> > #17 0x080ad3fc in ?? ()
> > #18 0xb7479b56 in __libc_start_main (main=0x80ad0a0, argc=3, ubp_av=0xbfc6abb4, init=0x824a9f0, fini=0x824a9e0, rtld_fini=0xb789cd20<_dl_fini>,
> >
> >
> > Best regards,
> > 	Maxim Levitsky
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Int...@li...
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >    
> 
> 

with glxgears I can reproduce a hang in _XReply with the same backtrace
up to intel_prepare_render.. i think there are some vblank events
going awol or somewhat like that.. 

i just have to move glxgears from one xrandr head to the next...
(a little bit timing in there, but nonetheless it is easy to trigger)

with the soon-to-be linux-2.6.34-rc1 however, it will now only
hang some 1 or 2 secs then continue to run. 

i'm running on 64bit... (kernel + userland) ... 

hth,
Flo

Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?

[Török E. <edw...@gm...>]

On 2010-03-06 21:58, Corbin Simpson wrote:
> HoN needs PBOs? How annoying.

It needs these:
64MB OpenGL 1.2 / GLSL 1.10 compliant video card with the following
extensions present: ARB_multitexture, ARB_vertex_buffer_object,
ARB_shader_objects, ARB_fragment_shader, ARB_vertex_shader,
ARB_shading_language_100, ARB_pixel_buffer_object, EXT_framebuffer_object

> 
> I'll pull in the patch if nobody else says anything, but I'd much
> prefer that Alex or somebody else more familiar with r600 do it.

Thanks!

Best regards,
--Edwin

Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?

[Corbin S. <mos...@gm...>]

HoN needs PBOs? How annoying.

I'll pull in the patch if nobody else says anything, but I'd much
prefer that Alex or somebody else more familiar with r600 do it.

~ C.

2010/3/6 Török Edwin <edw...@gm...>:
> Hi Andre,
>
> I've been using your patch that enables pbo on r600:
> http://cgit.freedesktop.org/~andrem/mesa/commit/?h=r600-test&id=6ee755760d124c85bdfd121fd491f68fccca84f7
>
> Are you considering enabling it in Mesa 7.8?
>
> Some games won't even start without pbo support (for example Heroes of
> Newerth).
>
> Even if gameplay isn't perfect (there are some rendering artifacts[1],
> and some effects are slow [2]) at least the game starts with that patch.
>
> [1] which is not related to your pbo patch, I see artifacts w/o it too
> in other games, and blender:
> https://bugs.freedesktop.org/show_bug.cgi?id=26735
> [2] which can be turned off, like refraction
>
> Best regards,
> --Edwin
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>



-- 
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

Corbin Simpson
<Mos...@gm...>

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Stephan R. <mai...@op...>]

looks this like my problems that i have reported some days ago with 
Subject "Problem using an Mesa based App with recent 
xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?

i have still this issue, but i dont know what you need for informations 
to fix the issues?

with ati driver i dont have problems, only here with intel driver on my 
Thinkpad X200t with intel HDA Graphics card

Stephan

Am 06.03.2010 17:46, schrieb Maxim Levitsky:
> On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote:
>    
>> On Sat, 06 Mar 2010 16:40:27 +0200
>> Maxim Levitsky<max...@gm...>  wrote:
>>
>>      
>>> On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote:
>>>        
>>>> On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote:
>>>>          
>>>>> On Fri, 05 Mar 2010 23:48:48 +0200
>>>>> Maxim Levitsky<max...@gm...>  wrote:
>>>>>
>>>>>            
>>>>>> 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)
>>>>>>              
>>>>> if you just want a working setup, perhaps you should try using
>>>>> something that got (probably) tested by at least some people:
>>>>>   	http://intellinuxgraphics.org/2009Q4.html
>>>>> cheers,
>>>>> Flo
>>>>>            
>>>> Well, I now have a working setup with mesa
>>>> ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5
>>>>
>>>> The problem is that I hoped that once all heavy work in regard to KMS
>>>> was done, there will be no serious regressions in 3D stack, but only bug
>>>> fixes, because it is very hard to track and fix bugs there.
>>>>
>>>> However, once again 3D stack is in bad shape, and this is not good.
>>>>          
>>>
>>> More testing shows the following behaviour:
>>>
>>>
>>>
>>> Full screen mode is completely busted. As soon as any 3D application
>>> switches to full screen mode, even without changing the resolution, it
>>> hangs (note that I didn't see GPU hangs due to that)
>>>
>>> Compiz is broken (its also a full screen app...). As soon as it starts,
>>> it draws few windows, and then stalls.
>>>
>>> In window mode all applications do work.
>>>
>>>
>>> Now I guess this is worth a bugzilla entry.
>>> (If this isn't there yet...)
>>>        
>> I'm not seeing this on GM45.  I just installed a totally fresh stack on
>> a new F12 installation and compiz and games work well.  But please file
>> a bug and include everything needed (see intellinuxgraphics.org for the
>> list); hope we can find the issue.
>>      
>
> Here, gdb backtrace while running sauerbraten full screen:
>
>
> #2  0xb6e93d80 in ?? () from /usr/lib/libxcb.so.1
> #3  0xb6e959d2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
> #4  0xb7387e7e in _XReply (dpy=0x9023938, rep=0xbfc6a4dc, extra=0, discard=0) at xcb_io.c:454
> #5  0xb772ba30 in DRI2GetBuffersWithFormat (dpy=0x9023938, drawable=62914575, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2,
>      outCount=0xbfc6a608) at dri2.c:428
> #6  0xb7729f62 in dri2GetBuffersWithFormat (driDrawable=0x93eed50, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, out_count=0xbfc6a608,
>      loaderPrivate=0x93eecb0) at dri2_glx.c:435
> #7  0xb6557bf3 in intel_update_renderbuffers (context=0x905c678, drawable=0x93eed50) at intel_context.c:253
> #8  0xb65581d5 in intel_prepare_render (intel=0x90c6c50) at intel_context.c:395
> #9  0xb657a423 in brw_try_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001',
>      min_index=0, max_index=3) at brw_draw.c:340
> #10 brw_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3)
>      at brw_draw.c:441
> #11 0xb663ea64 in vbo_exec_vtx_flush (exec=0x9102b30, unmap=1 '\001') at vbo/vbo_exec_draw.c:384
> #12 0xb663a42a in vbo_exec_FlushVertices_internal (ctx=0xfffffdfc, unmap=255 '\377') at vbo/vbo_exec_api.c:872
> #13 0xb663c230 in vbo_exec_FlushVertices (ctx=0x90c6c50, flags=1) at vbo/vbo_exec_api.c:906
> #14 0xb65daea5 in _mesa_set_enable (ctx=0x90c6c50, cap=3042, state=1 '\001') at main/enable.c:283
> #15 0xb65db1bf in _mesa_Enable (cap=3042) at main/enable.c:1007
> #16 0x080abf08 in ?? ()
> #17 0x080ad3fc in ?? ()
> #18 0xb7479b56 in __libc_start_main (main=0x80ad0a0, argc=3, ubp_av=0xbfc6abb4, init=0x824a9f0, fini=0x824a9e0, rtld_fini=0xb789cd20<_dl_fini>,
>
>
> Best regards,
> 	Maxim Levitsky
>
> _______________________________________________
> Intel-gfx mailing list
> Int...@li...
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>    


-- 
               ### OpenELEC.tv ###
The free and open Mediacenter Distribution 4 you
              http://www.openelec.tv

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Maxim L. <max...@gm...>]

On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote:
> On Sat, 06 Mar 2010 16:40:27 +0200
> Maxim Levitsky <max...@gm...> wrote:
> 
> > On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: 
> > > On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote:
> > > > On Fri, 05 Mar 2010 23:48:48 +0200
> > > > Maxim Levitsky <max...@gm...> wrote:
> > > > 
> > > > > 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)
> > > > 
> > > > if you just want a working setup, perhaps you should try using
> > > > something that got (probably) tested by at least some people:
> > > >  	http://intellinuxgraphics.org/2009Q4.html
> > > > cheers,
> > > > Flo
> > > 
> > > Well, I now have a working setup with mesa 
> > > ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5
> > > 
> > > The problem is that I hoped that once all heavy work in regard to KMS
> > > was done, there will be no serious regressions in 3D stack, but only bug
> > > fixes, because it is very hard to track and fix bugs there.
> > > 
> > > However, once again 3D stack is in bad shape, and this is not good.
> > 
> > 
> > More testing shows the following behaviour:
> > 
> > 
> > 
> > Full screen mode is completely busted. As soon as any 3D application
> > switches to full screen mode, even without changing the resolution, it
> > hangs (note that I didn't see GPU hangs due to that)
> > 
> > Compiz is broken (its also a full screen app...). As soon as it starts,
> > it draws few windows, and then stalls.
> > 
> > In window mode all applications do work.
> > 
> > 
> > Now I guess this is worth a bugzilla entry.
> > (If this isn't there yet...)
> 
> I'm not seeing this on GM45.  I just installed a totally fresh stack on
> a new F12 installation and compiz and games work well.  But please file
> a bug and include everything needed (see intellinuxgraphics.org for the
> list); hope we can find the issue.


Here, gdb backtrace while running sauerbraten full screen:


#2  0xb6e93d80 in ?? () from /usr/lib/libxcb.so.1
#3  0xb6e959d2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
#4  0xb7387e7e in _XReply (dpy=0x9023938, rep=0xbfc6a4dc, extra=0, discard=0) at xcb_io.c:454
#5  0xb772ba30 in DRI2GetBuffersWithFormat (dpy=0x9023938, drawable=62914575, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, 
    outCount=0xbfc6a608) at dri2.c:428
#6  0xb7729f62 in dri2GetBuffersWithFormat (driDrawable=0x93eed50, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, out_count=0xbfc6a608, 
    loaderPrivate=0x93eecb0) at dri2_glx.c:435
#7  0xb6557bf3 in intel_update_renderbuffers (context=0x905c678, drawable=0x93eed50) at intel_context.c:253
#8  0xb65581d5 in intel_prepare_render (intel=0x90c6c50) at intel_context.c:395
#9  0xb657a423 in brw_try_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', 
    min_index=0, max_index=3) at brw_draw.c:340
#10 brw_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3)
    at brw_draw.c:441
#11 0xb663ea64 in vbo_exec_vtx_flush (exec=0x9102b30, unmap=1 '\001') at vbo/vbo_exec_draw.c:384
#12 0xb663a42a in vbo_exec_FlushVertices_internal (ctx=0xfffffdfc, unmap=255 '\377') at vbo/vbo_exec_api.c:872
#13 0xb663c230 in vbo_exec_FlushVertices (ctx=0x90c6c50, flags=1) at vbo/vbo_exec_api.c:906
#14 0xb65daea5 in _mesa_set_enable (ctx=0x90c6c50, cap=3042, state=1 '\001') at main/enable.c:283
#15 0xb65db1bf in _mesa_Enable (cap=3042) at main/enable.c:1007
#16 0x080abf08 in ?? ()
#17 0x080ad3fc in ?? ()
#18 0xb7479b56 in __libc_start_main (main=0x80ad0a0, argc=3, ubp_av=0xbfc6abb4, init=0x824a9f0, fini=0x824a9e0, rtld_fini=0xb789cd20 <_dl_fini>, 


Best regards,
	Maxim Levitsky

[Mesa3d-dev] [Bug 26904] undefined symbol: GLwCreateM2DrawingArea

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26904





--- Comment #2 from Paul Jaques <pa...@ge...>  2010-03-06 08:37:40 PST ---
It looks like others have found similar problems, I just looked at
http://ubuntuforums.org/showthread.php?t=373104.

I've used GLwCreateMDrawingArea on various Red Hat releases and it's always
worked, and this is pretty well eastablished and standard code. I'm not sure
what happens exactly, but I guess GLwCreateMDrawingArea get's mapped to
GLwCreateM2DrawingArea via the include files - I haven't checked this, so not
sure. The GLwCreateM2DrawingArea function is in my RHEL5.4 libraries, just not
in my Fedora libraries.

For the time being I have a workaround by just using my RH libraries on Fedora,
so at least the code is working OK.

Regards, Paul.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Jesse B. <jb...@vi...>]

On Sat, 06 Mar 2010 16:40:27 +0200
Maxim Levitsky <max...@gm...> wrote:

> On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: 
> > On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote:
> > > On Fri, 05 Mar 2010 23:48:48 +0200
> > > Maxim Levitsky <max...@gm...> wrote:
> > > 
> > > > 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)
> > > 
> > > if you just want a working setup, perhaps you should try using
> > > something that got (probably) tested by at least some people:
> > >  	http://intellinuxgraphics.org/2009Q4.html
> > > cheers,
> > > Flo
> > 
> > Well, I now have a working setup with mesa 
> > ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5
> > 
> > The problem is that I hoped that once all heavy work in regard to KMS
> > was done, there will be no serious regressions in 3D stack, but only bug
> > fixes, because it is very hard to track and fix bugs there.
> > 
> > However, once again 3D stack is in bad shape, and this is not good.
> 
> 
> More testing shows the following behaviour:
> 
> 
> 
> Full screen mode is completely busted. As soon as any 3D application
> switches to full screen mode, even without changing the resolution, it
> hangs (note that I didn't see GPU hangs due to that)
> 
> Compiz is broken (its also a full screen app...). As soon as it starts,
> it draws few windows, and then stalls.
> 
> In window mode all applications do work.
> 
> 
> Now I guess this is worth a bugzilla entry.
> (If this isn't there yet...)

I'm not seeing this on GM45.  I just installed a totally fresh stack on
a new F12 installation and compiz and games work well.  But please file
a bug and include everything needed (see intellinuxgraphics.org for the
list); hope we can find the issue.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Maxim L. <max...@gm...>]

On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: 
> On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote:
> > On Fri, 05 Mar 2010 23:48:48 +0200
> > Maxim Levitsky <max...@gm...> wrote:
> > 
> > > 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)
> > 
> > if you just want a working setup, perhaps you should try using
> > something that got (probably) tested by at least some people:
> >  	http://intellinuxgraphics.org/2009Q4.html
> > cheers,
> > Flo
> 
> Well, I now have a working setup with mesa 
> ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5
> 
> The problem is that I hoped that once all heavy work in regard to KMS
> was done, there will be no serious regressions in 3D stack, but only bug
> fixes, because it is very hard to track and fix bugs there.
> 
> However, once again 3D stack is in bad shape, and this is not good.


More testing shows the following behaviour:



Full screen mode is completely busted. As soon as any 3D application
switches to full screen mode, even without changing the resolution, it
hangs (note that I didn't see GPU hangs due to that)

Compiz is broken (its also a full screen app...). As soon as it starts,
it draws few windows, and then stalls.

In window mode all applications do work.


Now I guess this is worth a bugzilla entry.
(If this isn't there yet...)


Best regards,
	Maxim Levitsky

[Mesa3d-dev] r600 pixel_buffer_object for 7.8?

[Török E. <edw...@gm...>]

Hi Andre,

I've been using your patch that enables pbo on r600:
http://cgit.freedesktop.org/~andrem/mesa/commit/?h=r600-test&id=6ee755760d124c85bdfd121fd491f68fccca84f7

Are you considering enabling it in Mesa 7.8?

Some games won't even start without pbo support (for example Heroes of
Newerth).

Even if gameplay isn't perfect (there are some rendering artifacts[1],
and some effects are slow [2]) at least the game starts with that patch.

[1] which is not related to your pbo patch, I see artifacts w/o it too
in other games, and blender:
https://bugs.freedesktop.org/show_bug.cgi?id=26735
[2] which can be turned off, like refraction

Best regards,
--Edwin

Re: [Mesa3d-dev] Mesa (master): util: Code generate functions to pack and unpack a single pixel.

[Michel D. <mi...@da...>]

On Sat, 2010-03-06 at 12:44 +0000, José Fonseca wrote: 
> On Mon, 2010-03-01 at 09:03 -0800, Michel Dänzer wrote:
> > On Fri, 2010-02-26 at 08:47 -0800, Jose Fonseca wrote: 
> > > Module: Mesa
> > > Branch: master
> > > Commit: 9beb302212a2afac408016cbd7b93c8b859e4910
> > > URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=9beb302212a2afac408016cbd7b93c8b859e4910
> > > 
> > > Author: José Fonseca <jfo...@vm...>
> > > Date:   Fri Feb 26 16:45:22 2010 +0000
> > > 
> > > util: Code generate functions to pack and unpack a single pixel.
> > > 
> > > Should work correctly for all pixel formats except SRGB formats.
> > > 
> > > Generated code made much simpler by defining the pixel format as
> > > a C structure. For example this is the generated structure for
> > > PIPE_FORMAT_B6UG5SR5S_NORM:
> > > 
> > > union util_format_b6ug5sr5s_norm {
> > >    uint16_t value;
> > >    struct {
> > >       int r:5;
> > >       int g:5;
> > >       unsigned b:6;
> > >    } chan;
> > > };
> > 
> > José, are you aware that the memory layout of bitfields is mostly
> > implementation dependent? IME this makes them mostly unusable for
> > modelling hardware in a portable manner.
> 
> It's not only implementation dependent and slow -- it is also buggy!
> 
> gcc-4.4.3 is doing something very fishy to single bit fields. 
> 
> See the attached code. ff ff ff ff is expected, but ff ff ff 01 is
> printed with gcc-4.4.3. Even without any optimization. gcc-4.3.4 works
> fine.
> 
> Am I missing something or is this effectively a bug?

No idea, I just try to stay away from bitfields as much as possible.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [Mesa3d-dev] Mesa (master): util: Code generate functions to pack and unpack a single pixel.

[Brian P. <bri...@gm...>]

On Sat, Mar 6, 2010 at 5:44 AM, José Fonseca <jfo...@vm...> wrote:
> On Mon, 2010-03-01 at 09:03 -0800, Michel Dänzer wrote:
>> On Fri, 2010-02-26 at 08:47 -0800, Jose Fonseca wrote:
>> > Module: Mesa
>> > Branch: master
>> > Commit: 9beb302212a2afac408016cbd7b93c8b859e4910
>> > URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=9beb302212a2afac408016cbd7b93c8b859e4910
>> >
>> > Author: José Fonseca <jfo...@vm...>
>> > Date:   Fri Feb 26 16:45:22 2010 +0000
>> >
>> > util: Code generate functions to pack and unpack a single pixel.
>> >
>> > Should work correctly for all pixel formats except SRGB formats.
>> >
>> > Generated code made much simpler by defining the pixel format as
>> > a C structure. For example this is the generated structure for
>> > PIPE_FORMAT_B6UG5SR5S_NORM:
>> >
>> > union util_format_b6ug5sr5s_norm {
>> >    uint16_t value;
>> >    struct {
>> >       int r:5;
>> >       int g:5;
>> >       unsigned b:6;
>> >    } chan;
>> > };
>>
>> José, are you aware that the memory layout of bitfields is mostly
>> implementation dependent? IME this makes them mostly unusable for
>> modelling hardware in a portable manner.
>
> It's not only implementation dependent and slow -- it is also buggy!
>
> gcc-4.4.3 is doing something very fishy to single bit fields.
>
> See the attached code. ff ff ff ff is expected, but ff ff ff 01 is
> printed with gcc-4.4.3. Even without any optimization. gcc-4.3.4 works
> fine.
>
> Am I missing something or is this effectively a bug?

Same result with gcc 4.4.1.

If pixel.chan.a is put into a temporary int var followed by the
scaling arithmetic it comes out as expected.  Looks like a bug to me.

BTW, it looks like sizeof(union util_format_b5g5r5a1_unorm) == 4, not 2.

-Brian

Re: [Mesa3d-dev] Mesa (master): util: Code generate functions to pack and unpack a single pixel.

[José F. <jfo...@vm...>]

On Mon, 2010-03-01 at 09:03 -0800, Michel Dänzer wrote:
> On Fri, 2010-02-26 at 08:47 -0800, Jose Fonseca wrote: 
> > Module: Mesa
> > Branch: master
> > Commit: 9beb302212a2afac408016cbd7b93c8b859e4910
> > URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=9beb302212a2afac408016cbd7b93c8b859e4910
> > 
> > Author: José Fonseca <jfo...@vm...>
> > Date:   Fri Feb 26 16:45:22 2010 +0000
> > 
> > util: Code generate functions to pack and unpack a single pixel.
> > 
> > Should work correctly for all pixel formats except SRGB formats.
> > 
> > Generated code made much simpler by defining the pixel format as
> > a C structure. For example this is the generated structure for
> > PIPE_FORMAT_B6UG5SR5S_NORM:
> > 
> > union util_format_b6ug5sr5s_norm {
> >    uint16_t value;
> >    struct {
> >       int r:5;
> >       int g:5;
> >       unsigned b:6;
> >    } chan;
> > };
> 
> José, are you aware that the memory layout of bitfields is mostly
> implementation dependent? IME this makes them mostly unusable for
> modelling hardware in a portable manner.

It's not only implementation dependent and slow -- it is also buggy!

gcc-4.4.3 is doing something very fishy to single bit fields. 

See the attached code. ff ff ff ff is expected, but ff ff ff 01 is
printed with gcc-4.4.3. Even without any optimization. gcc-4.3.4 works
fine.

Am I missing something or is this effectively a bug?

Jose

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Maxim L. <max...@gm...>]

On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote:
> On Fri, 05 Mar 2010 23:48:48 +0200
> Maxim Levitsky <max...@gm...> wrote:
> 
> > 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)
> 
> if you just want a working setup, perhaps you should try using
> something that got (probably) tested by at least some people:
>  	http://intellinuxgraphics.org/2009Q4.html
> cheers,
> Flo

Well, I now have a working setup with mesa 
ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5

The problem is that I hoped that once all heavy work in regard to KMS
was done, there will be no serious regressions in 3D stack, but only bug
fixes, because it is very hard to track and fix bugs there.

However, once again 3D stack is in bad shape, and this is not good.


Best regards,
	Maxim Levitsky

Re: [Mesa3d-dev] Mesa (master): mesa: Export GL_EXT_texture_cube_map.

[José F. <jfo...@vm...>]

On Fri, 2010-03-05 at 16:16 -0800, Ian Romanick wrote:
> 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?  

Hi Ian,

It was Adobe Photoshop CS4. 

It actually searches for both GL_ARB_texture_cube_map and
GL_EXT_texture_cube_map, but somewhere along the way it ignores the
former and outputs in a system information log:

  Cube Maps NOT SUPPORTED...

It is quite possible that it is a bug in the system information output
code, and the GL code actually uses cubemaps. But it is almost
impossible to be sure, as Photoshop is very complex and has several
distinct uses of OpenGL (e.g., effects, visualization, etc). And at any
rate if an user would see the above message it would get legitimately
worried.

It seemed simpler just to list GL_EXT_texture_cube_map!

> I didn't think
> anyone ever actually shipped this extension.  I guess Nvidia might have..

I don't have my NVIDIA machine handy, but I checked it before committing
this and IIRC they indeed had this extension listed.

Jose

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Florian M. <fl...@mi...>]

On Fri, 05 Mar 2010 23:48:48 +0200
Maxim Levitsky <max...@gm...> wrote:

> 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)

if you just want a working setup, perhaps you should try using
something that got (probably) tested by at least some people:
 	http://intellinuxgraphics.org/2009Q4.html
cheers,
Flo