Re: [Mesa3d-dev] gallium cached bufmgr busy change
Dave,
I don't oppose this new method -- it shouldn't be necessary to add fencing just
to use pb_cache --, but this method adds a new way of doing the same thing.
Does the underlying buffer support PIPE_BUFFER_USAGE_DONT_BLOCK? If so what
about doing:
boolean
pb_cache_is_buffer_compat()
{
void map;
map = pb_map(buf->buffer, PIPE_BUFFER_USAGE_DONT_BLOCK | PIPE_BUFFER);
if (map) {
/* TODO: cache the map value for the first map */
pb_unmap(buf->buffer);
return TRUE;
}
return FALSE;
}
Jose
From: Dave Airlie [airl...@gmail.com]
Sent: Sunday, March 07, 2010 20:36
To: Luca Barbieri
Cc: mesa
Subject: Re: [Mesa3d-dev] gallium cached bufmgr busy change
On Sun, Mar 7, 2010 at 9:44 PM, Luca Barbieri wrote:
> I think you are supposed to do this using the fenced bufmgr over
> cached along with a (ideally userspace) fencing mechanism.
> If you can implement pb_busy, you should be able to implement
> fence_signalled in exactly the same way (making the fence handle a
> pointer to buffers should work for this purpose, if standalone fences
> are hard to do).
> The fenced bufmgr will only pass destruction requests to the wrapped
> bufmgr once the fences are signalled.
>
It just seemed a bit heavyweight, I don't want userspace fences, so why
do I have to jump though abstraction hoops?
The fencing solution isn't near as efficent from what I can see, as it
is designed around fences not buffer busy, I'll see if I can give it a try,
but I suspect it look and smell like a hack.
Dave.
--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Compile error in radeon_texture.c
Hi,
There is a compile error in radeon_texture.c.
Thanks.
Johannes
gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver
-I../../../../../include -I../../../../../src/mesa
-I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri
-I/usr/include/drm-g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
-fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71
-DHAVE_LIBDRM_RADEON=1 -I/usr/include/drm -DRADEON_R200 radeon_texture.c -o
radeon_texture.o
In file included from radeon_mipmap_tree.c:39:
radeon_tile.h:1: error: expected identifier or '(' before '.' token
radeon_mipmap_tree.c: In function 'get_texture_image_size':
radeon_mipmap_tree.c:90: warning: implicit declaration of function
'get_tile_size'
radeon_mipmap_tree.c: In function 'get_texture_image_row_stride':
radeon_mipmap_tree.c:102: warning: implicit declaration of function
'get_aligned_compressed_row_stride'
gmake[6]: *** [radeon_mipmap_tree.o] Error 1
gmake[6]: *** Waiting for unfinished jobs
gmake[6]: Leaving directory
`/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/r200'
gmake[5]: *** [lib] Error 2
gmake[5]: Leaving directory
`/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri/r200'
gmake[4]: *** [subdirs] Error 1
gmake[4]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri'
gmake[3]: *** [default] Error 1
gmake[3]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/mesa/drivers'
gmake[2]: *** [driver_subdirs] Error 2
gmake[2]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/mesa'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/packages/BUILD/Mesa/src'
make: *** [default] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.OTEkCI (%build)
--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Corbin Simpson wrote: > 2010/3/8 Ian Romanick : >> Okay. I'm convinced. I'll leave it up to the r600 maintainers to make >> the final call. However, they really need to do it before RC1 (March 12th). > > Thread hijack! Are docs changes okay? I'd like to note that r300g As long as they don't cause regressions. ;) > works for the simpler things in life, that bugs may be filed against > it, and that it's been taken off the all-kitten diet. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuULXkACgkQX1gOwKyEAw/eNwCeMWtmKVFrsP3Xszv7lQ2qsfDB y4EAniZo3oVtGOOmoeU686yzCrnRYDZi =dtmN -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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?
2010/3/8 Ian Romanick : > Okay. I'm convinced. I'll leave it up to the r600 maintainers to make > the final call. However, they really need to do it before RC1 (March 12th). Thread hijack! Are docs changes okay? I'd like to note that r300g works for the simpler things in life, that bugs may be filed against it, and that it's been taken off the all-kitten diet. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Török Edwin wrote: > I've run the piglit tests using tests/r500.tests, with glean in quick mode. > > With patch: 620/686 pass > Without patch: 614/679 pass (I opened a bugreport about these failures > here: https://bugs.freedesktop.org/show_bug.cgi?id=26933) > > The pbo tests results are: > glean/pbo: fail > general/pbo-teximage-tiling: pass > general/pbo-read-argb: pass > general/pbo-teximage-tiling-2: pass > general/pbo-drawpixels: pass > general/pbo-readpixels-small: pass > general/object_purgeable-api-pbo: skip > general/pbo-teximage: pass > fbo/fbo-pbo-readpixels-small: pass Okay. I'm convinced. I'll leave it up to the r600 maintainers to make the final call. However, they really need to do it before RC1 (March 12th). > The glean/fbo fail looks like some FP tolerance being too strict (1.0 vs > 1.0). Is there a way to accept 1.0 for 1.0 in the piglit tests? > > pbo test: Test OpenGL Extension GL_ARB_pixel_buffer_object > > FAILURE: glGetPolygonStipple failed (at tpbo.cpp:1028) > (1, 0) = [1.00, 1.00, 1.00], should be [1.0, 1.0, 1.0] > pbo: NOTE perf[0] = 372.891 MB/s, which is in normal mode > pbo: NOTE perf[1] = 261.088 MB/s, which is using PBO > pbo: FAIL rgba8, db, z24, s8, win+pmap, id 33 > 9 tests passed, 1 tests failed. That's pretty weird. I was pretty sure that glean checked for equality by making sure the difference was below some threshold. As far as I can tell, fabs(1.00 - 1.0) should be below any reasonable threshold. There's clearly something else going wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuUJLYACgkQX1gOwKyEAw/MPQCfZ8b/sSBRR8yN8z9u6tQrlY7J +4sAnRKvgpboQ8D3ObcNwW5lEUKudPPv =5D6f -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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Summer of Code ideas
Hey guys, Summer of code is coming on us. I need you to help fill/correct the ideas page at http://wiki.x.org/wiki/SummerOfCodeIdeas I moved some 2009 ideas which are still relevant into 2010. But I don't really know about the state of subsystems I don't follow, for example I know nothing about xcb or input. So I'd be grateful if you could update it and move the relevant ideas to 2010, or add new ideas. Thanks, Stephane -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium cached bufmgr busy change
On Sun, Mar 7, 2010 at 9:44 PM, Luca Barbieri wrote: > I think you are supposed to do this using the fenced bufmgr over > cached along with a (ideally userspace) fencing mechanism. > If you can implement pb_busy, you should be able to implement > fence_signalled in exactly the same way (making the fence handle a > pointer to buffers should work for this purpose, if standalone fences > are hard to do). > The fenced bufmgr will only pass destruction requests to the wrapped > bufmgr once the fences are signalled. > It just seemed a bit heavyweight, I don't want userspace fences, so why do I have to jump though abstraction hoops? The fencing solution isn't near as efficent from what I can see, as it is designed around fences not buffer busy, I'll see if I can give it a try, but I suspect it look and smell like a hack. Dave. -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Probably, i monkeyed in wrong direction .....
2010/3/6 :
> В сообщении от Friday 05 March 2010 23:49:03 Stephane Marchesin написал(а):
>> 2010/3/5 :
>> > В сообщении от 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 (gdb) print i
> $1 = 18
>
> ===
>
> Please, someone, enlight me on this small C secret, what was wrong in this
> for() ?
>
count is GLuint, i.e. unsigned. If count < 5, count-5 ~ around 4
billion due to overflow. Changing the check to i+5 < count should make
it work.
Mike.
--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] dri-extension branch - clean up advertising extensions in Gallium
This branch is aimed to address the following issues: * Extensions are advertised in both st/mesa and st/dri, doing the same thing in two places. * The inability to disable extensions in pipe_screen::get_param because st/dri overrides the decisions of st/mesa. Here's the branch: http://cgit.freedesktop.org/~mareko/mesa/log/?h=dri-extensions The first commit moves the differences between st/dri and st/mesa to the latter and removes dri_init_extensions from st/dri. It doesn't remove any extensions from the list except for those not advertised by pipe_screen. The second commit enables texture_rectangle by default in Gallium. To my knowledge any Gallium hardware can do this and I suspect it was dependent on NPOT textures by accident. All this is of course tested with piglit and glean. Please review. In case it's not OK, please let me know what needs to be done. -Marek -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again
On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote: > On Sat, 06 Mar 2010 16:40:27 +0200 > Maxim Levitsky 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 wrote: > > > > > > > > > On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: > > > > > > On Fri, 05 Mar 2010 23:18:07 +0200 > > > > > > Maxim Levitsky wrote: > > > > > > > > > > > > > On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: > > > > > > > > On Fri, 05 Mar 2010 22:42:21 +0200 > > > > > > > > Maxim Levitsky 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. > Done: https://bugs.freedesktop.org/show_bug.cgi?id=26939 I also opened a bug for other very annoying problem that was present for long time. https://bugs.freedesktop.org/show_bug.cgi?id=26938 Best regards, Maxim Levitsky -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] nv04 line emulation - closer to working version
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!
diff --git a/src/mesa/drivers/dri/nouveau/nv04_render.c b/src/mesa/drivers/dri/nouveau/nv04_render.c
index b5943d9..371bed0 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_render.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_render.c
@@ -153,6 +153,110 @@ swtnl_points(GLcontext *ctx, GLuint first, GLuint last)
static void
swtnl_line(GLcontext *ctx, GLuint v1, GLuint v2)
{
+#if 1
+typedef unsigned int U032;
+
+typedef struct
+{
+ float ScreenX;
+ float ScreenY;
+ float ScreenZ;
+ float EyeM;
+ U032 Color;
+ U032 Specular;
+ float TextureS;
+ float TextureT;
+} NV_HW_Vertex;
+
+
+
+ GLfloat LineWidth;
+ GLfloat dx, dy, z, z1;
+ GLfloat x1,x2,y1,y2;
+ NV_HW_Vertex vertex_four[4];
+
+
+ GLfloat pos_tmp1[4]; /*x,y,z,w */
+ GLfloat pos_tmp2[4]; /*x,y,z,w */
+
+ LineWidth = ctx->Line.Width * 0.5F;
+
+ /*
+ * Get line extents.
+ */
+
+ x1 = ((float *) _tnl_get_vertex( ctx, v1 ))[0];
+ x2 = ((float *) _tnl_get_vertex( ctx, v2 ))[0];
+ y1 = ((float *) _tnl_get_vertex( ctx, v1 ))[1];
+ y2 = ((float *) _tnl_get_vertex( ctx, v2 ))[1];
+
+/*
+* Determine major and minor axis.
+*/
+
+ dx = x2 - x1; dy = y2 - y1;
+ if (fabs(dx) > fabs(dy))
+ {
+ dy = LineWidth;
+ dx = 0.0F;
+ }
+ else
+ {
+ dx = LineWidth;
+ dy = 0.0F;
+ }
+
+ // z = ((float *) _tnl_get_vertex( ctx, v1 ))[2] + ctx->LineOffset;
+
+
+/* Populate NV_HW_vertex */
+ vertex_four[0].ScreenX = x1 - dx;
+ vertex_four[0].ScreenY = y1 - dy;
+ vertex_four[0].ScreenZ = ((float *) _tnl_get_vertex( ctx, v1 ))[2];
+ vertex_four[0].EyeM = ((float *) _tnl_get_vertex( ctx, v1 ))[3];
+ vertex_four[0].Color = ((unsigned int *) _tnl_get_vertex( ctx, v1 ))[4];
+ vertex_four[0].Specular = ((unsigned int *) _tnl_get_vertex( ctx, v1 ))[5];
+ vertex_four[0].TextureS = ((float *) _tnl_get_vertex( ctx, v1 ))[6];
+ vertex_four[0].TextureT = ((float *) _tnl_get_vertex( ctx, v1 ))[7];
+
+ vertex_four[1].ScreenX = x1 + dx;
+ vertex_four[1].ScreenY = y1 + dy;
+ vertex_four[0].ScreenZ = ((float *) _tnl_get_vertex( ctx, v1 ))[2];
+ vertex_four[0].EyeM = ((float *) _tnl_get_vertex( ctx, v1 ))[3];
+ vertex_four[0].Color = ((unsigned int *) _tnl_get_vertex( ctx, v1 ))[4];
+ vertex_four[0].Specular = ((unsigned int *) _tnl_get_vertex( ctx, v1 ))[5];
+ vertex_four[0].TextureS = ((float *) _tnl_get_vertex( ctx, v1 ))[6];
+ vertex_four[0].TextureT = ((float *) _tnl_get_vertex( ctx, v1 ))[7];
+
+ vertex_four[2].ScreenX = x2 + dx;
+ vertex_four[2].ScreenY = y2 + dy;
+ vertex_four[0].ScreenZ = ((float *) _tnl_get_vertex( ctx, v2 ))[2];
+ vertex_four[0].EyeM = ((float *) _tnl_get_vertex( ctx, v2 ))[3];
+ vertex_four[0].Color = ((unsigned int *) _tnl_get_vertex( ctx, v2 ))[4];
+ vertex_four[0].Specular = ((unsigned int *) _tnl_get_vertex( ctx, v2 ))[5];
+ vertex_four[0].TextureS = ((float *) _tnl_get_vertex( ctx, v2 ))[6];
+ vertex_four[0].TextureT = ((float *) _tnl_get_vertex( ctx, v2 ))[7];
+
+ vertex_four[3].ScreenX = x2 - dx;
+ vertex_four[3].ScreenY = y2 - dy;
+ vertex_four[0].ScreenZ = ((float *) _tnl_get_vertex( ctx, v2 ))[2];
+ vertex_four[0].EyeM = ((float *) _tnl_get_vertex( ctx, v2 ))[3];
+ vertex_four[0].Color = ((unsigned int *) _tnl_get_vertex( ctx, v2 ))[4];
+ vertex_four[0].Specular = ((unsigned int *) _tnl_get_vertex( ctx, v2 ))[5];
+ vertex_four[0].TextureS = ((float *) _tnl_get_vertex( ctx, v2 ))[6];
+ vertex_four[0].TextureT = ((float *) _tnl_get_vertex( ctx, v2 ))[7];
+
+
+
+
+#endif
+ BEGIN_PRIMITIVE(4);
+ OUT_RINGp(chan, &vertex_four[0], vertex_len);
+ OUT_RINGp(chan, &vertex_four[1], vertex_len);
+ OUT_RINGp(chan, &vertex_four[2], vertex_len);
+ OUT_RINGp(chan, &vertex_four[3], vertex_len);
+ END_PRIMITIVE(0x320210);
+
}
static void
--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Probably, i monkeyed in wrong direction .....
В сообщении от Friday 05 March 2010 23:49:03 Stephane Marchesin написал(а):
> 2010/3/5 :
> > В сообщении от 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;iFrom c8b92b0f57113c6341decd504e97f97e1371dd82 Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu
Date: Sun, 7 Mar 2010 00:33:53 +
Subject: [PATCH] DANGEROUS rework primitive selection, add few optimized cases ported from old code. Only tested with trivial/tri!
---
src/mesa/drivers/dri/nouveau/nv04_context.c |3 +
src/mesa/drivers/dri/nouveau/nv04_context.h |3 +
src/mesa/drivers/dri/nouveau/nv04_render.c | 447 ++-
3 files changed, 440 insertions(+), 13 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nv04_context.c b/src/mesa/drivers/dri/nouveau/nv04_context.c
index f129417..40934b1 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_context.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_context.c
@@ -164,6 +164,8 @@ nv04_context_create(struct nouveau_screen *screen, const GLvisual *visual,
if (!nctx)
return NULL;
+
+ nctx->new_render_state = -1;
ctx = &nctx->base.base;
hw = &nctx->base.hw;
@@ -179,6 +181,7 @@ nv04_context_create(struct nouveau_screen *screen, const GLvisual *visual,
ctx->Const.MaxTextureUnits = NV04_TEXTURE_UNITS;
ctx->Const.MaxTextureMaxAnisotropy = 2;
ctx->Const.MaxTextureLodBias = 15;
+
/* 2D engine. */
ret = nv04_surface_init(ctx);
diff --git a/src/mesa/drivers/dri/nouveau/nv04_context.h b/src/mesa/drivers/dri/nouveau/nv04_context.h
index ccd3b61..ee0b2ba 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_context.h
+++ b/src/mesa/drivers/dri/nouveau/nv04_context.h
@@ -34,6 +34,9 @@ struct nv04_context {
struct nouveau_grobj *eng3d;
struct nouveau_surface dummy_texture;
float viewport[16];
+ GLuint new_state;
+ GLenum current_primitive;
+ GLuint new_render_state;
};
#define to_nv04_context(ctx) ((struct nv04_context *)(ctx))
diff --git a/src/mesa/drivers/dri/nouveau/nv04_render.c b/src/mesa/drivers/dri/nouveau/nv04_render.c
index b5943
[Mesa3d-dev] [PATCH] nouveau/nv04: GL_EXT_secondary_color (v2)
git apply has automatic whitespace fixup mode ..
From 4123a117eb53ba466a174ed0fbf53d9917adcae5 Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu
Date: Sun, 7 Mar 2010 18:22:15 +
Subject: [PATCH] nouveau/nv04: GL_EXT_secondary_color
(v2) applied with whitespace fixes. Still on top of enabled NV_blend_square
---
src/mesa/drivers/dri/nouveau/nouveau_context.c |2 ++
src/mesa/drivers/dri/nouveau/nv04_state_raster.c |8
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c b/src/mesa/drivers/dri/nouveau/nouveau_context.c
index 47ee9dc..7d695d4 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_context.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_context.c
@@ -43,6 +43,7 @@
#define need_GL_EXT_framebuffer_object
#define need_GL_EXT_fog_coord
+#define need_GL_EXT_secondary_color
#include "main/remap_helper.h"
@@ -56,6 +57,7 @@ static const struct dri_extension nouveau_extensions[] = {
{ "GL_EXT_framebuffer_object", GL_EXT_framebuffer_object_functions },
{ "GL_EXT_stencil_wrap", NULL },
{ "GL_EXT_fog_coord", GL_EXT_fog_coord_functions },
+ { "GL_EXT_secondary_color", GL_EXT_secondary_color_functions },
{ "GL_NV_blend_square", NULL },
{ "GL_SGIS_generate_mipmap", NULL },
{ NULL,NULL }
diff --git a/src/mesa/drivers/dri/nouveau/nv04_state_raster.c b/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
index 4314fc3..96ff022 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
@@ -275,6 +275,10 @@ nv04_emit_blend(GLcontext *ctx, int emit)
else
blend |= NV04_MULTITEX_TRIANGLE_BLEND_SHADE_MODE_FLAT;
+ /* Secondary color */
+ if (NEED_SECONDARY_COLOR (ctx))
+ blend |= NV04_MULTITEX_TRIANGLE_BLEND_SPECULAR_ENABLE;
+
/* Fog. */
if (ctx->Fog.Enabled)
blend |= NV04_MULTITEX_TRIANGLE_BLEND_FOG_ENABLE;
@@ -309,6 +313,10 @@ nv04_emit_blend(GLcontext *ctx, int emit)
else
blend |= get_texenv_mode(GL_MODULATE);
+ /* Secondary color */
+ if (NEED_SECONDARY_COLOR (ctx))
+ blend |= NV04_TEXTURED_TRIANGLE_BLEND_SPECULAR_ENABLE;
+
/* Fog. */
if (ctx->Fog.Enabled)
blend |= NV04_TEXTURED_TRIANGLE_BLEND_FOG_ENABLE;
--
1.6.5.4
--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again
On Sat, 06 Mar 2010 18:02:51 +0100 Stephan Raue 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=, > > 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=, 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=0xfdfc, > > 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 > > intel-...@lists.freedesktop.org > > 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 -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] nouveau/nv04: GL_EXT_secondary_color
Requres updated libdrm header (nouveau_class.h)
Tested with progs/demos/spectex and progs/tests/seccol
From 2b709f31c8ba35b1a40279203493baa8fa584e3f Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu
Date: Sun, 7 Mar 2010 01:09:21 +
Subject: [PATCH] nouveau/nv04: GL_EXT_secondary_color
---
src/mesa/drivers/dri/nouveau/nouveau_context.c |2 ++
src/mesa/drivers/dri/nouveau/nv04_state_raster.c | 14 +++---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c b/src/mesa/drivers/dri/nouveau/nouveau_context.c
index 47ee9dc..7d695d4 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_context.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_context.c
@@ -43,6 +43,7 @@
#define need_GL_EXT_framebuffer_object
#define need_GL_EXT_fog_coord
+#define need_GL_EXT_secondary_color
#include "main/remap_helper.h"
@@ -56,6 +57,7 @@ static const struct dri_extension nouveau_extensions[] = {
{ "GL_EXT_framebuffer_object", GL_EXT_framebuffer_object_functions },
{ "GL_EXT_stencil_wrap", NULL },
{ "GL_EXT_fog_coord", GL_EXT_fog_coord_functions },
+ { "GL_EXT_secondary_color", GL_EXT_secondary_color_functions },
{ "GL_NV_blend_square", NULL },
{ "GL_SGIS_generate_mipmap", NULL },
{ NULL,NULL }
diff --git a/src/mesa/drivers/dri/nouveau/nv04_state_raster.c b/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
index 4314fc3..d578783 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_state_raster.c
@@ -184,7 +184,7 @@ nv04_emit_control(GLcontext *ctx, int emit)
ctrl0 |= get_comparison_op(ctx->Color.AlphaFunc) << 8 |
FLOAT_TO_UBYTE(ctx->Color.AlphaRef);
-
+
/* Stencil test. */
if (ctx->Stencil.WriteMask[0])
ctrl0 |= NV04_MULTITEX_TRIANGLE_CONTROL0_STENCIL_WRITE;
@@ -274,7 +274,11 @@ nv04_emit_blend(GLcontext *ctx, int emit)
blend |= NV04_MULTITEX_TRIANGLE_BLEND_SHADE_MODE_GOURAUD;
else
blend |= NV04_MULTITEX_TRIANGLE_BLEND_SHADE_MODE_FLAT;
-
+
+ /* Secondary color */
+ if (NEED_SECONDARY_COLOR (ctx))
+ blend |= NV04_MULTITEX_TRIANGLE_BLEND_SPECULAR_ENABLE;
+
/* Fog. */
if (ctx->Fog.Enabled)
blend |= NV04_MULTITEX_TRIANGLE_BLEND_FOG_ENABLE;
@@ -302,12 +306,16 @@ nv04_emit_blend(GLcontext *ctx, int emit)
blend |= NV04_TEXTURED_TRIANGLE_BLEND_SHADE_MODE_GOURAUD;
else
blend |= NV04_TEXTURED_TRIANGLE_BLEND_SHADE_MODE_FLAT;
-
+
/* Texture environment. */
if (ctx->Texture._EnabledUnits)
blend |= get_texenv_mode(ctx->Texture.Unit[0].EnvMode);
else
blend |= get_texenv_mode(GL_MODULATE);
+
+ /* Secondary color */
+ if (NEED_SECONDARY_COLOR (ctx))
+ blend |= NV04_TEXTURED_TRIANGLE_BLEND_SPECULAR_ENABLE;
/* Fog. */
if (ctx->Fog.Enabled)
--
1.6.5.4
--
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again
On Sat, 6 Mar 2010 15:11:59 -0800 Jesse Barnes wrote: > 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 > i played a little with parallel debugging of glxgears and X ... i could manage it somewhat... one problem i had, was that after a while the screen-saver would disable my displays and then glxgears wouldnt hang anymore... (where to disable that?) the other problem i faced was, that i could happily step through the dispatch loop in the xserver and could also break in the dri2GetBuffersWithFormat, but i didn't know what to look at... what datastructures hold the xserver-side state of the client? hm.. i think i have to give that another go... cheers, Flo -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again
On Sun, 07 Mar 2010 00:24:24 +0200 Maxim Levitsky 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 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... -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again
Hi Jesse, Am 07.03.2010 00:11, schrieb Jesse Barnes: > 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. > > dont know if this help: strace output from Xorg (1.1MB): http://sources.openelec.tv/tmp/logfile/xbmc/Xorg.strace strace output from my Application (1.4MB): http://sources.openelec.tv/tmp/logfile/xbmc/xbmc.strace i have only strace and gdb installed for debugging, let me know if i need other programs for debugging. Stephan > Jesse > > On Sat, 06 Mar 2010 18:02:51 +0100 > Stephan Raue 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 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 wrote: >>> >>> >>> On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: > On Fri, 05 Mar 2010 23:18:07 +0200 > Maxim Levitsky wrote: > > > >> On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: >> >> >>> On Fri, 05 Mar 2010 22:42:21 +0200 >>> Maxim Levitsky 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 ru
Re: [Mesa3d-dev] gallium-winsys-handle-rebased branch
Dear Keith, I've tried out your gallium-winsys-handle-rebased branch.I downloaded it as a .tar.gz file instead of from git,as I couldn't download it that way.I compiled and installed it with the same ./configure options I use for Mesa git master,and I use the latest git versions of DRM,Linux-2.6/nouveau kernel modules,and the xf86-video-nouveau driver.I'm currently using Fedora 13,and my video card is: 01:00.0 VGA compatible controller: nVidia Corporation NV40 [GeForce 6800 GT] (rev a1) (prog-if 00 [VGA controller]) After a re-boot there didn't seem to be any ill effects. Regards, STEVE555 Keith Whitwell-3 wrote: > > This branch is hopefully ready for broader testing ahead of a merge. > > Can people, especially nv people, pull this down and try it out. Jakob > has made a best effort to get this right, but neither of us have > hardware. > > The branch itself is the start of a significant cleanup of some of the > uglier bits of gallium, particularly the integration with cross-process > shared surfaces, swapbuffers, etc. > > Keith > > > -- > 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 > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > > -- View this message in context: http://old.nabble.com/gallium-winsys-handle-rebased-branch-tp27781621p27811209.html Sent from the mesa3d-dev mailing list archive at Nabble.com. -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium cached bufmgr busy change
I think you are supposed to do this using the fenced bufmgr over cached along with a (ideally userspace) fencing mechanism. If you can implement pb_busy, you should be able to implement fence_signalled in exactly the same way (making the fence handle a pointer to buffers should work for this purpose, if standalone fences are hard to do). The fenced bufmgr will only pass destruction requests to the wrapped bufmgr once the fences are signalled. -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?
On 03/07/2010 01:00 AM, Ian Romanick wrote: > 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? I've run the piglit tests using tests/r500.tests, with glean in quick mode. With patch: 620/686 pass Without patch: 614/679 pass (I opened a bugreport about these failures here: https://bugs.freedesktop.org/show_bug.cgi?id=26933) The pbo tests results are: glean/pbo: fail general/pbo-teximage-tiling: pass general/pbo-read-argb: pass general/pbo-teximage-tiling-2: pass general/pbo-drawpixels: pass general/pbo-readpixels-small: pass general/object_purgeable-api-pbo: skip general/pbo-teximage: pass fbo/fbo-pbo-readpixels-small: pass The glean/fbo fail looks like some FP tolerance being too strict (1.0 vs 1.0). Is there a way to accept 1.0 for 1.0 in the piglit tests? pbo test: Test OpenGL Extension GL_ARB_pixel_buffer_object FAILURE: glGetPolygonStipple failed (at tpbo.cpp:1028) (1, 0) = [1.00, 1.00, 1.00], should be [1.0, 1.0, 1.0] pbo: NOTE perf[0] = 372.891 MB/s, which is in normal mode pbo: NOTE perf[1] = 261.088 MB/s, which is using PBO pbo: FAIL rgba8, db, z24, s8, win+pmap, id 33 9 tests passed, 1 tests failed. I've also run piglit w/o the patch applied, the pbo test were the only ones that changed to skip (except for glean/pbo which was pass due to extension not present). So the rest of the piglit tests are unaffected by this patch (they pass/fail the same way). > >> 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® 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again
On Sat, 2010-03-06 at 23:55 +0100, Florian Mickler wrote: > On Sun, 07 Mar 2010 00:24:24 +0200 > Maxim Levitsky 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 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... Note that I did try git master of linus tree, and that didn't help with the hang at all (now pulled it again, but don't see any changes in drm code) Best regards, Maxim Levisky -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
