Re: [Mesa-dev] r600g/mesa/gallium performance, whois to blame ?
On Fri, 2010-11-12 at 20:32 -0800, Jerome Glisse wrote: > > I think r600c is just a bit too naive and so it end up being very > expensive to change any states with it. But i haven't took a closer > look. I don't think we should look too much at relative cost of > changing state. I think fglrx optimized the function call cost just > enough so that it didn't impact performances, while nvidia did go nuts > and over optimized function call overhead. Thus i think target should > be more about making sure core mesa + gallium with noop pipe driver > should be able to keep up at 500t draw call/sec when states change > occur (of course this could vary depending on which states change) and > not 173t call/sec. I think the idea of installing a noop pipe driver & using that to optimize everything else in the stack is a good one. It's true that the per-statechange overhead hasn't really had a lot of attention in the Mesa statetracker, and in particular there is a lot of work done every draw call to re-assemble all of the vertex buffers and vertex elements. A lot of that could be short-circuited with a little effort. Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gl_FragCoord / FBOs vs mesa/st
On Sun, 2010-11-14 at 20:18 -0800, Dave Airlie wrote:
> Eric just checked in a test into piglit that tests that the
> gl_FragCoord works the right way up for FBOs,
>
> Now all the gallium drivers fail this currently and fixing it creates
> an ugly linkage between the currently bound buffer and the fragment
> shader, since if you swap from an FBO to rendering to the front
> buffer, you need recompile the fragment shader to emit a proper wpos
> manipulation. Just wondering if anyone sees a nicer way to do this,
> than caching frag shaders with some sort of key in the state tracker,
> (which is pretty much what 965 has done.).
I guess the other possibility would be to have a couple of constants in
the constant buffer which get factored into the fragcood calculation in
such a way as to effect a flip based on their value, eg:
fc' = fc * const[0].x + const[0].y
where const[0] is either
-> {1, 0} for non-flipped
-> {-1, fb_height} for flipped
Keith
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gl_FragCoord / FBOs vs mesa/st
On Mon, 2010-11-15 at 01:28 -0800, Keith Whitwell wrote:
> On Sun, 2010-11-14 at 20:18 -0800, Dave Airlie wrote:
> > Eric just checked in a test into piglit that tests that the
> > gl_FragCoord works the right way up for FBOs,
> >
> > Now all the gallium drivers fail this currently and fixing it creates
> > an ugly linkage between the currently bound buffer and the fragment
> > shader, since if you swap from an FBO to rendering to the front
> > buffer, you need recompile the fragment shader to emit a proper wpos
> > manipulation. Just wondering if anyone sees a nicer way to do this,
> > than caching frag shaders with some sort of key in the state tracker,
> > (which is pretty much what 965 has done.).
>
> I guess the other possibility would be to have a couple of constants in
> the constant buffer which get factored into the fragcood calculation in
> such a way as to effect a flip based on their value, eg:
>
>fc' = fc * const[0].x + const[0].y
>
> where const[0] is either
> -> {1, 0} for non-flipped
> -> {-1, fb_height} for flipped
Another question is how to tell the pipe driver which of these to use --
probably we want an explicit flag in one of the state atoms
(rasterizer?) to select between the two possibilities?
Keith
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gl_FragCoord / FBOs vs mesa/st
On Mon, 2010-11-15 at 01:32 -0800, Keith Whitwell wrote:
> On Mon, 2010-11-15 at 01:28 -0800, Keith Whitwell wrote:
> > On Sun, 2010-11-14 at 20:18 -0800, Dave Airlie wrote:
> > > Eric just checked in a test into piglit that tests that the
> > > gl_FragCoord works the right way up for FBOs,
> > >
> > > Now all the gallium drivers fail this currently and fixing it creates
> > > an ugly linkage between the currently bound buffer and the fragment
> > > shader, since if you swap from an FBO to rendering to the front
> > > buffer, you need recompile the fragment shader to emit a proper wpos
> > > manipulation. Just wondering if anyone sees a nicer way to do this,
> > > than caching frag shaders with some sort of key in the state tracker,
> > > (which is pretty much what 965 has done.).
> >
> > I guess the other possibility would be to have a couple of constants in
> > the constant buffer which get factored into the fragcood calculation in
> > such a way as to effect a flip based on their value, eg:
> >
> >fc' = fc * const[0].x + const[0].y
> >
> > where const[0] is either
> > -> {1, 0} for non-flipped
> > -> {-1, fb_height} for flipped
>
> Another question is how to tell the pipe driver which of these to use --
> probably we want an explicit flag in one of the state atoms
> (rasterizer?) to select between the two possibilities?
...hmm need more coffee. Of course you'd do this at the state tracker
level (as you detailed) & the pipe drivers wouldn't need to think about
it...
Keith
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31630] New: [PATCH] egl: Add texture from pixmap example for GLES2.
https://bugs.freedesktop.org/show_bug.cgi?id=31630 Summary: [PATCH] egl: Add texture from pixmap example for GLES2. Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: enhancement Priority: medium Component: Demos AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: alexandros.frant...@linaro.org Created an attachment (id=40279) View: https://bugs.freedesktop.org/attachment.cgi?id=40279 Review: https://bugs.freedesktop.org/review?bug=31630&attachment=40279 Add texture from pixmap example for GLES2. This patch adds a texture-from-pixmap example for GLES2 (based on the existing example for GLES1.1). It also adds a matrix.c file that contains common matrix operations needed by GLES2 programs (and used by the texture_from_pixmap_glesv2 example). (The functions in matrix.c can also be used by es2gears, coming in another patch). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31630] [PATCH] egl: Add texture from pixmap example for GLES2.
https://bugs.freedesktop.org/show_bug.cgi?id=31630 Alexandros Frantzis changed: What|Removed |Added Attachment #40279|0 |1 is obsolete|| --- Comment #1 from Alexandros Frantzis 2010-11-15 03:52:25 PST --- Created an attachment (id=40282) View: https://bugs.freedesktop.org/attachment.cgi?id=40282 Review: https://bugs.freedesktop.org/review?bug=31630&attachment=40282 Add texture from pixmap example for GLES2 (version 2). Use normal sin(), cos() instead of GNU-specific sincos(). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Makefile: don't include the same files twice in the tarball
On 11/13/2010 07:05 AM, Julien Cristau wrote: src/mesa/drivers/dri/*/*/*.[chS] is a superset of src/mesa/drivers/dri/*/server/*.[ch] and src/mesa/drivers/dri/common/xmlpool/*.[ch]. include/GL/internal/glcore.h is already in MAIN_FILES, no need for it in DRI_FILES too. src/glx/Makefile was listed twice. Signed-off-by: Julien Cristau --- This patch is against 7.9, I haven't checked if master needs it too. See http://lists.debian.org/debian-x/2010/11/msg00556.html and http://lists.debian.org/debian-x/2010/11/msg00562.html for the rationale. Committed. Thanks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gl_FragCoord / FBOs vs mesa/st
On Mon, Nov 15, 2010 at 4:57 AM, Keith Whitwell wrote:
> On Mon, 2010-11-15 at 01:32 -0800, Keith Whitwell wrote:
>> On Mon, 2010-11-15 at 01:28 -0800, Keith Whitwell wrote:
>> > On Sun, 2010-11-14 at 20:18 -0800, Dave Airlie wrote:
>> > > Eric just checked in a test into piglit that tests that the
>> > > gl_FragCoord works the right way up for FBOs,
>> > >
>> > > Now all the gallium drivers fail this currently and fixing it creates
>> > > an ugly linkage between the currently bound buffer and the fragment
>> > > shader, since if you swap from an FBO to rendering to the front
>> > > buffer, you need recompile the fragment shader to emit a proper wpos
>> > > manipulation. Just wondering if anyone sees a nicer way to do this,
>> > > than caching frag shaders with some sort of key in the state tracker,
>> > > (which is pretty much what 965 has done.).
>> >
>> > I guess the other possibility would be to have a couple of constants in
>> > the constant buffer which get factored into the fragcood calculation in
>> > such a way as to effect a flip based on their value, eg:
>> >
>> > fc' = fc * const[0].x + const[0].y
>> >
>> > where const[0] is either
>> > -> {1, 0} for non-flipped
>> > -> {-1, fb_height} for flipped
>>
>> Another question is how to tell the pipe driver which of these to use --
>> probably we want an explicit flag in one of the state atoms
>> (rasterizer?) to select between the two possibilities?
>
> ...hmm need more coffee. Of course you'd do this at the state tracker
> level (as you detailed) & the pipe drivers wouldn't need to think about
> it...
FWIW, r6xx+ hw has a set of shader booleans (32 per shader type)
defined in registers for toggling chunks of code in your shaders, so
you could build a shader and constant buffer to handle multiple
situations, then just update the boolean values when you need to
change what chunk of code is required. I currently use this in the
EXA/Xv code in the ddx for handling several senarios in the same
shader.
Alex
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31568] [r300g] SIGSEGV src/mesa/vbo/vbo_exec_array.c:1154
https://bugs.freedesktop.org/show_bug.cgi?id=31568 --- Comment #2 from Brian Paul 2010-11-15 08:06:26 PST --- I can't reproduce this with any other driver. The piglit test in question doesn't call glMultiDrawElements() at all so I don't see how we'd wind up in that function unless something in API dispatch was broken. Nobody else has reported anything like that. Can you try a clean rebuild of Mesa, Vinson? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31569] [r300g] SIGSEGV src/mesa/main/api_loopback.c:1470
https://bugs.freedesktop.org/show_bug.cgi?id=31569 --- Comment #2 from Brian Paul 2010-11-15 08:11:46 PST --- This looks bogus too. Line 90 of provoking-vertex.c is a call to the glProvokingVertexEXT() function, not glVertexAttribI1uiv. Vinson, how are you building Mesa in this case? Maybe try a clean build, or a debug build and see what happens. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31544] bad format in _mesa_format_to_type_and_comps
https://bugs.freedesktop.org/show_bug.cgi?id=31544 --- Comment #21 from Brian Paul 2010-11-15 08:14:32 PST --- At this point I think my patch which set's the texImage->TexFormat field in r600SetTexBuffer2() is the right fix but now you're hitting another r600 bug. One of the r600 developers will probably have to help you with that. I'll commit the above patches for radeon/r600. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31544] bad format in _mesa_format_to_type_and_comps
https://bugs.freedesktop.org/show_bug.cgi?id=31544 --- Comment #22 from Alex Deucher 2010-11-15 08:21:11 PST --- (In reply to comment #21) > I'll commit the above patches for radeon/r600. Please patch r200 and r300 similarly. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31544] bad format in _mesa_format_to_type_and_comps
https://bugs.freedesktop.org/show_bug.cgi?id=31544 --- Comment #23 from Brian Paul 2010-11-15 08:27:45 PST --- (In reply to comment #22) > (In reply to comment #21) > > I'll commit the above patches for radeon/r600. > > Please patch r200 and r300 similarly. Yup, just did. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: Added a missing call to r600_bc_add_literal().
Signed-off-by: Tilman Sauerbeck --- This patch fixes a "literal not added correctly" error for Heroes of Newerth in the main menu. I don't fully understand the code; please review. src/gallium/drivers/r600/r600_shader.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/gallium/drivers/r600/r600_shader.c b/src/gallium/drivers/r600/r600_shader.c index f6153c0..501e4af 100644 --- a/src/gallium/drivers/r600/r600_shader.c +++ b/src/gallium/drivers/r600/r600_shader.c @@ -926,6 +926,11 @@ static int tgsi_split_constant(struct r600_shader_ctx *ctx, struct r600_bc_alu_s if (r) return r; } + + r = r600_bc_add_literal(ctx->bc, ctx->value); + if (r) + return r; + r600_src[i].sel = treg; r600_src[i].rel =0; j--; -- 1.7.3.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: Lower the minimum stride from 512 to 256 bytes to fix bug #31578.
piglit/fbo-readpixels still passes for me. Signed-off-by: Tilman Sauerbeck --- Please review. And someone please tell me where those 512 and 256 bytes are coming from :) src/gallium/drivers/r600/r600_texture.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/drivers/r600/r600_texture.c b/src/gallium/drivers/r600/r600_texture.c index e719f7f..d79f45c 100644 --- a/src/gallium/drivers/r600/r600_texture.c +++ b/src/gallium/drivers/r600/r600_texture.c @@ -171,7 +171,7 @@ static unsigned r600_texture_get_stride(struct pipe_screen *screen, stride = align(stride, 512); if (ptex->bind & PIPE_BIND_RENDER_TARGET) - stride = align(stride, 512); + stride = align(stride, 256); return stride; } -- 1.7.3.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: Lower the minimum stride from 512 to 256 bytes to fix bug #31578.
On Mon, Nov 15, 2010 at 4:41 PM, Tilman Sauerbeck wrote: > piglit/fbo-readpixels still passes for me. > > Signed-off-by: Tilman Sauerbeck > --- > > Please review. And someone please tell me where those 512 and 256 bytes > are coming from :) The alignment depends on the type of tiling in use (linear, 1d, 2d). See this drm patch for more info: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=fba4312e223f1187efc8c083daed70e57fa9c9d3 The info needed can be queried via the tiling info ioctl. Alex > > src/gallium/drivers/r600/r600_texture.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/gallium/drivers/r600/r600_texture.c > b/src/gallium/drivers/r600/r600_texture.c > index e719f7f..d79f45c 100644 > --- a/src/gallium/drivers/r600/r600_texture.c > +++ b/src/gallium/drivers/r600/r600_texture.c > @@ -171,7 +171,7 @@ static unsigned r600_texture_get_stride(struct > pipe_screen *screen, > stride = align(stride, 512); > > if (ptex->bind & PIPE_BIND_RENDER_TARGET) > - stride = align(stride, 512); > + stride = align(stride, 256); > > return stride; > } > -- > 1.7.3.1 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31643] New: Heroes of Newerth - Units and buildings (all animations) became invisible
https://bugs.freedesktop.org/show_bug.cgi?id=31643 Summary: Heroes of Newerth - Units and buildings (all animations) became invisible Product: Mesa Version: 7.9 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: ilconte...@libero.it Hello there I have the following issue. I passed from debian sid (mesa 7.7) to ubuntu 10.10 64bit (mesa 7.9dev) I own a Vaio TT with an integrated intel card. direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset GEM 20100330 DEVELOPMENT OpenGL version string: 2.1 Mesa 7.9-devel OpenGL shading language version string: 1.20 OpenGL extensions: GL_3DFX_texture_compression_FXT1, GL_APPLE_client_storage, 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) Linux teo-vaio 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:32:27 UTC 2010 x86_64 GNU/Linux Here a photo of the bug to clearly show that all the animations became invisible: http://i55.tinypic.com/ofu5qe.png I never had any issues since the game went out, so I guess there has been a regression or a bug in the latest versions of mesa (also the 7.10 git has the same issue). I already tried to reinstall ubuntu, reinstall the game, update the kernel, the intel driver and mesa to the latest version available, all without success. I hope you can understand what this bug is. Regards -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
