Re: [Mesa3d-dev] ARB draw buffers + texenv program
On Tue, Apr 13, 2010 at 2:21 PM, Corbin Simpson
mostawesomed...@gmail.com wrote:
On Tue, Apr 13, 2010 at 6:42 AM, Roland Scheidegger srol...@vmware.com
wrote:
On 13.04.2010 02:52, Dave Airlie wrote:
On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul bri...@vmware.com wrote:
Dave Airlie wrote:
Just going down the r300g piglit failures and noticed fbo-drawbuffers
failed, I've no idea
if this passes on Intel hw, but it appears the texenvprogram really
needs to understand the
draw buffers. The attached patch fixes it here for me on r300g anyone
want to test this on Intel
with the piglit test before/after?
The piglit test passes as-is with Mesa/swrast and NVIDIA.
It fails with gallium/softpipe both with and w/out your patch.
I think that your patch is on the right track. But multiple render targets
are still a bit of an untested area in the st/mesa code.
One thing: the patch introduces a dependency on buffer state in the
texenvprogram code so in state.c we should check for the _NEW_BUFFERS flag.
Otherwise, I'd like to debug the softpipe failure a bit further to see
what's going on. Perhaps you could hold off on committing this for a
bit...
Well Eric pointed out to me the fun line in the spec
(3) Should gl_FragColor be aliased to gl_FragData[0]?
RESOLUTION: No. A shader should write either gl_FragColor, or
gl_FragData[n], but not both.
Writing to gl_FragColor will write to all draw buffers specified
with DrawBuffersARB.
So I was really just masking the issue with this. From what I can see
softpipe messes up and I'm not sure where we should be fixing this.
swrast does okay, its just whether we should be doing something in gallium
or in the drivers is open.
Hmm yes looks like that's not really well defined. I guess there are
several options here:
1) don't do anything at the state tracker level, and assume that if a
fragment shader only writes to color 0 but has several color buffers
bound the color is meant to go to all outputs. Looks like that's what
nv50 is doing today. If a shader writes to FragData[0] but not others,
in gallium that would mean that output still gets replicated to all
outputs, but since the spec says unwritten outputs are undefined that
would be just fine (for OpenGL - not sure about other APIs).
2) Use some explicit means to distinguish FragData[] from FragColor in
gallium. For instance, could use different semantic name (like
TGSI_SEMANTIC_COLOR and TGSI_SEMANTIC_GENERIC for the respective
outputs). Or could have a flag somewhere (not quite sure where) saying
if color output is to be replicated to all buffers.
3) Translate away the single color output in state tracker to multiple
outputs.
I don't like option 3) though. Means we need to recompile if the
attached buffers change. Moreover, it seems both new nvidia and AMD
chips (r600 has MULTIWRITE_ENABLE bit) handle this just fine in hw.
I don't like option 1) neither, that kind of implicit behavior might be
ok but this kind of guesswork isn't very nice imho.
Whatever's easiest, just document it. I'd be cool with:
DECL IN[0], COLOR, PERSPECTIVE
DECL OUT[0], COLOR
MOV OUT[0], IN[0]
END
Effectively being a write to all color buffers, however, this one from
progs/tests/drawbuffers:
DCL IN[0], COLOR, LINEAR
DCL OUT[0], COLOR
DCL OUT[1], COLOR[1]
IMM FLT32 { 1., 0., 0., 0. }
0: MOV OUT[0], IN[0]
1: SUB OUT[1], IMM[0]., IN[0]
2: END
Would then double-write the second color buffer. Unpleasant. Language
like this would work, I suppose?
If only one color output is declared, writes to the color output shall
be redirected to all bound color buffers. Otherwise, color outputs
shall be bound to their specific color buffer.
Also, keep in mind that writing to multiple color buffers uses
additional memory bandwidth, so for performance, we should only do so
when required.
Alex
--
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 lists to freedesktop.org?
On Thu, Apr 8, 2010 at 6:21 PM, Brian Paul bri...@vmware.com wrote: Unless there's some objection I'm going to subscribe everyone to the new FD.O-based mesa-dev mailing list who's on the mesa3d-dev list. Probably in the next 24 hours. Then, some of you may have to log into the mailman interface (http://lists.freedesktop.org/mailman/listinfo/mesa-dev) to set digest mode, etc. -Brian Are there plans to move dri-devel as well? Alex -- 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] Correct GL_EQUIV code in r67/7xx.
On Sun, Mar 14, 2010 at 9:18 PM, Matthew W. S. Bell matt...@bells23.org.uk wrote: From 247e121106e8d3e389f2e5a6edf13ea70ac18df7 Mon Sep 17 00:00:00 2001 These seem to be documented in http://www.svgopen.org/2003/papers/RasterOperationsUsingFilterElements/index.html. --- src/mesa/drivers/dri/r600/r700_state.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/r600/r700_state.c b/src/mesa/drivers/dri/r600/r700_state.c index 6f156b5..12eaebb 100644 --- a/src/mesa/drivers/dri/r600/r700_state.c +++ b/src/mesa/drivers/dri/r600/r700_state.c @@ -614,7 +614,7 @@ static GLuint translate_logicop(GLenum logicop) case GL_XOR: return 0x66; case GL_EQUIV: - return 0xaa; + return 0x99; case GL_AND_REVERSE: return 0x44; case GL_AND_INVERTED: -- 1.7.0 Thanks, pushed. Alex -- 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] r600 pixel_buffer_object for 7.8?
2010/3/7 Ian Romanick i...@freedesktop.org: -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). Ok, I've gone ahead and enabled the extension in the 7.8 branch. Alex 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#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 -- 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] r600 pixel_buffer_object for 7.8?
2010/3/6 Corbin Simpson mostawesomed...@gmail.com: HoN needs PBOs? How annoying. I'll pull in the patch if nobody else says anything, but I'd much prefer that Alex or somebody else more familiar with r600 do it. Is that patch all that's needed for pbos? I was under the impression there was more work involved, but I haven't really had a chance to look into it further. Alex ~ C. 2010/3/6 Török Edwin edwinto...@gmail.com: Hi Andre, I've been using your patch that enables pbo on r600: http://cgit.freedesktop.org/~andrem/mesa/commit/?h=r600-testid=6ee755760d124c85bdfd121fd491f68fccca84f7 Are you considering enabling it in Mesa 7.8? Some games won't even start without pbo support (for example Heroes of Newerth). Even if gameplay isn't perfect (there are some rendering artifacts[1], and some effects are slow [2]) at least the game starts with that patch. [1] which is not related to your pbo patch, I see artifacts w/o it too in other games, and blender: https://bugs.freedesktop.org/show_bug.cgi?id=26735 [2] which can be turned off, like refraction Best regards, --Edwin -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com -- 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 -- 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 lists to freedesktop.org?
On Thu, Mar 4, 2010 at 3:37 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: Would anyone have objections if these lists moved to freedesktop.org? Yes please! The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. -- Jesse Barnes, Intel Open Source Technology Center -- 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 -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- 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 12:39 PM, michal mic...@vmware.com wrote: Roland Scheidegger wrote on 2010-02-24 15:18: On 24.02.2010 12:48, Christoph Bumiller wrote: This wasn't a problem before because textures and samplers were linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch, this coordinate normalization bit becomes a problem. NV50 hardware has that bit in the RESOURCE binding, and not the SAMPLER binding, and you can imagine that this will lead to us having to jump through a few annoying looking hoops to accomodate. As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have sampler states that are decoupled from the texture, and which contain a normalized coordinates bit, so it's worth considering not having it there in gallium either. For OpenGL, unnormalized coordinates are only used for RECT textures, and in this case it makes sense to make it a property of the texture. I agree this is not sampler state, but I don't quite agree this should be texture state. This changes how texture coordinates get interpreted in the interpolator - in that sense it is similar to the cylindrical texture coord wrap which we moved away from sampler state recently. This one got moved to shader declaration. I wonder if the normalization bit should be treated the same. Though OTOH you're quite right that in OpenGL this really is texture property (it is a different texture target after all), and afaik d3d doesn't support non-normalized coords (?). Hmm... Isn't it the case that for RECT targets we clear the bit, and for others we always set it? In mesa st I see: if (texobj-Target != GL_TEXTURE_RECTANGLE_ARB) sampler-normalized_coords = 1; By definition, RECT texture with normalised coordinates is just an NPOT. If we removed this apparently redundant flag, would that make nouveau developers life easier? FWIW, r3xx-r5xx always requires normalized coords, the normalization is currently done in the shader. On r6xx+, you can specify normalized or non-normalized coords in the tex instructions. Alex And, finally, I've seen you reverted the changes for independent image and sampler index in the texture opcodes. What's up with that ? Is the code not nice enough, or has the idea been discarded and by problem disappears ? Please consider this branch dead. It will be easier for me to introduce new, optional sampler and fetch opcodes a'la GL 3.0. There's just too much code to fix and test and we still want the older hardware not to stand on its head to try and translate back to old model. Thanks. -- 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 -- 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] light_twoside RE: [PATCH] glsl: put varyings in texcoord slots
On Wed, Feb 3, 2010 at 4:42 AM, Luca Barbieri l...@luca-barbieri.com wrote: I tested this on Windows, using nVidia driver 195 on nv40, and it seems we are all partially wrong. SM3 does indeed allow semantics unrelated to hardware resources. However, the semantic indices for any semantic type must be in the range 0-15, or D3DX will report a compiler error during shader compilation: error X2000: syntax error : unexpected token 'dcl_texcoord16' This is further confirmed by the following lines in d3d9types.h: #define MAXD3DDECLUSAGE D3DDECLUSAGE_SAMPLE #define MAXD3DDECLUSAGEINDEX 15 I would guess that these two 4-bit values are combined into an 8-bit value that is then passed directly to hardware like r600 which supports 8-bit semantic indices in hardware. Is this the case on Radeon? Is the 8-bit semantic table a feature of r300 too or only of r600+? Only r600+. r3xx-r5xx is more basic. You basically set up a table based on the inputs and outputs. Order doesn't matter as long as the table is correct for the vs and ps you are using. See pages 258-261 for the vertex fetch setup and pages 197-199 for the vs to ps routing of the r5xx accel guide: http://www.x.org/docs/AMD/R5xx_Acceleration_v1.4.pdf Alex In light of this, it may make sense to do some range limitation ourselves too. In particular, a good plan could be limiting all semantic indices to 0-15, except GENERIC, which could support a 0-127 range. This would allow to both directly take advantage of Radeon hardware, and let drivers that need to remap in software do so with direct lookup in a small array. -- 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 2, 2010 at 1:16 PM, Luca Barbieri l...@luca-barbieri.com wrote: Personally I'm going to take a break from this thread, spend a couple of days looking at i965, etc, to see what can be done to improve things there, and maybe come back with an alternate proposal. Yes, I think that the most important step is to precisely determine how both hardware (and especially the newer cards you mentioned) works and how shader APIs (especially DirectX) are defined. On AMD r6xx and newer asics, the hardware provides 8 bit semantic ids that are used for vertex fetches and shader to shader routing. See: http://www.x.org/docs/AMD/R6xx_R7xx_3D.pdf pages 10-11, 16-17 The driver can define the ids to whatever it wants and then data will be routed based on those ids. E.g., #define POSITION 1 #define COLOR0 2 #define TEXCOORD0 3 etc. then in your fetch shader: vfetch POSITION vfetch TEXCOORD0 vfetch COLOR0 and in your vs output: export COLOR0 export TEXCOORD0 export POSITION and in your ps inputs: input TEXCOORD0 input COLOR0 etc. The ordering doesn't matter all routing is done by semantic id. There's no need to recompile your vertex shaders or pixel shaders, you just adjust the fetch shader and sematic exports/imports state accordingly. The current r600 classic mesa driver just uses a hardcoded mapping right now, but it would make sense to use semantic ids in the gallium driver. Alex Once the workings of both are known and agreed upon, the best solution should be hopefully be clear. In addition to looking at hardware such as i965, it would be awesome to find some clear and unambiguous documentation on DirectX shader semantics. and agree on its interpretation. -- 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 -- 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 Fri, Jan 29, 2010 at 12:31 PM, Brian Paul brian.e.p...@gmail.com wrote: On Fri, Jan 29, 2010 at 9:49 AM, Brian Paul brian.e.p...@gmail.com wrote: On Fri, Jan 29, 2010 at 12:48 AM, Luca Barbieri l...@luca-barbieri.com wrote: I'd like to have some more definitive review comments on this patch (sending to Brian and Keith for this). Right now GLSL is the *only* Gallium user that does not use sequential indexes starting from 0 for vertex shader outputs and fragment shader inputs. This causes problems for some drivers such as nv30/nv40 that don't remap the indexes right now. This can be addressed in two ways: 1. Don't require Gallium users to use sequential indices, and require vertex shader inputs and fragment shader outputs to match perfectly 2. Don't require Gallium users to use sequential indices, and change nv30/nv40 and possibly other drivers to remap indices 3. Fix the only problematic user, GLSL, to use sequential indices (1) will break the Mesa state tracker in a very hard to fix way. (2) is complex and means that nv30/nv40 and maybe other drivers can no longer compile vertex and fragment shaders independently. (3) is a simple fix, provided by this patch. I feel that (3), implemented by this patch, is the best solution, since driver simplicity is one of the Gallium design goals, and I don't see any significant advantages in supporting discontiguous vertex shader output / fragment shader input values. OpenGL and DirectX 9/10 don't seem to allow arbitrary numbers for vertex shader outputs and fragment shader inputs, and instead require 0-7, 0-15 or 0-31 depending on feature level. If this is wrong, please correct me. I propose that Gallium should also require 0-x indices and not arbitrary values. Thus, GLSL should be fixed to respect that. Note that this change cannot be done in the state tracker because it requires to see both the fragment and vertex shaders at once, which only happens in the GLSL linker. Thus, while the change has been discussed with Gallium in mind, it is done at the Mesa program level, and it actually results in Mesa programs with contiguous indices. This also potentially benefits non-Gallium drivers. What do you think? Luca, I'm OK with this change in principle but I need a bit more time to review the problem and your patch... Luca, Let me make sure I understand the problem here. Are you specifically concerned about the GENERIC[x] semantic labels/indexes that are attached to VS outputs and FS inputs? I hacked a Mesa GLSL demo to use texcoords and varying vars and saw something like this: VERT DCL IN[0] DCL OUT[0], POSITION DCL OUT[1], GENERIC[0] DCL OUT[2], GENERIC[10] ... FRAG DCL IN[0], GENERIC[0], PERSPECTIVE DCL IN[1], GENERIC[10], PERSPECTIVE DCL OUT[0], COLOR ... We use the semantic names/labels GENERIC[0] and GENERIC[10] but note that the actual inputs/outputs are in consecutive slots. This is as intended. The semantic indexes are used to match up inputs/outputs logically but they should not effect which hardware interpolation slots are used. FWIW, I think DX10 required or at least encouraged semantic mapping support in hardware. R6xx+ radeons support this and r3xx-r5xx hardware do to a lesser degree. You can use arbitrary, driver specific ids and the hardware will match up inputs and outputs based on those ids. Alex Prior to Keith's commit 07fafc7c9346aa260829603bf3188596481e9e62 the generic semantic indexes were consecutive, BTW. -Brian -- 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 -- 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 Fri, Jan 29, 2010 at 12:55 PM, Luca Barbieri l...@luca-barbieri.com wrote: FWIW, I think DX10 required or at least encouraged semantic mapping support in hardware. R6xx+ radeons support this and r3xx-r5xx hardware do to a lesser degree. You can use arbitrary, driver specific ids and the hardware will match up inputs and outputs based on those ids. Can you provide a reference to the DX10 API for doing that? I'm not very familiar with DX10, and a quick search on MSDN didn't turn anything relevant. I'm not sure off hand. That's the answer I got internally as to why we have semantic mapping support in hw. Alex Does the VMWare DirectX state tracker use non-sequential semantic indices in the implementation of such a feature? -- 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] perrtblend merge
On Tue, Jan 26, 2010 at 11:03 AM, Roland Scheidegger srol...@vmware.com wrote: Oh, I should have added the PIPE_CAP bits (even if not supported) to all drivers. Good catch. I'll do that for the other drivers now. Roland (btw, I think r500 could do separate colormasks, but not separate blend enables, and there might be more hardware like that. However, this is not exposed by GL, it might be supported by some DX9 cap bit, but it didn't seem worthwile to add a separate gallium cap bit for supporting per-rt blend enables and colormasks, respectively.) Seems fine. It would be easy to add later if the need arises. Alex On 26.01.2010 16:37, Corbin Simpson wrote: Yeah, r300 doesn't but r600 does. I've read through the branch, and the r300g patch looks perfect. I've pushed another patch on top for the pipe caps, to avoid post-merge cleanups for myself. On Tue, Jan 26, 2010 at 7:00 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Jan 26, 2010 at 9:44 AM, Roland Scheidegger srol...@vmware.com wrote: Hi, I'm planning on merging this branch to master soon. This will make it possible to do per render target blend enables, colormasks, and also per rendertarget blend funcs (with a different CAP bit for the latter, and this one isn't actually used in mesa state tracker yet). None of the drivers other than softpipe implement any of it, but they were adapted to the interface changes so should continue to run. Apparently, that functionality is only interesting for drivers supporting multiple render targets, and the hw probably needs to be quite new (I know that i965 could support it (well not the multiple blend funcs but the rest), but the driver currently only supports 1 render target). FWIW, AMD R6xx+ hw supports MRTs and per-MRT blends as well, although at the moment the driver also only supports 1 RT. Alex -- 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 -- 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] mesa_7_7_branch - master merges
On Mon, Jan 25, 2010 at 12:17 PM, Eric Anholt e...@anholt.net wrote: On Mon, 25 Jan 2010 13:04:10 +, José Fonseca jfons...@vmware.com wrote: mesa_7_7_branch and master are becoming quite different, because of all the gallium interface changes that have been going into master, so merging fixes from mesa_7_7_branch into master is becoming less and less of a trivial exercise. This is aggravated by the fact we are basing a release from the mesa_7_7_branch, so it's likely that we'll need to have temporary non-invasive bugfixes that should not go into master (which should receive instead the proper and potentially invasive fix). I see a few alternatives here: a) stop merging mesa_7_7_branch - master. bugfixes should be applied to both branches. preferably by the person that wrote the patch. This, please. I still hate the merge stable - master plan, because it means that the drivers of people other than the one doing the merge gets broken. I would prefer this as well. Alex -- 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 10:52 AM, Marek Olšák mar...@gmail.com wrote: On Mon, Jan 18, 2010 at 3:22 PM, Luca Barbieri l...@luca-barbieri.com wrote: I think this is not necessary and fixing the rasterizer setup in the driver would by better than fixing the state tracker. In r300g, we dynamically allocate rasterizer units based on vertex shader outputs. If the vertex shader uses slots 1, 5, 20, 100, the driver maps them to units 1,2,3,4. But what if the fragment shader has inputs 1, 2, 5, 20, 100? If you remap the fragment shader to 1, 2, 3, 4, 5, then they will mismatch. You would need to either: 1. Generate shaders in the driver for the fragment/vertex combination instead of each one separately 2. Require that vertex shader outputs match fragment shader inputs exactly (1) makes the driver much more complex and slow. I think we should try to make it possible to avoid this, unless the hardware absolutely requires it. (2) will probably break the existing fixed pipeline and ARB_fp/vp support, and also make the driver more complex than necessary. Does r300g compile both fragment and vertex shader together? Also note that all Gallium-capable hardware should support 8 varying slots, so anything that uses only texture coordinates should not need any remapping. I was talking about the rasterizer (interpolator) units, which, on r300, are quite flexible and can read an arbitrary vertex shader output and write it to an arbitrary fragment shader input (= register address). Given this flexibility, fragment and vertex shaders are compiled separately in r300g and semantic indices don't matter, just the total number of varyings. I think DX9 required this flexibility when mapping VS to PS, so it's likely most DX9 hw supports this. Alex -- 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] Mystery of u_format.csv
2010/1/6 Michel Dänzer mic...@daenzer.net: On Wed, 2010-01-06 at 15:18 +, Keith Whitwell wrote: On Wed, 2010-01-06 at 07:13 -0800, José Fonseca wrote: On Wed, 2010-01-06 at 06:51 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:32 +, José Fonseca wrote: On Wed, 2010-01-06 at 06:23 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:03 +, José Fonseca wrote: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM , arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM , arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM , arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM , arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM , arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM , arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Actually, 'array' formats should be endianness neutral, Yep. and IMO 'arith' formats should be defined in the CPU endianness. I originally thought that too, but Keith convinced me that gallium is a hardware abstraction, and all 3d hardware is little endian, therefore gallium formats should be always in little endian. Then there probably should be no 'arith' formats, at least not when the components consist of an integer number of bytes. Yes, that's probably the best. Though as discussed before, having 'reversed' formats defined in the other endianness as well might be useful. Drivers which can work on setups where the CPU endianness doesn't match the GPU endianness should possibly only use 'array' formats, but then there might need to be some kind of mapping between the two kinds of formats somewhere, maybe in the state trackers or an auxiliary module... Basically a developer implementing a pipe drivers for a hardware should not have to worry about CPU endianness. If a graphics API define formats in terms of the native CPU endianness then the state tracker will have to do the translation. That's more or less what I meant in my last sentence above. Hopefully it'll be possible to share this between state trackers at least to some degree via an auxiliary module or so. At least OpenGL and X11 define (some)
Re: [Mesa3d-dev] Yet more r300g fear and loathing...
On Mon, Dec 21, 2009 at 12:49 PM, tom fogal tfo...@alumni.unh.edu wrote: Corbin Simpson mostawesomed...@gmail.com writes: So, yet another thing that r300 sucks balls at: NPOT textures. We've been talking it over on IRC, and here's the options. 1) Don't do NPOT. Stop advertising PIPE_CAP_NPOT, refuse to accept non-NPOT dimensions on textures. This sucks because it means that we don't get GL 2.0, which means most apps (bless their non-compliant souls) will refuse to attempt GLSL, which means that there's really no point in continuing this driver. What's the performance of NPOT when implemented in the driver? I work on real-time visualization apps; the one in particular I'm thinking of does texture sampling of potentially-NPOT textures via GLSL. If sampling a NPOT texture is not going to run in hardware, the app is useless. Further, our app keeps track of the amount of GL memory allocated for textures, FBOs and the like. If a texture is going to be silently extended, that messes with our management routines [1]. The hardware supports rectangular texture sampling. What's missing is support for certain wrap modes and mipmaps with npot textures. Neither of which are used that often. Alex We don't have the resources to maintain a card database of this card with this driver advertises X but implements it in software, though such a thing is desperately needed. It would be much easier for us if advertising X means we implement it in HW. Incorrect reporting of NPOT in particular is so prevalent that we have a settings dialog that allows a user to force power of two textures, causing us to silently extend our textures before uploading them. Many of our users don't even know what a GPU is. What else can we do, though? Anyway, all that said, if performance suffers in any way I vote for not advertising the extension or GL 2.0. If an application is broken, an application is broken. Maybe add a debug statement so that the application author can figure out what they've done wrong, should they ever find the desire to fix their code. I realize this is getting beyond the scope of your inquiry. GL really needs a query that allows an application developer to figure out if a feature is accelerated by the hardware or not. Since it lacks this, the advertising of extensions is just about the only thing we, as app developers, can use as a heuristic. -tom [1] ... maybe this isn't such a big deal. GL's memory management is lame/opaque and as such we haven't found a way to utilize this information usefully, yet. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa Radeon Compile Problem
On Sat, Dec 5, 2009 at 6:18 PM, Mike Lothian m...@fireburn.co.uk wrote: Hi I had a compile error with the latest git mesa The error is: x86_64-pc-linux-gnu-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 -march=native -O2 -pipe -w -ffast-math -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_LIBDRM_RADEON=1 -I/usr/include/drm -DRADEON_R100 -Wall radeon_texstate.c -o radeon_texstate.o radeon_texstate.c: In function 'radeonSetTexBuffer2': radeon_texstate.c:675: error: too few arguments to function 'radeon_update_renderbuffers' Reverting 433f0a82f5a4696e6b0c4061f645485ec8079bb4 seems to fix it for me Already fixed. Alex -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r600/r700 compiler future?
On Sat, Nov 28, 2009 at 5:36 AM, Pierre Ossman pierre-l...@ossman.eu wrote: I'm sorry this reply is so late. I completely forgot about this thread... On Mon, 2 Nov 2009 10:35:16 -0500 Li, RichardZ richardz...@amd.com wrote: Yes, you are right. When the compiler code was put there, as Alex said, we hope to get everything worked. Certainly emit alu instruction based on write-mask is the must-do tune up for current compiler. We are preparing compiling capability for r6/r7 driver for mesa glsl IL to hw instructions. Originally I hoped could tune up compiler after it. Surely any optimizations are welcome, especially this one. I hope current code is only a start point for us to make its graphics run better together. :-) Getting things working first, and then getting them fast is definitely the right approach. I think everyone is familiar with the evils of premature optimisations. :) That said, I think we need to get the basic architecture right or risk having to rewrite a lot of the compiler when trying to optimise it. The more I've been thinking about it, the more it feels right to have the internal representation based around elements as opposed to vectors. The frontend of the compiler would then generate these element based operations, and we'd have an instruction scheduler that organises them efficiently. In the first version that scheduler would just make sure that instructions are tagged in a way that gives proper execution. That shouldn't require any reordering and therefore shouldn't be that messy to implement. Later we can improve the scheduler to pack instructions more tightly. As for Mesa vs Gallium, I guess making a really good compiler is only important for Gallium as that is the long term solution and Mesa is just a stop-gap. I'm not sure how the GLSL compiler you are working on looks like, nor do I know what design Corbin's Gallium code uses, but I'm hoping we're all pulling in the same direction. :) The r600 GLSL code is already in git. Reviews/thoughts much appreciated. Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] Proposed Mesa 7.7 / 7.6.1 release schedule
On Wed, Nov 18, 2009 at 10:26 AM, Brian Paul bri...@vmware.com wrote: Julien Cristau wrote: On Wed, Nov 18, 2009 at 07:44:46 -0700, Brian Paul wrote: The 7.6.1 release should be ready to go at any time since it's just bug fixes. So I'd like to make a release candidate today, and release 7.6.1 by the end of the week. I think bug #24131 should be a blocker for 7.6.1. Apparently a revert fixes it... One of the radeon developers should make the call, but I'd be OK with reverting it. For reference: http://bugs.freedesktop.org/show_bug.cgi?id=24131 I'll go ahead and test and revert it. Do I need to apply to all three branches or will 7.6 get merged into the other 2 at some point? Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] Proposed Mesa 7.7 / 7.6.1 release schedule
On Wed, Nov 18, 2009 at 11:13 AM, Brian Paul bri...@vmware.com wrote: Alex Deucher wrote: On Wed, Nov 18, 2009 at 10:26 AM, Brian Paul bri...@vmware.com wrote: Julien Cristau wrote: On Wed, Nov 18, 2009 at 07:44:46 -0700, Brian Paul wrote: The 7.6.1 release should be ready to go at any time since it's just bug fixes. So I'd like to make a release candidate today, and release 7.6.1 by the end of the week. I think bug #24131 should be a blocker for 7.6.1. Apparently a revert fixes it... One of the radeon developers should make the call, but I'd be OK with reverting it. For reference: http://bugs.freedesktop.org/show_bug.cgi?id=24131 I'll go ahead and test and revert it. Do I need to apply to all three branches or will 7.6 get merged into the other 2 at some point? Just commit to the 7.6 branch. I'll eventually merge that branch to 7.7 and then to master. Pushed. Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r600/r700 compiler future?
On Sun, Nov 1, 2009 at 9:34 AM, Pierre Ossman pierre-l...@ossman.eu wrote: I'm looking at r600/r700 compiler with the ambition of filling in the missing pieces. I've just read through the documentation and the basic structure of the compiler, and I'm having a hard time understanding the design choices of the code. Hopefully someone can fill me in on what the plan is here. The basic problem is that the compiler is a somewhat poor fit for the hardware. The compiler is designed around vectors, whilst the hardware works more in terms of individual elements (albeit with a whole bunch of restrictions). This disparity means that the compiler in its current form can be very inefficient. Worst case scenario is using 25% of the hardware. As an example, I've been looking at implementing the EXP op. A simple implementation would use 4 instruction groups with the current compiler, but the hardware should be capable of doing it with 2. An optimised implementation would range in efficiency between 100% and 33% of hardware capability. The common case would probably still be 50%. So what's the plan here? This kind of inefficiency must be a temporary solution and not the final goal? At this point the compiler is pretty much unoptimized; it was written to make sure everything worked. In most cases it just provides the basic functionality, so optimizations are welcome. I've cc'ed Richard as he has written most of the shader code at this point. Alex -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Thu, Oct 29, 2009 at 9:49 AM, Brian Paul bri...@vmware.com wrote: Alex Deucher wrote: On Wed, Oct 28, 2009 at 11:44 PM, Brian Paul brian.e.p...@gmail.com wrote: OK, the merge is done. Here's a quick summary of the changes: * The old gl_texture_format struct is replaced by a new gl_format enum. * The new formats are defined in formats.h and all the helper functions are in formats.c * textures and renderbuffers now use the same format info/fields * some special case code for compressed vs. uncompressed textures was unified. * new XRGB and X8Z24 formats * removed swrast-only/GLchan texture formats I don't know of any regressions but I haven't tested all the DRI drivers. If anyone finds any problems, let me know (please provide details) and I'll help you ASAP. fbo_firecube spews the following: radeonSetSpanFunctions: bad format: 0x001C OK, should be fixed now. Yep, that did it. thanks! Alex -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Wed, Oct 28, 2009 at 11:44 PM, Brian Paul brian.e.p...@gmail.com wrote: OK, the merge is done. Here's a quick summary of the changes: * The old gl_texture_format struct is replaced by a new gl_format enum. * The new formats are defined in formats.h and all the helper functions are in formats.c * textures and renderbuffers now use the same format info/fields * some special case code for compressed vs. uncompressed textures was unified. * new XRGB and X8Z24 formats * removed swrast-only/GLchan texture formats I don't know of any regressions but I haven't tested all the DRI drivers. If anyone finds any problems, let me know (please provide details) and I'll help you ASAP. fbo_firecube spews the following: radeonSetSpanFunctions: bad format: 0x001C Alex -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r600: implement ARB_occlusion_query
On Mon, Oct 26, 2009 at 5:32 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, Oct 26, 2009 at 4:55 AM, Stephan Schmid stephan_2...@gmx.de wrote:
This implements GL_ARB_occlusion_query for RV610
Currently it results in a huge performance gain in games that take advantage
of
ARB_oq such as sauerbraten (cube2).
issues:
- this was tested so far only on RV610. I figured out that the RV610 writes
one
single uint64_t value when triggering the zpass write event. The specs
aren't
too clear about what exactly is written.
It might be that there are multiple zpass counters on chip and that
r6xx/r7xx
chips write one uint64_t per counter (just as the r300 do it). In this case
the
RV610 would write only one value because it's one of the smallest chips in
the
family so it's got only one counter.
If my assumtion were true it would be necessary to use n*sizeof(uint64_t) in
r600_emit_query_finish as offset (n = number of counters/values written) and
to consider the additional values in radeonQueryGetResult when computing the
result of the query.
It would be interesting to know what the other r6xx/r7xx write on
zpass-write event
to support them as well.
Stephan,
Nice work! The zpass stuff is per DB just like the older chips, so
you'll need to allocate enough memory to support two qwords for each
DB. The number of DBs depends on the asic. We'll probably need a drm
query similar to what we do for r300. I'm working on a cleaned up
version of your mesa patch and a drm patch to return the number of RBs
like we do for r300.
After testing, it seems r6xx aggregates the zpass results from all DB
blocks into 1 qword. R7xx, seems to work differently. I'm following
up internally. The attached patch works properly on all r6xx cards I
have and certain r7xx cards. tri-query and glean oq tests pass.
Alex
From 888e8fd56788bcf4fc42b9d630ad1c4a01d8c9b1 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Tue, 27 Oct 2009 03:50:58 -0400
Subject: [PATCH] r600: add occlusion query support
Based on initial patch from Stephan Schmid stephan_2...@gmx.de.
Basic idea is to dump the zpass count before and after and substract
to get the total number of visible fragments. R6xx appears to
aggregate the results of all DB blocks into a single qword and works
properly on all cards I've tested on. R7xx seems to work differently
and needs follow up.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
src/mesa/drivers/dri/r600/r600_context.c | 28 --
src/mesa/drivers/dri/r600/r700_chip.c | 50 +
src/mesa/drivers/dri/r600/r700_state.c|1 +
src/mesa/drivers/dri/radeon/radeon_queryobj.c | 28 +++---
4 files changed, 97 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/r600/r600_context.c b/src/mesa/drivers/dri/r600/r600_context.c
index c1bf76d..6fe2926 100644
--- a/src/mesa/drivers/dri/r600/r600_context.c
+++ b/src/mesa/drivers/dri/r600/r600_context.c
@@ -64,6 +64,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#include r600_cmdbuf.h
#include r600_emit.h
#include radeon_bocs_wrapper.h
+#include radeon_queryobj.h
#include r700_state.h
#include r700_ioctl.h
@@ -73,11 +74,8 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#include utils.h
#include xmlpool.h /* for symbolic values of enum-type options */
-/* hw_tcl_on derives from future_hw_tcl_on when its safe to change it. */
-int future_hw_tcl_on = 1;
-int hw_tcl_on = 1;
-
#define need_GL_VERSION_2_0
+#define need_GL_ARB_occlusion_query
#define need_GL_ARB_point_parameters
#define need_GL_ARB_vertex_program
#define need_GL_EXT_blend_equation_separate
@@ -98,6 +96,7 @@ static const struct dri_extension card_extensions[] = {
/* *INDENT-OFF* */
{GL_ARB_depth_texture, NULL},
{GL_ARB_fragment_program, NULL},
+ {GL_ARB_occlusion_query,GL_ARB_occlusion_query_functions},
{GL_ARB_multitexture, NULL},
{GL_ARB_point_parameters, GL_ARB_point_parameters_functions},
{GL_ARB_shadow, NULL},
@@ -204,6 +203,25 @@ static void r600_fallback(GLcontext *ctx, GLuint bit, GLboolean mode)
context-radeon.Fallback = ~bit;
}
+static void r600_emit_query_finish(radeonContextPtr radeon)
+{
+ context_t *context = (context_t*) radeon;
+ BATCH_LOCALS(context-radeon);
+
+ struct radeon_query_object *query = radeon-query.current;
+
+ BEGIN_BATCH_NO_AUTOSTATE(4 + 2);
+ R600_OUT_BATCH(CP_PACKET3(R600_IT_EVENT_WRITE, 2));
+ R600_OUT_BATCH(ZPASS_DONE);
+ R600_OUT_BATCH(query-curr_offset); /* hw writes qwords */
+ R600_OUT_BATCH(0x);
+ R600_OUT_BATCH_RELOC(VGT_EVENT_INITIATOR, query-bo, 0, 0, RADEON_GEM_DOMAIN_GTT, 0);
+ END_BATCH();
+ query-curr_offset += 8 * sizeof(uint64_t);
+ assert(query-curr_offset RADEON_QUERY_PAGE_SIZE);
+ query-emitted_begin = GL_FALSE;
+}
+
static void r600_init_vtbl(radeonContextPtr radeon)
{
radeon-vtbl.get_lock = r600_get_lock
Re: [Mesa3d-dev] texformat-rework branch
On Mon, Oct 26, 2009 at 3:06 PM, Brian Paul bri...@vmware.com wrote: Alex Deucher wrote: On Fri, Oct 23, 2009 at 5:23 PM, Brian Paul bri...@vmware.com wrote: Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Most apps assert: radeon_create_renderbuffer: Unknown format 0x001b glxgears: main/renderbuffer.c:1981: _mesa_add_renderbuffer: Assertion `rb' failed. Here's a patch to try. That seems to fix it. Alex -Brian diff --git a/src/mesa/drivers/dri/radeon/radeon_fbo.c b/src/mesa/drivers/dri/radeon/radeon_fbo.c index 4084682..fc0d312 100644 --- a/src/mesa/drivers/dri/radeon/radeon_fbo.c +++ b/src/mesa/drivers/dri/radeon/radeon_fbo.c @@ -280,12 +280,17 @@ radeon_create_renderbuffer(gl_format format, __DRIdrawablePrivate *driDrawPriv) rrb-base.DataType = GL_UNSIGNED_SHORT; rrb-base._BaseFormat = GL_DEPTH_COMPONENT; break; + case MESA_FORMAT_X8_Z24: + rrb-base.DataType = GL_UNSIGNED_INT; + rrb-base._BaseFormat = GL_DEPTH_COMPONENT; + break; case MESA_FORMAT_S8_Z24: rrb-base.DataType = GL_UNSIGNED_INT_24_8_EXT; rrb-base._BaseFormat = GL_DEPTH_STENCIL; break; default: - fprintf(stderr, %s: Unknown format 0x%04x\n, __FUNCTION__, format); + fprintf(stderr, %s: Unknown format %s\n, + __FUNCTION__, _mesa_get_format_name(format)); _mesa_delete_renderbuffer(rrb-base); return NULL; } -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Fri, Oct 23, 2009 at 5:23 PM, Brian Paul bri...@vmware.com wrote: Alex, Nicolai, Would you guys please test the texformat-rework branch again? If it looks OK, I'd like to merge to master soon, but probably not until next week. Most apps assert: radeon_create_renderbuffer: Unknown format 0x001b glxgears: main/renderbuffer.c:1981: _mesa_add_renderbuffer: Assertion `rb' failed. Alex -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r600: implement ARB_occlusion_query
On Mon, Oct 26, 2009 at 4:55 AM, Stephan Schmid stephan_2...@gmx.de wrote: This implements GL_ARB_occlusion_query for RV610 Currently it results in a huge performance gain in games that take advantage of ARB_oq such as sauerbraten (cube2). issues: - this was tested so far only on RV610. I figured out that the RV610 writes one single uint64_t value when triggering the zpass write event. The specs aren't too clear about what exactly is written. It might be that there are multiple zpass counters on chip and that r6xx/r7xx chips write one uint64_t per counter (just as the r300 do it). In this case the RV610 would write only one value because it's one of the smallest chips in the family so it's got only one counter. If my assumtion were true it would be necessary to use n*sizeof(uint64_t) in r600_emit_query_finish as offset (n = number of counters/values written) and to consider the additional values in radeonQueryGetResult when computing the result of the query. It would be interesting to know what the other r6xx/r7xx write on zpass-write event to support them as well. Stephan, Nice work! The zpass stuff is per DB just like the older chips, so you'll need to allocate enough memory to support two qwords for each DB. The number of DBs depends on the asic. We'll probably need a drm query similar to what we do for r300. I'm working on a cleaned up version of your mesa patch and a drm patch to return the number of RBs like we do for r300. Alex -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Blit support for r300
On Fri, Oct 23, 2009 at 2:37 AM, Maciej Cencora m.cenc...@gmail.com wrote: Hi, as you may already know r300 classic driver is in pretty good shape these days, but there's one thing that causes major slowdowns in many games: lack of hardware accelerated blit operation. Currently all glCopyTex[Sub]Image operations are done through span functions which is slow as hell. We could use the hw blitter unit, but using it causes stalls because of the 2D/3D mode switch. I was wondering how this could be fixed and I got this crazy idea of porting the everything-is-texture concept from gallium to classic mesa. Actually not all of it, just the pieces that make the renderbuffers look like textures for the driver. Shouldn't be too hard to implement using the 3D engine. We could write a generic radeon_blit.c modules and then add asic specific functions to the vtbl to actually do the blit. The 3D engine will also get better memory throughput on newer chips than the 2D engine, so that's another advantage. Alex -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul bri...@vmware.com wrote: Nicolai, I made some changes on the texformat-rework branch last night. Could you re-test? There may still be issues but I'll work with you to fix them. I did a quick test of the branch on r600. openarena works ok. However demos/teapot, rain, engine, and tests/zcomp, zdrawpix, zreaddraw all segfault with the following: GL_VERSION = 1.4 Mesa 7.7-devel GL_RENDERER = Mesa DRI R600 (RS780 9610) 20090101 TCL DRI2 radeonSetSpanFunctions: bad format: 0x0003 radeonSetSpanFunctions: bad format: 0x0003 radeonSetSpanFunctions: bad format: 0x001C Segmentation fault Alex -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Thu, Oct 22, 2009 at 1:31 PM, Brian Paul bri...@vmware.com wrote:
Alex Deucher wrote:
On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul bri...@vmware.com wrote:
Nicolai,
I made some changes on the texformat-rework branch last night. Could
you re-test? There may still be issues but I'll work with you to fix
them.
I did a quick test of the branch on r600. openarena works ok.
However demos/teapot, rain, engine, and tests/zcomp, zdrawpix,
zreaddraw all segfault with the following:
GL_VERSION = 1.4 Mesa 7.7-devel
GL_RENDERER = Mesa DRI R600 (RS780 9610) 20090101 TCL DRI2
radeonSetSpanFunctions: bad format: 0x0003
radeonSetSpanFunctions: bad format: 0x0003
radeonSetSpanFunctions: bad format: 0x001C
Segmentation fault
Does the attached patch help?
Yes, that fixes the segfaults. The tests/z* tests fail to render
correctly though. r600 span code probably needs to be changed to deal
with the new depth format changes.
Alex
-Brian
diff --git a/src/mesa/drivers/dri/radeon/radeon_fbo.c
b/src/mesa/drivers/dri/radeon/radeon_fbo.c
index 21007d8..096ded2 100644
--- a/src/mesa/drivers/dri/radeon/radeon_fbo.c
+++ b/src/mesa/drivers/dri/radeon/radeon_fbo.c
@@ -280,14 +280,14 @@ radeon_create_renderbuffer(GLenum format,
__DRIdrawablePrivate *driDrawPriv)
rrb-base._BaseFormat = GL_DEPTH_COMPONENT;
break;
case GL_DEPTH_COMPONENT24:
- rrb-base.Format = MESA_FORMAT_Z32;
- rrb-base.DataType = GL_UNSIGNED_INT;
- rrb-base._BaseFormat = GL_DEPTH_COMPONENT;
+ rrb-base.Format = MESA_FORMAT_S8_Z24;
+ rrb-base.DataType = GL_UNSIGNED_INT_24_8_EXT;
+ rrb-base._BaseFormat = GL_DEPTH_STENCIL;
break;
case GL_DEPTH24_STENCIL8_EXT:
rrb-base.Format = MESA_FORMAT_S8_Z24;
rrb-base.DataType = GL_UNSIGNED_INT_24_8_EXT;
- rrb-base._BaseFormat = GL_STENCIL_INDEX;
+ rrb-base._BaseFormat = GL_DEPTH_STENCIL;
break;
default:
fprintf(stderr, %s: Unknown format 0x%04x\n, __FUNCTION__,
format);
diff --git a/src/mesa/drivers/dri/radeon/radeon_span.c
b/src/mesa/drivers/dri/radeon/radeon_span.c
index 9cdcde1..2add8c3 100644
--- a/src/mesa/drivers/dri/radeon/radeon_span.c
+++ b/src/mesa/drivers/dri/radeon/radeon_span.c
@@ -848,9 +848,9 @@ static void radeonSetSpanFunctions(struct
radeon_renderbuffer *rrb)
{
if (rrb-base.Format == MESA_FORMAT_RGB565) {
radeonInitPointers_RGB565(rrb-base);
- } else if (rrb-base.Format == MESA_FORMAT_RGBA) { /* XXX */
+ } else if (rrb-base.Format == MESA_FORMAT_XRGB) {
radeonInitPointers_xRGB(rrb-base);
- } else if (rrb-base.Format == MESA_FORMAT_RGBA) {
+ } else if (rrb-base.Format == MESA_FORMAT_ARGB) {
radeonInitPointers_ARGB(rrb-base);
} else if (rrb-base.Format == MESA_FORMAT_ARGB) {
radeonInitPointers_ARGB(rrb-base);
@@ -858,7 +858,7 @@ static void radeonSetSpanFunctions(struct
radeon_renderbuffer *rrb)
radeonInitPointers_ARGB1555(rrb-base);
} else if (rrb-base.Format == MESA_FORMAT_Z16) {
radeonInitDepthPointers_z16(rrb-base);
- } else if (rrb-base.Format == GL_DEPTH_COMPONENT32) { /* XXX */
+ } else if (rrb-base.Format == MESA_FORMAT_X8_Z24) {
radeonInitDepthPointers_z24(rrb-base);
} else if (rrb-base.Format == MESA_FORMAT_S8_Z24) {
radeonInitDepthPointers_s8_z24(rrb-base);
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Thu, Oct 22, 2009 at 2:24 PM, Brian Paul bri...@vmware.com wrote: Alex Deucher wrote: On Thu, Oct 22, 2009 at 1:31 PM, Brian Paul bri...@vmware.com wrote: Alex Deucher wrote: On Thu, Oct 22, 2009 at 11:40 AM, Brian Paul bri...@vmware.com wrote: Nicolai, I made some changes on the texformat-rework branch last night. Could you re-test? There may still be issues but I'll work with you to fix them. I did a quick test of the branch on r600. openarena works ok. However demos/teapot, rain, engine, and tests/zcomp, zdrawpix, zreaddraw all segfault with the following: GL_VERSION = 1.4 Mesa 7.7-devel GL_RENDERER = Mesa DRI R600 (RS780 9610) 20090101 TCL DRI2 radeonSetSpanFunctions: bad format: 0x0003 radeonSetSpanFunctions: bad format: 0x0003 radeonSetSpanFunctions: bad format: 0x001C Segmentation fault Does the attached patch help? Yes, that fixes the segfaults. OK, I'll commit that. More clean-up and simplification can be done (maybe tonight). The tests/z* tests fail to render correctly though. r600 span code probably needs to be changed to deal with the new depth format changes. Yes, the R600 WRITE_DEPTH() macro seems to change S8Z24 into Z24S8 (or vice versa). That shouldn't be needed any more. I've pushed a fix. thanks, Alex -Brian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] gallium-blitter
On Thu, Oct 15, 2009 at 10:58 PM, Younes Manton youne...@gmail.com wrote: On Thu, Oct 15, 2009 at 8:54 PM, Corbin Simpson mostawesomed...@gmail.com wrote: URL: http://cgit.freedesktop.org/~csimpson/mesa/log/?h=gallium-blitter So, with r600g right around the corner, I'd like to do something about this blitter/no blitter thing. Just wondering, how can you get hardware clear/copy on R600 if the 3D engine can't sample and render to a particular format? Are you doomed to a software fallback for these? Hopefully no relatively common format is in that category. You can always use 1 byte src/dst formats and implement memcpy using the 3D engine. This patch series contains one new getparam, PIPE_CAP_BLITTER, and a proposed ABI change to accompany it. surface_copy and surface_fill are proposed to have a way of indicating whether or not they successfully performed the fill/blit. It is up to the state tracker to determine whether or not to rely on these functions. Issues: - Should surface_copy and surface_fill return boolean instead of void? With this patchset, they'll return FALSE if they fail, and always return FALSE if PIPE_CAP_BLITTER isn't set. - Instead, should surface_copy and surface_fill simply be allowed to be NULL if PIPE_CAP_BLITTER is set? State tracker could continue to assume that, if present, surface_copy and surface_fill behave as expected and never fail. I prefer NULL, at least you know right away if you try to call and it isn't available, vs forgetting to check the return value and having to track it down. However I think right there's a mix of both conventions in use right now... - Should clear be included with these two? I don't think any drivers are doing anything with clear except wiring it up to util_clear... Better to let them keep the option for flexibility's sake IMO, especially if it doesn't require much maintenance. If someone ever needs to do something different here it's an easy job. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Initial version of GL_MESA_gpu_program3
On Wed, Oct 14, 2009 at 3:02 PM, Nicolai Hähnle nhaeh...@gmail.com wrote: Alex, I added you to the CC in case you can help clarify the points on R500 vertex programs. Am Wednesday 14 October 2009 08:20:42 schrieb Ian Romanick: Issue 2: 1) R500 supports unstructured branching in fragment programs but not in vertex programs, so I'm happy about leaving it out. Weird. That's backwards from how other SM3 GPUs do it. Usually you get unstructured branching in the AoS vertex shader. I agree. To be honest, the vertex processor documentation for R500 confuses the hell out of me. Somehow, the way it is written it suggests that there is a JUMP instruction that can only jump based on a constant register, which just seems extremely bizarre, but the documentation is quite consistent about it, because it tells us to use conditional write instructions to implement if- else-statements. Maybe there is a part which is simply missing? I also see neither JUMP nor LOOP opcodes anywhere, just registers describing the first and last instruction pointer for a loop. It's not part of the actual shader code per se; it's implemented in parallel to the vertex shader and interacts with it. See the VAP_PVS_FLOW_CNTL_* regs. r3xx-r5xx have them so it should be possible on all 3 generations; r5xx supports longer programs however. Alex 2) R500 supports address registers as described in vertex programs (including input/output offsets), but has no address registers at all in fragment programs. A loop address register can be used as offsets in loops, but the values loaded into this register must be determined at compile time. I had intended to move the grammar for ARL and ARR out of the generic GPU grammar and into the vertex program-specific grammar. The intention is that LOOP/ENDLOOP is the only way to load an address register in a fragment program. LOOP/ENDLOOP set the .x component and leave the other components undefined. Since the ENDLOOP restores the previous value of the address register, the last ENDLOOP restores garbage. My intention was to provide consistent syntactic sugar over the constrained functionality of the loop index. Sounds good. snip I think we can do everything you throw at us on R500. The only difficulty is that R500 is a bit schizophrenic in that vertex programs are very different from fragment programs, but we can emulate things. The only stupid weakness is that swizzling predicates in fragment programs is essentially impossible (the only natively supported swizzles are .rgba and the smears ., ., ., .). Obviously we can emulate this. How painful would it be to emulate? We could restrict the set of available predicate swizzles. I think this matches D3D, so it shouldn't be a problem for Wine. I'd always be happier if I didn't have to do it, but it's certainly easier than what we're already doing for R300 fragment programs anyway. The question is whether you want to add a fragment-program-only restriction to the provided swizzles. I don't feel very strongly either way. Issue 11: R500 supposedly supports relative addressing of temporary registers in vertex programs, and also in fragment programs (but only using loop indices). I have never tested whether it actually works, though. This would be a good feature to have. Would it be possible to hack up a test? Do you know of any limitations? Will do this weekend, at least for vertex programs; I don't know of any limitations. I don't know if I'll get to hacking something up for fragment programs soon, because that's slightly more involved (I haven't done fragment program loops yet). Issue 13: Similar to issue 2, R500 fragment programs support unstructured everything but vertex programs don't, so not overlapping sounds good to me. Issue 15: I know R500 fragment programs can support a CONT, but I'm not so familiar with the R500 vertex programs, and they seem generally less flexible. I didn't see an explicit CONT instruction. If there's no unstructured branch, there probably isn't a way to do it. Issue 17: I would *expect* negative addressing offsets to work on R500, but somehow I haven't been able to get them to work. I'll see if I can look into it again. No hardware that I'm aware of supports true negative offsets in the instructions. This is made to work with program parameters by putting the base of the array at a large enough positive offset to make the largest negative offset be zero. For example, if the program uses my_array[A0.x - 10], the driver has to place my_array at parameter slot 10 or higher. I see. I don't think we can do similar trickery for attributes and results. I think we may have to leave the negative offsets just for program parameters and only allow positive offsets for attributes and results. Note that NV_gpu_program4 only allows positive offsets. It can get away with this because SM4
Re: [Mesa3d-dev] [HD3470/R600] graphics corruption, GPU lockup...
On Wed, Sep 30, 2009 at 10:20 AM, Daniel J Blueman daniel.blue...@gmail.com wrote: When running 2.6.32-rc1 with modesetting on a HD3470/R600 GPU [1] with updated userland [2], I experience a GPU lockup 2-3 seconds after starting glxgears under compiz. We also see intermittent rendering buffer corruption [3] when glxgears is started, and sometimes corruption with text compositing in eg gnome-terminal. When the GPU lockup occurs, we observe Xorg is waiting for the GPU operation to complete [4]; DRM debug reflects this [5]. Xorg.log [attached] isn't telling. The problem isn't reproducible booting with 'nomodeset', so sounds like the radeon KMS init path doesn't correctly/consistently initialise some registers. What tools would be useful to dump the state, perhaps so I can perform a like for like comparison? There may be some buffer accounting issues with draw prims under kms. Does disabling draw prims fix the issue? To disable the draw prims interface, revert this patch: http://cgit.freedesktop.org/mesa/mesa/commit/?id=eea30906de37ea3b2f8a594c2b33b643d3dde987 Alex -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r600: 2 patches to correct blend functionality
On Mon, Sep 28, 2009 at 12:48 PM, Andre Maasikas amaasi...@gmail.com wrote: gets nexuiz explosions working, also correct doom3 title screen Andre, These look good after a quick review. I won't be able to test or commit them until I get back from xdc on Thursday. Alex -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: Proposed mesa_7_5_branch and mesa_7_6_branch freeze for release
On Tue, Sep 22, 2009 at 4:46 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I would like to open XDC by shipping Mesa 7.5.2 and 7.6. In order to make that happen, I propose the following: - - Freeze both branches at 12:01AM PDT 9/25 (this upcoming Friday). - - I will tag both trees at that time. One will get mesa_7_5_2_rc1, and the other will get mesa_7_6_rc1. - - Once those tags appear, please test whatever drivers *you* care about on whatever platforms *you* care about. - - Report any new regressions to bugzilla. If you find something that you believe is an absolute show stopper, mark it as such. We'll discuss whether we want to block the releases for it. For 7.6, I want to set the bar for blocking the release very, very high. At least one distro really wants to use 7.6, and their freeze is perilously soon. IMO, pretty much only build failures or 7.6 make my computer catch on fire, but 7.5.1 does not are blockers. I had intended to post this RFC quite some time ago, but life issues outside of $JOB have distracted me for the last few weeks. The time has just slipped by. Aside from the absurdly compressed schedule, this seems to be what most other projects do, and I think Mesa should to. We've partially done this in the past, but our process could use a little more, well, process. :) I've pulled in most of the r600 driver fixes from master into 7.6 and at this point the driver is pretty solid. The only major remaining issue for general usage is the fact that text typed in terminals under dri1 with GL compositers running doesn't show up for some reason. Works fine with dri1 and copy/pasting text in the terminal also works fine. If anyone has any ideas it would be nice to get this fixed for 7.6. Alex -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: Proposed mesa_7_5_branch and mesa_7_6_branch freeze for release
2009/9/24 Michel Dänzer mic...@daenzer.net: On Thu, 2009-09-24 at 14:34 -0400, Alex Deucher wrote: On Thu, Sep 24, 2009 at 2:07 PM, Alex Deucher alexdeuc...@gmail.com wrote: I've pulled in most of the r600 driver fixes from master into 7.6 and at this point the driver is pretty solid. The only major remaining issue for general usage is the fact that text typed in terminals under dri1 with GL compositers running doesn't show up for some reason. Works fine with dri1 and copy/pasting text in the terminal also works ^^^ Works fine with dri2. What terminals is that with? Is their text rendered in hardware or software? gnome-terminal here (hw accelerated), but apparently it happens elsewhere as well. Alex -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] r600: add support for cube textures
On Wed, Sep 23, 2009 at 7:37 AM, Andre Maasikas amaasi...@gmail.com wrote: Needs quite a few extra instructions, please test/review if I got them all right. Looks good thanks! Alex -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Bug in Mesa3d, or something else?
On Mon, Sep 21, 2009 at 12:29 PM, Jeremy Murphy jeremy.william.mur...@gmail.com wrote: On Tue, 22 Sep 2009 01:50:45 am Brian Paul wrote: Jeremy Murphy wrote: Hi there, I've come up against a bug, but I'm not sure if it's in Mesa or something else. I was testing the example programs from OpenGL Distilled (http://code.google.com/p/ogld/), especially the Picking program for its mouse stuff. If you don't feel like compiling it to see for yourself, it's just three objects that can be dragged around in the x-y plane, but if you drag on the background then it rotates the view. Pretty standard stuff. Works as expected on my x86 machine, but doesn't work as expected on my x86_64 machine where attempting to drag an object never works -- it always rotates the view. Object selection just isn't working. Both machines are relatively identical Linux systems and both have a Radeon graphics card. Does this sound like a bug in Mesa3d? If it is, I'm happy to help with fixing it, but being new to the code, I'm not sure where to start looking. Thanks! Cheers. Does the problem occur only with hardware rendering or with software rendering too? Good question: what's the simplest way to test s/w rendering? Is that with something like LIBGL_ALWAYS_INDIRECT=1? LIBGL_ALWAYS_SOFTWARE=1 Alex -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Bug in Mesa3d, or something else?
On Mon, Sep 21, 2009 at 12:51 PM, Jeremy Murphy jeremy.william.mur...@gmail.com wrote: On Tue, 22 Sep 2009 02:43:04 am Alex Deucher wrote: On Mon, Sep 21, 2009 at 12:29 PM, Jeremy Murphy jeremy.william.mur...@gmail.com wrote: On Tue, 22 Sep 2009 01:50:45 am Brian Paul wrote: Jeremy Murphy wrote: Hi there, I've come up against a bug, but I'm not sure if it's in Mesa or something else. I was testing the example programs from OpenGL Distilled (http://code.google.com/p/ogld/), especially the Picking program for its mouse stuff. If you don't feel like compiling it to see for yourself, it's just three objects that can be dragged around in the x-y plane, but if you drag on the background then it rotates the view. Pretty standard stuff. Works as expected on my x86 machine, but doesn't work as expected on my x86_64 machine where attempting to drag an object never works -- it always rotates the view. Object selection just isn't working. Both machines are relatively identical Linux systems and both have a Radeon graphics card. Does this sound like a bug in Mesa3d? If it is, I'm happy to help with fixing it, but being new to the code, I'm not sure where to start looking. Thanks! Cheers. Does the problem occur only with hardware rendering or with software rendering too? Good question: what's the simplest way to test s/w rendering? Is that with something like LIBGL_ALWAYS_INDIRECT=1? LIBGL_ALWAYS_SOFTWARE=1 What insight! Apart from the fact that the torus does not display, it does fix the problem with selection. So what does that mean in terms of locating the bug? Sounds like there may be issues with both the driver and core mesa. Alex -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] g3dvl and xvmc indention and location
On Thu, Sep 17, 2009 at 1:21 PM, Younes Manton youne...@gmail.com wrote: On Thu, Sep 17, 2009 at 12:43 PM, Zack Rusin za...@vmware.com wrote: Hey, I'm going to start adding XvMC acceleration to the Gallium's xorg state tracker. I'd like to move src/xvmc to src/gallium/state_trackers/xorg/xvmc and run the standard Mesa3D indent command on both g3dvl and xvmc. I'm by no means saying that the style in them is bad, or that any style is better than any other. What I am saying is that when working within a project that has a well defined indention (docs/devinfo.html) it's anti-social and difficult for everyone involved when parts of the code are using something completely different. It's unrealistic to expect people to keep switching indention that drastically when moving between files within a project. So all I'm asking for is some consistency which I think is going to make everything a lot easier for all of us. z Be my guest. I wasn't aware of the indent stuff when I started, apologies. You might also want to move src/driclient, since it's not used by anyone else. But aside from that I'm still messing with the pipe_video_context stuff I proposed a while back, which carves up state_trackers/g3dvl pretty good and which might make what you want to do a little easier. At the moment it compiles and runs (no output to window, everything safely stubbed, slowly porting over what used to be the state tracker into aux libs), if you have any interest. Maybe I can put it somewhere so people can comment on the interface and auxiliaries if nothing else. Also, Cooper has been working xvmc using g3dvl as well and has it working with softpipe on radeon hardware. Alex -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] More on Mesa branching / bug-fix model
On Wed, Sep 16, 2009 at 3:11 PM, Keith Whitwell kei...@vmware.com wrote: On Wed, 2009-09-16 at 11:54 -0700, Alex Deucher wrote: On Tue, Sep 15, 2009 at 5:25 PM, Brian Paul bri...@vmware.com wrote: Alex Deucher wrote: On Sun, Sep 13, 2009 at 4:21 AM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: The main problem right now is we have 3 active branches (master, 7.6 and 7.5) and it can be confusing. I wasn't really planning on another 7.5.x release until Eric cherry-picked a bunch of changes to it. I'm still not sure I'll release 7.5.2 in any case. Ian, I'd be happy to see the 7.6 release made at any time. At that time, I'm inclined to abandon the 7.5 branch. Then we'll just have master and one branch to think about. That's pretty easy. That sounds good. How about if we release 7.6 and 7.5.2 simultaneously at XDC. There are a couple bugs that I want to fix before 7.6 ships, and I think Eric has a couple as well. He's going to be out next week, so I want to give him a chance to wrap things up. I expect progress to be slowed during the week of LPC. :) There have been a bunch of r600 fixes to master since 7.6 was branched. If I move new r600 devel to the 7.6 branch, what's the preferred way to pull the previous r600 changes in master over to the 7.6 branch? Cherry picking should work. But remember that new development should occur on master while bug fixes should go on the 7.6 or 7.5 branches. I guess in some cases bug fixing looks like new development... It's tough with r600 since it's a new driver the line between bug fixes and new features is pretty hazy. Has r600 reached the level of being a supported/stable release? If the line is hazy, then I would say it hasn't and you're really still in a development cycle, in which case master is still the place where that happens. I guess the question is that the current r600 code in the 7.6 branch is much less stable than the code in master. But for 7.6 I guess we can just say r600 isn't stable yet and not built it by default. Alex -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] More on Mesa branching / bug-fix model
On Sun, Sep 13, 2009 at 4:21 AM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: The main problem right now is we have 3 active branches (master, 7.6 and 7.5) and it can be confusing. I wasn't really planning on another 7.5.x release until Eric cherry-picked a bunch of changes to it. I'm still not sure I'll release 7.5.2 in any case. Ian, I'd be happy to see the 7.6 release made at any time. At that time, I'm inclined to abandon the 7.5 branch. Then we'll just have master and one branch to think about. That's pretty easy. That sounds good. How about if we release 7.6 and 7.5.2 simultaneously at XDC. There are a couple bugs that I want to fix before 7.6 ships, and I think Eric has a couple as well. He's going to be out next week, so I want to give him a chance to wrap things up. I expect progress to be slowed during the week of LPC. :) There have been a bunch of r600 fixes to master since 7.6 was branched. If I move new r600 devel to the 7.6 branch, what's the preferred way to pull the previous r600 changes in master over to the 7.6 branch? Alex -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa 7.6 branch coming
On Fri, Sep 4, 2009 at 1:53 PM, Corbin Simpsonmostawesomed...@gmail.com wrote: On 09/03/2009 03:57 PM, Alex Deucher wrote: On Thu, Sep 3, 2009 at 6:51 PM, Dave Airlieairl...@linux.ie wrote: I've been holding off, its the problem with merging code from 3 drivers with different white space into one set of common code, you get bits of the style of all 3 drivers. heh, 4 now and r600 is especially messy. Are you exempting r300g because it has a strict 4-spaces-to-the-tab rule, or because it's not a real driver? :3 It doesn't share as much common code, but mostly, I didn't think of it. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa 7.6 branch coming
On Thu, Sep 3, 2009 at 6:51 PM, Dave Airlieairl...@linux.ie wrote: Funny you should mention whitespace. I've been looking at the radeon code a bit lately. What a mess. Within a single source file I've seen 3 different levels of indentation (3/4 space and 8-space tabs). I'd be happy to see the whole thing run through 'indent'. I've been holding off, its the problem with merging code from 3 drivers with different white space into one set of common code, you get bits of the style of all 3 drivers. heh, 4 now and r600 is especially messy. Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] mesa: fix saturation logic in emit_texenv()
This commit seems to break redbook texbind and texsub on r600: http://cgit.freedesktop.org/mesa/mesa/commit/?id=956e6c3978abe918348377cf05e5c92971e50d3f Has anyone else had any problems with these apps on other hardware? Thanks, Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/4] RESEND: Fix races in glapi
On Mon, Aug 24, 2009 at 1:48 PM, Brian Paulbri...@vmware.com wrote: Chia-I Wu wrote: Hi, This patch series was sent about 1 month ago. It went through several iterations, and should have resolved all concerns. The patches were scattered in that thread. This mail resends the series, with updated commit logs. It fixes random crashes at initialization time in progs/xdemos/glthreads and progs/egl/xeglthreads. Committed. Thanks. FWIW, 17090cf3efb0db8fa01b502a9c0df27cbd1a67da prevents you from using 3d drivers without rebuilding the xserver. Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] radeon: Optimise dma buffer handling.
On Tue, Aug 18, 2009 at 1:04 PM, Pauli Nieminensuok...@gmail.com wrote: There has been some updates to master branch again which conflict with these patches so here is updated versions. These looks good and fix the geometry corruption issues on r6xx/r7xx. I've gone ahead and pushed them. As you mentioned we still seem to be leaking some bo's in the r600 driver, but things are much better and should be easier to track down. Thanks! Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] r300: Movde debug output from stdout to stderr in copiler.
On Fri, Aug 14, 2009 at 7:55 AM, Pauli Nieminensuok...@gmail.com wrote:
Signed-off-by: Pauli Nieminen suok...@gmail.com
Pushed. thanks!
---
.../drivers/dri/r300/compiler/r3xx_vertprog_dump.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/r300/compiler/r3xx_vertprog_dump.c
b/src/mesa/drivers/dri/r300/compiler/r3xx_vertprog_dump.c
index 39cc695..980ef3e 100644
--- a/src/mesa/drivers/dri/r300/compiler/r3xx_vertprog_dump.c
+++ b/src/mesa/drivers/dri/r300/compiler/r3xx_vertprog_dump.c
@@ -128,24 +128,24 @@ static char* r300_vs_swiz_debug[] = {
static void r300_vs_op_dump(uint32_t op)
{
- printf( dst: %d%s op: ,
+ fprintf(stderr, dst: %d%s op: ,
(op 13) 0x7f, r300_vs_dst_debug[(op 8) 0x7]);
if (op 0x80) {
if (op 0x1) {
- printf(PVS_MACRO_OP_2CLK_M2X_ADD\n);
+ fprintf(stderr, PVS_MACRO_OP_2CLK_M2X_ADD\n);
} else {
- printf( PVS_MACRO_OP_2CLK_MADD\n);
+ fprintf(stderr, PVS_MACRO_OP_2CLK_MADD\n);
}
} else if (op 0x40) {
- printf(%s\n, r300_vs_me_ops[op 0x1f]);
+ fprintf(stderr, %s\n, r300_vs_me_ops[op 0x1f]);
} else {
- printf(%s\n, r300_vs_ve_ops[op 0x1f]);
+ fprintf(stderr, %s\n, r300_vs_ve_ops[op 0x1f]);
}
}
static void r300_vs_src_dump(uint32_t src)
{
- printf( reg: %d%s swiz: %s%s/%s%s/%s%s/%s%s\n,
+ fprintf(stderr, reg: %d%s swiz: %s%s/%s%s/%s%s/%s%s\n,
(src 5) 0x7f, r300_vs_src_debug[src 0x3],
src (1 25) ? - : ,
r300_vs_swiz_debug[(src 13) 0x7],
@@ -166,11 +166,11 @@ void r300_vertex_program_dump(struct
r300_vertex_program_code * vs)
unsigned offset = i*4;
unsigned src;
- printf(%d: op: 0x%08x, i, vs-body.d[offset]);
+ fprintf(stderr, %d: op: 0x%08x, i, vs-body.d[offset]);
r300_vs_op_dump(vs-body.d[offset]);
for(src = 0; src 3; ++src) {
- printf( src%i: 0x%08x, src,
vs-body.d[offset+1+src]);
+ fprintf(stderr, src%i: 0x%08x, src,
vs-body.d[offset+1+src]);
r300_vs_src_dump(vs-body.d[offset+1+src]);
}
}
--
1.6.3.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Blender: problem with offset menus on ATI R200/R300
On Fri, Aug 14, 2009 at 4:44 AM, Terry Barnabyter...@beam.ltd.uk wrote: I am using the latest drm/xf86-video-ati/mesa code from git on a Fedora 11 base platform. There was a problem with Blenders menu's being painted in black/white, that has now been fixed (Thanks to whoever !). However, there is still an issue where the menus and buttons are displayed offset about 20 pixels above and a few pixels to the left of where they should be (Bug 23232). This happens when DRI2 is used. If nomodeset is used on the kernel command line this appear sto make the system use DRI and the menus are Ok. There are other issues with DRI however (2D pixel artifacts and very slow blender 3D operation (software renderer is faster !)). Any ideas on where to look for this bug ? What xserver are you using? IIRC, front buffer rendering was broken in some versions. you may be hitting that. Is there a way to switch between using DRI2 and DRI1 at run time ? Yes, switch on/off KMS. Reload the radeon drm module with modeset=1 or modeset=0 to switch. Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Blender: problem with offset menus on ATI R200/R300
On Fri, Aug 14, 2009 at 11:29 AM, Terry Barnabyter...@beam.ltd.uk wrote: On 08/14/2009 03:56 PM, Alex Deucher wrote: On Fri, Aug 14, 2009 at 4:44 AM, Terry Barnabyter...@beam.ltd.uk wrote: I am using the latest drm/xf86-video-ati/mesa code from git on a Fedora 11 base platform. There was a problem with Blenders menu's being painted in black/white, that has now been fixed (Thanks to whoever !). However, there is still an issue where the menus and buttons are displayed offset about 20 pixels above and a few pixels to the left of where they should be (Bug 23232). This happens when DRI2 is used. If nomodeset is used on the kernel command line this appear sto make the system use DRI and the menus are Ok. There are other issues with DRI however (2D pixel artifacts and very slow blender 3D operation (software renderer is faster !)). Any ideas on where to look for this bug ? What xserver are you using? IIRC, front buffer rendering was broken in some versions. you may be hitting that. Is there a way to switch between using DRI2 and DRI1 at run time ? Yes, switch on/off KMS. Reload the radeon drm module with modeset=1 or modeset=0 to switch. Alex Thanks for the reply: I am using the stock Fedora 11 X-Server. This is XOrg Version: 1.6.1.901. Any idea which versions had broken front buffer rendering ? I'm pretty sure the fixes are not in F11. Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] radeon: Add protection against recursive DRM locking.
On Sun, Aug 2, 2009 at 12:16 PM, Pauli Nieminensuok...@gmail.com wrote: Sorry for leaving bad patch just before leaving for weekend trip. I have now fixed that bugs that I created when trying to change logic in hurry. Unforunately, running any 3d app with this patch seems to hang the gpu. Alex On Fri, Jul 31, 2009 at 6:44 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Fri, Jul 31, 2009 at 7:18 AM, Pauli Nieminensuok...@gmail.com wrote: Hi. Some clean up to code so it is better thread safety even tough it is not 100% without locking or atomic operations. (Now it works same way as intel does recursion prevention) Another adittion is to make debug output to check if DEBUG_SANITY is set. Whole lock debugging is compiled out if there is NDEBUG set so there wouldn't be need of passing debug parameters in release version. Can you fix this up? It's broken at the moment. Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] radeon: Add protection against recursive DRM locking.
On Sun, Aug 2, 2009 at 1:58 PM, Pauli Nieminensuok...@gmail.com wrote: yes. It was missing the fix because of no git add before git commit --amend. Looks like you attached the same patch :) On Sun, Aug 2, 2009 at 8:35 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Sun, Aug 2, 2009 at 12:16 PM, Pauli Nieminensuok...@gmail.com wrote: Sorry for leaving bad patch just before leaving for weekend trip. I have now fixed that bugs that I created when trying to change logic in hurry. Unforunately, running any 3d app with this patch seems to hang the gpu. Alex On Fri, Jul 31, 2009 at 6:44 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Fri, Jul 31, 2009 at 7:18 AM, Pauli Nieminensuok...@gmail.com wrote: Hi. Some clean up to code so it is better thread safety even tough it is not 100% without locking or atomic operations. (Now it works same way as intel does recursion prevention) Another adittion is to make debug output to check if DEBUG_SANITY is set. Whole lock debugging is compiled out if there is NDEBUG set so there wouldn't be need of passing debug parameters in release version. Can you fix this up? It's broken at the moment. Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] radeon: Add protection against recursive DRM locking.
On Fri, Jul 31, 2009 at 7:18 AM, Pauli Nieminensuok...@gmail.com wrote: Hi. Some clean up to code so it is better thread safety even tough it is not 100% without locking or atomic operations. (Now it works same way as intel does recursion prevention) Another adittion is to make debug output to check if DEBUG_SANITY is set. Whole lock debugging is compiled out if there is NDEBUG set so there wouldn't be need of passing debug parameters in release version. Can you fix this up? It's broken at the moment. Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] radeon: Add r6xx/r7xx chip family to get_chip_family_name
On Mon, Jul 27, 2009 at 10:13 AM, Pauli Nieminensuok...@gmail.com wrote: This fixes problem that glxinfo was reporting r600+ cards as unknown. pushed, thanks! -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] mesa r6xx-rewrite git is missing a file?
On Wed, Jul 22, 2009 at 11:52 AM, e...@cs.bgu.ac.ile...@cs.bgu.ac.il wrote: hello. I've want to test the r6xx-rewrite mesa, I've got the code from git and I'm trying to compile it, the compilation fails at one stage when the file eglcurrent.c is said to be missing, no reference to the file was found in regards to the r6xx-rewrite so I'm guessing it isn't suppose to be in it, here is the error snip: The r6xx-rewrite branch was merged to master a few days ago. The r6xx-rewrite branch should be considered dead now. Use master instead. Alex -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] build failure in current r6xx-rewrite branch
On Fri, Jul 17, 2009 at 7:09 PM, Radu Beneakitanat...@gmail.com wrote: gmake[3]: Entering directory `/root/build/mesa/src/egl/main' Makefile:87: depend: No such file or directory gmake[3]: *** No rule to make target `eglcurrent.c', needed by `depend'. Stop. Fixed in mesa master. r6xx/r7xx development has moved to mesa master now. You can workaround it in the old branch by disabling egl when you run configure (--disable-egl). Alex -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Another round of patches for r300
On Thu, May 14, 2009 at 4:03 PM, Maciej Cencora m.cenc...@gmail.com wrote: Dnia czwartek, 14 maja 2009 o 03:09:41 Maciej Cencora napisał(a): Hi, this patch-set isn't yet ready for being committed, but it's near. What's inside: 1) fallback handling has been rewritten to work with SWTCL I created r300Fallback function (based on the one in r200 driver) and call it every time there's suspicion that we may be need to fall-back to software. In r300Fallback function we check if we're going to switch between SW and HW rasterization - if so we plug appropriate Render functions (_swsetup_Wakeup to plug software rasterizer functions). It worked for HW TCL because we have never plugged our Render functions like we do for SW TCL in r300InitSwtcl. 2) cleanup, cleanup, cleanup and some more cleanup :) The 10th patch is a little big, so probably you will want me to split it, right? Currently I've tested every patch with glxgears and sauerbraten - I'm running some piglit tests right now. Please test, review and comment. Regards, Maciej Cencora I'm sending updated patch-set. It should be ready to commit now. Changes: - removed RADEON_SWTCL and RADEON_CONFORMANCE_MODE according to Michel Daenzer suggestion, - renamed r300Fallback to r300SwitchFallback according to Philipp Klaus Krause suggestion, - removed unused r300_context.options.def_max_insotropy field, - removed WIP comments, - minor code movement (options-hw_tcl_enabled is initialized fully in r300ParseOptions), - new patch that fixes LIT 0^0 case in vertex shaders (fixes glean/vertProg1 test). It lengthens the LIT code by 4 instructions (MUL, SLT, SGE and MAD) and uses two temporaries. I'm wondering if I shouldn't enable the new behavior only in conformance mode. What do you think? Pushed 1-10 as discussed on IRC. Alex -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Another round of patches for r300
On Thu, May 14, 2009 at 4:03 PM, Maciej Cencora m.cenc...@gmail.com wrote: Dnia czwartek, 14 maja 2009 o 03:09:41 Maciej Cencora napisał(a): Hi, this patch-set isn't yet ready for being committed, but it's near. What's inside: 1) fallback handling has been rewritten to work with SWTCL I created r300Fallback function (based on the one in r200 driver) and call it every time there's suspicion that we may be need to fall-back to software. In r300Fallback function we check if we're going to switch between SW and HW rasterization - if so we plug appropriate Render functions (_swsetup_Wakeup to plug software rasterizer functions). It worked for HW TCL because we have never plugged our Render functions like we do for SW TCL in r300InitSwtcl. 2) cleanup, cleanup, cleanup and some more cleanup :) The 10th patch is a little big, so probably you will want me to split it, right? Currently I've tested every patch with glxgears and sauerbraten - I'm running some piglit tests right now. Please test, review and comment. Regards, Maciej Cencora I'm sending updated patch-set. It should be ready to commit now. Changes: - removed RADEON_SWTCL and RADEON_CONFORMANCE_MODE according to Michel Daenzer suggestion, - renamed r300Fallback to r300SwitchFallback according to Philipp Klaus Krause suggestion, - removed unused r300_context.options.def_max_insotropy field, - removed WIP comments, - minor code movement (options-hw_tcl_enabled is initialized fully in r300ParseOptions), - new patch that fixes LIT 0^0 case in vertex shaders (fixes glean/vertProg1 test). It lengthens the LIT code by 4 instructions (MUL, SLT, SGE and MAD) and uses two temporaries. I'm wondering if I shouldn't enable the new behavior only in conformance mode. What do you think? I tested whole patch-set with piglit and it shows no regressions. Unless there are any objections, I'll just apply them as is for now. We can always change the LIT case later if need be. Alex -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] More radeon-rewrite patches
On Thu, May 7, 2009 at 12:03 PM, Maciej Cencora m.cenc...@gmail.com wrote: Hi, two cleanup patches and one bug fix this time. Any comments? Pushed. BTW, you really should get an account so you can push this stuff yourself :) -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] One patch for radeon-rewrite branch
On Mon, May 4, 2009 at 11:15 AM, Maciej Cencora m.cenc...@gmail.com wrote: On sobota, 2 maja 2009 13:41:54 Maciej Cencora wrote: On sobota, 2 maja 2009 02:50:54 you wrote: On 02.05.2009 01:53, Maciej Cencora wrote: Hi, this simple patch fixes (for IGP chips, non IGP aren't affected): - 8 piglit tests: general/texgen, glean/texCube, mesa/crossbar, shaders/fp- kil, texturing/gen-teximage, texturing/gen-texsubimage, texturing/lodbias, texturing/texredefine, - KDE4 Kwin shadows (when desktop effects use OpenGL backend), - #16452 bug, - many others... Could anyone test it on some RS48x cards? Maciej Cencora --- - From f2c2db095fe908b428ad0dccefc39f078cccb3a6 Mon Sep 17 00:00:00 2001 From: Maciej Cencora m.cenc...@gmail.com Date: Sat, 2 May 2009 01:30:23 +0200 Subject: [PATCH] r300: set proper texture row alignment for IGP chips Looks like IGP chips require 64 byte alignment --- src/mesa/drivers/dri/radeon/radeon_mipmap_tree.c | 11 ++- 1 files changed, 6 insertions(+), 5 deletions(-) I'm a bit sceptical that this is correct for all IGP chips, especially non-r300 versions. Also, note that RADEON_CHIPSET_TCL does not necessarily mean it's a igp, though IIRC only first gen radeons came in non-tcl discrete flavors. Roland Yes, you're right. I forgot the code is shared with r100 and r200 drivers. I should probably add new field to radeon_context structure (e.g. tex_row_align) and initialize it during context creation based on chip family. I think RS400, RS600, RS690 and RS740 families needs the 64 bytes alignment, but it would be the best if someone from AMD could confirm this. Maciej Cencora Here's updated patch based on informations from Alex Deucher. Pushed. Thanks. It doesn't look like RS4xx cards need this, but I'm attempting to get a definitive answer. Alex -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] More radeon-rewrite patches
On Mon, Apr 27, 2009 at 10:52 AM, Maciej Cencora m.cenc...@gmail.com wrote: Hi, another round of patches against radeon-rewrite branch. Any comments? These look good. The vertex shader program limits should be updated for r5xx as well. Alex -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] More radeon-rewrite patches
On Mon, Apr 27, 2009 at 10:52 AM, Maciej Cencora m.cenc...@gmail.com wrote: Hi, another round of patches against radeon-rewrite branch. Pushed. -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Another radeon-rewrite patchset
On Fri, Apr 24, 2009 at 12:00 PM, Maciej Cencora m.cenc...@gmail.com wrote: On piątek, 24 kwietnia 2009 17:00:07 Maciej Cencora wrote: On piątek, 24 kwietnia 2009 16:42:53 you wrote: Hi, among some general cleanup this patchset contains performance regression fix for non TCL cards, and some debugging related improvements. Any comments? Regards, Maciej Cencora please replace the last patch with these two. Since the patch that fixes perf regression we use fixed function SWTCL if possible for non TCL hardware, we need to add point attenuation stage. Maciej Cencora here's updated patchset. It includes the additional patch from previous email and also reverts part of 0007-r300-always-route-4-texcoord-components-to- RS.patch (alpha component of fogcoord should be 1 according to GL_ARB_fragment_program spec). These patches look good to me. Alex -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r300 fragment program fix
On Mon, Apr 20, 2009 at 8:04 PM, Maciej Cencora m.cenc...@gmail.com wrote: Hi, this patch fixes fragment programs where input modifier (negate or abs) was used for texture instruction - r300 hw doesn't support it, so add MOV inst with necessary modifiers before the tex inst. It fixes failing piglit/fp-kil test. Committed. thanks. Alex -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r300 swtcl cleanup
On 3/25/09, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maciej Cencora wrote: On piątek, 20 marca 2009 21:23:45 you wrote: Hi, here is a simple cleanup patch for r300 dri driver. It's pretty trivial so I think it can be commited without a problem. Any reason why it hasn't been committed yet? Is there something wrong with this patch? Since Alex reviewed it and acked it, I'm assuming he didn't realize that you needed someone to commit it for you. If you're on IRC, you might ping people there. That's the usual way to unclog a stopped-up drain. :) In any case, I've taken care of it. Sorry, I didn't realize it hadn't been committed yet. Maciej, you really should request git commit access. Barring that, as Ian said, ping one of us on IRC. Alex -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texture tiling, sw fallbacks and bufmgrs.
On 3/21/09, Dave Airlie airl...@linux.ie wrote: Hi all, So I had to drop texture tiling when I did the radeon-rewrite but I'd like to bring them back. Now with traditional drivers, we have the mesa copy of the texture and the card copy, and we usually texture from VRAM only, so we can upload to VRAM and tile on the way, and if we hit a sw fallback we just use the textures from the mesa fallback. In the bufmgr world in theory we don't keep two copies of textures around, and on radeons we can at least enable texture tiling on GART textures. So if I store the texture tiled for hw use, we don't have anything like span access to textures from what I can see for sw use. If the texture was in VRAM, in theory for sw use we could use a surface, however it leave tiled in GART busted. I'm just wondering if anyone has already tackled this in any driver, and how this could work best. Does Gallium provide surface accessors for textures like spans? I'm sort of thinking I keep two buffers objects, one sw only and one for hw to use and use the GPU to blit between them when updates are needed. Something similar could also be used for non-CPU-accessible vram. In the linear texture or accessible vram cases the copy would be a nop. Alex -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r300 swtcl cleanup
On 3/20/09, Maciej Cencora m.cenc...@gmail.com wrote: Hi, here is a simple cleanup patch for r300 dri driver. It's pretty trivial so I think it can be commited without a problem. Looks good to me. Alex -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): r300-gallium: Add unaccelerated surface_copy.
On Thu, Mar 5, 2009 at 11:45 AM, Michel Dänzer mic...@daenzer.net wrote: On Thu, 2009-03-05 at 08:37 -0800, Corbin Simpson wrote: Okay, so the commented-out code following that fallback is the blitter setup. It's simple, straightforward, and clean, but it requires a massive flush before and after, so I probably will toss it out. So surface_copy will eventually be done on the 3D engine instead. Note that I think this won't necessarily avoid the flushes, as the render target will likely change before/after the surface_copy(). This works terrifically, as long as there's no overlap between src and dest. As Jakob has reminded me, there's no guarantee made in Gallium regarding whether or not the src and dest will overlap in memory. The comment above util_blit_pixels_tex() says * Overlapping regions are acceptable. Although util_blit_pixels_tex may not be usable directly, if feasible I think it would be nice to have some kind of default surface_copy implementation using a textured quad, so that doesn't need to be re-implemented in each driver. I agree, it would be nice to solve this once in a generic manner so we don't have to do it again and again as more chips drop their 2D blitters. Alex -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] R2xx
On Tue, Aug 26, 2008 at 9:48 AM, [EMAIL PROTECTED] wrote: Does anyone know if the datasheets programming guides for AMD's old R2xx cards have been released? If so, where could I find them? They are not yet available without an NDA. Alex - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] R2xx
On Tue, Aug 26, 2008 at 1:56 PM, [EMAIL PROTECTED] wrote: What a shameThanks! Pretty much everything you would need is already available in the opensource drivers. AMD may be able to release them without an NDA eventually, but we are currently busy with the r6xx/r7xx doc release which has taken longer than expected. Alex Dee Sharpe -Original Message- From: Alex Deucher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: mesa3d-dev@lists.sourceforge.net; [EMAIL PROTECTED] Sent: Tue, 26 Aug 2008 8:54 am Subject: Re: [Mesa3d-dev] R2xx On Tue, Aug 26, 2008 at 9:48 AM, [EMAIL PROTECTED] wrote: Does anyone know if the datasheets programming guides for AMD's old R2xx cards have been released? If so, where could I find them? They are not yet available without an NDA. Alex Get the MapQuest Toolbar. Directions, Traffic, Gas Prices More! - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Yet another r300 memory management tree
On Mon, Aug 4, 2008 at 11:40 AM, Roland Scheidegger [EMAIL PROTECTED] wrote: On 04.08.2008 15:05, Nicolai Hähnle wrote: Am Montag 04 August 2008 14:51:37 schrieb Roland Scheidegger: On 03.08.2008 00:40, Nicolai Hähnle wrote: Hi there, seeing as lacking a memory manager is a pretty frustrating state of mind, I thought I'd explore this area a bit. My goals are: - bring the r300_dri driver into a state that is more compatible with a proper in-kernel memory manager, - do so with as little breakage as possible, and - do so without changes to DRM or DDX (binary compatibility and all that) Basically, I want to have a development tree that is in almost-perfect condition almost all the time while moving towards memory management. My tree is here: http://cgit.freedesktop.org/~nh/mesa/ (on the master branch) Some comments about this tree: 1. I decided not to use an approach based on dri_bufmgr_fake yet. Instead, I based the bufmgr on the existing r300_mem which uses the RADEON_ALLOC/etc. ioctls to allocate buffers for DMA. 2. Textures are still handled in the old way - they will require dri_bufmgr_fake-like handling, probably more like airlied's approach. 3. The tree contains a lot of patches to unify the way command buffer emits are done. Basically, I introduced macros BEGIN_BATCH/OUT_BATCH/etc. similar to what we have in the DRM and the DDX - hopefully, this will reduce confusion for new people. There's a new macro called COMMIT_BATCH. The idea behind this macro is that BEGIN_BATCH can flush the command buffer at times where we really don't want the command buffer to be flushed (flushing between certain kinds of packet3 can cause lockups, etc.). The COMMIT_BATCH indicates a point in time where flushing the command buffer is unproblematic, and it should probably be used rarely. Together with r300EnsureCmdBufSpace there's a chance that it'll yield good results. 4. dri_bufmgr-API #1: Allocating space for the command buffer via DRM_RADEON_ALLOC would be kind of silly, but the command buffer has to be a dri_bo. So I overloaded the flags parameter of the dri_bo_alloc call to tell the bufmgr what kind of memory the caller wants. 5. dri_bufmgr-API #2: Radeon hardware has some very weird relocation requirements. So far, the only one I've dealt with is that the blitter command contains a dword which combines a buffer offset with a buffer pitch. I've overloaded the emit_reloc flags parameter to tell the bufmgr about the relocation type. I would like to go ahead with this work and merge it back to Mesa master pretty soon (that's the whole point of this little exercise), after making it more complete and running it through thorough testing. Please tell me if I'm running off in a completely stupid direction. Not looked closely at it, but this sounds pretty reasonable to me (ok - the 3 texture copies do not). Any plans on converting r200/radeon too? Yes, the 3 texture copies suck. My plan is to override gl_texture_image like in the intel driver. That way we can go back to 2 texture copies (and eventually a single texture copy with proper memory management). As for r200/radeon: I don't have any such hardware, and I don't want to make massive changes in code that I cannot test. Ok, fair enough. It's just that this is code which probably should be shared between all 3 drivers. There are basically no differences wrt memory management or command submission for those chips, and it would probably simplify maintenance if they could share this code. I'd be happy to help verify the changes on older asics. I can also dig up some old cards to send you if that helps. Alex - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Fwd: Re: glxinfo and client glx vendor string with ATI cards]
On Mon, Jul 28, 2008 at 4:22 AM, Alexandre Conrad [EMAIL PROTECTED] wrote: Hey Corbin, I'm forwarding this email to the public ML. Thanks for the feedback. Regrads, Original Message Subject: Re: [Mesa3d-dev] glxinfo and client glx vendor string with ATI cards Date: Fri, 25 Jul 2008 10:50:07 -0700 From: Corbin Simpson [EMAIL PROTECTED] To: Alexandre Conrad [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexandre Conrad wrote: Philipp Klaus Krause wrote: Maybe this affects only the fglrx driver since I get this with my NVIDIA card: :~$ glxinfo | grep client glx vendor client glx vendor string: NVIDIA Corporation So the NVIDIA drivers (proprietary) seem to put some information here (thus enabling flash hardware accel). So I'm really not trying to make things incorrect, I'm just trying to make things more accurate by filling in more fields as it might have been forgotten. Again, I'm not pointing my finger towards Mesa, I want to figure out who fills in this data. BTW, What does SGI stands for? Nvidia uses their own GLX, so they put NVIDIA corporation in the string. Everyone else uses the GLX initially made by SGI. SGI was a vendor of highend graphics workstations, they played an important role in OpenGL standardization. Lately they're more into supercomputing than graphics. Silicon Graphics rang my bell but I was just unsure how they were related with client glx vendor string thing. That and why nvidia has something else than SGI makes sens to me now. GLX is included in the Mesa tarball. You could change the vendor string in /src/glx/x11/glxcmds.c (currently :static const char __glXGLXClientVendorName[] = SGI;). Great. I'll try to hack this, although I'm not sure to have the compiling skills... Thank you so much Philipp and Michel for your help and suggestions. This definitly cleared things up. I'll point this thread to Adobe. Howdy. Sorry for getting here late. :3 One more caveat: Flash requires the following extensions to be present, even if it is not actually using them, before it will enable OpenGL mode: - - GL_ARB_multitexture (done) - - GL_EXT_framebuffer_object (FBO - mem manager) - - GL_ARB_shader_objects - - GL_ARB_shading_language_100 (GLSL) - - GL_ARB_fragment_shader (done) So we need a memory manager for DRI, and also GLSL, before we can get HW-accelerated Flash. (Thank God they don't just check for OGL 2.0!) There was also a blocker bug with Mesa-based libGL on the Adobe side, but it's been handled. Oh, and finally, the only reason they're not using Xv is because only one DDX driver (nouveau) provides the RGB colorspace needed for Xv -- theoretically, all of the textured-video Xv implementations could support RGB, and this would be fairly easy (I've already got a half-baked patch sitting around for this on xf86-video-ati...) Actually the radeon overlay Xv adapter exposes RGB surfaces as well. Do RGB Xv surfaces really give you anything over using render? Alex - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Fwd: Re: glxinfo and client glx vendor string with ATI cards]
On Mon, Jul 28, 2008 at 10:36 AM, Corbin Simpson [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex Deucher wrote: On Mon, Jul 28, 2008 at 4:22 AM, Alexandre Conrad [EMAIL PROTECTED] wrote: Hey Corbin, I'm forwarding this email to the public ML. Thanks for the feedback. Regrads, Original Message Subject: Re: [Mesa3d-dev] glxinfo and client glx vendor string with ATI cards Date: Fri, 25 Jul 2008 10:50:07 -0700 From: Corbin Simpson [EMAIL PROTECTED] To: Alexandre Conrad [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexandre Conrad wrote: Philipp Klaus Krause wrote: Maybe this affects only the fglrx driver since I get this with my NVIDIA card: :~$ glxinfo | grep client glx vendor client glx vendor string: NVIDIA Corporation So the NVIDIA drivers (proprietary) seem to put some information here (thus enabling flash hardware accel). So I'm really not trying to make things incorrect, I'm just trying to make things more accurate by filling in more fields as it might have been forgotten. Again, I'm not pointing my finger towards Mesa, I want to figure out who fills in this data. BTW, What does SGI stands for? Nvidia uses their own GLX, so they put NVIDIA corporation in the string. Everyone else uses the GLX initially made by SGI. SGI was a vendor of highend graphics workstations, they played an important role in OpenGL standardization. Lately they're more into supercomputing than graphics. Silicon Graphics rang my bell but I was just unsure how they were related with client glx vendor string thing. That and why nvidia has something else than SGI makes sens to me now. GLX is included in the Mesa tarball. You could change the vendor string in /src/glx/x11/glxcmds.c (currently :static const char __glXGLXClientVendorName[] = SGI;). Great. I'll try to hack this, although I'm not sure to have the compiling skills... Thank you so much Philipp and Michel for your help and suggestions. This definitly cleared things up. I'll point this thread to Adobe. Howdy. Sorry for getting here late. :3 One more caveat: Flash requires the following extensions to be present, even if it is not actually using them, before it will enable OpenGL mode: - - GL_ARB_multitexture (done) - - GL_EXT_framebuffer_object (FBO - mem manager) - - GL_ARB_shader_objects - - GL_ARB_shading_language_100 (GLSL) - - GL_ARB_fragment_shader (done) So we need a memory manager for DRI, and also GLSL, before we can get HW-accelerated Flash. (Thank God they don't just check for OGL 2.0!) There was also a blocker bug with Mesa-based libGL on the Adobe side, but it's been handled. Oh, and finally, the only reason they're not using Xv is because only one DDX driver (nouveau) provides the RGB colorspace needed for Xv -- theoretically, all of the textured-video Xv implementations could support RGB, and this would be fairly easy (I've already got a half-baked patch sitting around for this on xf86-video-ati...) Actually the radeon overlay Xv adapter exposes RGB surfaces as well. Do RGB Xv surfaces really give you anything over using render? Ish. If more drivers supported the RGB Xv formats, we might be able to talk the Adobe guy into adding Xv acceleration into Flash. As is, Flash is RGB-based, and they're not interested in bundling a YUV conversion library just for Xv. (Never mind that they're ALREADY doing YUV-RGB in software for Flash Video...) It's just a thought, since I bet we could equip all the DDX drivers with RGB Xv a LOT faster than we could support GLSL and FBOs in Mesa. That's really the only reason I brought it up. Hmm. Now that I think about it, there's a lot of reasons to use Xv in Flash. In video mode, especially full-screen, it would be a lot faster to draw the video controls in YUV mode, and just pass a YUV panel into Xv, than to do the software conversion. But then again, we don't have Flash source code, so this is the best short-term solution I can come up with. Why not use Xv for YUV data, and render for RGB data? Both are available and accelerated on most chips. All RGB Xv support gives you is scaling. With render you not only get scaling, but transforms in general and composite ops. In fact, anholt even proposed adding YUV src formats to render. Alex - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Combining Mesa3D and DRI mailing lists and/or sites?
On Thu, Jun 12, 2008 at 12:56 PM, Tomas Carnecky [EMAIL PROTECTED] wrote: Keith Whitwell wrote: The DRI list has in effect become the list for development of the drm kernel module, libdrm, and the various memory manager implementations. While Mesa is an important client of these, it is far from being the only client. Interesting. Who else is a client of drm? (apart of the ATI driver which, last I heard, uses drm). All of the open source 3D drivers use the drm. Alex - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Sudden pinkness with r300 git
On Mon, Feb 25, 2008 at 8:18 PM, Chris Rankin [EMAIL PROTECTED] wrote: Hi, Something added to git tonight has turned menu boxes in World or Warcraft bight pink :-)! (I'd provide a screenshot, but trying to run WoW while sharing the screen with another application always locks up the GPU.) I have at least been able to rule out the cache-flush change to r300_emit.c, but it's too late to start git-bisecting now. Markus Amsler just posted a fix. Alex - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Help offered
On Dec 26, 2007 6:15 AM, Hugo Gomes [EMAIL PROTECTED] wrote: Hello, I am more into GLSL, what got me really excited about on mesa3D help-wanted web-page was the topics: 4. Help to incorporate the 3Dlabs' shading language compiler for OpenGL 2.0. 5. Implement assembly language (SSE/MMX) code generation for vertex/fragment programs. even though they might be outdated. Also, i don't have much experience either in hardware drivers, or in glsl. I could also work some test cases on the driver or on the glsl compiler, but again experience limits me. Your best bet is to checkout the latest code and dive in. write small demos or play with the code until you start to get a feel for it. That's how we all learned :) If there's anything you don't understand, please ask on the list. Alex On Dec 26, 2007 7:46 AM, Alex Deucher [EMAIL PROTECTED] wrote: On Dec 21, 2007 7:39 PM, Hugo Gomes [EMAIL PROTECTED] wrote: Hello, i'm a student from portugal,and would like to help out with everything i can, on the development of the mesa3d lib. Any suggestions where to start ? What aspect are you looking to hack on? HW drivers? GLSL? Alex - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Help offered
On Dec 21, 2007 7:39 PM, Hugo Gomes [EMAIL PROTECTED] wrote: Hello, i'm a student from portugal,and would like to help out with everything i can, on the development of the mesa3d lib. Any suggestions where to start ? What aspect are you looking to hack on? HW drivers? GLSL? Alex - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] unichrome: just a bit of code cleanup
On Nov 9, 2007 10:58 AM, Brian Paul [EMAIL PROTECTED] wrote: Benno Schulenberg wrote: Alex Deucher wrote: Benno, Since you seem to be the only one working on unichrome support, you might as well get a freedesktop account so you can commit patches directly: Thanks for the offer, but I don't think I qualify for that. I can fiddle a bit with the code, but have no comprehension of how it all works. I'm not sure that anyone understands _all_ of Mesa and the drivers. :) Code clean-ups and comments are always appreciated so you're welcome to get commit ability to do that at least. Plus if you mess around with the code long enough you'll actually understand it :) Alex - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] unichrome: just a bit of code cleanup
Benno,
Since you seem to be the only one working on unichrome support,
you might as well get a freedesktop account so you can commit patches
directly:
http://www.freedesktop.org/wiki/AccountRequests
Alex
On Nov 8, 2007 6:22 PM, Benno Schulenberg [EMAIL PROTECTED] wrote:
Signed-off-by: Benno Schulenberg [EMAIL PROTECTED]
---
src/mesa/drivers/dri/unichrome/via_tris.c | 19 ---
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/unichrome/via_tris.c
b/src/mesa/drivers/dri/unichrome/via_tris.c
index 73e6626..b97dacd 100644
--- a/src/mesa/drivers/dri/unichrome/via_tris.c
+++ b/src/mesa/drivers/dri/unichrome/via_tris.c
@@ -625,13 +625,12 @@ static void viaFastRenderClippedPoly(GLcontext *ctx,
const GLuint *elts,
}
}
+
/**/
/*Choose render functions */
/**/
-
-
#define _VIA_NEW_VERTEX (_NEW_TEXTURE | \
_DD_NEW_SEPARATE_SPECULAR |\
_DD_NEW_TRI_UNFILLED | \
@@ -665,16 +664,17 @@ static void viaChooseRenderState(GLcontext *ctx)
vmesa-drawTri = via_draw_triangle;
}
- if (flags (ANY_FALLBACK_FLAGS|ANY_RASTER_FLAGS)) {
+ if (flags (ANY_FALLBACK_FLAGS | ANY_RASTER_FLAGS)) {
if (ctx-Light.Enabled ctx-Light.Model.TwoSide)
index |= VIA_TWOSIDE_BIT;
- if (flags DD_TRI_OFFSET) index |= VIA_OFFSET_BIT;
if (ctx-Polygon.FrontMode != GL_FILL || ctx-Polygon.BackMode !=
GL_FILL)
index |= VIA_UNFILLED_BIT;
- if (flags ANY_FALLBACK_FLAGS) index |= VIA_FALLBACK_BIT;
+ if (flags DD_TRI_OFFSET)
+ index |= VIA_OFFSET_BIT;
+ if (flags ANY_FALLBACK_FLAGS)
+ index |= VIA_FALLBACK_BIT;
- /* Hook in fallbacks for specific primitives.
- */
+ /* Hook in fallbacks for specific primitives. */
if (flags POINT_FALLBACK)
vmesa-drawPoint = via_fallback_point;
@@ -685,11 +685,8 @@ static void viaChooseRenderState(GLcontext *ctx)
vmesa-drawTri = via_fallback_tri;
}
-
- if ((flags DD_SEPARATE_SPECULAR)
- ctx-Light.ShadeModel == GL_FLAT) {
+ if ((flags DD_SEPARATE_SPECULAR) ctx-Light.ShadeModel == GL_FLAT)
index = VIA_MAX_TRIFUNC; /* flat specular */
- }
if (vmesa-renderIndex != index) {
vmesa-renderIndex = index;
--
1.5.2.5
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] Potential patch for R200 accelerated TFP
On 8/12/07, Chris Rankin [EMAIL PROTECTED] wrote: OK, here it is - the final version. Now given that I am running Fedora 7 at the moment, exactly what will I need to update in order to test it? Are there any official Xorg packages that I will need to grab and compile, or is everything still unreleased from git repositories? shouldn't: - if ( !t || t-base.totalSize == 0 ) + if ( !t || t-base.totalSize == 0 | t-image_override ) be + if ( !t || t-base.totalSize == 0 || t-image_override ) You'll need a fairly recent (post 1.3 xserver) and mesa. you can grab them from git. Redhat may also provide experimental packages. Alex - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] 3D support for 2048x2048 on intel drivers
On 7/25/07, Chase Douglas [EMAIL PROTECTED] wrote: Brian Paul wrote: The rendering code is spread across many files, both in the driver and core Mesa. There's no single point that everything goes through for rendering. I see that there are a lot of functions in i915_state.c that deal with the rendering. Functions such as i915CullFaceFrontFace and i915Scissor (which seems to be clipping). Is the goal to modify those functions such that when they draw a renderbuffer with dimensions 2048 in any direction, that it draws as many times as necessary for sections that aren't within 2048x2048 chunks? If so, how does one move the 2048x2048 render frame to another region, and then render the corresponding region in the renderbuffer there? You'd need to re-program the offset of the 3D engine when you iterate. Alex - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tricky problem with dark corners
On 3/22/07, Michel Dänzer [EMAIL PROTECTED] wrote: On Wed, 2007-03-21 at 00:58 +0300, malc wrote: On Tue, 20 Mar 2007, Michel D?nzer wrote: On Thu, 2007-03-15 at 21:36 +0300, malc wrote: Apparently the problem is that pages obtained by the call to get_user_pages admit caching, so adding flush_dcache_range upon dequeuing buffer in the device driver removes the artifacts. Even with this i still get roughly a 3x speedup compared to grab to some buffer then copy to gart with memcpy. However i believe things can be improved: 1. call glXGetMemoryOffsetMESA 2. tell the driver to grab into special memory with this offset This should avoid the need of having to mess with get_user_pages and caching altogether. Question is though, is this possible at all? Possibly. In fact, it should be easy with a traditional AGP bridge which provides a physically linear view of the aperture to the CPU. Unfortunately, that's not the case with Apple UniNorth bridges, so is this on a Mac or a different PowerPC machine such as a Pegasos? If the former I suspect you may have to hook into the DRM or agpgart to get at the pages backing the AGP mapping. Thanks for the answer, i had a feeling of being either completely offtopic or a subject to overzelous spam filtering. It's a Mac (mini) with UniNorth. I don't mind at all having to deal with non linear mappings, current code is already in this situation. So I think basically you need to determine the mapping of the allocated memory to physical pages and tell the grabber to write to those pages. Unfortunately my knowlege of AGP/GARTs/appertures is virtually non-existent, i was wondering if there's a document that describes the basic concepts to the layman? I don't know of one, but someone on the list might. wikipedia has some basic info: http://en.wikipedia.org/wiki/IOMMU Alex - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] comments on r300_fragprog.c commit
On 3/15/07, Brian Paul [EMAIL PROTECTED] wrote: Some code comments below: Oliver McFadden wrote: src/mesa/drivers/dri/r300/r300_fragprog.c | 91 src/mesa/drivers/dri/r300/r300_state.c | 14 ++-- src/mesa/drivers/dri/r300/r300_state.h |1 src/mesa/drivers/dri/r300/r300_vertexprog.c | 67 +--- 4 files changed, 103 insertions(+), 70 deletions(-) New commits: diff-tree 4e4ab2a62bf33a582420cff85775a6580167b5a9 (from 4d2eb637a20e4fdf5d5f6c0ea4d4627894594661) Author: Oliver McFadden [EMAIL PROTECTED] Also, if you are committing someone else's code, you should use the --author option with git commit. Alex - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Nouveau DRI in mesa git ?
On 12/19/06, Stephane Marchesin [EMAIL PROTECTED] wrote: Hello, We are considering moving the nouveau DRI driver from sourceforge CVS to another place (it's currently at http://nouveau.cvs.sourceforge.net/nouveau/nouveau/). We were wondering if Mesa would accept having an experimental driver in git, maybe disabled by default, or in a branch ? What do you guys think ? Fine with me. r300 was experimental when we first merged it. mach64 was for years. trident and virge probably don't even work. Alex Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] vbo heads up
On 11/2/06, Jerome Glisse [EMAIL PROTECTED] wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Jerome Glisse wrote: On 11/2/06, Keith Whitwell [EMAIL PROTECTED] wrote: Keith Whitwell wrote: OK, the first round of work on the VBO branch seems to have gone quite smoothly. It'd be great if a couple of the key r200/r300 people could check the branch out and verify whether I've broken those drivers or not. It'd be particularly interesting to see if someone (Aapo?) can take a look at the disabled vtxfmt_a code and see if it is easy to port that over to the new archiecture. I've got a feeling it should be fairly straight-forward, as it's simple to fallback to the tnl/ module for any unexpected or non-handled situations. I took a quick look at this and it seems doable. I sketched out a simplified approach that just attempts to hook the existing code into a _radeon_draw_prims() callback. It looks like it might work, but it would be better to try for a deeper integration. I'm pretty bullish about the vbo code would like to see an early merge, so please take a look at this. Keith I investigated recently a bug (8348) and we don't check if in DrawRangeElement max - min won't requiert a memory area bigger than what we can have with DMA (which if i am right can't be bigger than RADEON_BUFFER_SIZE * 16). Do you see any easy they to work around this. I will try to test VBO branch today and complete your change. OK. I've got a couple of bugs to fix yet, and I've still got to try running glean, etc, so it'll be a couple of days before anything happens. But it would be good to have the r200/r300 drivers up to speed prior to a merge. Keith I have tried to play a bit with that but i segfault in vbo_exec_array.c line 127 with varray in progs/redbook know bug or something from my side ? Btw i have thinked a bit more about the need to update max-min vertices in drawelements and drawrangeelements and i don't see an easy way to split the rendering as we have to go throught all indices and make sure that (max-min)*primsize never need more memory than what dma alloc can give us. Don't you have similar problem with intel ? IIRC, radeons don't really have the limit either, I think the buffersize size stuff is a vestage of some past wrong... Didn't Roland look into some buffersize issues a while back? I could be way off though... Alex best, Jerome Glisse - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Merged texmem branch
I just wanted to say thanks to everyone that worked on this. This is a major step forward for open source drivers! Cheers! Alex On 11/1/06, Keith Whitwell [EMAIL PROTECTED] wrote: We've just merged the texmem-0-3-branch code. This has been a major project, probably much bigger than we realized when we started on it. The fundamental technology underpinning the changes is Thomas Hellstrom's new TTM memory manager which dynamically maps buffers into and out of the GART aperture as required for rendering. The benefits that flow from this are: - Vastly increased amount of memory available for texturing. - No need to reserve/waste memory for texture pool when not rendering. - Fast transfers to *and* from video memory. As a result we've been able to build a whole bunch of features into the i915tex driver that haven't been present in DRI-based drivers previously: - EXT_framebuffer_objects, render to texture - ARB_pixel_buffer_objects - Accelerated - CopyTexSubimage - DrawPixels - ReadPixels - CopyPixels - Accelerated texture uploads from pixel buffer objects - Potentially texturing directly from the pixel buffer object (zero copy texturing). If/when other drivers are ported to the memory manager, it will be easy to support VBO's in the same way. Keith - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
