Re: [Mesa-dev] About OpenGL QB stereo support..
> -Original Message- > From: mesa-dev-bounces+juan.j.zhao=intel@lists.freedesktop.org > [mailto:mesa-dev-bounces+juan.j.zhao=intel@lists.freedesktop.org] > On Behalf Of Corbin Simpson > Sent: Thursday, January 13, 2011 8:18 PM > To: rtfss none > Cc: mesa-dev@lists.freedesktop.org > Subject: Re: [Mesa-dev] About OpenGL QB stereo support.. > > On Wed, Jan 12, 2011 at 3:47 PM, rtfss none wrote: > > Hi, > > > > first sorry if not is the correct place to post it but I was thinking > > that with open source Sandy Bridge and AMD 68xx cards support that > > ship with Displayport 1.2 (AMD only) and HDMI1.4(both) connectors > > supporting > > 3d stereo output if could mesa developers expose support for it.. i.e. > > mesa ogl driver expose support for OGL QB stereo.. of course that > > perhaps should require changes to drm stack or both amd and intel > open > > source drivers to setup > > correct stereo frame packing output in this outputs.. that could add > > an advantage of open source drivers to propietary drivers which only > > expose ogl stereo support for professional cards.. and even then i > > think there is no currently support for ogl qb stereo support via > hdmi > > 1.4 nor in Nvidia and AMD worlds.. also this could be a good effort > to > > port all stereo madness to linux now that seem even MVC hardware > > decoding is supported on both Sandy Bridge and AMD 68xx cards.. that > > could be exposed via VAAPI for SandyBrige (I'm posting on libva dev > > list) or new OpenDecode AMD API which already exposes that support > > (currently Windows world only but some OCL developers have asked AMD > > to support also Linux).. > > DRI and GLX have all the correct support for GL_STEREO, but none of > the open drivers implement it as far as I know. This would probably be > a non-trivial thing to implement. > I don't think so. I read mesa's code and found that in dri_fill_in_modes, there is no operation to fill in the stereomode. > -- > When the facts change, I change my mind. What do you do, sir? ~ Keynes > > Corbin Simpson > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev --- *^_^* Many thanks & Best Regards Zhao Juan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 33071] xorg session stops due to 3d plotting
https://bugs.freedesktop.org/show_bug.cgi?id=33071 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Michel Dänzer 2011-01-14 00:51:12 PST --- *** This bug has been marked as a duplicate of bug 29184 *** -- 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 1/1] st/mesa: Set samplers views' first_level.
On 01/13/2011 03:55 AM, Henri Verbeet wrote: On 4 January 2011 22:05, Henri Verbeet wrote: Base level and min LOD aren't equivalent. In particular, min LOD has no effect on image array selection for magnification and non-mipmapped minification. --- src/mesa/state_tracker/st_atom_sampler.c |9 +++-- src/mesa/state_tracker/st_atom_texture.c |4 +++- 2 files changed, 6 insertions(+), 7 deletions(-) Did this get lost? Otherwise I'll probably push this sometime during the next few days. This isn't fresh in my head any more, but the code as-is matches the behaviour of NVIDIA's driver (and fixed a mipmap failure in a test somewhere). The mesa-demos/src/tests/mipmap_limits test is good for testing this. I applied your patch and now mipmap_limits no longer matches NVIDIA. I don't have time right now to dig into this. Does your patch fix something in particular? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/1] st/mesa: Set samplers views' first_level.
On 14 January 2011 16:49, Brian Paul wrote: > This isn't fresh in my head any more, but the code as-is matches the > behaviour of NVIDIA's driver (and fixed a mipmap failure in a test > somewhere). The mesa-demos/src/tests/mipmap_limits test is good for testing > this. > > I applied your patch and now mipmap_limits no longer matches NVIDIA. > Is that on any specific hardware / driver? I'll have a look at that demo to see what happens here. > I don't have time right now to dig into this. Does your patch fix something > in particular? > The specific bug it fixes is image array selection for linear filtered textures with Evergreen on r600g. (There's a Wine d3d9 test that ends up failing because of this, but it can be reproduced with a trivial GL program as well.) When mipmapping is disabled (i.e., with LINEAR or NEAREST filtering) min_lod / max_lod should be ignored, and the decision of what image to use should be based purely on the texture's base level. R600g behaves according to the spec in that regard, but because the state tracker currently always gives us 0 for first_level this means we always use level 0 for non-mipmapped textures. For what it's worth, the binary nvidia driver passes that test. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Common GL usage pattern where mesa/gallium is underperforming
On 01/13/2011 03:02 PM, Jerome Glisse wrote: Hi, This mail is mostly a remainder to myself and also a try to get someone to look into it before i myself got more time on this :) A common GLSL pattern is : glUseProgram(Program1); glActiveTexture(GL_TEXTURE0 + 0); glBindTexture(...); glActiveTexture(GL_TEXTURE0 + 1); glBindTexture(...); ... glUniform4fARB(...); ... glDraw() glUseProgram(Program2); glActiveTexture(GL_TEXTURE0 + 0); glBindTexture(...); glActiveTexture(GL_TEXTURE0 + 1); glBindTexture(...); ... glUniform4fARB(...); ... glDraw() Such usage pattern shouldn't trigger many computation inside mesa as we are not modifying texture object state or doing anythings fancy, it's just about switching btw GLSL program and textures. Which sounds like a very common pattern for any GL program that does somethings else than spinning gears :) I added glslstateschange to perf in mesa demos to test the performances in front of such usage pattern. Here is some results (core-i5 3Ghz, difference with closed driver are much worse with slower CPU) : noop105.0 thousand change/sec nouveau 13.0 thousand change/sec fglrx-nosmp 57.5 thousand change/sec fglrx 73.4 thousand change/sec nvidia-nosmp 158.8 thousand change/sec nvidia277.8 thousand change/sec All profiles/datas can be downloaded at http://people.freedesktop.org/~glisse/results/ Obviously the noop driver shows that we are severly underperforming as we are slower than the closed nvidia driver while performing no real rendering, and we don't outperform fglrx by that much. Profiling of the noop driver and also of nexuiz (which has similar pattern) shows a couple of guilty points. Biggest offender is the recreation of sampler each time a texture is bind. The update_samplers (st_atom_sampler.c) memset their is likely useless, but the true optimization is to build sampler state along with the sampler_view_state as the only variable that doesn't came from the texture object is the lod bias value (unless i missed somethings). So idea is to build sampler along sampler_view when a texture object is finalized and to update this sampler state in update_sampler only if the lod bias value change, this should avoid a lot of cso creation overhead and speedup driver. I am not sure why update_textures shows so much in profile, my guess is that pipe_sampler_view_reference is burning cpu cycle as we likely have a lot of texture unit. Texture state is also a big offender, mesa revalidate texture state& texture coordinate generation each time a new shader program is bound. Plan here is to compute a mask for (see update_texture_state main/texstate.c) _EnabledUnits _GenFlags _TexGenEnabled for each program (compute this mask from program information as it's constant with the program) and only recompute state if we see states changes in the masked unit (ie unit that affect the bound program). I will get back to this optimization latter (in couple weeks hopefully), but if you have more idea or if someone remember of an easy improvement that can help for this situations that would be welcome :) One of the root causes of this is the _NEW_TEXTURE flag is too broad. We should probably have separate flags for new per-texture parameters, new texture bindings, new texture env, etc. As it is now, if something as small as texture border color or lod bias is changed, we revalidate _all_ texture-related state. The gallium sampler state and views should probably be stored in the texture objects and not per-context to reduce construction of those states. It's great that you're looking at this. I'll just warn you that this area (state validation) is an easy place to introduce regressions. Hopefully changes can be made in logical steps that are easy to verify. Lots of testing should be done. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): i965: Remove unnecessary headers.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/13/2011 10:59 AM, Vinson Lee wrote: >> -Original Message- >> From: mesa-dev-bounces+vlee=vmware@lists.freedesktop.org [mailto:mesa- >> dev-bounces+vlee=vmware@lists.freedesktop.org] On Behalf Of Ian >> Romanick >> Sent: Thursday, January 13, 2011 10:43 AM >> To: mesa-dev@lists.freedesktop.org >> Subject: Re: [Mesa-dev] Mesa (master): i965: Remove unnecessary headers. >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 01/13/2011 09:29 AM, Vinson Lee wrote: >>> Module: Mesa >>> Branch: master >>> Commit: 1f6693033256123ec5cf6f186e5cfb1679e523d3 >>> URL: >> http://cgit.freedesktop.org/mesa/mesa/commit/?id=1f6693033256123ec5cf6f186 >> e5cfb1679e523d3 >>> >>> Author: Vinson Lee >>> Date: Thu Jan 13 09:28:47 2011 -0800 >>> >>> i965: Remove unnecessary headers. >> >> Does this actually provide any tangible benefit to anyone? All of the >> spurious header file frobbing has caused several irritations for me, at >> least: >> >> 1. Some commonly used things, like MIN2, MAX2, and ELEMENTS, have moved. >> This causes frustration when writing new code. >> >> 2. The changes cause massive invalidations of my compiler cache. As a >> result, my average build times are longer. I can only assume that the >> perceived benefit of all these changes is reduced build time. >> >> If there's no benefit, it just feels like spam. > > The purpose is to reduce build times and improve throughput in automated > testing. For everyone on a modern system with a caching compiler it is having the opposite effect. Optimizing the build for automated testing (as opposed to optimizing it for development) is the tail wagging the dog. Unless you're making other, *useful* changes to the files at the same time, stop making these kinds of changes. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0wlEUACgkQX1gOwKyEAw/CKgCgkBpMXD69QGnZmreKEhfuEPCZ zx0AnRJjVcabAs3acUTeiAl2IGjqC95d =0UGf -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): mesa: Simplify _mesa_base_fbo_format by making it exceptions to teximages.
On 01/14/2011 02:58 PM, Eric Anholt wrote: Module: Mesa Branch: master Commit: 65c41d55a06137115f0b4c67f9a3fd2708f0b625 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=65c41d55a06137115f0b4c67f9a3fd2708f0b625 Author: Eric Anholt Date: Thu Jan 13 10:05:50 2011 -0800 mesa: Simplify _mesa_base_fbo_format by making it exceptions to teximages. The comment of "this is just like teximages except for..." is a pretty good clue that we're handling this wrong. By just using the teximage code, we catch a bunch of cases we'd missed, like GL_RED and GL_RG. _mesa_base_fbo_format() also serves as an error checking function so that invalid internalFormat parameters to glRenderBufferStorage() are rejected. We need to reject compressed formats, index formats, dudv formats, ycbcr formats, etc. I think we lost that with your change. Maybe we need to pass a 'renderable' flag into the function so we can do the extra checking. If _mesa_base_tex_format() is going to be overloaded with FBO format checking, the comment on that function needs to be updated. Maybe even rename _mesa_base_tex_format() to _mesa_base_surface_format() or something like that to make it clear that it's not just used for texture internal formats. The original comment was correct- they're similar functions, but not the same. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): mesa: Add channel-wise copy propagation to ir_to_mesa.
On 01/14/2011 02:58 PM, Eric Anholt wrote:
Module: Mesa
Branch: master
Commit: 34a9da4eb4dd41dc874f1a175e993e42d4ff4b2a
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=34a9da4eb4dd41dc874f1a175e993e42d4ff4b2a
Author: Eric Anholt
Date: Wed Jan 12 18:25:33 2011 -0800
mesa: Add channel-wise copy propagation to ir_to_mesa.
This catches more opportunities than the prog_optimize.c code on
openarena's fixed function shaders turned to GLSL, mostly due to
looking at multiple source instructions for copy propagation
opportunities. It should also be much more CPU efficient than
prog_optimize.c's code.
---
src/mesa/program/ir_to_mesa.cpp | 129 +++
1 files changed, 129 insertions(+), 0 deletions(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index c601ef6..0d40b09 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -295,6 +295,8 @@ public:
bool process_move_condition(ir_rvalue *ir);
+ void copy_propagate(void);
+
void *mem_ctx;
};
@@ -2616,6 +2618,131 @@ set_uniform_initializers(struct gl_context *ctx,
talloc_free(mem_ctx);
}
+/*
+ * On a basic block basis, tracks available PROGRAM_TEMPORARY register
+ * channels for copy propagation and updates following instructions to
+ * use the original versions.
+ *
+ * The ir_to_mesa_visitor lazily produces code assuming that this pass
+ * will occur. As an example, a TXP production before this pass:
+ *
+ * 0: MOV TEMP[1], INPUT[4].xyyy;
+ * 1: MOV TEMP[1].w, INPUT[4].;
+ * 2: TXP TEMP[2], TEMP[1], texture[0], 2D;
+ *
+ * and after:
+ *
+ * 0: MOV TEMP[1], INPUT[4].xyyy;
+ * 1: MOV TEMP[1].w, INPUT[4].;
+ * 2: TXP TEMP[2], INPUT[4].xyyw, texture[0], 2D;
+ *
+ * which allows for dead code elimination on TEMP[1]'s writes.
+ */
+void
+ir_to_mesa_visitor::copy_propagate(void)
+{
+ ir_to_mesa_instruction *acp[this->next_temp * 4];
This does not compile with MSVC:
src\mesa\program\ir_to_mesa.cpp(2644) : error C2466: cannot allocate
an array of constant size 0
src\mesa\program\ir_to_mesa.cpp(2644) : error C2133: 'acp' : unknown size
src\mesa\program\ir_to_mesa.cpp(2646) : error C2070:
'ir_to_mesa_instruction *[]': illegal sizeof operand
src\mesa\program\ir_to_mesa.cpp(2709) : error C2070:
'ir_to_mesa_instruction *[]': illegal sizeof operand
src\mesa\program\ir_to_mesa.cpp(2718) : error C2070:
'ir_to_mesa_instruction *[]': illegal sizeof operand
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): mesa: Add channel-wise copy propagation to ir_to_mesa.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/14/2011 03:22 PM, Brian Paul wrote:
> On 01/14/2011 02:58 PM, Eric Anholt wrote:
>> +void
>> +ir_to_mesa_visitor::copy_propagate(void)
>> +{
>> + ir_to_mesa_instruction *acp[this->next_temp * 4];
>
> This does not compile with MSVC:
>
> src\mesa\program\ir_to_mesa.cpp(2644) : error C2466: cannot allocate an
> array of constant size 0
> src\mesa\program\ir_to_mesa.cpp(2644) : error C2133: 'acp' : unknown size
> src\mesa\program\ir_to_mesa.cpp(2646) : error C2070:
> 'ir_to_mesa_instruction *[]': illegal sizeof operand
> src\mesa\program\ir_to_mesa.cpp(2709) : error C2070:
> 'ir_to_mesa_instruction *[]': illegal sizeof operand
> src\mesa\program\ir_to_mesa.cpp(2718) : error C2070:
> 'ir_to_mesa_instruction *[]': illegal sizeof operand
Right. C89 and unextended C++ require that the size of an array be a
compile-time constant. GCC, G++, C99, C++0x (I'm pretty sure), and
clang relax this requirement. sigh...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0w374ACgkQX1gOwKyEAw/klgCfTGVqvxMvNHf5SBRJ92hMH1Df
VsIAoJAM/m8mg5EXqnYBbzJLgMEabwU4
=LmIv
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
