Re: [Mesa3d-dev] mesa doesn't work with compiz (i965 + tips of all branches)
Curious. Admittedly I can't look at the content of that commit, but they
can't be too useless if compiz selects them. IIRC the point was to limit the
runtime of Intel internal tests; can't those tests be amended instead? The
number of configs will only grow; r300g has over 200 now thanks to
multisampling.
Posting from a mobile, pardon my terseness. ~ C.
On Jun 29, 2010 1:28 PM, "Maxim Levitsky" wrote:
On Tue, 2010-06-29 at 20:34 +0300, Maxim Levitsky wrote:
> On Sun, 2010-06-27 at 19:07 +0300, Maxim ...
Bisected this to
73e24cd5a7a0760726a681dda5b88805ddcf1555 is first bad commit
commit 73e24cd5a7a0760726a681dda5b88805ddcf1555
Author: Ian Romanick
Date: Mon Feb 8 10:34:52 2010 -0800
intel: Stop exposing useless 24 depth/0 stencil configs
Signed-off-by: Ian Romanick
Reviewed-by: Kristian Høgsberg
:04 04 5ba858b23d6502d9eaa39a8ec612a38ffae50e2c
0060acef28a49d519aed5a21cbde2bc833f840a8 M src
Reverting this, and removing one assert, fixes compiz
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 61803cf..0f6d1da 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -306,7 +306,7 @@ intelCreateBuffer(__DRIscreen * driScrnPriv,
}
if (mesaVis->depthBits == 24) {
-assert(mesaVis->stencilBits == 8);
+//assert(mesaVis->stencilBits == 8);
/* combined depth/stencil buffer */
struct intel_renderbuffer *depthStencilRb
= intel_create_renderbuffer(MESA_FORMAT_S8_Z24);
Best regards,
Maxim Levitsku
--
This SF.net email i...
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] to Implement on new GPUs
On Thu, Apr 15, 2010 at 7:12 AM, nitesh suthar wrote: > I am using SOC S3C6410 . Google doesn't tell me much about this chip other than that it's made by Samsung and it powers some Android devices. A few posts suggest that it's either a Samsung original, or an SGX-based core. If it's the latter, you are out of luck. SGX does not have any open-source code or free datasheets, and they actively discourage reverse-engineering by levying strong licensing requirements on their binary drivers. Your best bet at this stage may well be to contact Samsung. At any rate, Mesa drivers are implemented by writing code that uses the hooks in the general driver context. src/mesa/drivers are all the drivers, and src/mesa/drivers/dri may be of particular use if you are planning on doing GL with X. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On Tue, Apr 13, 2010 at 6:42 AM, Roland Scheidegger wrote:
> On 13.04.2010 02:52, Dave Airlie wrote:
>> On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul 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.
"""
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] to Implement on new GPUs
On Mon, Apr 12, 2010 at 9:13 PM, nitesh suthar wrote: > hello all, > thank you for reply > Actually I am working on arm board which support OpenGLES 1.1 and OpenGLES > 2.0. > which provides hardware acceleration for redering images. > What my objective is that I want to implement this OpenGLES 2.0 into mesa > for interactive graphics with hardware acceleration to use Mesa in arm board > with this suppurted OpenGLES libraries. > how could I proceed for implement OpenGLES 2.0 in Mesa ? GL and GLES are programming APIs, not hardware APIs. In order to support your hardware, you will have to write a backend driver which interfaces with that hardware for Mesa. We're not all embedded developers, but some of us might be familiar with your hardware. Which chipset and board is this? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler
On Sat, Apr 3, 2010 at 3:10 PM, Zack Rusin wrote: > On Saturday 03 April 2010 17:17:46 Luca Barbieri wrote: >> > > From the compute support LLVM->TGSI translation isn't even about > optimizations, it's about "working". Writing a full C/C++ compiler that > generates TGSI is a lot less realistic than reusing Clang and writing a TGSI > code-generator for it. > So the LLVM code-generator for TGSI would be a very high impact project for > Gallium. Obviously a code-generator that can handle control-flow (to be honest > I'm really not sure why you want to restrict it to something without control- > flow in the first place). > > Having said that I'm not sure whether this is something that's a good GSOC > project. It's a fairly difficult piece of code to write. One that to do right > will depend on adding some features to TGSI (a good source of inspiration for > those would be AMD's CAL and NVIDIA's PTX > http://developer.amd.com/gpu_assets/ATI_Intermediate_Language_(IL)_Specification_v2b.pdf > http://www.nvidia.com/content/CUDA-ptx_isa_1.4.pdf ) > > I thought the initial proposal was likely a lot more feasible for a GSOC (of > course there one has to point out that Mesa's GLSL compiler already does > unroll loops and in general simplifies control-flow so the points #1 and #2 > are > largely no-ops, but surely there's enough work on Gallium Radeon's drivers > left to keep Tom busy). Otherwise having a well-defined and reduced scope with > clear deliverables would be rather necessary for LLVM->TGSI code because that > is not something that you could get rock solid over a summer. Agreed. There are some things here that need to be kept in mind: 1) r300/r500 are not architectures powerful enough to merit general compilation, and they don't mesh well with LLVM. The hand-written optimizations we already have in place are fine for these chipsets. 2) We should leverage LLVM when possible, since we're going to be increasingly dependent on it anyway. 3) Common code goes up, specialized code goes down. That's the entire point of Gallium. Specialized compiler passes that operate on TGSI but are only consumed by one driver should move down into the driver. I think that the first two parts of Tom's original proposal would be better spent on r300 only, taking nha's r300g-glsl work and cleaning and perfecting it. If we can pass all of the GLSL tests (save for the NOISE test) on r300, then we will be far better off as opposed to work on TGSI towards the same goal. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler
nals for R500 fragment and vertex shaders (4 weeks) > 4. More compiler optimizations / other GLSL features (2 weeks) > > Tasks 1-3 will be required for this project. > Task 4 is optional. > > Thank you. Wow! Looks like you're certainly on the right track and you've been doing your research. I would say that the first two items on your list would be fine as a complete project. TGSI streams are tricky to modify, and you may find that you have to write more and more TGSI-specific code as you dig in. (For example, there are no helpers for strength reduction in TGSI yet.) I'll wait for everybody else to chime in, but it looks good so far. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] gallium: fix dri_destroy_option_cache() when optionCache.info is NULL
On Fri, Apr 2, 2010 at 6:44 AM, Yann Droneaud wrote:
> With an Intel 855GM handled by intel_drv, there's a crash with Gallium3D
> enabled DRI driver for Intel i915 (--enable-gallium-intel).
> The Gallium3D driver doesn't support the 855GM as expected by
> intel_drv, it failed to open the screen and give an half
> initialized screen structure to dri_destroy_option_cache():
> optionCache.info is NULL, so it's crashing while trying
> to free array content. This patch at least fix the crash in the function.
>
> Here's some logs of the fixed version:
>
> [ 16274.137] LoaderOpen(/opt/mesa/lib/xorg/modules/drivers/intel_drv.so)
> [ 16274.139] (II) Loading /opt/mesa/lib/xorg/modules/drivers/intel_drv.so
> [ 16274.183] (II) Module intel: vendor="X.Org Foundation"
> [ 16274.183] compiled for 1.8.0, module version = 2.11.0
> [ 16274.183] Module class: X.Org Video Driver
> [ 16274.183] ABI class: X.Org Video Driver, version 7.0
> [ 16274.183] (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
> i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
> E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G,
> 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45,
> 4 Series, G45/G43, Q45/Q43, G41, B43, Clarkdale, Arrandale
> [ 16274.382] (II) intel(0): Integrated Graphics Chipset: Intel(R) 855GME
> [ 16274.382] (--) intel(0): Chipset: "852GM/855GM"
> [ 16276.675] (II) intel(0): [DRI2] Setup complete
> [ 16276.675] (II) intel(0): [DRI2] DRI driver: i915
> debug_get_option: GALLIUM_TRACE = (null)
> debug_get_bool_option: GALLIUM_RBUG = FALSE
> debug_get_bool_option: INTEL_DUMP_CMD = FALSE
> i915_create_screen: unknown pci id 0x3582, cannot create screen
> dri_init_screen_helper: failed to create pipe_screen
> [ 16276.794] (EE) AIGLX error: Calling driver entry point failed
> [ 16276.794] (EE) AIGLX: reverting to software rendering
> [ 16276.794] (II) AIGLX: Screen 0 is not DRI capable
> [ 16276.796] (II) AIGLX: Loaded and initialized
> /opt/mesa/lib/dri/swrast_dri.so
> [ 16276.796] (II) GLX: Initialized DRISWRAST GL provider for screen 0
>
> Signed-off-by: Yann Droneaud
>
> ---
> src/gallium/state_trackers/dri/common/dri_screen.c | 10 ++
> 1 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/state_trackers/dri/common/dri_screen.c
> b/src/gallium/state_trackers/dri/common/dri_screen.c
> index 6fc7487..6e17614 100644
> --- a/src/gallium/state_trackers/dri/common/dri_screen.c
> +++ b/src/gallium/state_trackers/dri/common/dri_screen.c
> @@ -288,12 +288,14 @@ dri_destroy_option_cache(struct dri_screen * screen)
> {
> int i;
>
> - for (i = 0; i < (1 << screen->optionCache.tableSize); ++i) {
> - FREE(screen->optionCache.info[i].name);
> - FREE(screen->optionCache.info[i].ranges);
> + if (screen->optionCache.info) {
> + for (i = 0; i < (1 << screen->optionCache.tableSize); ++i) {
> + FREE(screen->optionCache.info[i].name);
> + FREE(screen->optionCache.info[i].ranges);
> + }
> + FREE(screen->optionCache.info);
> }
>
> - FREE(screen->optionCache.info);
> FREE(screen->optionCache.values);
> }
>
> --
> 1.6.4.4
Applied and pushed, thanks.
In general, this is the correct behavior; screens should fail to be
created if they can't find proper hardware to talk to. Not sure if
that behavior's documented, but it's correct.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] How do we init half float tables?
On Thu, Apr 1, 2010 at 6:17 PM, Luca Barbieri wrote: > Are you sure about this? > > I've tried doing it, and it turns out that basically every Gallium > module needs this initialized. > > For instance: > st/mesa due to glReadPixels > vg/mesa due to vgReadPixels > st/python due to mesa sampling > several programs in rbug to dump textures to disk > softpipe due to texture sampling > nv50 due to static attrbutes > > Also, if translate did not needlessly duplicate the generic format > support, it would also need it, and draw would too. > > Basically everything in Gallium will end up having util_format > initialized, and it seems there are at least 10 different places in > the code where such a call would need to be added (including strange > places like rbug with call pipe*tile* which calls util_format_read*). > > I added it for nv50 before realizing the extent of the changes needed, > but now think it is not really a feasible solution. > > In other words, I think this should be revisited as it results in > cluttering the codebase and creating a somewhat unreliable system. > > I believe that we should either use the global constructor-like > technique I introduced, or do the following: > 1. Pregenerate half float tables > 2. Initialize the S3TC function pointers to stubs that dlopen the > library, initialize the function pointers to the real functions and > then delegate to the real function corresponding to the stub > > More specifically, I think this two-step approach is superior to the > global constructor, but that the global constructor technique may be > useful in other cases where it is not possible to either pregenerate > or have a "free initialization check" due to the S3TC dynamic loading. I still think you might be overthinking this, but whatever. :3 ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium "raw" interfaces
On Thu, Apr 1, 2010 at 1:32 AM, Luca Barbieri wrote: >> Once MS changes interfaces, then there's _no advantage_ to using DX10 >> internally, regardless of what WINE does, and one might as well use >> OpenGL. Wine doesn't change that. > > [resent to ML, inadvertently replied only to Miles] > > Note that my proposal was not to use DirectX 10 internally, but rather > to expose DirectX 10 and promote it initially as an API to test > Gallium and later as the preferred Linux graphics API instead of > OpenGL, for the technical reason that a DirectX 10 over Gallium > implementation carries much less performance overhead than an OpenGL > implementation and is much simpler, due to the superior design of > DirectX 10. > > Using an extended version of DirectX 10 internally could also be an > option, but I don't think it's worth doing that right now and likely > it's not worth at all. > > Also note that Microsoft does not use DirectX 10 or 11 internally > either, but rather uses the "DirectX 10 DDI" or "DirectX 10 Device > Driver Interface", which is also publicly documented. > > The last time Microsoft did an incompatible interface change (DX10), > it was to move away from fixed pipeline support with scattered state > towards a shader-only pipeline with constant state objects. > > Exactly the same change was achieved by the move from the classic Mesa > architecture to the Gallium architecture: you could think of the move > to Gallium as switching to something like DX10 internally, done purely > for technical reasons, partially the same as the ones that prompted > Microsoft to make the transition. > > Actually, while this is not generally explicitly stated by Gallium > designers, Gallium itself is generally evolving towards being closer > to DirectX 10. > The biggest deviations are additional features needed to support > OpenGL features not included in DirectX 10. > > For instance, looking at recent changes: > - Vertex element CSOs, recently added, are equivalent to DX10 input layouts > - Sampler views, also recently added, are equivalent to DX10 shared > resource views > - Doing transfers per-context (recent work by Keith Whitwell) is what DX10 > does > - Having a "resource" concept (also recent work by Keith Whitwell) is > what DX10 does > - Gallium format values where changed from self-describing to a set of > stock values like DX10 > - Gallium format names where later changed and made identical to DX10 > ones (except for the fact that the names of the former start with > PIPE_FORMAT_ and the ones of the latter with DXGI_FORMAT_, and the > enumerated values are different) > - It has been decided to follow the DX9 SM3/DX10 model for shader > semantic linkage as opposed to the OpenGL one > > I recently systematically compared Gallium and DirectX 10, and found > them to be mostly equivalent, where the exceptions were usually either > additional features Gallium had for the sake of OpenGL, or Gallium > misdesigns that are being changed or looked into. > > This is not likely for the sake of imitating Microsoft, but just > because they made a good design, having had made the decision to > redesign the whole API from scratch when making DirectX 10. > It's also probably because VMWare is apparently funding DirectX 10 > support over Gallium, which obviously makes all discrepancies evident > for people working on that, and those are generally because DirectX 10 > is better, leading those people to improve the Gallium design taking > inspiration from DirectX 10. > > Presumably if Microsoft were to change interfaces incompatibly again > (notice that DX11 is a compatible change), Mesa would probably benefit > from introducing a further abstraction layer similar to new Microsoft > interface and have a Gallium->NewLayer module, since such a change > would most likely be a result of a paradigm shift in graphics hardware > itself (e.g. a switch to fully software-based GPUs like Larrabee). > > Also, unless Microsoft holds patents to DirectX 10 (which would be a > showstopper, even though Gallium may violate them anyway), I don't see > any difference from having to implement DirectX 10 or OpenGL, or any > difference in "openness" of the APIs. > It is indeed possible to participate in the ARB standardization > process and some Mesa contributors/leaders do, but I'm not sure > whether this is particularly advantageous: decisions that work well > for Microsoft and Windows are also likely to work well for Linux/Mesa > since the hardware is the same and the software works mostly > equivalently. > > And should some dec
Re: [Mesa3d-dev] GSOC: Gallium R300 driver
On Tue, Mar 30, 2010 at 10:05 AM, Luca Barbieri wrote: > DDX/DDY could cause miscompilation, but I think that only happens if > LLVM clones or causes some paths to net execute them. > > Someone proposed some time ago on llvmdev to add a flag to tell llvm > to never duplicate an intrinsic, not sure if that went through (iirc, > it was for a barrier instruction that relied on the instruction > pointer). > Alternatively, it should be possible to just disable any passes that > clone basic blocks if those instructions are present. > > The non-execution problem should be fixable by declaring DDX/DDY to > have global-write-like side effects (this will prevent dead code > elimination of them if they are totally unused, but hopefully shaders > are not written so badly they need that). We're talking about a HW-specific issue here, not anything that needs global changes. I'm really not sure where you're going with this. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] GSOC: Gallium R300 driver
On Tue, Mar 30, 2010 at 8:37 AM, Luca Barbieri wrote: >> Another idea was to convert TGSI to a SSA form. That would make unrolling >> branches much easier as the Phi function would basically become a linear >> interpolation, loops and subroutines with conditional return statements >> might be trickier. The r300 compiler already uses SSA for its optimization >> passes so maybe you wouldn't need to mess with TGSI that much... >> >>> >>> Is the conditional translation something that only needs to be done >>> in the Gallium drivers, or would it be useful to apply the translation >>> before the Mesa IR is converted into TGSI? Are any of the other drivers >>> (Gallium or Mesa) currently doing this kind of translation? >> >> Not that I know of. You may do it wherever you want theoretically, even in >> the r300 compiler and leaving TGSI untouched, but I think most people would >> appreciate if these translation were done in TGSI. > > It would be nice to have a driver-independent TGSI optimization module. > It could either operate directly on TGSI (probably only good for > simple optimization), or convert to LLVM IR, optimize, and convert > back. > > This would allow to use this for all drivers: note that at least > inlining and loop unrolling should generally be performed even for > hardware with full control flow support. > Lots of other optimizations would then be possible (using LLVM, with a > single line of code to request the appropriate LLVM pass), and would > automatically be available for all drivers, instead of being only > available for r300 by putting them in the radeon compiler. This is orthogonal to the suggested project... -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] GSOC: Gallium R300 driver
On Mon, Mar 29, 2010 at 10:09 PM, Tom Stellard wrote: > On Sat, Mar 27, 2010 at 02:11:54AM +0100, Marek Olšák wrote: >> >> From the driver point of view, we don't have to work on the GLSL compiler >> itself. The Mesa state tracker compiles GLSL to an assembler-like language >> called TGSI which is then translated ([1]) to the R300 compiler ([2]) shader >> representation. The more TGSI we handle, the more GLSL support we get. >> > > Is adding support for the TGSI opcodes that are currently ignored by > r300_tgsi_to_rc.c something that needs to be done? If so, are there > some opcodes you would prefer to see done first? > >> So now the status. r300g GLSL is missing the following features: >> >> 1) Branching and looping >> >> This is the most important one and there are 3 things which need to be done. >> * Unrolling loops and converting conditionals to multiplications. This is >> crucial for R3xx-R4xx GLSL support. I don't say it will work in all cases >> but should be fine for the most common ones. This is kind of a standard in >> all proprietary drivers supporting shaders 2.0. It would be nice have it >> work with pure TGSI shaders so that drivers like nvfx can reuse it too and I >> personally prefer to have this feature first before going on. > > Would you be able to provide a small example of how to convert the > conditionals to multiplications? I understand the basic idea is to mask > values based on the result of the conditional, but it would help me to see > an example. On IRC, eosie mentioned an alternate technique for emulating > conditionals: Save the values of variables that might be affected by > the conditional statement. Then, after executing both the if and the else > branches, roll back the variables that were affected by the branch that > was not supposed to be taken. Would this technique work as well? > > Is the conditional translation something that only needs to be done > in the Gallium drivers, or would it be useful to apply the translation > before the Mesa IR is converted into TGSI? Are any of the other drivers > (Gallium or Mesa) currently doing this kind of translation? > >> * Teaching the R300 compiler loops and conditionals for R500 fragment >> shaders. Note that R500 supports the jump instruction so besides adding new >> opcodes, the compiler optimization passes should be updated too (I think >> they haven't been designed with loops in mind). >> * The same but for R500 vertex shaders. The difference is conditionals must >> be implemented using predication opcodes and predication writes (stuff gets >> masked out). I think this only affects the conversion to machine code at the >> end of the pipeline. >> >> 2) Derivatives instructions fix >> >> It's implemented but broken. From docs: "If src0 is computed in the previous >> instruction, then a NOP needs to be inserted between the two instructions. >> Do this by setting the NOP flag in the previous instruction. This is not >> required if the previous instruction is a texture lookup." .. and that >> should be the fix. > > Is the only problem here that NOP is being inserted after texture > lookups when it shouldn't be? > >> 3) Perspective, flat, and centroid varying modifiers, gl_FrontFacing >> >> I think this is specific to the rasterizer (RS) block in hw ([3]). >> > > For my proposal, I am thinking about a schedule that looks > something like this (in this order): > > 1) Branching and looping - 4 to 6 weeks > 2) Derivatives instructions fix - 1 to 2 weeks > 3) Adding support for priority TGSI_OPCODES - 3 to 4 weeks > 4) Perspective, flat, and centroid varying modifiers, gl_FrontFacing > and Adding support for more TGSI_OPCODES - (if there is time left)* > > *GSOC lasts for 12 weeks. > > I would appreciate feedback on the order or the time estimates in this > schedule. I am sure some of the developers will have a better idea > how long some of these tasks might take. Also, if there is something > important that I am leaving out or something not important that I have > included let me know. This seems reasonable. The missing opcodes are all related to branches and loops, AFAIR, so you'll be working with those. Go ahead and set up your proposal on the GSoC site; we'll let you know if it needs tuning or tweaking. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds
On Mon, Mar 29, 2010 at 5:50 PM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Philipp Klaus Krause wrote:
>
>> Well, there is TexSubImage2D. Assuming we have a compressed texture
>> stored internally as some S3TC format and then the application replaces
>> part of it using TexSubImage2D. According to ARB_texture_compression we
>> may not go to uncompressed ("the allocation and chosen compressed image
>> format must not be a function of any other state and cannot be changed
>> once they are established". And while ARB_texture_compression does not
>> require TexSubImage2D support, EXT_texture_compression_s3tc does.
>
> Ah. Good catch. My best guess is that there are few, if any, apps that
> do that. Such apps would be easy to detect. We could enable the
> non-conformant behavior by default, and provide a driconf switch to
> disable it. We'd then need to blacklist apps that use unsupported
> cases. Since we can detect these cases, we can log a message when the
> occur.
>
> Does that seem like a reasonable compromise?
We don't have to compromise at all. If the image is already compressed
internally, then updating it with TexSubImage or CompressedTexSubImage
must be done along the block boundaries, and must be done with
pre-compressed blocks, so we are never decompressing and recompressing
the texture.
I've pushed a branch, s3tc-by-the-book, to my personal repo
(http://cgit.freedesktop.org/~csimpson/mesa/?h=s3tc-by-the-book), that
changes to this newer behavior. I haven't written up test cases for
these delightful corners and edges we're finding, but they shouldn't
be too hard to handle. The basic idea behind this branch is that if
the internal format request indicates that GL should compress the
texture with S3TC, but we don't have libdxtn present, we just change
the internal format to something more sensible and refuse to compress.
Comments and flames welcome.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds
allocated buffer. * Save the returned compressed image to disk, along with the associated width, height, depth, border parameters and the returned values of TEXTURE_COMPRESSED_IMAGE_SIZE_ARB and TEXTURE_INTERNAL_FORMAT. * Load the compressed image and its parameters, and call CompressedTexImage_[123]DARB to use the compressed image. The value of TEXTURE_INTERNAL_FORMAT should be used as and the value of TEXTURE_COMPRESSED_IMAGE_SIZE_ARB should be used as . The saved images will be valid as long as they are used on a device supporting the returned parameter. If the saved images are used on a device that does not support the compressed internal format, an INVALID_ENUM error would be generated by the call to CompressedTexImage_[123]D because of the unknown format. Note also that to reliably determine if the GL will compress an image without actually compressing it, an application need only define a proxy texture image and query TEXTURE_COMPRESSED_ARB as above. """ So this gives us a way to language-lawyer our way out of that entire half of the implementation. The other half, decompression, works if the compressed format is supported as a texture: see decompress_with_blit in the Gallium source. Gallium actually explicitly enables the basic parts of the extension based on whether or not it can use the compressed formats as samplers. (I am not sure if it's going to be that easy for classic Mesa.) So I think this covers all the paths, assuming Mesa implements the internal_format semantics necessary, although I haven't done any code-reading this morning yet. Ian, Brian, could you check my reasoning? We might be able to save this. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [radeonhd] Re: Status of s3tc patent in respect to open-source drivers and workarounds
On Sun, Mar 28, 2010 at 6:39 PM, SpliFF wrote: > Solves nothing other than push the legal burden onto someone else > (distributions) who further push the burden to the end-user. All of > which makes it harder to use. As far as I can tell the official site of > the "external project" claims the project is unmaintained and at any > rate it's rather unpopular with certain distributions for reasons that > should be obvious. > > I'm certainly not sugesting that knowingly infringing material be added > to mesa3d. What I'm suggesting is that some resources be made available > to write a new *non-infringing* decompressor and that it seems likely > the community may have overestimated the difficulty of the task. I often > wonder if the OSS community isn't becoming a victim of its own FUD. If > we need lawyers before writing code then we can't write ANY code and we > might as well all do something else. There is already a non-infringing decoder inside Mesa, wired up correctly, that kicks in when the HW supports it, but there's no extension that exposes only decoding and loading functionality. As Ian said, you need an encoder as well, and no HW has it, so you'd have to write some questionable code. > I want to reiterate that it is my belief (as in non-legal opinion) that > the s3tc patent does not cover the s3tc format itself, or even specific > algorithms. What it covers appear to be specific methods that can be > used to encode it and some steps that can be used to decode it. The > issue is whether those claimed steps are the ONLY way of achieving an > acceptable result and I honestly don't think they are. You are free to > form your own opinion on that point. Then again if the community plays > ostrich and assumes the problem is now solved - and worse concludes that > any discussion of it is heresy - then how can a new invention be > developed (at least collaboratively)? Unfortunately I lack the indepth > knowledge of mesa3d internals and s3tc processing requirements required > to invent such a thing myself. Cool, I'm glad that you share the opinion of other people on the Internets on this issue. Feel free to help keep libdxtn from bitrotting. However, many of the Mesa devs are paid, and their bosses have indicated that there are issues here, so don't hold your breath for any of us to do anything beyond maintain the interface to libdxtn. I'm kind of confused. Are you just trying to see if any of us can be convinced to write this code for you? > Unfortunately Spring is an engine, not a game. The issue is that people > writing games which use the engine typically use DDS textures due to > various community members bandying the format about like it's the second > coming. At any rate other than not supporting DDS at all (which would be > an extremely unpopular and unworkable decision) there isn't much I can > do to guarantee Spring games don't depend on proprietary drivers until a > non-infringing s3tc decoder exists. > > SpliFF > Well, I can't help you there. I'm sorry if I'm sounding antagonistic, but we've been over this many times. The patents, to me and to many people who ostensibly have received better legal advice, are too broadly written to be worked around. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds
ver). I really hope that as a community we can either invent > around this patent or bust it (at least in US / EU where it is most > problematic) without losing hardware support or requiring the > reformatting/conversion of digital assets.\ Since neither you nor Andrew are lawyers, I would kindly ask that you refrain from attempting to provide legal advice. :3 The scant legal advice that *has* been obtained suggests that the current course of action, wherein S3TC is not advertised without the aid of an external library or a configuration option force-enabling it, is the best course of action. I for one would prefer to have firsthand legal advice before making any changes, although I am not a lawyer and cannot provide legal advice. At any rate, since Spring is open-source, I would heavily advise the Spring team to remember that OpenGL extensions that are not part of a core version are not guaranteed to be available, and in this case, there is a trivial workaround for when the extension is not present, so you guys could (and should!) include an uncompressed texture path and ship uncompressed textures. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium "raw" interfaces
On Sun, Mar 28, 2010 at 12:19 PM, Luca Barbieri wrote: > I posted something similar some time ago, that however could use > hardware accelerated drivers with DRI2 or KMS, provided a substantial > set of helpers and offered a complement of 3 demos. > > My solution to window-system issues was to simply have the application > provide a "draw" callback to the framework, which would automatically > create a maximized window with the application name in the title, and > call draw in a loop, presenting the results. > > Then I had a path that woud use the X DRI2 interface if possible, and > another path that would use the Linux DRM KMS API (and initially some > EGL+ad-hoc extension paths that were later dropped). > > It no longer works due to Gallium interface changes, but maybe it can > be resurrected and merged with graw. > > However, there is a disadvantage to having Gallium programs in-tree: > they break every time the Gallium interface in changed and avoiding > that means that in addition to fixing all drivers and state trackers, > you also need to fix all programs for each change Presumably this will no longer be a problem when Gallium is a more mature, stable interface. I much prefer this "try it and see" mentality over the design-by-committee mess that has popped up elsewhere. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Rationale of gallium-resources changes?
On Sat, Mar 27, 2010 at 5:34 PM, Luca Barbieri wrote: > Having drivers capable of doing "send-to-hardware-and-forget-about-it" > on arbitrary state setting could be a nice thing instead, but > unfortunately a lot of hardware fundamentally can't do this, since for > instance: > 1. Shaders need to be all seen to be linked, possibly modifying the > shaders themselves (nv30) > 2. Constants need to be written directly into the fragment program (nv30-nv40) > 3. Fragment programs depend on the viewport to implement > fragment.position (r300) > 4. Fragment programs depend on bound textures to specify normalization > type and emulate NPOT (r300, r600?, nv30) > and so on... > 5. Sometimes sampler state and textures must be seen together since > the hardware mixes it To be fair, this is all "old hardware sucks at new APIs." We're stretching a bit with r300 and nv30, hardware never really meant for this kind of generalized pluggable pipeline setup. r500 and nv40 are better, but it's not until r600 and nv50 that we really are completely unburdened from all of this old suckage. That's life, unfortunately. Also, I'm sure there's always going to be hardware that has quirks, regardless of the set of functionality we expose. We're just going to have to aim for the biggest common subsets plus the least painful way of adding the full pipeline features. Gallium thankfully no longer resembles its original target too much, but it's become a reasonable abstraction. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] GSOC: Gallium R300 driver
On Tue, Mar 23, 2010 at 12:13 AM, Corbin Simpson wrote: > Good question. There's a handful of things. Passing piglit might be a > good goal. Bumping the GL version further up, or solidifying the GLSL > support, might be good too. Oh, and how could I forget this? We have a sizeable todo list: http://dri.freedesktop.org/wiki/R300ToDo ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] GSOC: Gallium R300 driver
On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard wrote: > On Thu, Mar 18, 2010 at 03:25:04PM -0700, Corbin Simpson wrote: >> >> Nifty. Well, there's a few places to look for information. >> >> If you're not sure how the actual video card works, >> http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork is a >> great starting point. Of particular interest is the 3D engine; r300g >> only talks to the 3D part of the video card. >> >> The reference Gallium driver is probably identity, although softpipe >> is a good reference as well. We also have documentation for the >> Gallium API and associated bits; if you don't want to build it >> yourself from the Mesa tree, there should be an up-to-date copy at >> http://people.freedesktop.org/~csimpson/gallium-docs/. (If there's a >> problem with the documentation, lemme know!) >> > > Thanks for the information. > > After spending some time learning about the Gallium driver architecture, I > think it might be better to set a goal to implement or improve a specific > feature of the Gallium R300 driver rather than trying to get a specific > game or application to work. Is there a feature that is currently missing > from the R300 driver that might make a good project for the summer? Good question. There's a handful of things. Passing piglit might be a good goal. Bumping the GL version further up, or solidifying the GLSL support, might be good too. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] GSOC: Gallium R300 driver
On Thu, Mar 18, 2010 at 12:30 PM, Tom Stellard wrote: > Hi, > > I am interested in working on the Gallium R300 driver as a part of > Google Summer of Code. I would like to try and target a specific game, > probably Civilization 4, and get it working as well as possible. I am > interested in getting some feedback on whether or not this is a good > goal for the summer. In the past, I have filed bug reports and done some > testing of the mesa drivers, but I have not spent a lot of time looking at > the code. Where is a good place for me to start looking through the code? > Is there a reference Gallium driver I can look at to get a good idea of > how the drivers are structured? Nifty. Well, there's a few places to look for information. If you're not sure how the actual video card works, http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork is a great starting point. Of particular interest is the 3D engine; r300g only talks to the 3D part of the video card. The reference Gallium driver is probably identity, although softpipe is a good reference as well. We also have documentation for the Gallium API and associated bits; if you don't want to build it yourself from the Mesa tree, there should be an up-to-date copy at http://people.freedesktop.org/~csimpson/gallium-docs/. (If there's a problem with the documentation, lemme know!) ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
On Wed, Mar 17, 2010 at 6:13 PM, Luc Verhaegen wrote: > On Wed, Mar 17, 2010 at 12:28:39AM +0100, Luc Verhaegen wrote: >> Modularized dri drivers and an SDK enabled mesa tree are available in my >> personal git repos at http://cgit.freedesktop.org/~libv/ >> >> The SDK enabled mesa tree adds to the mesa build system to create shared >> libraries libmesadri and libmesadricommon. It creates the relevant .pc >> files and installs the necessary headers include/mesa/ (and updates >> glcore.h). The patch is about 300 lines each time, and only adjusts the >> build system. >> >> The modularized drivers are fully autotooled and can be built and >> installed the familiar way once the dependencies are available >> (currently, libdrm and the dri sdk, and some driver specific libdrms for >> i9xx and radeon). These drivers are i810, i9xx (i915 and i965), mach64, >> mga, r128, radeon (also includes r200, r300 and r600), savage, sis, tdfx >> and unichrome. >> >> This work was done for currently 16 versions between mesa 7.0 and the >> freshly tagged 7.8-rc1, all were extensively and oft repeatedly built >> through. 5 versions were also run tested (glxinfo, glxgears) for the >> radeon and unichrome drivers, and the swrast driver was also tested >> several times. Such a large range of versions was handled to prove the >> long term feasability of this. >> >> This work satisfies my requirements from my "TODO: Mesa" slide from my >> fosdem talk, for which the slides are available at: >> http://people.freedesktop.org/~libv/graphics_driver_stack_(FOSDEM2010_-_slides)$ >> >> This only handles the DRI part of things, gallium seems to be more in >> flux atm, and from what i hear, it should be easier to have modular >> drivers there. >> >> Comments, additions, changes? >> >> Thanks, >> >> Luc Verhaegen. > > After giving the mesa3d-dev list the opportunity to have a whole day of > deafening silence, maybe the other lists should join in on that fun :p Hey Luc, Wow. This is pretty nifty. Lots of work here, obviously. I do have a couple of questions, though: ~) Did you know about or use the automake branch that Eric and I have had floating around for a while? ~) Do you think it's gonna be tenable to ship the drivers with lots of shared code (i915/i965, radeon/r200/r300/r600) like this? Seems like we might run into the situation we've got right now with the X server and DDX drivers, where it might be easier to move some drivers back in. Also (warning: sore subject!) it reminds me of the mesa/drm tree and the same problems with keeping code in two locations... Maybe that's just me. As far as Gallium goes, I really wouldn't worry about it. From what I can tell, the people that actually care about header stability have been using really specific versions of the interface in their own shipped bundles, and there's far too much mainline work going on right now to really even attempt this kind of splitting. I think there's a total of five branches right now that will change the entire Gallium interface, all getting prepared for merge? Lots of churn. Gallium's all mix'n'match though, so it shouldn't be a big deal further down the road. Sorry for not speaking up sooner; it's finals week and my attention to every single email in my box is rather limited. :3 ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Galuim3d alteration idea. Cache and common storage for glsl to native gpu conversions .
On Sat, Mar 13, 2010 at 3:13 AM, Peter Dolding wrote: > http://ccache.samba.org/ is where part of this idea comes from. > > > Speeding up glsl conversion to gpu code will make things more effective. > There is no point running the glsl to native gpu conversions more times than > that are require particularly on devices or anything that is depending on > battery life. > > This brings me to the second half of the idea common storage framework. > > Directory struct that comes to mind for me. > > /usr/shared/galuim3d filename> > > Target would contain glsl for like the raw glsl and like R300 for card > particular implementations as per a list. > > Of course version of compiler would have to be stuck at the start of the > pre built GPU code and checked on load. If out of date rebuild. > > Then like a opengl extension to request shared glsl code access. > galuim3dloader(application,shader,version) direct. > galuim3dloaderlatest(application,shader) just to load the newest version of > that shader. > > Few advantages of common glsl storage applications able to share glsl code > like they can share libraries making it simple to implement fancy features > on the gpu. Able to reduce how much glsl code has to be built to > particular cards. And the possibility of allowing applications to migrate > from card to card of different types without issues. Reason shader > information commonally exposed. > > Same kind of caching for opencl would also be good. No point wasting > cpu/gpu time running compilers when we can cache or store the results. > > Of course these ideas really were not possible to implement without access > to raw GPU native code. Already done, at least the parts that make sense. We have a system called CSO (Constant State Objects) that caches native shader objects. We don't store them as files for a handful of reasons; the largest reason is that shaders need to be recompiled depending on other state inside the driver. -- Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): st/mesa: Always recalculate invalid index bounds.
On Fri, Mar 12, 2010 at 6:53 PM, Roland Scheidegger wrote: > On 13.03.2010 03:20, Corbin Simpson wrote: >> I've pushed a revert of the original patch, and an r300g patch that, >> while not perfect, covers the common case that Wine hits. > > I think I don't really understand that (and the fix you did for r300g). > Why can't you simply clamp the maxIndex to the minimum of the submitted > maxIndex and the vertex buffer max index? > > Now you have this: > maxIndex = MIN3(maxIndex, r300->vertex_buffer_max_index, count - minIndex); > > This is then used to set the hardware max index clamp. However, for > example count could be 3, min index 0, but the actual vertices fetched > 0, 15, 30 - as long as the vertex buffers are large enough this is > perfectly legal, but as far as I can tell your patch would force the > hardware to just fetch the 0th vertex (3 times). Count really tells you > nothing at all about the index range (would also be legal to have huge > count but very small valid index range if you fetch same vertices > repeatedly). That's why I said that it's not perfect. :3 r300->vertex_buffer_max_index is, on this particular rendering path, *also* bogus, which is too bad because it should be used instead of maxIndex/minIndex here. But, as I said before, if it's too big then it can't be used, and we need to err on the side of caution if we err at all. One misrendered draw call is better than dropping the entire packet of commands on the floor. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): st/mesa: Always recalculate invalid index bounds.
On Fri, Mar 12, 2010 at 5:20 PM, Jose Fonseca wrote: > Because if you have a huge vertex buffer and you only draw few indices you > may choose to upload to VRAM only the vertices actually referred. > Applications do this. And for certain hardware uploads are very slow, so it > is an worthwhile optimization. Sure, not saying that it's not. > Efficiency is just or more important goal than principles like "state tracker > should sanitize". There is hardware that can handle buffers with out of > bounds indices without crashing. The APIs we expose also make the same > promise. In such situation the shortcomings on one hardware should not be > taxed to all. Oh, it's not a hardware limitation. If the vert and elt indices aren't clamped, then an attacker could theoretically retrieve bits of VRAM/GTT he shouldn't be allowed to peek at. In order to prevent this, the radeon kernel module requires that I set those clamps, and that they be within the bounds of the various buffers being used for rendering. I wouldn't call it a shortcoming so much as a security consideration. I've pushed a revert of the original patch, and an r300g patch that, while not perfect, covers the common case that Wine hits. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): st/mesa: Always recalculate invalid index bounds.
This seems to be at odds with the idea that the pipe driver receives
pre-sanitized inputs. If this patch is reverted:
- I can't trust the min and max elts, because they're set to ~0
- I can't just use the vertex buffer sizes, because they're set to ~0
So I have to do the maths myself, guessing just like st/mesa guesses. Maybe
this is specific to Radeons, but I *always* need those values.
I don't mind this, but IMO it *must* be doc'd, "The minimum and maximum
index limits passed to draw_elements and draw_range_elements may be
invalid," and really, at that point, why are we even passing them? Seems
absurd to me. :3
Posting from a mobile, pardon my terseness. ~ C.
On Mar 12, 2010 5:40 AM, "Keith Whitwell" wrote:
On Fri, 2010-03-12 at 02:54 -0800, Corbin Simpson wrote:
> Module: Mesa
> Branch: master
> Commit: 50876ddaaff72a324ac45e255985e0f84e108594
> URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=50876ddaaff72a324ac45e255985e0f84e108594
>
> Author: Corbin Simpson
> Date: Fri Mar 12 02:51:40 2010 -0800
>
> st/mesa: Always recalculate invalid index bounds.
>
> These should always be sanitized before heading towards the pipe driver,
> and if the calling function explicitly marked them as invalid, we need
> to regenerate them.
>
> Allows r300g to properly pass a bit more of Wine's d3d9 testing without
> dropping stuff on the floor.
>
> ---
>
> src/mesa/state_tracker/st_draw.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_draw.c
b/src/mesa/state_tracker/st_draw.c
> index 8b01272..d81b361 100644
> --- a/src/mesa/state_tracker/st_draw.c
> +++ b/src/mesa/state_tracker/st_draw.c
> @@ -542,9 +542,9 @@ st_draw_vbo(GLcontext *ctx,
> assert(ctx->NewState == 0x0);
>
> /* Gallium probably doesn't want this in some cases. */
> - if (!index_bounds_valid)
> - if (!vbo_all_varyings_in_vbos(arrays))
> - vbo_get_minmax_index(ctx, prims, ib, &min_index, &max_index);
> + if (index_bounds_valid != GL_TRUE) {
> + vbo_get_minmax_index(ctx, prims, ib, &min_index, &max_index);
> + }
Corbin,
This isn't really desirable. Ideally this range checking should be
pushed into pipe driver, because it's an expensive operation that is not
necessary on a lot of hardware. #
Specifically, vertex fetch hardware can often be set up with the min/max
permissible index bounds to avoid accessing vertex data outside of the
bound VB's. This can be achieved by examining the VBs, with min_index
== 0, max_index = vb.size / vb.stride.
The case where we need to calculate them internally is if some data is
not in a VB, meaning we can't guess what the legal min/max values are.
Also note that we need that min/max information to be able to upload the
data to a VB.
So, I think the code was probably correct in the original version -
defer the minmax scan to the hardware driver, which may or may not need
it.
But maybe there is a better way to let the driver know that we are not
providing this information.
Keith
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] mesa vbo validation issue [was Re: Wine/Gallium indexed strided VBO fail]
On Wed, Mar 10, 2010 at 7:11 AM, Brian Paul wrote:
>>> get_arrays_bounds: Handling 2 attrs
>>> attr 0: stride 16 size 12 start (nil) end 0xfffc
>>> attr 1: stride 16 size 4 start 0xc end (nil)
>>> buffer range: (nil) 0xfffc range -4 max index 4294967295
>
> Can you post the patch you used to print this info, Corbin?
Inlined:
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 8a6e1ed..7ae152c 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -293,6 +293,8 @@ get_arrays_bounds(const struct st_vertex_program *vp,
const GLubyte *high_addr = NULL;
GLuint attr;
+ debug_printf("get_arrays_bounds: Handling %u attrs\n", vpv->num_inputs);
+
for (attr = 0; attr < vpv->num_inputs; attr++) {
const GLuint mesaAttr = vp->index_to_input[attr];
const GLint stride = arrays[mesaAttr]->StrideB;
@@ -301,6 +303,8 @@ get_arrays_bounds(const struct st_vertex_program *vp,
_mesa_sizeof_type(arrays[mesaAttr]->Type));
const GLubyte *end = start + (max_index * stride) + sz;
+ debug_printf("attr %u: stride %d size %u start %p end %p\n",
attr, stride, sz, start, end);
+
if (attr == 0) {
low_addr = start;
high_addr = end;
@@ -348,7 +352,7 @@ setup_interleaved_attribs(GLcontext *ctx,
const GLubyte *low, *high;
get_arrays_bounds(vp, vpv, arrays, max_index, &low, &high);
- /*printf("buffer range: %p %p %d\n", low, high, high-low);*/
+ printf("buffer range: %p %p range %d max index %u\n", low,
high, high-low, max_index);
offset0 = low;
if (userSpace) {
>>> So right here (from device.ok) we have interleaved userspace VBO, that is
>>> being
>>> prepped inside core Mesa. Two delightful things here; the first attr
>>> seems way
>>> off-base, it shouldn't dare be giving us bad pointers, and the second
>>> attr's
>>> pointers don't even line up!
>>
>> In VBO rendering, the pointers are really just offsets into the VBO, so
>> should be interpreted as numbers.
>>
>> The first attribute has what looks like a small negative number. I
>> don't know if that's legal or not in GL - I suspect it is probably not
>> legal and should be rejected in the mesa validation code.
>
> This would have come in via the 'ptr' argument to one of the
> glVertex/Color/etcPointer() functions. We never check for negative pointer
> values.
Just started digging into this again, finally have spare time (if only
for a few days.) I will hopefully have a followup soon.
~ C.
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin Simpson
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium questions ...
On Thu, Mar 11, 2010 at 9:13 AM, Jerome Glisse wrote: > Also i think GLSL state that the sampler information should be defined > at shader build time but the TGSI doesn't seems to provide those, for > r600 i need to have a shader rewritting because of this (it's not big > and i don't mind much and i also can avoid rewritting by checking if > there is a change in the bound sampler). Yeah, welcome to TGSI. You'll have to do like r300g and recompile the shader. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] mesa vbo validation issue [was Re: Wine/Gallium indexed strided VBO fail]
On Wed, Mar 10, 2010 at 6:59 AM, Keith Whitwell wrote: > It's great you found a bug, but why all the excitement? Just track it > down and propose a fix. Mesa's pretty well debugged, but there are > always going to be new issues. I'm not sure why it warrants this type > of implicit criticism when you come across something new. I wasn't aware of any implicit criticism in my post. If I said something wrong, I'm sorry; I'm a little bit fried from studying for a final, and what started as a relaxing diversion from math review has kind of turned into a multi-package bug and increased my frustration more than just a bit. I'll check the specs later and see if there's validation code missing, and also see if Wine needs similar patches. Again, sorry and thanks. ~ C. -- Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Wine/Gallium indexed strided VBO fail
I don't know the VBO code that well, so I'm asking you guys if this has ever come up before. http://bugs.winehq.org/show_bug.cgi?id=22000 Gallium and indexed rendering are not very happy with each other. I get some fairly solidly reliable segfaults with both a d3d9 DLL test (device.ok) and Civ4 (Steam version). Hardware is a Radeon R580 (X1900), driver is r300g from Mesa git. My current guess, based on the Mesa debug info I dumped, is that the indexed rendering code is slightly baked and maybe trusting the underlying GL driver a bit too much. get_arrays_bounds: Handling 2 attrs attr 0: stride 16 size 12 start (nil) end 0xfffc attr 1: stride 16 size 4 start 0xc end (nil) buffer range: (nil) 0xfffc range -4 max index 4294967295 So right here (from device.ok) we have interleaved userspace VBO, that is being prepped inside core Mesa. Two delightful things here; the first attr seems way off-base, it shouldn't dare be giving us bad pointers, and the second attr's pointers don't even line up! Compare to a sane program (Mesa's drawarrays): get_arrays_bounds: Handling 2 attrs attr 0: stride 16 size 12 start 0x8087020 end 0x808705c attr 1: stride 16 size 4 start 0x808702c end 0x8087060 buffer range: 0x8087020 0x8087060 range 64 max index 3 r300g doesn't really care. The kernel drops the rendering on the floor for a variety of reasons, not least being the ridiculous max_index. But then it segfaults, and I have zero idea why. I'd guess it's something to do with tossing around NULL pointers like candy, but I'm honestly not sure and I haven't really dug into the DLL code yet. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] Minor gallium changes
On Tue, Mar 9, 2010 at 6:37 AM, José Fonseca wrote: > On Mon, 2010-03-08 at 15:28 -0800, Brian Paul wrote: >> 1. Rename pipe_sampler_state:min_mip_filter to mip_filter. >> >> I don't know that the "min" part of that field refers to. >> >> >> 2. Remove PIPE_MAX_TEXTURE_LEVELS from p_state.h >> >> This token isn't used anywhere in the gallium interface anymore, nor >> the state trackers. I've already removed the use of this token in the >> gallium drivers (use per-driver #defines instead). There's still some >> use in the blitter code though. > > This looks fine. > >> 3. BTW, none of these #defines are used in the gallium interface >> header files: >> PIPE_MAX_CONSTANT_BUFFERS >> PIPE_MAX_ATTRIBS >> PIPE_MAX_SAMPLERS >> PIPE_MAX_VERTEX_SAMPLERS >> >> They are used in the utility code and drivers though. Should we >> define these in the gallium interface if they're not used by the >> interface itself? > > PIPE_MAX_SAMPLERS / PIPE_MAX_VERTEX_SAMPLERS are the maximum argument > set_fragment_sampler_textures/set_vertex_sampler_textures. These are > indeed unnecessary given that there are corresponding caps queries. So > state trackers should use arrays big enough to represent the API limits, > and pipe drivers should use arrays big enough to represent the hardware > limits, and both should agree on what's passed via the caps. > > Ditto for PIPE_MAX_CONSTANT_BUFFERS. > > I'm not sure about PIPE_MAX_ATTRIBS though. Can't find a caps for it. Since the drivers need to know those limits, can we doc them? I've been looking them up in the headers when I need to see their values, and I know I'm not the only one. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-sw-api-2, cell driver alert!
On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell wrote: > This leaves r300g as the only remaining user of > pipe_winsys/u_simple_screen - which means we can rename that code > r300_winsys and pull it into that driver... Dave had some code that "fixes" this, I think. I more or less agreed to stay out of it, but I might take a look if killing u_simple_screen is a priority. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?
2010/3/8 Ian Romanick : > Okay. I'm convinced. I'll leave it up to the r600 maintainers to make > the final call. However, they really need to do it before RC1 (March 12th). Thread hijack! Are docs changes okay? I'd like to note that r300g works for the simpler things in life, that bugs may be filed against it, and that it's been taken off the all-kitten diet. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r600 pixel_buffer_object for 7.8?
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. ~ C. 2010/3/6 Török Edwin : > Hi Andre, > > I've been using your patch that enables pbo on r600: > http://cgit.freedesktop.org/~andrem/mesa/commit/?h=r600-test&id=6ee755760d124c85bdfd121fd491f68fccca84f7 > > Are you considering enabling it in Mesa 7.8? > > Some games won't even start without pbo support (for example Heroes of > Newerth). > > Even if gameplay isn't perfect (there are some rendering artifacts[1], > and some effects are slow [2]) at least the game starts with that patch. > > [1] which is not related to your pbo patch, I see artifacts w/o it too > in other games, and blender: > https://bugs.freedesktop.org/show_bug.cgi?id=26735 > [2] which can be turned off, like refraction > > Best regards, > --Edwin > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?
FYI r300 only supports 24 interpolators: 16 linear and 8 perspective. (IIRC; not in front of the docs right now.) r600 supports 256 fully configurable interpolators. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge
R300 could benefit. I will push a patch to make it more useful after the merge. Posting from a mobile, pardon my terseness. ~ C. On Mar 1, 2010 11:32 AM, "Roland Scheidegger" wrote: On 01.03.2010 19:02, Roland Scheidegger wrote: > Hi, > > this branch turns vertex element into a cs... Ok, I've converted nv30/nv40 too. Not that they'd precalculate any hw state... Roland -- Download Int... -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium software fallback/draw command failure
Wow, this really got a lot of discussion. I don't really care *where* the sanity code is, but it just seems horribly wrong that it's got to be duplicated between per-hook per-driver in a library that purports simplified drivers with reduced LOCs. I suppose it's unavoidable to a degree as long as driver setup is bare, though. There are alternatives to every single bad draw case, but handling them correctly needs to be required and documented, and that means we probably have to agree on them. Examples: - Oversized colorbufs are forbidden; if you absolutely need them, I could cook up a u_shatter but it's going to be hilariously slow due to CPU blits - While not all textures can fit into VRAM, find the biggest texture and shrink it - Too many verts or too many indices are handled by multiple draw calls - If the bound pipeline is incomplete (at least one state bound to NULL or unset), results are undefined Async errors make sense, or at least more sense than no error reporting at all. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium software fallback/draw command failure
On Sun, Feb 28, 2010 at 9:15 PM, Dave Airlie wrote:
> On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt wrote:
>> On Sun, 2010-02-28 at 20:25 +0100, Jerome Glisse wrote:
>>> Hi,
>>>
>>> I am a bit puzzled, how a pipe driver should handle
>>> draw callback failure ? On radeon (pretty sure nouveau
>>> or intel hit the same issue) we can only know when one
>>> of the draw_* context callback is call if we can do
>>> the rendering or not.
>>>
>>> The failure here is dictated by memory constraint, ie
>>> if user bind big texture, big vbo ... we might not have
>>> enough GPU address space to bind all the desired object
>>> (even for drawing a single triangle) ?
>>>
>>> What should we do ? None of the draw callback can return
>>> a value ? Maybe for a GL stack tracker we should report
>>> GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line
>>> is i think pipe driver are missing something here. Any
>>> idea ? Thought ? Is there already a plan to address that ? :)
>>>
>>> Cheers,
>>> Jerome
>>
>> I think a vital point you're missing is: do we even care? If rendering
>> fails because we simply can't render any more, do we even want to fall
>> back? I can see a point in having a cap on how large a buffer can be
>> rendered but apart from that, I'm not sure there even is a problem.
>>
>
> Welcome to GL. If I have a 32MB graphics card, and I advertise
> a maximum texture size of 4096x4096 + cubemapping + 3D textures,
> there is no nice way for the app to get a clue about what it can legally
> ask me to do. Old DRI drivers used to either use texmem which would
> try and scale the limits etc to what it could legally fit in the
> memory available,
> or with bufmgr drivers they would check against a limit from the kernel,
> and in both cases sw fallback if necessary. Gallium seemingly can't do this,
> maybe its okay to ignore it but it wasn't an option when we did the
> old DRI drivers.
GL_ATI_meminfo is unfortunately the best bet. :C
Also Gallium's API is written so that drivers must never fail on
render calls. This is *incredibly* lame but there's nothing that can
be done. Every single driver is currently encouraged to just drop shit
on the floor if e.g. u_trim_pipe_prim fails, and every driver is
encouraged to call u_trim_pipe_prim, so we have stupidity like: if
(!u_trim_pipe_prim(mode, &count)) { return; }
In EVERY SINGLE DRIVER. Most uncool. What's the point of a unified API
if it can't do sanity checks? >:T
~ C.
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin Simpson
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): r300/compiler: Assert that array index is not negative.
On Fri, Feb 26, 2010 at 1:38 AM, José Fonseca wrote:
> On Fri, 2010-02-26 at 01:18 -0800, Corbin Simpson wrote:
>> > Module: Mesa
>> > Branch: master
>> > Commit: e5c691f445e1c02e6e2f75b817b13d7024f7a3a6
>> > URL:
>> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=e5c691f445e1c02e6e2f75b817b13d7024f7a3a6
>> >
>> > Author: Vinson Lee
>> > Date: Fri Feb 26 00:17:03 2010 -0800
>> >
>> > r300/compiler: Assert that array index is not negative.
>> >
>> > ---
>> >
>> > .../drivers/dri/r300/compiler/r500_fragprog_emit.c | 2 ++
>> > 1 files changed, 2 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
>> > b/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
>> > index 829f028..710cae7 100644
>> > --- a/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
>> > +++ b/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
>> > @@ -469,6 +469,8 @@ void r500BuildFragmentProgramHwCode(struct
>> > r300_fragment_program_compiler *compi
>> > if (compiler->Base.Error)
>> > return;
>> >
>> > + assert(code->inst_end >= 0);
>> > +
>> > if ((code->inst[code->inst_end].inst0 & R500_INST_TYPE_MASK) !=
>> > R500_INST_TYPE_OUT) {
>> > /* This may happen when dead-code elimination is disabled or
>> > * when most of the fragment program logic is leading to a KIL */
>>
>> Sorry, is this actually a problem? If this assertion is actually being
>> hit, it sure would be nice to hear about it since it. Empty shaders
>> shouldn't just be handled with debugging code.
>
> Vinson has been cleaning up code base based on the results of coverity
> static code analysis.
>
> Coverity generates thousands of errors/warnings for Mesa source code.
> Not all errors/warnings reported by coverity are actually hit in
> practice, but putting asserts and/or error handling code will at least
> inform coverity that that can't ever happen, and allow the real errors
> to stand out.
>
> I imagine this is the case here.
>
> Jose
>
>
Alright, thanks for the heads-up. I was not sure if this was static
analysis or not. I know that some of the r300 code is not so hot WRT
signed vs. unsigned comps and related things, so these kinds of
commits tend to get extra scrutiny from Nicolai and I.
Thanks for the explanation and hard work!
~ C.
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin Simpson
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): r300/compiler: Assert that array index is not negative.
> Module: Mesa
> Branch: master
> Commit: e5c691f445e1c02e6e2f75b817b13d7024f7a3a6
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=e5c691f445e1c02e6e2f75b817b13d7024f7a3a6
>
> Author: Vinson Lee
> Date: Fri Feb 26 00:17:03 2010 -0800
>
> r300/compiler: Assert that array index is not negative.
>
> ---
>
> .../drivers/dri/r300/compiler/r500_fragprog_emit.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
> b/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
> index 829f028..710cae7 100644
> --- a/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
> +++ b/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
> @@ -469,6 +469,8 @@ void r500BuildFragmentProgramHwCode(struct
> r300_fragment_program_compiler *compi
> if (compiler->Base.Error)
> return;
>
> + assert(code->inst_end >= 0);
> +
> if ((code->inst[code->inst_end].inst0 & R500_INST_TYPE_MASK) !=
> R500_INST_TYPE_OUT) {
> /* This may happen when dead-code elimination is disabled or
> * when most of the fragment program logic is leading to a KIL */
Sorry, is this actually a problem? If this assertion is actually being
hit, it sure would be nice to hear about it since it. Empty shaders
shouldn't just be handled with debugging code.
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin Simpson
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium format swizzles (Was: util: fix swizzles in the format table for 8-bits-per-channel formats)
I'm one of those wierdos that always thinks in rgba, strq, xyzw, order, but I guess we should go with what's popular... Posting from a mobile, pardon my terseness. ~ C. On Feb 23, 2010 12:28 PM, "Brian Paul" wrote: José Fonseca wrote: > On Mon, 2010-02-22 at 06:34 -0800, José Fonseca wrote: >> On Sun, 2010-02-21 a... It feels a little unnatural that an XY vertex format would be described by PIPE_FORMAT_G32R32_FLOAT, but if that makes things more consistant I can live with it. I think the priority is to have consistency. -Brian -- Download Intel®... -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Are unwritted Gallium FS inputs undefined or (0, 0, 0, 1)?
Undefined, I think. We could formalize that. Of course, for sanity, you may want to swizzle those to 0001 in your compiler. Posting from a mobile, pardon my terseness. ~ C. On Feb 23, 2010 10:33 AM, "Luca Barbieri" wrote: If a fragment program uses a semantic/index pair which is not mentioned by the vertex program, or is mentioned but the corresponding register is never written to, what happens? Is the value undefined or intialized to (0, 0, 0, 1)? OpenGL seems to specify that such values are undefined, and of course that would be more convenient for Gallium drivers. What are the requirements for Gallium drivers? -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa removals
Glide is a GL->glide driver, right? So it is not needed for libglide apps? Posting from a mobile, pardon my terseness. ~ C. On Feb 22, 2010 8:40 AM, "Brian Paul" wrote: Starting a new thread on this... Here's a proposal of things to remove from the Mesa tree. GLU: glu/mini glu/mesa GLUT: glut/fbdev glut/ggi glut/directfb glut/dos glut/mini glut/os2 non-DRI drivers: drivers/allegro drivers/directfb drivers/d3d drivers/dos drivers/ggi drivers/glide drivers/svga DRI drivers: drivers/dri/fb drivers/dri/ffb drivers/dri/gamma progs/directfb progs/ggi progs/windml progs/miniglx Comments? -Brian -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Remove color index rendering?
Can we doc it and comment it out? IME somebody will pop out and claim a use for it. Posting from a mobile, pardon my terseness. ~ C. On Feb 19, 2010 5:19 PM, "Ian Romanick" wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While we're on the topic of removing dead weight, can we remove support for color index rendering? None of the hardware drivers support color index rendering, and color index rendering is deprecated in OpenGL 3.0 (and removed in 3.1). Can it please die in a fire? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt/Kd8ACgkQX1gOwKyEAw+zpQCgj+Yr0Bo3e6O3BijR5KYEds48 DfIAniZibZEaXZsO0qYa9OW5745LM9xL =tcrK -END PGP SIGNATURE- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
On Fri, Feb 19, 2010 at 11:14 AM, Brian Paul wrote: > Guillem Jover wrote: >> Hi! >> >> [ CCing Daniel Borca who used to work on 3dfx support in Mesa and >> libglide, not sure though if he is around or interested anymore. ] >> >> On Thu, 2010-02-18 at 17:25:02 -0700, Brian Paul wrote: >>> 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx, >>> allegro, ggi, dri/mga, dri/mach64. Maybe more. Any objections? >> >> Could the drivers for actual hardware (namely glide, tdfx, dri/mga >> and dri/mach64) be exempted from removal? I at least still have cards >> for those, not sure though how many users might be out there, but >> whenever libglide has broken in Debian, I tend to receive bug reports, >> so I'd assume there's still some. And it always saddens me a bit when >> hardware support gets dropped in projects. > > I have/had no idea if the tdfx, glide, mga or mach64 drivers function > anymore. If someone is actively using or testing the drivers I guess > we could keep them, but I'd rather not otherwise. One of my co-workers, bless his soul, is digging out a PCI Voodoo3 for my collection, so I can maintain tdfx. I don't know about glide. I am *not* testing mga; I don't have the right motherboard for it, sorry. mach64's DRM code was getting a once-over by somebody on either dri-devel or LKML; maybe we could wait and see if somebody cares. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): r300g: remove L8_UNORM from colorbuffer formats
Yeah, I would have nak'd this. Will revert when I get home. Posting from a mobile, pardon my terseness. ~ C. On Feb 19, 2010 12:56 AM, "Michel Dänzer" wrote: On Thu, 2010-02-18 at 19:24 -0800, Marek Olk wrote: > Module: Mesa > Branch: master > Commit: fc427d23439a2702068209957f08990ea29fe21b > URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=fc427d23439a2702068209957f08990ea29fe21b > > Author: Marek Olšák > Date: Fri Feb 19 04:23:06 2010 +0100 > > r300g: remove L8_UNORM from colorbuffer formats > > Not renderable in OpenGL anyway. The Xorg state tracker uses it though. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): main: Fix compiler warning. No need to convert/ store depthScale as GLfloat just to convert it back to GLuint to call unpack_depth_span .
2010/2/12 Karl Schultz : > Thanks! Wilco! Still catching on here. > > Also is typing: > > main: > (or the appropriate mesa sub-system) > > at the beginning a mesa-specific convention, or something that git can > do somewhat automatically or with some configuration? I notice a > great deal of consistency here in the commit messages - almost to the > point of looking rather automatic. It's project-specific and manual; if you search hard enough, you'll find ones that have headers like "r300g, radeong: " We mostly do it for two reasons: 1) It accelerates grepping through git logs to find that one commit, if we don't know exactly what to git blame; 2) It lets others see, at a glance, whether or not the commit in question is worth reading immediately. For example, I don't mind admitting that I don't really read commits to svga, so I tend to ignore "svga: " commits. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats .
;>>>>>>>> would want differing expansions in different parts of the pipeline. >>>>>>>>> That indicates a single flag in the context somewhere isn't sufficient >>>>>>>>> to choose between the two. >>>>>>>>> >>>>>>>>> Maybe there need to be two versions of these PIPE_FORMAT_ enums to >>>>>>>>> capture the different values in the missing components? >>>>>>>>> >>>>>>>>> EG: >>>>>>>>> >>>>>>>>> PIPE_FORMAT_R32G32_0001_FLOAT >>>>>>>>> PIPE_FORMAT_R32G32__FLOAT >>>>>>>>> >>>>>>>>> ? or something along those lines?? >>>>>>>>> >>>>>>>>> >>>>>>>> You are right. >>>>>>>> >>>>>>>> Alternatively, follow the more sane API (GL apparently), assume 0001 as >>>>>>>> default and use the infix to override. >>>>>>> Note it's not just GL. D3D10 uses same expansion. Only D3D9 is >>>>>>> different. Well for texture sampling anyway, I don't know what d3d does >>>>>>> for vertex formats. >>>>>>> >>>>>>> Though for most hardware it would make sense to have only one format per >>>>>>> different expansion, and use some swizzling parameter for sampling, >>>>>>> because that's actually how the hardware works. But not all drivers will >>>>>>> be able to do this, unfortunately. >>>>>> You mean, having a swizzle in pipe_sampler_state ? >>>>>> >>>>>> It sounds a good idea. >>>>>> >>>>>> In the worst case some component will inevitably need to make shader >>>>>> variants with different swizzles. In this case it probably makes sense >>>>>> to be the pipe driver -- it's a tiny shader variation which could be >>>>>> done without recompiling the whole shader, but if the state tracker does >>>>>> it then the pipe driver will always have to recompile. >>>>>> >>>>>> In the best case it is handled by the hardware's texture sampling unit. >>>>>> >>>>>> It's in theory similar to baking the swizzle in the format as Keith >>>>>> suggested, but cleaner IMHO. The question is whether it makes sense to >>>>>> have full xwyz01 swizzles, or just 01 swizzles. >>>>> Another alternative is to just add the behaviour we really need - a >>>>> single flag at context creation time that says what the behaviour of the >>>>> sampler should be for these textures. >>>>> >>>>> Then the driver wouldn't have to worry about varients or mixing two >>>>> different expansions. Hardware (i965 at least) seems to have one global >>>>> mode to switch between these, and that's all we need to choose the right >>>>> behaviour for each state tracker. >>>>> >>>>> It might be simpler all round just to specify it at context creation. >>>> Yes, for rg01 vs rg11 this is easiest. It doesn't solve the depth >>>> texture mode problem though. >>>> Also, we sort of have that flag already, I think there's no reason why >>>> this needs to be separate from gl_rasterization_rules (though I guess in >>>> that case it's a bit a misnomer...) >>> I'd prefer to avoid a big "I'm a GL/DX9 context" flag, and split >>> different behaviours into different flags. Sure, a GL state tracker >>> might set them all one way, but that doesn't mean some future >>> state-tracker wouldn't want to use a novel combination. >>> >>> The GL rasterization rules flag should be renamed to reflect what it's >>> really asking for. >>> >> Ok, makes sense. So gl_rasterization_rules should be like pixel_center_half? >> And would a new flag for the unused channel expansion in textures >> sampling also include the different texture border sampling rules or >> should that also be separate (though i965 driver would need to decide >> what rules it wants to follow if they are different...). > > > I think we need per-sampler texture swizzles. That would solve three > problems: > > 1. GL vs. D3D 9 vs. D3D 10 texture component mappings > 2. GL_DEPTH_TEXTURE_MODE > 3. GL_EXT/ARB_texture_swizzle (part of GL 3.3 and later) > > This potentially requires shaders to be recompiled in response to > texture sampler state, but we're already doing that in some cases. > And it's not state that changes often. > > -Brian This. r300g already gave up on the shader recompile thing; we now have a setup where the shaders will be recompiled until they match, and then re-cached, so a pathological case might end up attaching ten or more HW shaders to one TGSI stream. Hardly ideal, but as everybody else has noticed, it's kind of unavoidable. So... who doesn't have per-sampler texture swizzling? Also should the default for R and RG be (r, 0, 0, 1) or (r, 1, 1, 1)? Inquiring minds want to know, and settling those blanks now rather than later would be *awesome*. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 4/6] dri: Allow selective generation of accum. buffer configs
On Tue, Feb 9, 2010 at 10:47 AM, Ian Romanick wrote: > Corbin Simpson wrote: >> Otherwise this looks fine. > > Can I consider that a 'Reviewed-by:'? :) Could I get a version that also fixes Gallium, or should I provide that? :3 Reviewed-by: Corbin Simpson ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 4/6] dri: Allow selective generation of accum. buffer configs
s_array, stencil_bits_array,
> depth_buffer_factor, back_buffer_modes,
> back_buffer_factor,
> - msaa_samples_array, 1);
> + msaa_samples_array, 1, TRUE);
> if (configs == NULL) {
> fprintf(stderr, "[%s:%u] Error creating FBConfig!\n", __func__,
> __LINE__);
> --
> 1.6.6
>
>
> --
> 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
>
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin Simpson
--
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] gallium, r300g: add PIPE_CAP_QUADS_DONT_FLATSHADE_FIRST
I addressed this in the docs already, see the note in flatshade_first in Rasterizer. In short, we should always provoke quads GL-style. Posting from a mobile, pardon my terseness. ~ C. On Feb 6, 2010 12:39 PM, "Marek Olšák" wrote: Hi, I got some time to revisit the issue from December regarding quads not following the first provoking vertex convention. The attached patch adds PIPE_CAP_QUADS_DONT_FLATSHADE_FIRST to gallium, which gets propagated to the return value of glGet*(GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION, ...). Please review/push. Marek On Fri, Dec 18, 2009 at 10:58 AM, José Fonseca wrote: > On Thu, 2009-12-17 at 20:41 -0800, Marek Olšák wrote: > > Hi, > > > > GL_ARB_provoking_vertex states that quads are not required to abide > > the provoking vertex convention, and the actual hardware and/or driver > > behavior can be queried with > > GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION. > > > > I'd like to add a new PIPE_CAP_* to query for this capability in > > Gallium, as it appears R3xx-R5xx hardware doesn't support the first > > vertex convention for quads and I'd like the driver to behave > > correctly. Fortunately, other primitive types are supported. > > > > I decided to use the name "quads follow flatshade_first convention" > > instead of "provoking vertex convention" because the actual state > > variable in pipe_rasterizer_state is called flatshade_first. > > > > The attached patch: > > - adds PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION > > - adds the query in the Mesa state tracker > > - and updates softpipe and llvmpipe to return 1 when this cap is > > queried, and r300g to explicitly return 0 > > > > Please review/push. > > > > Cheers. > > > > Marek > > Hi Marek, > > One problem I have with this patch and many of past get_param changes > for that matter, is that it changes default behavior and forces all pipe > drivers to be updated. It is not the first time that a get_param changes > broke drivers because it. I happened with > PIPE_CAP_BLEND_EQUATION_SEPARATE. > > As the number of drivers is increases this is a no-no. It also > complicates writing drivers since they have to answer a large number of > queries, most of which are specific to one or two particular hardware > devices. > > IMO, there are two ways to overcome this: > > a) when introducing new PIPE_CAP_xxx have its semantics such that 0 will > yield the previous behavior > > b) change get_param/paramf prototype so that it is passed the default > value as an argument. > > That said, reading > http://www.opengl.org/registry/specs/EXT/provoking_vertex.txt , issue #2 > (How should quads be handled?) it seems that 0 is actually a better > default -- provoking vertex of quads does not apply to D3D and is only > relevant for that extension. So I don't oppose for this to go in as is. > > But, independent of this change, lets fix the get_param/paramf calls. > Keith, does b) above sound good to you? > > Jose > > -- 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] empty vertex buffers
It's not deeply, truly painful, but it's certainly annoying and it would be nice to force buffers to be at least contiguously bound, if not non-sparse. I know D3D permits sparse elements though, so I won't hold my breath. On Sat, Feb 6, 2010 at 3:04 AM, Keith Whitwell wrote: > On Fri, Feb 5, 2010 at 2:46 PM, Joakim Sindholt wrote: >> Let's assume I have an array of vertex elements that indicate >> position/color in vertex buffer #3. Let's also for the sake of argument >> say that there is nothing else in my vertex elements. No other buffers >> are being pointed to. Is it legal for me to >> pipe_context::set_vertex_buffers with an array size of 3 and set buffer >> 1 and 2 == NULL? >> > > Not to mention buffer 0... > > At the moment I'd say that, yes this is permitted. I'm not sure if > there is any state-tracker out there that really wants to be able to > do this, though, so it is something we could look at tightening up if > it is causing real pain at the driver level. > > Keith > > -- > 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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
[Mesa3d-dev] Gallium DRI fbconfig/visual setup
Two things... Are accumbufs still slow in Gallium-land? Should we still mark them as slow? How many multisamples should we actually pretend/advertise? Should we have a cap to check the number of multisamples supported? Should we just say that four samples are done for the fbconfig/visual, and then replace pipe_texture::nr_samples with a multisample boolean flag? ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] [RFC] reduce number of visuals exposed by Intel drivers
I'm cool with that. There's actually a couple Gallium fbconfig things I wanna bring up, but I'll start another thread for those. On Fri, Feb 5, 2010 at 1:01 PM, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I'd like to remove a bunch of the visuals and fbconfigs exposed by the > Intel drivers. There are several categories of visuals that are likely > not useful to anyone. A couple of our test suites (e.g., glean) like to > run over every possible visual. As a result, the test suites take an > extraordinary amount of time to run. > > I propose removing: > > * All 24-bit depth / 0-bit stencil visuals. These are compatible with > the default state of a 24-bit depth / 8-bit stencil visual and offer no > memory savings. This will eliminate 24 (of 72) visuals by itself. > > * All but one of the visuals with accumulation buffer. Accumulation > is a software path in the Intel drivers (though this could be fixed), so > I don't see any utility in offering multiple, optimized buffer > configuration choices. This will eliminate an additional 23 visuals. > > This will leave the 25 visuals and 37 fbconfigs that are likely to be > useful. > > Anyone have a concerns with me doing this? > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAktshzkACgkQX1gOwKyEAw/aSgCeJ+vgWfSuCxGgLqN+FjiSaR82 > 0A4Anj3O9qK6bI5E92YLBewrpDFcYwmW > =e0Qq > -END PGP SIGNATURE- > > -- > 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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
[Mesa3d-dev] What should we do when shaders fail to compile?
Just got a bug report. A compiz plugin asked for five texture indirections, but r300 can only do four. This kind of shader error can't be worked around without a full fallback, but most APIs permit shaders to fail to compile. Is it okay to fail shaders? Maybe return NULL on creation if the shader can't be compiled? ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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 (master): Track frag shader changes introduced by commit 4769566500be1a53dd9b4cc1a613aef439a0e3d8
Short bump on this. I noticed Dave committed something that might fix this better, is everything working now? For some reason, r300c didn't break over here, so I can't really see whether everything's okay again. ~ C. 2010/2/3 Michel Dänzer : > On Tue, 2010-02-02 at 11:52 -0800, Corbin Simpson wrote: >> Module: Mesa >> Branch: master >> Commit: 3fedfc71289875de7e8381fb298aa26cee8d1822 >> URL: >> http://cgit.freedesktop.org/mesa/mesa/commit/?id=3fedfc71289875de7e8381fb298aa26cee8d1822 >> >> Author: Scott Moreau >> Date: Tue Feb 2 11:59:53 2010 -0700 >> >> Track frag shader changes introduced by commit >> 4769566500be1a53dd9b4cc1a613aef439a0e3d8 >> >> Signed-off-by: Corbin Simpson >> >> --- >> >> src/mesa/drivers/dri/r300/r300_blit.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/src/mesa/drivers/dri/r300/r300_blit.c >> b/src/mesa/drivers/dri/r300/r300_blit.c >> index e24c795..54ac251 100644 >> --- a/src/mesa/drivers/dri/r300/r300_blit.c >> +++ b/src/mesa/drivers/dri/r300/r300_blit.c >> @@ -114,7 +114,7 @@ static void create_fragment_program(struct r300_context >> *r300) >> inst->U.I.SrcReg[0].Swizzle = RC_SWIZZLE_XYZW; >> >> compiler.Base.Program.InputsRead = (1 << FRAG_ATTRIB_TEX0); >> - compiler.OutputColor = FRAG_RESULT_COLOR; >> + compiler.OutputColor[0] = FRAG_RESULT_COLOR; >> compiler.OutputDepth = FRAG_RESULT_DEPTH; >> compiler.is_r500 = (r300->radeon.radeonScreen->chip_family >= >> CHIP_FAMILY_RV515); >> compiler.code = &r300->blit.fp_code; > > Are you guys getting working hardware acceleration with this driver > since the compiler MRT changes? For me e.g. running > > RADEON_DEBUG=all ./progs/tests/fbotest1 > > prints out among other things: > > Fragment Program: Initial program: > # Fragment Program/Shader 0 > 0: MOV OUTPUT[1], INPUT[1]; > 1: END > Fragment Program: After native rewrite: > # Radeon Compiler Program > 0: MOV output[1], input[1]; > r300compiler error: get_used_ptr: index 256613760 is out of bounds for > file 3 > WARNING! Falling back to software for fragment program > > So only software rendering, presumably because OutputColor[1..3] aren't > initialized properly. I've tried initializing them to various values and > while some of them get me past the problem above, then I only get a > black window. > > The r300g driver is working though, including the drawbuffers(2) tests > these changes were aimed at. > > Any ideas? FWIW this is on my PowerBook with an RV350. > > > -- > Earthling Michel Dänzer | http://www.vmware.com > Libre software enthusiast | Debian, X and DRI developer > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] gallium/docs: format texture formats into real table
Great minds think alike, apparently: 516e7159aeb4 And yeah, the PDF output isn't the best; HTML looks a lot better: http://people.freedesktop.org/~csimpson/gallium-docs/tgsi.html#texture-sampling-and-texture-formats Thanks for the patch, sorry I beat you to it. :3 ~ C. On Tue, Feb 2, 2010 at 10:28 AM, Nathan Kidd wrote: > On 10-02-02 10:18 AM, Brian Paul wrote: >> >> I've added this table to the gallium docs, with the LA format. Maybe >> someone else more familiar with Sphinx can fix up the formatting. > > The attached patch does so, though unfortunately the latex->pdf > conversion[1] does a pretty bad job on the table. > > -Nathan > > [1] PAPER=letter make latex && make -C build/latex all-pdf && evince > build/latex/Gallium.pdf > > -- > 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 > > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] Grab bag of random questions (whoo)
This++. I've been scratching my head at some of these; having them specified would be great. Posting from a mobile, pardon my terseness. ~ C. On Feb 1, 2010 11:25 AM, "Brian Paul" wrote: Speaking of texture formats and texture sampling, one area of Gallium that's under-specified is what (x,y,z,w) values are returned by TEX instructions when sampling from each of the various texture formats. A while back I started a table comparing OpenGL to D3D: texture componentsOpenGL D3D --- R,G,B,A (R,G,B,A) (R,G,B,A) R,G,B (R,G,B,1) (R,G,B,1) R,G (R,G,0,1) (R,G,1,1) R (R,0,0,1) (R,1,1,1) A (0,0,0,A) (0,0,0,A) L (L,L,L,1) (L,?,?,1) (probably L,L,L,1) I (I,I,I,I) (?,?,?,?) UV(0,0,0,1)* (U,V,1,1) Z (Z,Z,Z,Z) or (0,Z,0,1) (Z,Z,Z,1) or (0,0,0,Z)** other formats?...... * per http://www.opengl.org/registry/specs/ATI/envmap_bumpmap.txt ** depends on GL_DEPTH_TEXTURE_MODE state For OpenGL, see page 141 of the OpenGL 3.1 spec. For D3D, see http://msdn.microsoft.com/en-us/library/ee422472(VS.85).aspx We should first add a column to the above table for Gallium and then decide whether to implement swizzling (and GL_DEPTH_TEXTURE_MODE) with extra GPU instructions or new texture/sampler swizzle state. -Brian -- The Planet: dedicate... -- 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
I propose that the following language be added to the spec: """ Gallium has no explicit mechanism for linking shaders. Shaders are implicitly linked in a pipeline at render time. Thus, linking must not fail and the pipe driver is permitted to change shader semantics to preserve linking. If a shader uses non-consecutive semantics, the pipe driver may remap them to be consecutive, within the bounds of other currently bound state. For example, if a shader samples from samplers 3 and 5, but the only samplers bound are 0 and 1, the driver may adjust the shader to sample from samplers 0 and 1 instead. If the bound shader pipeline does not have consistent outputs and inputs, the driver is permitted to remap them to be consistent through a driver-specific mechanism. For example, if a vertex shader writes generic 1, a fragment shader references generic 0, and there is no geometry shader bound, the pipe driver may change the vertex shader to write generic 0, or it may use a driver-specific internal routing table to route generic 1 to generic 0. If the total count of each semantic attribute written by the vertex shader does not match the counts read by the fragment shader, the driver may discard extraneous attributes and the values of missing attributes are undefined. If a geometry shader is present, this adjustment may happen on the vertex to geometry linking and geometry to fragment linking. """ I think this about covers it. This language seems *very* reasonable to me, while not totally ignoring the problems faced by nv50. ~ C. On Mon, Feb 1, 2010 at 7:29 AM, Luca Barbieri wrote: >> I can't really use a routing table state to produce a cso, because the hw >> routing table I generate depends on rasterizer state, e.g. I must not >> put in back face colour (we have a 2 to 1 mapping here) if twoside >> is disabled. >> >> Also, I'm routing based on the scalar *components* the FP reads, >> not whole TGSI pseudo vec4 registers (NUM_INTERPOLATORS will >> thus be inaccurate) - set_routing_table will have to pass me the >> respective programs too. >> Well, I can still use the cso and insert it into the rest of the routing >> table that still need to be assembled on the fly, I did that before the >> 1:1 mapping between FP and VP regs was removed. > > You are right, the routing table CSO needs to contain the fragment and > vertex shader handles, and ideally light_twoside should be moved to > the vertex->fragment routing table since it is really an attribute of > that and not polygon rasterization/setup. > > You can then just look at your internal data structure and construct a > scalar routing table from the vec4 one provided by Gallium. > > We could also, as a further extension, support scalar routing tables > directly in Gallium. > Note however that radeon hardware presumably only supports vector > ones, so we would need all 3 options with caps. > A further intermediate step could be vector routing tables with swizzling. > > -- > 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] Grab bag of random questions (whoo)
masks are r5xx-only. >>> >> I also think even r500 shouldn't say this is supported. Just changing >> the colormasks isn't going to be very correct... >> >> Roland >> >> >> -- >> 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] Grab bag of random questions (whoo)
On Sun, Jan 31, 2010 at 6:21 AM, José Fonseca wrote: > On Sat, 2010-01-30 at 04:06 -0800, Corbin Simpson wrote: >> 5) How const is const for CSO? e.g. r300_state.c:498, we're not >> copying pipe_framebuffer_state but just the pointer. It appears to >> work, but is it actually safe? > > The const means the driver cannot change it. Not that it won't change. > > The long answer is depends on how the driver is implemented and commands > batched. The next time the set_framebuffer_state is called the previous > object may have been destroyed/modified, so if you have internal > references to it they would cause segfault. But if by the time that > happens you no longer have references to it -- e.g. you just have > references to the BOs that hold the frambuffer storage -- then it would > work fine. > > Short answer is -- it is better to just make a local copy. Alright, not hard to fix. >> Also, on the topic of framebuffers, is >> it okay to refuse to render if no MRTs or Z buffer are present? > > Not really. At least not as it stands. If the hardware requires these > then they'll need to be created internally by the pipe driver. > > We could add a caps for this but I see no point for it, since it's so > easy to create a dummy framebuffer internally. Again, I should have typed "and." I was thinking in terms of sanity checks. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] Grab bag of random questions (whoo)
On Sat, Jan 30, 2010 at 5:13 AM, Roland Scheidegger wrote: > On 30.01.2010 13:06, Corbin Simpson wrote: >> Handful of random things bugging me. > >> 2) progs/tests/drawbuffers and progs/tests/drawbuffers2, and possibly >> others, segfault with both softpipe and the HW driver at >> sl_pp_version.c:45. I think there's some codegen going on there? At >> any rate, if anybody has any hints on how to solve it, that'd be nice. > Works for me (with softpipe). Curses, looks like I'll have to dig in myself. Thanks though. >> >> 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in >> the fragment constants reads, "Since Gallium doesn't support >> GL_ARB_shadow_ambient, this is always (0,0,0,0), right?" > I'd think so. This extension isn't in core GL (and d3d can't do it > neither), and AFAIK there's no hardware (which doesn't emulate the > shadow functionality in the fragment shader) which could actually do it. Alrighty. I just won't worry about it. I wonder if I can get my compiler to not bother asking for those values, or to do a swizzle to 0 for those. >> Another >> comment reads, "Gallium doesn't provide us with any information >> regarding this mode, so we are screwed. I'm setting 0 = LUMINANCE," >> above the texture compare modes. I don't really like that section of >> code, but it probably can't get cleaner, right? > Yes, that's not very clean, but there doesn't seem to be an easy > solution for this. Exposing this in gallium only seems marginally > useful, since again modern hardware can't really do anything useful with > that information neither. Maybe would need to tweak the shader if > actually the "wrong" channels are used (probably shouldn't be the > driver's responsibility to do this), but I guess assuming default > LUMINANCE works just fine usually. New OGL won't have that problem... New OGL? GL3? Sweet. >> >> 7) Is there more information on the dual-source blend modes? I'm not >> sure if I can do them; might have to bug AMD for the register values. > Pretty sure most pre-DX10 hardware can't do that, the blend unit just > doesn't have access to multiple source colors. > I've attached a small patch which shows how softpipe implements it. > (But I still need to write a testcase probably for the python > statetracker to see if it actually works...). > Pretty easy really, just using pixel shader color outputs 0 and 1 for > blending (note that in this form this restricts dual source blending to > one render target, this is the same restriction DX10 enforces, and if > you look at i965 docs it actually has this restriction in hardware). Alright, I'll clean those up, maybe with a comment. >> >> I think that's it for now. Sorry for all the questions, but I'm really >> starting to get a good handle on the hardware and interface, and I'm >> ready to start beating the classic driver in serious benchmarks; I >> think that r300's probably the most mature driver alongside nv50 and >> maybe nv40. > Great! > > Roland > And starting to get rid of all those XXX, too. :3 ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] Grab bag of random questions (whoo)
On Sat, Jan 30, 2010 at 8:24 AM, Marek Olšák wrote: > Hi Corbin, > > On Sat, Jan 30, 2010 at 1:06 PM, Corbin Simpson > wrote: >> >> 5) ... Also, on the topic of framebuffers, is >> it okay to refuse to render if no MRTs or Z buffer are present? > > Do you mean color-only and depth-only rendering? This is a must. Shadow > mapping heavily relies on depth-only rendering. OTOH post-processing effects > like HDR, bloom, depth of field, later parts of deferred-rendering methods, > and many other advanced methods require color-only rendering. The FBO > extensions allows either no color attachment or no depth-stencil attachment. > I know there are inter-CSO depedencies in r300g because of this, but I don't > see any other way around it. I should have said "and," not "or." I was thinking about sanity tests, and whether it should be possible, legal, or good to bind no targets at all to the framebuffer_state. We already refuse to bind too many MRTs, so it wouldn't be a big change; I was thinking in terms of a rule for Gallium, along the lines of: If the number of colorbuffers attempting to be bound exceeds MAX_RENDER_TARGETS as reported by get_param, the context may refuse to bind the state. If there are no colorbuffers bound, and no depthbuffer bound, the context may refuse to bind the state. This could be consolidated into boolean u_check_framebuffer_state(struct pipe_context*, const struct pipe_framebuffer_state*); at that point. >> 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in >> the fragment constants reads, "Since Gallium doesn't support >> GL_ARB_shadow_ambient, this is always (0,0,0,0), right?" > > I think the extension could be added to Gallium since the r300 compiler can > generate code for it. But we'd either need to PIPE_CAP it or make it optional. I'm starting to compile a list of requirements for Gallium hardware targets, and this is one of those things that might make more sense at the st level. See Roland's comments. >> Another >> comment reads, "Gallium doesn't provide us with any information >> regarding this mode, so we are screwed. I'm setting 0 = LUMINANCE," >> above the texture compare modes. I don't really like that section of >> code, but it probably can't get cleaner, right? > > Even though this is a rarely used feature in OpenGL nowadays, it should get > fixed if we want to be GL-compliant. That means adding depth texture modes > in pipe_sampler_state and setting them in the Mesa state tracker. The R300 > compiler can already generate code for these modes as well. Need to check how many other drivers can handle it. >> 7) Is there more information on the dual-source blend modes? I'm not >> sure if I can do them; might have to bug AMD for the register values. > > I bet R300 can't do these modes. It's only a Direct3D 10.0 feature, not > present in Direct3D 10.1. MS must have a good reason to remove it. See my comments with Roland. > BTW I looked at some of your patches and r3xx-r5xx cards don't even support > separate blend enables, therefore the cap should be 0. Or are you going to > emulate this using independent color channel masks and two rendering passes? > That could be done in the state tracker. Also, I think the indep. color > masks are r5xx-only. I'll double-check in the docs. We should have support for separate blend enables through the colormasks, at least, but if that's r500-only then I'll have to do a test and such. Thanks for the heads-up. > Cheers. > > Marek > ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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
[Mesa3d-dev] Grab bag of random questions (whoo)
Handful of random things bugging me. 1) Team Fortress 2 (and probably other Source games, haven't really checked) request some fairly large VBOs and indexbufs, beyond what I can provide. Is there any good example code on how to use translate/indices to slice up buffers for multiple render runs? 2) progs/tests/drawbuffers and progs/tests/drawbuffers2, and possibly others, segfault with both softpipe and the HW driver at sl_pp_version.c:45. I think there's some codegen going on there? At any rate, if anybody has any hints on how to solve it, that'd be nice. 3) Is there still interest in the translate helper I proposed a couple weeks ago? It would take a list of "safe" formats, a list of VBO elements, and a list of VBOs (corresponding), and return a list of VBO elements and VBOs that only contain those "safe" formats. State trackers would call a pipe_screen (or pipe_context?) method with just the VBOs and elements, and it would fix them up without exposing the list of safe formats. 4) user_buffer_create doesn't appear to see an incredible amount of usage. Would it be too horrible to make *all* buffer allocations delayed, transparently? I ask because apparently the PIPE_BUFFER_USAGE flags (PIXEL, CONSTANT, etc.) are "optimization hints" and not guarantees, which is very annoying since I need to prevent constantbufs from ever becoming BO-backed... 5) How const is const for CSO? e.g. r300_state.c:498, we're not copying pipe_framebuffer_state but just the pointer. It appears to work, but is it actually safe? Also, on the topic of framebuffers, is it okay to refuse to render if no MRTs or Z buffer are present? 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in the fragment constants reads, "Since Gallium doesn't support GL_ARB_shadow_ambient, this is always (0,0,0,0), right?" Another comment reads, "Gallium doesn't provide us with any information regarding this mode, so we are screwed. I'm setting 0 = LUMINANCE," above the texture compare modes. I don't really like that section of code, but it probably can't get cleaner, right? 7) Is there more information on the dual-source blend modes? I'm not sure if I can do them; might have to bug AMD for the register values. I think that's it for now. Sorry for all the questions, but I'm really starting to get a good handle on the hardware and interface, and I'm ready to start beating the classic driver in serious benchmarks; I think that r300's probably the most mature driver alongside nv50 and maybe nv40. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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
I would say that the routing table really needs to be handled by the driver implicitly. When you're told to draw things, you do your shader routing/linking before you draw. If the routing table really does depend on the shaders and only the shaders, then I wouldn't be opposed to some CSO, but I don't think it's horribly necessary. And no, pre-optimizing TGSI is stupid. Every single backend does something different with its shaders. You can't deliver something besides TGSI to drivers, either; it will suck badly for out-of-tree drivers and compat. Just write a real compiler for your HW. ~ C. On Fri, Jan 29, 2010 at 12:47 PM, Luca Barbieri wrote: > On Fri, Jan 29, 2010 at 8:49 PM, Keith Whitwell wrote: >> So the nv40 code is doing the wrong thing... :) >> >> The rule currently is that the generic tags are just tags and are used only >> to establish mapping between fragment shader and vertex shader. Additionaly >> the vertex shader should always supply at least the inputs required by the >> fragment shader. Taking a guess, without specific hardware support for >> routing, nv40 should translate the fragment shader inputs into successive >> SRC_TC slots, and build a mapping from semantic-index -> SRC_TC slot that >> can be applied when translating the vertex shader. >> >> You might complain that in this world a vertex shader will require multiple >> translations depending on which fragment shader is bound, as one taking >> fewer inputs will have different numberings. That's true, but you also get >> the opportunity to specialize the vertex shader as a result, eliminating >> dead code in each case - which may be worth the effort. >> >> Anyway, it sounds like what you really want is to change the linkage rules. >> This is possible, of course, but we should discuss it in those terms. > And >> then if we do revisit those rules, we should take a deeper look at linkage >> and figure out if anything else can be changed. > > Yes, this is what I'm proposing. > > Actually, those rules do not seem to be documented, so I was not sure > whether they were a requirement or were just a "bonus" feature of some > drivers. > > Right now it seems to me that no users of Gallium require this functionality. > In particular: > 1. GLSL and anything with similar link-by-name can of course be > modified to use sequential indices > 2. ARB fragment program and vertex program use index-limited texcoord slots > 3. g3dvl needs and uses 8 texcoord slots, indices 0-7 > 4. vega and xorg use indices 0-1 > 5. DX10 seems to restrict semantics to 0-N range, if I'm not mistaken > 6. The GL_EXT_separate_shader_objects extension does not provide > arbitrary index matching for GLSL, but merely lets it use a model > similar to ARB fp/vp > > Thus, unless I am mistaken, no current API needs this feature. > > In addition, note that current rules do *not* allow to bind inputs and > outputs by name, since the semantic index is an integer and not a > screen. > However, the hardware implementation could probably allow that, since > it most likely works by specifying the fragment shader input a given > vertex shader output maps to. > > Thus, I propose to: > 1. Change the rules to require semantic indices to be in a 0-N range. > Document this appropriately. > 2. Fix GLSL to respect that using the patch I posted. Everything else > should be already fine. > 3. If necessary, add a ->set_routing_table function that takes pairs > of vertex shader outputs and fragment shader inputs to associate > > This allows to state tracker to support seamless "link by variable > name string" by packing the indices in sequential numbers, and then > using a dictionary kept in the state tracker to build an appropriate > routing table. > > There are also geometry programs, so both vs->gs and gs->fs routing > tables are probably needed. > > What do you think? > > > As an aside, regarding shader optimization, I would suggest a > driver-independent LLVM-based middle layer that takes TGSI as input > and can provide either optimized LLVM bytecode or optimized TGSI to > the driver (letting the driver choose with appropriate caps). > > -- > 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 > ___ >
Re: [Mesa3d-dev] About buffer management functions in gallium
At this point in time, r300 and r600 will probably share a lot of buffer management (softpipe r600 already works) so I am not too inclined to move that code out. Someday, though, that might change. Posting from a mobile, pardon my terseness. ~ C. On Jan 29, 2010 11:46 AM, "Keith Whitwell" wrote: Basically we needed to enforce a strict layering between state-tracker, driver and winsys, so that everything that the state-tracker did would go through the driver level and have the driver be able to intercept that and inject whatever necessary behaviour at that level. Previously, many of the buffer management functions bypassed the driver and landed directly in the winsys, which turned out to be a big problem if the driver needed to do something special with those functions. I think the svga device fell into this category. At this stage, the pipe_winsys struct was deprecated, and drivers have been encouraged to define their own winsys interfaces. Because we didn't want to disrupt all the drivers, we defined a layered implementation of the screen functions in terms of the old pipe_winsys entity, and hooked that up in r300, nvXX, softpipe, etc, in the hope that they would slowly migrate to a pure pipe_screen implementation. So far nobody has done that afaik, but sooner or later it would be good to clean this up. One thing that will probably happen sooner rather than later is that softpipe will stop using pipe_winsys as its backend interface and just turn to MALLOC() for allocations and have a winsys that only exposes scanout-buffer allocations. Keith ____ From: Corbin Simpson [mostawesomed...@gmail.com] Sent: Friday, January 29, 2010 11:05 AM To: Cooper Yuan Cc: Mesa3D-Development Subject: Re: [Mesa3d-dev] About buffer management functions in gallium On Fri, Jan 29, 2010 at 1:44 AM, Cooper Yuan wrote: > Hi Corbin, > I noticed... -- 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] About buffer management functions in gallium
On Fri, Jan 29, 2010 at 1:44 AM, Cooper Yuan wrote: > Hi Corbin, > I noticed that functions related to buffer management, for instance, > pipe_create, surface_buffer_create, buffer+map, buffer_unmap, have been > defined in both pipe_winsys and pipe_screen. > Actually, we set this function pointer as our implementation, for example, > radeon_surface_buffer_create, only in pipe_winsys. > Would you tell me why there are two function pointer sets in both > pipe_winsys and pipe_screen and what's the intention. > Cooper (CCing people who can probably answer better than me.) Hi Cooper, All of the buffer management and fence handling used to be only in pipe_winsys back in Gallium 0.1, and the winsys was accessed directly from its pointer in pipe_screen. That's just the way it was. At some point during Gallium 0.2, these got copied to pipe_screen, and a simple helper called u_simple_screen got introduced. u_simple_screen wraps a pipe_winsys and handles the accesses through pipe_screen. So, if you call e.g. buffer_map on the pipe_screen, it calls u_pass_buffer_map which calls buffer_map on the pipe_winsys. I don't know *why* this is. It's made our lives easier though, so I'm not really arguing against it. Take it easy, ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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
Look harder. There *should* be routing tables of some sort on there.
If there really aren't, then you might have to actually start in on
your shader compilers instead of just translating opcodes
one-at-a-time, but this isn't a bad thing as it's what everybody needs
to do for performance.
Also, as stated before, it's a bad idea to fix GLSL and pretend that
everything's kosher, because it'll break again next time somebody
provides a shader generator of non-trivial complexity. HLSL is the
obvious candidate, but there might be GPGPU languages that do the same
thing. While I have no serious objection to changing Gallium's TGSI
semantics and permanently forbidding this, I kind of wish the drivers
could just be more robust.
~ C.
On Fri, Jan 29, 2010 at 10:15 AM, Luca Barbieri wrote:
> As a concrete example, the current nv40 code does this during fragment
> program translation.
> case TGSI_SEMANTIC_GENERIC:
> if (fdec->Semantic.Index <= 7) {
> hw = NV40_FP_OP_INPUT_SRC_TC(fdec->Semantic.
> Index);
> } else {
> NOUVEAU_ERR("bad generic semantic index\n");
> return FALSE;
> }
> break;
>
> As a result, GLSL completely fails to work on nv30 and nv40.
>
> nv50 instead seems to have hardware routing support, which is used by
> the driver.
>
> --
> 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
>
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin Simpson
--
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] gallium docs
ng written. > > But documentation is not an absolute requirement to join. I complained > about lack of documentation 8 years ago, but I didn't stop -- I analyzed > the whole archive of mesa3d-dev and dri-dev mailing lists, created FAQs, > glossaries, a wiki. A lot of that material is in todays' DRI wiki still. > > The problem is here is developer's time. And once in a while you see a > newbie demanding documentation, personalized help, or pushing their > vision of what the architecture should look like. And we really have no > time to produce that documentation immediately, explaining basic stuff, > or argue why things are as they are. Probably you're better than one of > them, but unfortunately you sounded like one, and that's probably why > this harsh reaction. > > In summary, it is not our intention to be elitist and put the entry bar > high to avoid newbies, but we simply do not have the time to lower the > bar ourselves. If newbies are really serious about participating and > joining development, they will have to surpass the hurdles themselves > and hopefully help lower the entry bar while they still remember how > difficult it is to get started on this. > > Jose > > > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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
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 wrote: > On Tue, Jan 26, 2010 at 9:44 AM, Roland Scheidegger > 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] gallium docs
s better not to introduce any performance >> > >> regressions in vertex processing until llvm code generation is in >> place >> > >> and working for everybody. >> > >> >> > > >> > > I agree. It's too early to remove the sse2 code. >> > > >> > > >> > OK, that makes sense, I will leave it alone for the time being. >> > >> > Thanks, guys. >> > >> > >> -- >> > 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 >> >> >> Windows Live: Friends get your Flickr, Yelp, and Digg updates when they >> e-mail you. >> <http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010> > > > -- > 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] st/mesa: fix unsigned/signed breakage in scissor
After giving it another look, I concluded that no additional checks are needed, but... Can I have a ruling on these, so that I know what to put into the docs for Gallium? "The scissors may be set to include area outside of the viewport." "The driver may clamp the scissors to the viewport when scissoring is enabled." I know that this is wrong for GL, but is it wrong for Gallium? I'll have to double-check some sanity code in this case, because Radeon scissors can't ever be turned off and so they have some fun side effects. "The scissors are ignored when the scissor flag (linkref to pipe_rasterizer_state::scissor) is disabled, so the scissors never need to be set if they will not be used." On Sun, Jan 24, 2010 at 4:53 PM, Brian Paul wrote: > On Sun, Jan 24, 2010 at 5:40 PM, Xavier Chantry > wrote: >> On Mon, Jan 25, 2010 at 12:56 AM, Brian Paul wrote: >>> On Sat, Jan 23, 2010 at 9:27 AM, Xavier Chantry >>> wrote: >>>> commit 53174afeeb introduced a portability change that converted GLint x,y >>>> to GLuint. That breaks when x and y are negative, which seems to be >>>> allowed, >>>> and which at least one game uses : teeworlds. >>>> >>>> Rather than simply reverting the change, it seems possible to convert the >>>> 16bit unsigned to GLint so that comparisons are made between signed >>>> integers >>>> instead. This hopefully does not break anything while keeping MSVC happy. >>>> >>>> Signed-off-by: Xavier Chantry >>> >>> Committed to the 7.7 branch. Thanks. >>> >> >> Oh great, thanks ! >> >> I kept investigating / testing and found another related issue. Sorry >> for not spotting it earlier, patch attached : >> 0001-st-mesa-another-signed-unsigned-fix-in-scissor.patch >> >> I also considered your last mail proposing to do bound/sanity checks >> earlier. I discussed a bit with MostAwesomeDude on IRC who made this >> proposal : >> 22:44 < MostAwesomeDude> Hm. Personally, I think that you should clamp >> against the current viewport. >> 22:44 < MostAwesomeDude> Since the scissor test operates on pixels. >> 22:48 < MostAwesomeDude> The scissor test discards pixels that would >> otherwise be in the viewport. >> 22:49 < MostAwesomeDude> So it makes sense that having your scissor >> box be bigger than the viewport is useless. > > MostAwesomeDude is incorrect. The viewport transformation and scissor > test are different things. Clamping the scissor box to the viewport > would be wrong. > > >> So I went ahead and did that, see attached patch >> 0001-mesa-bounds-check-and-sanitize-glScissor-arguments.patch >> This patch would also fix teeworlds on its own, without any of my st/mesa >> fixes. >> However jbauman spotted serious shortcomings : >> 00:13 < jbauman> shining^, what if they set a small viewport, a large >> scissor, a big viewport, and then draw? >> 00:14 < jbauman> you also have to keep track of the input scissor and >> the actual used scissor >> 00:30 < jbauman> also, there may be interactions between switching >> scissor/viewport/fbos >> >> So it's more complex than I expected, and not sure what to do now. >> Even if we find and implement a reliable way to clamp scissor against >> viewport, I don't know if this will ensure that x+width and y+height >> are never negative. So I would be happy with my straightforward fix to >> st/mesa which deals with that and fix teeworlds, I hope completely >> this time ! >> > > What exactly is the issue with teeworlds? I haven't seen a bug report. > > I can apply the first part of your bounds-check patch which adds some > _mesa_debug() calls, but the rest is invalid. > > -Brian > > -- > 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] [PATCH] st/mesa: fix unsigned/signed breakage in scissor
I am nearly sure that x and y are not permitted to be negative, but I
am not sure if I am reading the spec correctly. We should get Ian or
Brian to verify.
On Sat, Jan 23, 2010 at 8:27 AM, Xavier Chantry
wrote:
> commit 53174afeeb introduced a portability change that converted GLint x,y
> to GLuint. That breaks when x and y are negative, which seems to be allowed,
> and which at least one game uses : teeworlds.
>
> Rather than simply reverting the change, it seems possible to convert the
> 16bit unsigned to GLint so that comparisons are made between signed integers
> instead. This hopefully does not break anything while keeping MSVC happy.
>
> Signed-off-by: Xavier Chantry
> ---
>
> My knowledge of mesa and opengl is close to 0 and C one is limited so this
> could be all wrong.
> If this is not the proper fix, just enligthen me :)
>
> src/mesa/state_tracker/st_atom_scissor.c | 8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_atom_scissor.c
> b/src/mesa/state_tracker/st_atom_scissor.c
> index 3fd59e1..fb666b8 100644
> --- a/src/mesa/state_tracker/st_atom_scissor.c
> +++ b/src/mesa/state_tracker/st_atom_scissor.c
> @@ -52,14 +52,14 @@ update_scissor( struct st_context *st )
> scissor.maxy = fb->Height;
>
> if (st->ctx->Scissor.Enabled) {
> - if ((GLuint)st->ctx->Scissor.X > scissor.minx)
> + if (st->ctx->Scissor.X > (GLint)scissor.minx)
> scissor.minx = st->ctx->Scissor.X;
> - if ((GLuint)st->ctx->Scissor.Y > scissor.miny)
> + if (st->ctx->Scissor.Y > (GLint)scissor.miny)
> scissor.miny = st->ctx->Scissor.Y;
>
> - if ((GLuint)st->ctx->Scissor.X + st->ctx->Scissor.Width < scissor.maxx)
> + if (st->ctx->Scissor.X + st->ctx->Scissor.Width < (GLint)scissor.maxx)
> scissor.maxx = st->ctx->Scissor.X + st->ctx->Scissor.Width;
> - if ((GLuint)st->ctx->Scissor.Y + st->ctx->Scissor.Height <
> scissor.maxy)
> + if (st->ctx->Scissor.Y + st->ctx->Scissor.Height < (GLint)scissor.maxy)
> scissor.maxy = st->ctx->Scissor.Y + st->ctx->Scissor.Height;
>
> /* check for null space */
> --
> 1.6.6.1
>
>
> --
> 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
>
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin Simpson
--
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] What about gl_rasterization_rules?
Personally I omitted it from r300g because nobody used it. That could change, and I know exactly where the flags on the HW are to utilize it. On Thu, Jan 21, 2010 at 9:54 AM, Roland Scheidegger wrote: > On 21.01.2010 18:47, Luca Barbieri wrote: >> On Thu, Jan 21, 2010 at 6:34 PM, Corbin Simpson >> wrote: >>> Maybe it's just me, since I actually wrote the docs, but does anybody >>> else read them? >>> >>> From cso/rasterizer.html (viewable at e.g. >>> http://people.freedesktop.org/~csimpson/gallium-docs/cso/rasterizer.html >>> ): >>> >>> gl_rasterization_rules >>> Whether the rasterizer should use (0.5, 0.5) pixel centers. When >>> not set, the rasterizer will use (0, 0) for pixel centers. >>> >>> So why aren't these patches using >>> pipe_rasterizer_state::gl_rasterization_rules? >> >> It's a different thing. >> gl_rasterization_rules affects the way fragments are rasterized, i.e. >> the set of fragments which a primitive is mapped to. >> Changing it is equivalent to adding/subtracting a subpixel offset to >> the viewport (which seemingly depends on the primitive type). >> >> The pixel center convention instead sets how the values look like in >> the fragment shader. >> Changing it is equivalent to adding/subtracting 0.5 to the >> fragment.position in the fragment shader. >> >> In other words, yes, if you set gl_rasterization_rules and the pixel >> center in a mismatched way, fragment.position will not be the >> coordinate of the "rasterization center". >> >> As another example, suppose you do a blit with the 3D engine using >> fragment.position to sample from a texture rectangle with bilinear >> filtering. >> A wrong rasterization convention may cause 1 pixel black bars at the borders. >> A wrong pixel center convention will cause a 2x2 blur filter to be >> applied to the texture. >> >> BTW, gl_rasterization_rules is ignored by almost all drivers > > Most but not all. Not the software based ones, for instance. Should be > easy to add to r300 (and the nouveau ones, I assume), I guess these > simply don't care enough about environments with different (= DX9) > rasterization rules :-). > > Roland > >> >>>From the spec: >> << >> The scope of this extension deals *only* with how the fragment >> coordinate XY location appears during programming fragment processing. >> Beyond the scope of this extension are coordinate conventions used >> for rasterization or transformation. >> >> -- >> 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 > > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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
[Mesa3d-dev] What about gl_rasterization_rules?
SI_PROPERTY_FS_COORD_ORIGIN:
> + ttr->origin_lower_left = prop->u[0].Data;
> + break;
> + case TGSI_PROPERTY_FS_COORD_PIXEL_CENTER:
> + ttr->pixel_center_integer = prop->u[0].Data;
> + break;
> + }
> +}
> +
> static void handle_immediate(struct tgsi_to_rc * ttr, struct
> tgsi_full_immediate * imm)
> {
> struct rc_constant constant;
> @@ -314,6 +327,9 @@ void r300_tgsi_to_rc(struct tgsi_to_rc * ttr, const
> struct tgsi_token * tokens)
> tgsi_parse_token(&parser);
>
> switch (parser.FullToken.Token.Type) {
> + case TGSI_TOKEN_TYPE_PROPERTY:
> + handle_property(ttr, &parser.FullToken.FullProperty);
> + break;
> case TGSI_TOKEN_TYPE_DECLARATION:
> break;
> case TGSI_TOKEN_TYPE_IMMEDIATE:
> diff --git a/src/gallium/drivers/r300/r300_tgsi_to_rc.h
> b/src/gallium/drivers/r300/r300_tgsi_to_rc.h
> index 93e90ec..392239c 100644
> --- a/src/gallium/drivers/r300/r300_tgsi_to_rc.h
> +++ b/src/gallium/drivers/r300/r300_tgsi_to_rc.h
> @@ -34,6 +34,8 @@ struct tgsi_to_rc {
> const struct tgsi_shader_info * info;
>
> int immediate_offset;
> + unsigned char origin_lower_left : 1;
> + unsigned char pixel_center_integer : 1;
> };
>
> void r300_tgsi_to_rc(struct tgsi_to_rc * ttr, const struct tgsi_token *
> tokens);
> --
> 1.6.3.3
>
>
> --
> 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
>
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin Simpson
--
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] Supporting cards with OpenGL-like WPOS in hardware?
t; ___ >> Mesa3d-dev mailing list >> Mesa3d-dev@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > > > ------ > 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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
[Mesa3d-dev] pipe_vertex_buffer and format translate
So, with half-float vert attribs looming on the horizon, I want to address, hopefully with some finality, vertex attrib formats. Basically, should drivers be expected to use aux/translate on pipe_vertex_buffers that have pipe_vertex_elements not supported in HW? If so, then there's probably a bit more code that can be built up to automate the process. Also it kind of sucks because we can't translate on bind (the st could remap and change VBO data behind our backs) and so we must translate on every single draw. Obviously there's ways to alleviate this, but they all require a tad more typing than I'm going to commit to right now. If not, then can we add a new target/usage/whatever to is_format_supported, or rename it to is_texture_format_supported and add is_vertex_format_supported? Let the state tracker worry about this nonsense. Either way, I anticipate having to build a function that, given a pipe_vertex_element and pipe_vertex_buffer, and a list of acceptable pipe_formats, internally magically modifies things inside so that all resulting VBOs are safe for HW. Thoughts? -- Corbin Simpson -- 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] [PATCH] glsl: put varyings in texcoord slots
Actually, we don't even bother worrying about the rasterizer's routing table until we've bound a pair of shaders and start drawing. Right before the draw call, we re-generate, among other things, routing tables for the vert shader and the rasterizer. This is *incredibly* powerful, because it means we only have to compile the shaders once, and load the rasterizer tables based on those shaders. I even baked up a CSO to cache the tables, but it turned out to be an overall slowdown. If you get this patch in, then you'll still have to fight with every other state tracker that doesn't prettify their TGSI. It would be a much better approach to attempt to RE the routing tables. Also FYI the r300-r500 rasterizer can only handle, off the top of my head, 16 sets of vectors total (8 colors, 8 texcoords) so you're not the only ones with this kind of limitation. The situation gets better for r600 and nv50. ~ C. On Mon, Jan 18, 2010 at 8:27 AM, Luca Barbieri wrote: > So, basically, you allocate the rasterizer units according to the > vertex shader, and when the fragment shader comes up, you say "write > rasterizer output 4 to fragment input 100"? > > The current nouveau drivers can't do this. > There are "routing" registers in hardware, but I think the nVidia > proprietary driver (at least without GLSL) leaves them unaltered after > initialization and I don't think we really know how they would work. > They are also very likely limited to at most 256 values (maybe even > less, such as 16), even if they can actually be made to work. > > The way the current pre-nv50 driver works is that there are 8 slots, > each of which has an interpolator and a fixed associated vertex shader > output and fixed fragment input. This seems a rather obvious way to > design hardware, and so shouldn't be uncommon. > > Thus, the inputs/outputs can't be packed, because that will break if > the fragment shader doesn't use a vertex output. > And there is no way to correct that when the fragment program comes > up, other than recompiling the vertex shader, which would be very > desirable to avoid having to do. > > Non-GLSL programs can only use the 8 texcoords, so there is no problem > there since hardware supports 8 slots. > > Thus, I think my proposed solution is the simplest and most efficient > approach. > Any other solution would require much more, and slower, code in the > Gallium drivers for nv30, nv40, and maybe Intel too. > > -- > 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] [RFC] merge gallium-fb-dimensions
Already reviewed this, looks awesome. Thanks. Posting from a mobile, pardon my terseness. ~ C. On Jan 14, 2010 11:02 AM, "Keith Whitwell" wrote: Unless there are objections, I'll merge this branch tomorrow. Basically the branch just removes the width and height fields from the framebuffer struct, and adds utility functions to extract the same data from the individual surfaces. This lays the groundwork for supporting mixed-size framebuffer attachments, which I'll do in a separate branch. The one outstanding change required is to documentation, which I'll do prior to merging. Keith -- 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 -- 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] Mesa release for the end of March?
Sometime over the next day I will update the docs and flesh out the gallium info. R300g should be marked as testing; it passes roughly as much piglit as softpipe. I would only recommend blocking 7.8 to get those gallium docs filled out; otherwise, no complaints here. Posting from a mobile, pardon my terseness. ~ C. On Jan 13, 2010 2:43 PM, "Brian Paul" wrote: Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > All, > > It's time again... Master seems pretty stable now and I think a 7.8 release would be OK but there are a few semi-major things coming in: 1. A lot of EGL and OpenGL ES changes. 2. I have an outstanding branch that cleans up some texture image code related to mapping/unmapping that I'd like to get merged but it could break some things. I'll try to get back on that one of these days. 3. Ongoing enhancements to gallium to support GL3. That's being done step-by-step and shouldn't cause much upheaval. We can probably put a stake in the ground at any time for 7.8. BTW, when we do get GL3 support we'll bump Mesa to 8.0 but there's no target date yet. > Working backwards from a "last week of March" release, master would have > to branch to mesa_7_8... Sounds OK to me. -Brian -- 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-...@lists.sourceforge... -- 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] Gallium feature levels
The hybrid approach is appealing to me, since Radeons are so damn quirky, but anything not requiring me to set up the dedicated fog block wins my vote. ~ C. On Mon, Jan 11, 2010 at 1:50 PM, Jakob Bornecrantz wrote: > > On 11 jan 2010, at 21.17, Zack Rusin wrote: > >> On Monday 11 January 2010 16:15:38 Jakob Bornecrantz wrote: >>> On 11 jan 2010, at 17.49, Zack Rusin wrote: >>>> I think the other stuff is acceptable. Take a look at the docs and >>>> let me know >>>> what you think. >>> >>> Hmm I don't think you should remove the CAPs but instead just say if >>> level X then CAPs Y,Z,W,Q are assumed to be present. This way the >>> hardware that fall between the cracks can expose one level plus the >>> extra CAPs it can do. >> >> Would that be useful for anything? Or do you mean feature level + >> exceptions, >> oterhwise what's the point of feature levels if nothing supports >> them fully. > > Take the i915 for instance it can do level 1, but it can also do real > npot textures. Not just for last_level == 0. > > Ian said a lot more and better > >> >>> Another thing level 3 and below harder can not do ARB_npot but they >>> can do NV_texture_rect, the only hardware we have drivers that this >>> matter for is nv30 (I think) and r300. >> >> Yes, that's what the "unnormalized coords" part is about :) > > What I meant is that in st_extensions.c you check for feature level > > 1 and set ARB_npot if that is true. But it isn't untill level 4 "2D > textures pot if MipCount >1" is set to no. So to make the test correct > and cover the i915 case the test should be level >= 4 or CAP_NPOT. > > Cheers Jakob. > > -- > 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] Running with scissors
If that's the case, then I will patch the kernel to not be such a crybaby. Posting from a mobile, pardon my terseness. ~ C. On Jan 11, 2010 11:20 AM, "Marek Olšák" wrote: It was NOT intended to be a performance optimization, it's a fix. I added it because kernel would have rejected the command stream if everything had been culled by scissoring. Marek On Mon, Jan 11, 2010 at 4:39 PM, Corbin Simpson wrote: > > > Pardon the subject pun, it was totally necessary at this early hour. :3 > > > If the scissor test ... > > -- > 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
[Mesa3d-dev] Running with scissors
Pardon the subject pun, it was totally necessary at this early hour. :3 If the scissor test is enabled, and the scissors obscure the entire framebuffer, should drawing calls still be run? Talking on IRC, it seems like there's a valid use-case for performance testing, and I'm of the mind that anybody that deliberately sets up the pipeline and scissor that way probably intended for it. I just want a clarification so I know whether I should revert bfcafbe15dc, and also I wanted to document it. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] [PATCH] [RFC] Remove PIPE_TEX_FILTER_ANISO to properly implement GL_EXT_texture_filter_anisotropic
Never had an occasion to really look and see; is there an actual example or use-case? Posting from a mobile, pardon my terseness. ~ C. On Jan 4, 2010 1:07 PM, "Luca Barbieri" wrote: Does this answer really to magnification in addition to minification? In other words, does R300 with anisotropic minfilter + bilinear magfilter behave differently than anisotropic minfilter + anisotropic magfilter? -- 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] [PATCH] [RFC] Remove PIPE_TEX_FILTER_ANISO to properly implement GL_EXT_texture_filter_anisotropic
On r300, aniso definitely works and is noticeably different from bilinear. Posting from a mobile, pardon my terseness. ~ C. On Jan 4, 2010 12:19 PM, "Luca Barbieri" wrote: > Note that different 3d apis have different requirements - ideally we > should be able to choose so... Maybe we could, in addition to this change, split max_anisotropy into max_min_anisotropy and max_mag_anisotropy. That should handle any possible API (unless some cards really give meaning to an anisotropic mipfilter). However, is anisotropic magnification really meaningful? On R300, anisotropic magnification can be set, but does it do anything different than bilinear? If so, what? -- 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] [PATCH] Gallium API demos and supporting infrastructure
Couple things. First, if we're going to start autogenerating headers, can we do GL API first? I've got a handful of patches against those Python scripts, and I can always sit down in a couple days and bang out the rest of it. (While we're at it, since we're doomed to bring it up every couple months, can we do automake? Please?) For coding conventions, sorry for 4-space tabs in r300 and radeon. I don't intend to change it though. If coding conventions are SERIOUS BUSINESS, then can we just write down indent rules? Finally, there are almost certainly already out-of-tree drivers and state trackers based on 0.1 and 0.2 "versions" of the API. Why wasn't it a priority to version the API before? ~ C. On Fri, Jan 1, 2010 at 3:29 AM, Thomas Hellstrom wrote: > Keith Whitwell wrote: >> Luca, >> >> This is an impressive body of work. I want to give Jose a chance to >> review the EGL/GLX extensions before pushing, but in the meantime I hope >> it's ok if I make a couple of quick suggestions/requests: >> >> Firstly, we're going to be evolving the TGSI instruction set a fair bit >> over the coming months to catch up with newer GLSL versions, CL, etc. >> >From that point of view, it would be preferable if the code you've added >> in uureg.h could be automatically regenerated after TGSI changes. I see >> you've got some python in the comments showing how you built the file in >> the first place -- would it be possible to extract that to an actual >> script that the build system can use to regenerate uureg.h on TGSI >> changes? I'm mainly thinking about automatically tracking new >> instructions, I guess. >> >> > One implication of exposing the Gallium API in this way would probably > be that people start to > develop out-of-tree applications, and that means the API needs to be > versioned. > > /Thomas > > > -- > 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] RFC: gallium changes for conditional rendering
How many HW drivers have a conditional render switch? I think all of them, but I'm not sure. At any rate, should be fine for r300. Posting from a mobile, pardon my terseness. ~ C. On Dec 31, 2009 1:57 PM, "Brian Paul" wrote: Here's my first stab at adding conditional rendering to gallium (and softpipe and the Mesa state tracker). It's pretty simple. There's one new pipe_context function: render_condition(). It specifies the pipe_query object to check before rendering. If the query parameter is NULL it means render normally. This is for implementing GL_NV_conditional_render and the corresponding feature in OpenGL 3.0. Comments? -Brian -- 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] geometry shading patches
Half of the in-tree HW-accelerated drivers lack geo shaders, not to mention out-of-tree drivers. I politely request that drivers not be required to have the geo shader hooks filled out; mesa st can detect this and enable extensions appropriately. Posting from a mobile, pardon my terseness. ~ C. On Dec 25, 2009 8:16 AM, "Zack Rusin" wrote: On Friday 25 December 2009 07:03:02 Corbin Simpson wrote: > Isn't this incredibly at odds with our p... No, it's really not. We don't have caps for core features, e.g we don't have caps for vertex shaders and this goes hand in hand with that. Geometry shaders are optional in the pipeline meaning that unlike fragment shaders they can be absent in which case the pipeline behaves just like it would if the api didn't have geometry shaders exposed at all i.e. vertex shader outputs go directly do the fragment shader. So for games/apps that don't use geometry shaders this won't matter at all. And games/app that are so new that they actually check for geometry shaders will already be slow on i915 and r300 not because of geometry shaders, but because they're running on it on i915 or r300 =) Not to mention that this is not a fringe feature that will be present only in super high-end and futuristic hardware. All in all it's a bit like fixed-point hardware - programmable hardware is not a cap because it's what Gallium models. We can't just keep the Gallium interface at i915 level and mark everything above that as a cap, it'd be silly given that we're generations past that now. z -- 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] geometry shading patches
Isn't this incredibly at odds with our previous discussion, in which we generally agreed to not advertise support for unaccelerated things? Geometry shaders are simply not going to have any kind of speed on i915, nv30, nv40, or r300. I can't speak for Jakob or the Nouveau guys, but at least r300g is trying to keep Draw usage to a minimum. I know i915 has to use Draw, so that won't be a problem, but nv30 and nv40 are Draw-free IIRC. ~ C. On Thu, Dec 24, 2009 at 6:09 AM, Keith Whitwell wrote: > Zack, > > In terms of advertising support for this - I wonder if this isn't something > we should just turn on for all drivers, given that in the worst case it is > just a vertex path fallback, and a lot of drivers will be hitting those for > various reasons anyway. > > Keith > > From: Zack Rusin [za...@vmware.com] > Sent: Thursday, December 24, 2009 5:24 AM > To: mesa3d-dev > Cc: Keith Whitwell; Michal Krol > Subject: geometry shading patches > > yo, > > after our discussions i hacked a new version of geometry shading support in > gallium. the new geometry shading syntax looks as follows: > GEOM > PROPERTY GS_INPUT_PRIMITIVE TRIANGLES > PROPERTY GS_OUTPUT_PRIMITIVE TRIANGLE_STRIP > DCL IN[][0], POSITION, CONSTANT > DCL IN[][1], COLOR, CONSTANT > DCL OUT[0], POSITION, CONSTANT > DCL OUT[1], COLOR, CONSTANT > 0:MOV OUT[0], IN[0][0] > 1:MOV OUT[1], IN[0][1] > 2:EMIT > 3:MOV OUT[0], IN[1][0] > 4:MOV OUT[1], IN[1][1] > 5:EMIT > 6:MOV OUT[0], IN[2][0] > 7:MOV OUT[1], IN[2][1] > 8:EMIT > 9:ENDPRIM > 10:END > the attached patch series adds support for all of it throughout gallium > (including support for 2dimensional arrays in tgsi_sanity checking, tgsi_dump > and tgsi_text). > Right now don't support switching of primitives in the draw module (e.g. input > primitive being points and output primitive being a triangle_strip) but i'd > like to do that after committing the attached changes (also the semantic for > vertices which is a leftover from an old patch should be removed then if it's > ok with you). > > Keith, most relevant patches for you are 0001 and 0005. > Michal the most relevant to you are 0007, 0010, 0011 and 0012. > > z > > -- > 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] Yet more r300g fear and loathing...
This is completely reasonable, especially if it only wraps a pipe_context. I'm very okay with not having blitter directly used by pipe drivers. On Mon, Dec 21, 2009 at 9:57 AM, Jakob Bornecrantz wrote: > To be honest I'm way more in favor off doing 4 and/or with a env variable to > switch between incorrect rendering and software fallbacks, but maybe we can > do 3 but with another solution. > > At some point the Gallium interface was a expression of what hardware could > do not a interface to program against. Another guiding rule was that it > should be easy to write a pipe driver, putting all the hard stuff in the > state tracker. > > Now we are starting to see a lot of state trackers and its becoming harder > and harder to implement all the work around for the different caps. Even tho > the fallback/workaround code is in a module that can be shared its still a > pain to integrate and a lot of boiler plate code needs to be written and > maintained. > > Maybe we should revive the fallback module or make a another module like it > that takes care of all these shortcomings of the hardware. But it is > optional to the state tracker. That it is optional to the state tracker is > the big thing. > > So an usecase: > The mesa state tracker takes a look at the pipe caps of the r300 driver and > notices something bad no CAP_NPOT but CAP_TEXRECT. It then wraps the pipe > driver with the fallback pipe driver and uses that. And all the NPOT badness > is hidden from the state tracker. > > The code to switch between software and and hardwware rendering only needs > to be written once this includes the code to detect IF we should switch to > software and code to select between different modes of handling of different > type of errors, like FALLBACK_CONFORM, FALLBACK_BAD_RENDERING. > > The good part with this is that the fallback module is optional and for > state trackers that can handle some of the possible shortcomings or doesn't > need all of the functionality don't need to wrap the pipe driver. > > We get clean drivers, clean state tracker but a heap of code in the fallback > module... > > I could also see the blitter module getting sucked into the fallback module. > > Comments please? > > On 21 dec 2009, at 17.26, Corbin Simpson wrote: >> >> Alright, I think the plan of action here is to create an assistant >> auxiliary module which, given texrects, can provide full NPOT >> functionality, and use it for nv30 and r300. >> >> I'm going to need some API changes. First, I'd like to always assume >> that texrects are available. As far as I can tell, there's no >> Gallium-capable hardware that lacks it. >> >> Then, if this module is going to be transparent to the state trackers, >> I'd like to deprecate or nuke PIPE_CAP_NPOT since any texrect-capable >> driver can transparently become NPOT-capable. >> >> ~ C. >> >> On Mon, Dec 21, 2009 at 7:55 AM, Roland Scheidegger >> wrote: >>> >>> On 21.12.2009 15:13, Henri Verbeet wrote: >>>> >>>> 2009/12/21 Corbin Simpson : >>>>> >>>>> 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. >>>>> >>>>> 2) Don't do NPOT in the pipe, but do it in the state tracker instead, >>>>> as needed. Write up the appropriate fallbacks, and then let ARB_npot >>>>> be advertised by the state tracker regardless of whether PIPE_CAP_NPOT >>>>> is set. Lots of typing, though. Lots and lots of typing. >>>>> >>>>> 3) Same as above, but put all the fallbacks in the pipe instead of the >>>>> state tracker. I am *really* not fond of this, since PIPE_CAP was not >>>>> intended for lies, but it was mentioned in IRC, so I gotta mention it >>>>> here. >>>>> >>>>> 3) The fglrx special: Don't require ARB_npot for advertising GL 2.0. I >>>>> figured this wasn't on the table, but you never know... >>>>> >>>> This is not really about where to implement the fallbacks, but as far >>>> as Wine is c
Re: [Mesa3d-dev] Yet more r300g fear and loathing...
Alright, I think the plan of action here is to create an assistant auxiliary module which, given texrects, can provide full NPOT functionality, and use it for nv30 and r300. I'm going to need some API changes. First, I'd like to always assume that texrects are available. As far as I can tell, there's no Gallium-capable hardware that lacks it. Then, if this module is going to be transparent to the state trackers, I'd like to deprecate or nuke PIPE_CAP_NPOT since any texrect-capable driver can transparently become NPOT-capable. ~ C. On Mon, Dec 21, 2009 at 7:55 AM, Roland Scheidegger wrote: > On 21.12.2009 15:13, Henri Verbeet wrote: >> 2009/12/21 Corbin Simpson : >>> 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. >>> >>> 2) Don't do NPOT in the pipe, but do it in the state tracker instead, >>> as needed. Write up the appropriate fallbacks, and then let ARB_npot >>> be advertised by the state tracker regardless of whether PIPE_CAP_NPOT >>> is set. Lots of typing, though. Lots and lots of typing. >>> >>> 3) Same as above, but put all the fallbacks in the pipe instead of the >>> state tracker. I am *really* not fond of this, since PIPE_CAP was not >>> intended for lies, but it was mentioned in IRC, so I gotta mention it >>> here. >>> >>> 3) The fglrx special: Don't require ARB_npot for advertising GL 2.0. I >>> figured this wasn't on the table, but you never know... >>> >> This is not really about where to implement the fallbacks, but as far >> as Wine is concerned, we'd mostly care about not triggering those if >> we can avoid them, e.g. by restrictions on clamping and filtering. We >> don't care much if GL 2.0 is supported or not, so a hypothetical >> "MESA_conditional_npot" extension would work for us. Other >> applications might care though, in which case an extension that allows >> us to query what situations trigger fallbacks would work for us as >> well. >> >> The fglrx "solution" mostly just sucks, for an important part because >> there's (afaik) no real documentation on what the restrictions are, >> and the reported extensions are now inconsistent with the reported GL >> version. That said, Wine has code to handle this case now, and I >> imagine other applications do as well. > This is a very common hardware problem, there's lots of hardware out > there which can do "some" (like r300) or even all glsl shaders but lack > true npot support. I suspect there might be a few apps which try to see > if ARB_texture_npot is supported, and if not, they'll assume that > functionality isn't supported even if the driver says GL 2.0. There's > certainly precedent for not announcing extensions even if you have to > support it for a given gl version, one prominent example would be the > nvidia GF3/4 cards which were GL 1.4 but couldn't do blend_func_separate > - they didn't announce support for EXT_blend_func_separate and just used > software fallback when they needed. So of course just not announcing > support for it isn't sufficient you still need to implement this somehow > (unless you just want to misrender...) but it might give apps a hint, > even though the API wasn't really designed for this. Sounds like it'll > just pollute things though. Last time I checked the extension mechanism > in gallium when used with dri state tracker was broken though and needed > some work anyway (because dri_init_extensions was called after > st_create_context, and the former just enables lots of extensions > regardless any cap bits, hence the extension string will have lots of > extensions which might not be supported). > > Anyway, doing this in a utility module sounds good, though I'm not sure > what exactly you want to do. You could certainly fix up all texture > lookups in the shader by doing address calculations manually and so on, > but that gets a bit complicated quite soon I guess (in case of r300 it > probably also increases chances a shader won't fit onto hardware a lot). > Maybe misrendering things would still be an option, I think it would > mostly be clamp modes which wouldn't work
[Mesa3d-dev] Yet more r300g fear and loathing...
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. 2) Don't do NPOT in the pipe, but do it in the state tracker instead, as needed. Write up the appropriate fallbacks, and then let ARB_npot be advertised by the state tracker regardless of whether PIPE_CAP_NPOT is set. Lots of typing, though. Lots and lots of typing. 3) Same as above, but put all the fallbacks in the pipe instead of the state tracker. I am *really* not fond of this, since PIPE_CAP was not intended for lies, but it was mentioned in IRC, so I gotta mention it here. 3) The fglrx special: Don't require ARB_npot for advertising GL 2.0. I figured this wasn't on the table, but you never know... Also: Can we assume that texrects are part of core, or are there shaderful chipsets without them? ~ C. -- Corbin Simpson -- 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] [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION
I've started documenting things, using rest (since I already know it). I'll push a branch in a bit once I've got enough of it down. ~ C. On Sat, Dec 19, 2009 at 8:42 AM, Keith Whitwell wrote: > Tom, > > These both look great! The markup language is almost invisible and the raw > documents look a lot like the sort of ascii stuff I tend to write before > figuring out how to turn it into something fancier... Now just to pick one... > > Keith > > From: tom fogal [tfo...@alumni.unh.edu] > Sent: Saturday, December 19, 2009 8:32 AM > To: Keith Whitwell > Cc: Corbin Simpson; Christoph Bumiller; mesa3d-dev@lists.sourceforge.net > Subject: Re: [Mesa3d-dev] [PATCH] gallium: add > PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION > > Keith Whitwell writes: >> Ideally that would mean being able to produce a single patch or patch >> series that contains the changes to the headers *and* the changes to >> the spec, so th at all is being considered together. That means in >> turn having the spec in the git tree. Ideally we'd have an online >> version as well, in a wiki style. I'm interested in suggestions for >> how to make this happen. Ideally we *wouldn't* pollute the header >> files with so much text and markup that they become unreadable - >> ie. I don't really like the idea of doing the spec with doxygen - I'd >> prefer the headers to be human-readable. Thoughts? > > I'm partial to / been considering both asciidoc and sphinx in my own > projects. > > http://www.methods.co.nz/asciidoc/ > http://sphinx.pocoo.org/ > > Both are text-based formats that are intended to be readable `raw', but > are processable into more presentable formats. The git documentation: > > http://www.kernel.org/pub/software/scm/git/docs/user-manual.html > > is done with asciidoc. Python documentation: > > http://docs.python.org/library/index.html > > is done with sphinx. > > -tom > >> >> From: Corbin Simpson [mostawesomed...@gmail.com] >> Sent: Friday, December 18, 2009 7:11 PM >> To: Christoph Bumiller >> Cc: mesa3d-dev@lists.sourceforge.net >> Subject: Re: [Mesa3d-dev] [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_FLATSHA >> DE_FIRST_CONVENTION >> >> NAK to this series. Keith hasn't responded, although I expect that he >> would also NAK this. I would much rather have quads just never respect >> flatshade_first as part of the spec, than jump through these weird >> param hoops. >> >> Should somebody be documenting the API? I keep on having these kinds >> of stupid edge questions come up; r300 apparently is the quirkiest >> hardware of that generation. >> >> ~ C. >> >> On Fri, Dec 18, 2009 at 2:15 AM, Christoph Bumiller >> wrote: >> > Marek Olšák schrieb: >> >> Hi, >> >> >> >> GL_ARB_provoking_vertex states that quads are not required to abide >> >> the provoking vertex convention, and the actual hardware and/or driver >> >> behavior can be queried with >> >> GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION. >> >> >> >> I'd like to add a new PIPE_CAP_* to query for this capability in >> >> Gallium, as it appears R3xx-R5xx hardware doesn't support the first >> >> vertex convention for quads and I'd like the driver to behave >> >> correctly. Fortunately, other primitive types are supported. >> >> >> >> I decided to use the name "quads follow flatshade_first convention" >> >> instead of "provoking vertex convention" because the actual state >> >> variable in pipe_rasterizer_state is called flatshade_first. >> >> >> >> The attached patch: >> >> - adds PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION >> >> - adds the query in the Mesa state tracker >> >> - and updates softpipe and llvmpipe to return 1 when this cap is >> >> queried, and r300g to explicitly return 0 >> >> >> > You can add a "return 1" for nv50, too, in case you do push this patch. >> > I just tested and for quads I can also make them use either the first or >> > the last vertex's colour, i.e. flatshade convention is respected. >> > >> > Thanks, Christoph. >> >> Please review/push. >> >> >> >> Cheers. >> >> >> >> Marek >> >> >> >> >&
Re: [Mesa3d-dev] [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION
Okay, after experimenting a bit, I've found that only quads don't work, see 759fd1f25f3 for details. Thankfully, this is directly addressed in the GL spec; could we maybe redefine the Gallium API to say that quads and quadstrips shouldn't respect the flag? ~ C. On Fri, Dec 18, 2009 at 7:11 PM, Corbin Simpson wrote: > NAK to this series. Keith hasn't responded, although I expect that he > would also NAK this. I would much rather have quads just never respect > flatshade_first as part of the spec, than jump through these weird > param hoops. > > Should somebody be documenting the API? I keep on having these kinds > of stupid edge questions come up; r300 apparently is the quirkiest > hardware of that generation. > > ~ C. > > On Fri, Dec 18, 2009 at 2:15 AM, Christoph Bumiller > wrote: >> Marek Olšák schrieb: >>> Hi, >>> >>> GL_ARB_provoking_vertex states that quads are not required to abide >>> the provoking vertex convention, and the actual hardware and/or driver >>> behavior can be queried with >>> GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION. >>> >>> I'd like to add a new PIPE_CAP_* to query for this capability in >>> Gallium, as it appears R3xx-R5xx hardware doesn't support the first >>> vertex convention for quads and I'd like the driver to behave >>> correctly. Fortunately, other primitive types are supported. >>> >>> I decided to use the name "quads follow flatshade_first convention" >>> instead of "provoking vertex convention" because the actual state >>> variable in pipe_rasterizer_state is called flatshade_first. >>> >>> The attached patch: >>> - adds PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION >>> - adds the query in the Mesa state tracker >>> - and updates softpipe and llvmpipe to return 1 when this cap is >>> queried, and r300g to explicitly return 0 >>> >> You can add a "return 1" for nv50, too, in case you do push this patch. >> I just tested and for quads I can also make them use either the first or >> the last vertex's colour, i.e. flatshade convention is respected. >> >> Thanks, Christoph. >>> Please review/push. >>> >>> Cheers. >>> >>> Marek >>> >>> >>> >>> >>> -- >>> 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 >> > > > > -- > Only fools are easily impressed by what is only > barely beyond their reach. ~ Unknown > > Corbin Simpson > > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION
NAK to this series. Keith hasn't responded, although I expect that he would also NAK this. I would much rather have quads just never respect flatshade_first as part of the spec, than jump through these weird param hoops. Should somebody be documenting the API? I keep on having these kinds of stupid edge questions come up; r300 apparently is the quirkiest hardware of that generation. ~ C. On Fri, Dec 18, 2009 at 2:15 AM, Christoph Bumiller wrote: > Marek Olšák schrieb: >> Hi, >> >> GL_ARB_provoking_vertex states that quads are not required to abide >> the provoking vertex convention, and the actual hardware and/or driver >> behavior can be queried with >> GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION. >> >> I'd like to add a new PIPE_CAP_* to query for this capability in >> Gallium, as it appears R3xx-R5xx hardware doesn't support the first >> vertex convention for quads and I'd like the driver to behave >> correctly. Fortunately, other primitive types are supported. >> >> I decided to use the name "quads follow flatshade_first convention" >> instead of "provoking vertex convention" because the actual state >> variable in pipe_rasterizer_state is called flatshade_first. >> >> The attached patch: >> - adds PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION >> - adds the query in the Mesa state tracker >> - and updates softpipe and llvmpipe to return 1 when this cap is >> queried, and r300g to explicitly return 0 >> > You can add a "return 1" for nv50, too, in case you do push this patch. > I just tested and for quads I can also make them use either the first or > the last vertex's colour, i.e. flatshade convention is respected. > > Thanks, Christoph. >> Please review/push. >> >> Cheers. >> >> Marek >> >> >> >> >> -- >> 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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] gallium: add blitter
As far as immediate verts, why don't we just add support to r300g to switch to immediate mode for small VBOs? Posting from a mobile, pardon my terseness. ~ C. On Dec 13, 2009 3:28 PM, "Marek Olšák" wrote: Hi Keith, I've finished the blitter module. It fully implements the clear, surface_copy, and surface_fill functions. It properly fallbacks to software in case a surface cannot be sampled or rendered to according to usage. Copying a stencil buffer always fallbacks unless the ignore_stencil parameter (see util_blitter_copy) is set to TRUE. To my knowledge, GPUs cannot copy the stencil buffer (not sure if fiddling with texture formats can help). It's all documented in u_blitter.h. The pipe driver can optionally hook up a function to draw a quad (blitter_context::draw_quad). I realized that embedding 4 vertices into a command stream (AKA immediate mode) is much faster than writing them to a vertex buffer due to reduced driver overhead. It might be worth to consider adding the draw_quad function to pipe_context. When working on the blitter, I added the following things to util/u_simple_shaders: - util_make_fragment_tex_shader has a new parametr tex_target and the value should be one of TGSI_TEXTURE_* enums so that it can be used to sample from any kind of texture. - Added util_make_fragment_tex_shader_writedepth, which writes depth sampled from a texture. It's used for copying depth textures. - Added util_make_fragment_clonecolor_shader, which copies input COLOR[0] to a specified number of render targets. It's used to clear MRTs. Also, I moved the code for converting 2D texture coordinates into cubemap texture coordinates from u_gen_mipmap to a new function in util/u_texture. Please review/push. Once it gets approved, I will send patches with r300g blit support to Corbin. With this work, untiling a texture will be as easy as calling surface_copy whereas the driver state remains intact (theoretically). Cheers. Marek On Thu, Dec 10, 2009 at 6:23 PM, Keith Whitwell wrote: > On Thu, 2009-12-10 at 01:52 -0800, Marek Olšák wrote: >> Keith, >> >> I've taken your comment into consideration and started laying out a >> new simple driver module which I call Blitter. The idea is to provide >> acceleration for operations like clear, surface_copy, and >> surface_fill. The module doesn't depend on a CSO context, instead, a >> driver must call appropriate util_blitter_save* functions to save CSOs >> and a blit operation takes care of their restoration once it's done. >> >> I attached a patch illustrating the idea with the clear implemented >> and a working example of usage, but it's not ready to get pushed yet. >> >> Please tell me what you think about it. > > Marek, > > This looks good to me. It looks like this approach keeps the > implementation entirely on the driver side of the interface, which is > what I was hoping for. > > I had assumed that doing this type of operation in the driver would > require assistance "from above" for saving and restoring state. But it > seems like you've been able to do without that, which is nice. > > Let me know how it progresses. > > Keith > > -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-noblocks branch merge
I'm not enthused about this, but the r300g changes look fine, so go for it.
Posting from a mobile, pardon my terseness. ~ C.
On Dec 3, 2009 11:57 AM, "Christoph Bumiller"
wrote:
Roland Scheidegger schrieb:
> Hi, > > I'm planning to merge gallium-noblocks branch to master soon. This
api > change may affec...
What's strange with nv50 ?
There's this one "if (!pt->nblocksx[level]) {" in nv50_transfer.c that
was an unnecessary leftover because I hadn't seen miptree_blanket forgot
the initialize these and pushed a bit too early, thankfully this is now
gone automatically.
I just need the y blocks everywhere instead of just y because things
like offset = stride * y is simply wrong if you have *actual*
multi-pixel blocks (pitch as in nblocksx * width).
I hope no one will try to transfer just parts of a block (makes not much
sense for DXT imo though).
Well, as far as I can see nv50 should still work correctly, thanks for
adapting it.
> certainly if you have out of tree things they will break. > The changes
themselves should be fairl...
--
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] New configure option for mesa (autotools patch)
ISTR that there's a good reason for this behavior, but I can't remember what it is. Ian, Brian? Posting from a mobile, pardon my terseness. ~ C. On Dec 1, 2009 2:16 PM, "Tomáš Chvátal" wrote: Hi, I am cleaning bugs open in gentoo for mesa and i found one with patch attached to it, which is applicable upstream. Patch just allows us to to disable writable relocations in gl. It is "must" for users using PaX and others. For more detailed rationale please look onto bug in our bugzilla [1] Jeremy Huddleston created the patch i attach here and it really fixes the problem. So my question is, could you consider applying this for 7.6 7.7 and trunk? Cheers Tomas [1] http://bugs.gentoo.org/show_bug.cgi?id=240956 -- 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 -- 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] [PATCH] Add entrypoints for setting vertex texture state
R600, FWIW, has fully unified shaders. I think NV50 does too. Doesn't really matter too much though. Posting from a mobile, pardon my terseness. ~ C. On Nov 30, 2009 11:18 AM, "Keith Whitwell" wrote: For the most part in gallium we've treated fragment vs vertex as part of the function name rather than as an argument, so this is consistent. So far it seems hardware isn't very regular at this granularity -- it's not like you just end up doing the same thing for fragment shaders/const-buffers/samplers/textures as you do for the vertex equivalents. The example of passing shader unit as an argument which we have at the moment is constant buffers - in svga and i965 these get split up almost immediately and handled by different paths throughout the driver. If you look at other fragment vs. vertex code (eg shaders) in the drivers, typically they are quite divergent as well. On balance, my preference at this point is to keep distinct entrypoints for each unit... Keith From: José Fonseca [jfons...@vmware.com] Sent: Monday, November 30, 2009 10:51 AM To: Michal Krol Cc: Keith Whitwell; Roland Scheidegger; mesa3d-dev Subject: Re: [Mesa3d-dev] [PATCH] Add entrypoints for setting vertex texture state Sorry for poppin... -- 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] minor u_math.h speedup fun
Do your test again. I just pushed a fairly fast variable-length bitcount. Sorry for not pushing it earlier. Posting from a mobile, pardon my terseness. ~ C. On Nov 28, 2009 10:12 AM, "Joakim Sindholt" wrote: I was perusing the commit log for mesa and stumbled upon the recently added util_bitcount. It uses a rather naïve algorithm and I thought I'd look into it as someone mentioned this problem to me before. This is what I found, should anyone be interested: http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallel In any case, I wrote a little profiler that I have attached (bc.c). The interesting bit is what result it throws out. [zha...@ztoshiba ~]$ gcc bc.c -O3 -o bc && ./bc 1 billion of __builtin_popcount(), fast_bitcount(), and naive() (in that order) __builtin_popcount(): 12.541 seconds fast_bitcount(): 7.312 seconds naive(): 58.240 seconds And this is the real reason I'm putting something this unimportant/trivial on the ML. Should the builtin be removed in favor of this wonder-algorithm? and can I even justify pushing this patch considering the requirement of knowing CHAR_BIT (from limits.h, amount of bits in a char)? -- 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
