Re: [Mesa3d-dev] Does DX9 SM3 - VMware svga with arbitrary semantics work? How?
On Tue, Mar 02, 2010 at 09:43:51PM +0100, Luca Barbieri wrote: - Not sure about i965 On i965 interpolators are not a dedicated piece of hardware, they're programs like the other shaders. So the problem is entirely different, and more at the level of space allocation in the thread-to-thread communication packets in the pipeline vs. register allocation in the shaders (there's a semi-direct mapping). OG. -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Searching for the Depth Buffer implementation
On Mon, Mar 01, 2010 at 08:22:37PM -0800, asimov01 wrote: I am trying to implement the openGL Readpixels for depth buffer in plain c++. I have tried to dig into openGL for this but I think this is protected and I think its done in hardware. I tried to look in mesa but can't seem to track it down. If anyone knows which file the mesa code is in please point me in the right direction, I would really appreciate it. I just need to see how mesa deals with this. Mesa includes both software and hardware renderers. For software, the readpixels implementation is in mesa/src/mesa/swrast/s_readpix.c and eventually calls read_depth_pixels. For hardware support it varies, grep for ReadPixels in mesa/src/mesa/drivers/dri/*/*.c I am actually also trying to find glViewPort implementation. I have the math that goes with it but again want to see how mesa has implemented it. mesa/src/main/viewport.c is probably what you're interested in. OG. -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium software fallback/draw command failure
On Mon, Mar 01, 2010 at 12:55:09PM +0100, Jerome Glisse wrote: So you don't like the pipe_context::validate() of Jose ? My taste goes to the pipe_context::validate() and having state tracker setting the proper flag according to the API they support (GL_OUT_OF_MEMORY for GL), this means just drop rendering command that we can't do. validate-then-do is a race condition waiting to happen. Validate is also a somewhat costly operation to do, and 99.999% of the time for nothing. You don't want to optimize for the error case, and that's what validate *is*. OG. -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium software fallback/draw command failure
On Mon, Mar 01, 2010 at 02:57:08PM +0100, Jerome Glisse wrote: validate function i have in mind as virtualy a zero cost (it will boil down to a bunch of add followed by a test) and what validate would do would be done by draw operation anyway. Not would, will. You have no way to be sure nothing changed between validate and draw, unless you're happy with an interface that will always be unusable for multithreading. So you'll do it twice for something that will always tell yes except once in a blue moon. And if you want to be sure that validate passes implies draw will work, it's often more than a bunch of adds. Allocations can fail even if the apparent free space is enough. See fragmentation and alignment, among others. Morality: reduce the number of operations in the normal (often called fast) path *first*, ask questions later. Trying to predict failures is both unreliable and costly. Xorg/mesa is perceived slow enough as it is. OG. -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium software fallback/draw command failure
On Mon, Mar 01, 2010 at 04:08:32PM +0100, Jerome Glisse wrote: Do you have solution/proposal/idea on how to handle the situation i am describing ? I've been looking at gallium from far away, but it seems to me you have two independant issues: - informing the caller of errors in atomic draw() calls - deciding what to do when the error is due to resource exhaustion For the first issue, if the api doesn't allow for returning errors, then the api is crap and has to be fixed. No two ways about it. For the second issue, you can have a generic way, a per-driver (call them state trackers if you want) specific way, both, or neither (also known as the fuck it solution). The generic way is to, when you get an out of whatever error, drop down to software in the caller. That requires having enough state available to be able to apply software to the specific operations in the first place. Potentially slow, but otoh all drivers would benefit from it. It would happen only on error, so outside of the fast path. The specific way is to handle all you can in the driver, for instance splitting as you proposed, and punt in error only if you really can't do anything accelerated. Both allows you in case of punting to still be able to do the requested render. Belt and suspenders :-) Neither just means ensuring errors go up all the way in the chain to the application. Personally I'd start by that, but that's just me. Ensure that the application has enough information, even if after-the-fact, to do its own tuning. A polygon not drawing silently is an atrocity to debug. An out of resources error is something obvious (debug-wise) you can throw money or code at. Having neither, i.e. correctness in error handling, does not prevent you to play with the generic or specific ways afterwards. But I suspect you'll find more interesting to work on enabling access to currently unavailable hardware features and tell people that if they want 16 8192^3 textures they can go full software explicitely or buy a card capable of it. Reasonableness has limits. OG. -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] move normalized texel coordinates bit to sampler view
On Thu, Feb 25, 2010 at 11:00:28AM -0700, Brian Paul wrote: We should also be thinking about texture array targets. With a 2D texture array, the S and T coords would be normalized, but not R. I think we either need new texture targets for RECT, 1D_ARRAY, 2D_ARRAY, etc. or per-dimension normalization flags. I'm thinking the former may be better (simpler) since textures are created as a particular type and not changed afterward. We also know the texture type/target when we execute TEX shader instructions. If it's part of sampler state it gives the impression that it's variable state, but it really isn't. The latter is probably unworkable because : - filtering is done only on the selected texture and not between elements of the array - mipmaps are per-selected texture, giving a very different layout than the dim+1 texture type Intel has different hardware types for say 2D_ARRAY vs. 3D, probably for these reasons. OG. -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 00/11] Kill various _mesa_* wrappers.
On Fri, Feb 19, 2010 at 11:30:44AM -0800, Ian Romanick wrote: I'd also like to see additional patches to eliminate: - _mesa_bzero - Conditionally wrap this if HAVE_BZERO is not defined. Do the usual autoconf magic to detect it. Let non-autoconf builds figure it out there own way. Shouldn't you just use memset instead? OG. -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 4/6] dri: Allow selective generation of accum. buffer configs
On Mon, Feb 08, 2010 at 05:09:58PM -0800, Ian Romanick wrote: From: Ian Romanick ian.d.roman...@intel.com Modify the interface to driCreateConfigs allowing drivers to not expose configs with an accumuation buffer. All of the drivers calling function have been updated to pass true for the accumulation selector. This maintains the current behavior. What's the gain? You don't (and probably won't) remove code, so that's just removing functionality for the sake of removing functionality. So what's the point, short of the current x11/glx visual concept is outdated and a capability request would be better? OG. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] light_twoside RE: [PATCH] glsl: put varyings in texcoord slots
On Tue, Feb 02, 2010 at 07:09:12PM +0100, Luca Barbieri wrote: Otherwise, we will need to recompile either of the shaders at link time, so that foo is assigned the same slot in both shaders, which is what we do now in GLSL linking, but is somewhat inefficient and in particular can lead to compilation time growing quadratically in the number of shaders, and slower shader switching. Slower shader switching is what caches are for. And if you have n VS and m FS, and a large subset of the n*m combinations (that's where your quadratic comes from, right?) are actually used, then it's rather obvious that inter-shader constant propagation and dead code removal is going to be a must. Incidentally, you can multiply by the number of geometry shaders while you're at it. As for link-by-name, it's pretty obvious it's going to become to norm and not the exception. Numbers are opaque, names aren't, and shaders are a bitch to write and debug. In addition color and texture coords is way too specific and is pretty sure to morph into int and float, or even float only, given HDR, and how easier it is hardware wise and shader compiler wise to just have large-n parallel float interpolation units. That with link-time shared types. So you'd better ensure your approach is ready for a more dynamic world where you can't decide a lot of things until link time. OG. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
On Mon, Jan 18, 2010 at 09:06:01PM +0100, Luca Barbieri wrote: As for REing the tables, it may not be possible. This is the code that apparently sets them up right now: /* vtxprog output routing */ so_method(so, screen-curie, 0x1fc4, 1); so_data (so, 0x06144321); so_method(so, screen-curie, 0x1fc8, 2); so_data (so, 0xedcba987); so_data (so, 0x0021); so_method(so, screen-curie, 0x1fd0, 1); so_data (so, 0x00171615); so_method(so, screen-curie, 0x1fd4, 1); so_data (so, 0x001b1a19); This makes me think that only 4 bits might be used for the values (look at the arithmetic progressions of 4-bit values), so that there is a limit of 16 vertex output/fragment inputs. Looking at the so_data values, 1fcx is 4 bits, 1fdx is 8 bits. It's also a little strange to have 24 slots for 16 possible values. If GLSL starts at index 10, we are still in trouble because less than 8 varyings will be available. Shader model 4 requires at least 32 interpolated values. Subsequent versions will want more and more. Any start index is going to blow up someday unless it's a very large value (which 10 isn't). OG. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] New state tracker API discussion
On Sun, Jan 17, 2010 at 10:24:47AM +0800, Chia-I Wu wrote: http://cgit.freedesktop.org/~olv/st_api/ I may be missing things, I'm new at that area of the system, but I noticed two things: - TEXTURE_1D missing ? - make_current seems to only expect one input and output texture/surface. Multitexturing (input) is the norm, and MRT (output) is becoming standard too. Isn't that an issue? OG. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
