Re: [Mesa3d-dev] Yet more r300g fear and loathing...
I am not very fond of the idea having another layer of function-call indirections and state management between a driver and a state tracker. I kinda succeed in making the failover driver work with some hacks and limitations (e.g. no textures). Even if I use it as a simple pass-through driver, it results in 40% performance drop in glxgears and 10% performance drop in progs/perf/draw_overhead. The driver overhead is a real issue here and it might be much higher with a full-blown fallback driver, and nobody wants the performance to suck so much. Also I'd like the applications which don't hit any fallback path to not be affected by this additional overhead, so putting a fallback driver on top of a real driver should be deferred if possible which makes this whole thing non-trivial. In the meantime I think we could lie that NPOTs are supported and implement only the functionality state trackers really want (2D textures with the repeat wrap mode and bilinear filtering done in the shader [0]). That would make all state trackers happy except the Mesa one, but doing software fallback instead would not make it happy either. We're talking about turning unavailable features to unusable ones, is it worth it? [0] I think I could do it if someone tells me how to easily replace TEX instructions with my own code in TGSI. Marek On Mon, Dec 21, 2009 at 6:57 PM, 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? > > 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 > -- 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...
On Mon, Dec 21, 2009 at 12:05:50PM -0700, tom fogal wrote: | Allen Akin writes: | > The only reliable way to solve the problem is to benchmark the | > operations you want to use, in precisely the conditions you intend | > to use them, and then make a judgement as to whether the performance | > is good enough. | | That's not nearly good enough either. Well, as far as I know it's the only existing technique that's guaranteed to work, so I wouldn't dismiss it too casually. I sympathize, though. I've been down this path and I know it isn't an easy one. | Rendering a 128^3 dataset in a 400x400 window (which is *tiny* for us) | on some Apple platforms (I think some Intels, older 10.5 with some ATI | cards) can take upwards of ten minutes, during which the application | is hung. ... So for your app, you can't afford to benchmark every time -- you have to do it once (during testing, at installation, or the first run after installation, for example) and save the results for later reuse. One good way to do this is to provide a separate "tuning" app or script that runs benchmarks and saves configuration information. Users can run it whenever they install/upgrade your app or their hardware. | ... On Linux systems with really old nvidia drivers, it crashes | the system. On Linux systems with old nvidia drivers, it crashes the | X server. On Linux systems with new nvidia drivers, a watchdog timer | kicks in after 4 seconds and the screen visibly blinks, corruption is | observed in other apps such as firefox, etc. Those are genuine problems, and I don't mean to minimize them, but they're outside the scope of the performance-characterization question. If the systems are that unstable, your app is going to have problems even when you're not benchmarking. | Further, drivers can do whatever they want on just about any GL call. | We recently added such a `benchmark' feature to our application, | choosing the LoD dynamically based on the time to render the previous | few frames. Many drivers will take, e.g. ~50ms for the majority of | frames, and then spike with e.g. a 300ms frame before dropping back | down to 50. Yes, that's one of the many problems that make performance "guarantees" less useful than you'd like. I don't know what's happening in the particular case you've described (maybe some time-consuming memory-management operation that's only triggered occasionally), but it's hard for me to see how you could boil down this sort of complex behavior into a caps bit that simply says "accelerated" or "not accelerated". | This `solution' is like asking app developers to benchmark JITted code; | there's far too much variability for it to actually work. ... Experience suggests that's not true in general. Nearly everyone tests their code on some number of systems and tunes it accordingly. What I'm suggesting is just formalizing that process a bit. Your case may be different, of course, but I don't know enough about it to speak to it directly. |... I would much | rather deal with a state explosion. Let's assume for the moment that you can come up with a good scheme for encoding the operations you want and the state that applies at the time the operations are executed (and this is by no means easy). Don't forget that you have to handle sequences of operations, and that execution order matters. You'll have to deal with typically tens of GL state variables that can materially affect the performance of each operation, and you'll also have to deal with behavior that's data-dependent (size limits, powers-of-two, etc.), and you'll also have to deal with state that's outside the GL (e.g. characteristics of the drawing surfaces that are determined by the window system). If you try to handle this as a straightforward database problem, I think you're talking billions of records. On the other hand, there may be only tens to hundreds of cases that are relevant to your app, and your benchmarks for checking them can be concise. This is a genuinely hard problem. The industry uses a mix of caps bits (or equivalent, like extension advertisements), minimum requirements for hardware, and pipeline "validation" schemes. As long as the underlying functionality keeps changing, no single one of these approaches will be ideal for long. At least performance-testing is robust. | > I haven't tracked this subject since I left the ARB, but maybe the | > Khronos folks have done some more work on it. | | What is the appropriate forum for this? I'm sorry, I don't know; I've been away from it for too long. One of the other folks here might be able to make a suggestion. If not, I'd check at opengl.org. | As I argue initially and above, since it is the only possibility at | this point, I'm going to argue strongly that extension advertisement | implies some sort of standard on performance. ... It was once (maybe still is) common policy that the presence of an exten
Re: [Mesa3d-dev] Yet more r300g fear and loathing...
On Mon, Dec 21, 2009 at 10:49:14AM -0700, tom fogal wrote: | ... GL really | needs a query that allows an application developer to figure out if a | feature is accelerated by the hardware or not. Since it lacks this, | the advertising of extensions is just about the only thing we, as app | developers, can use as a heuristic. This has been discussed since the Dawn of Time, but it might be useful to recap the main reasons why such a query doesn't exist: (1) There's no tractable way to enumerate isolated features or deal with the combinatorial explosion of state variables that affect whether any given feature is accelerated. (2) Some features can be partially accelerated, so it's not clear what a query should return in such cases. (3) On some systems, there have been features that were available in the GPU but were faster if implemented in software on the CPU. (4) Even if a feature is "accelerated" in some way, it may still be too slow to use. The only reliable way to solve the problem is to benchmark the operations you want to use, in precisely the conditions you intend to use them, and then make a judgement as to whether the performance is good enough. This tends to be application-specific, so previous attempts to make a centralized database of results failed. I wouldn't say it's impossible, but it is very difficult. I haven't tracked this subject since I left the ARB, but maybe the Khronos folks have done some more work on it. As you say, using extension advertisements seems to be the most common workaround, though it's far from perfect. Allen -- 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...
The draw module approach can only work if the texcoords are used directly for texture lookups, not for calculated coords (it should be possible to detect these cases though). Roland On 21.12.2009 19:32, Keith Whitwell wrote: > Faking those wrap modes is something that could be done either in the > draw module (by decomposing triangles and adjusting the texcoords) or > in the pixel shader (by adding logic to adjust the texcoord on a > per-pixel basis). Probably the draw-module approach is the easiest > to implement and is appropriate for an infrequently used path - you > still get hardware rasterization speeds, just a more expensive vertex > path. > > Keith From: Alex Deucher > [alexdeuc...@gmail.com] Sent: Monday, December 21, 2009 10:18 AM To: > tom fogal Cc: Mesa3D-Development Subject: Re: [Mesa3d-dev] Yet more > r300g fear and loathing... > >> I work on real-time visualization apps; the one in particular I'm >> thinking of does texture sampling of potentially-NPOT textures via >> GLSL. If sampling a NPOT texture is not going to run in hardware, >> the app is useless. Further, our app keeps track of the amount of >> GL memory allocated for textures, FBOs and the like. If a texture >> is going to be silently extended, that messes with our management >> routines [1]. >> > > The hardware supports rectangular texture sampling. What's missing > is support for certain wrap modes and mipmaps with npot textures. > Neither of which are used that often. > > -- > 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] Yet more r300g fear and loathing...
Ah yes, good point... Keith From: Roland Scheidegger [srol...@vmware.com] Sent: Monday, December 21, 2009 11:05 AM To: Keith Whitwell Cc: Alex Deucher; tom fogal; Mesa3D-Development Subject: Re: [Mesa3d-dev] Yet more r300g fear and loathing... The draw module approach can only work if the texcoords are used directly for texture lookups, not for calculated coords (it should be possible to detect these cases though). Roland On 21.12.2009 19:32, Keith Whitwell wrote: > Faking those wrap modes is something that could be done either in the > draw module (by decomposing triangles and adjusting the texcoords) or > in the pixel shader (by adding logic to adjust the texcoord on a > per-pixel basis). Probably the draw-module approach is the easiest > to implement and is appropriate for an infrequently used path - you > still get hardware rasterization speeds, just a more expensive vertex > path. > > Keith From: Alex Deucher > [alexdeuc...@gmail.com] Sent: Monday, December 21, 2009 10:18 AM To: > tom fogal Cc: Mesa3D-Development Subject: Re: [Mesa3d-dev] Yet more > r300g fear and loathing... > >> I work on real-time visualization apps; the one in particular I'm >> thinking of does texture sampling of potentially-NPOT textures via >> GLSL. If sampling a NPOT texture is not going to run in hardware, >> the app is useless. Further, our app keeps track of the amount of >> GL memory allocated for textures, FBOs and the like. If a texture >> is going to be silently extended, that messes with our management >> routines [1]. >> > > The hardware supports rectangular texture sampling. What's missing > is support for certain wrap modes and mipmaps with npot textures. > Neither of which are used that often. > > -- > 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] Yet more r300g fear and loathing...
Allen Akin writes: > On Mon, Dec 21, 2009 at 10:49:14AM -0700, tom fogal wrote: > | ... GL really > | needs a query that allows an application developer to figure out if a > | feature is accelerated by the hardware or not. Since it lacks this, > | the advertising of extensions is just about the only thing we, as app > | developers, can use as a heuristic. [snip -- it's hard to know what to report] > The only reliable way to solve the problem is to benchmark the > operations you want to use, in precisely the conditions you intend > to use them, and then make a judgement as to whether the performance > is good enough. This tends to be application-specific, so previous > attempts to make a centralized database of results failed. I > wouldn't say it's impossible, but it is very difficult. That's not nearly good enough either. Rendering a 128^3 dataset in a 400x400 window (which is *tiny* for us) on some Apple platforms (I think some Intels, older 10.5 with some ATI cards) can take upwards of ten minutes, during which the application is hung. On Linux systems with really old nvidia drivers, it crashes the system. On Linux systems with old nvidia drivers, it crashes the X server. On Linux systems with new nvidia drivers, a watchdog timer kicks in after 4 seconds and the screen visibly blinks, corruption is observed in other apps such as firefox, etc. Further, drivers can do whatever they want on just about any GL call. We recently added such a `benchmark' feature to our application, choosing the LoD dynamically based on the time to render the previous few frames. Many drivers will take, e.g. ~50ms for the majority of frames, and then spike with e.g. a 300ms frame before dropping back down to 50. This `solution' is like asking app developers to benchmark JITted code; there's far too much variability for it to actually work. I would much rather deal with a state explosion. > I haven't tracked this subject since I left the ARB, but maybe the > Khronos folks have done some more work on it. What is the appropriate forum for this? > As you say, using extension advertisements seems to be the most > common workaround, though it's far from perfect. As I argue initially and above, since it is the only possibility at this point, I'm going to argue strongly that extension advertisement implies some sort of standard on performance. Alex reported the HW capabilities in reference to this, which in our case would mean we can use the HW-supported NPOT textures. However in the absence of, say, a vendor extension for reporting this, I'd rather just implicitly enable our workaround at the app level. -tom -- 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...
Faking those wrap modes is something that could be done either in the draw module (by decomposing triangles and adjusting the texcoords) or in the pixel shader (by adding logic to adjust the texcoord on a per-pixel basis). Probably the draw-module approach is the easiest to implement and is appropriate for an infrequently used path - you still get hardware rasterization speeds, just a more expensive vertex path. Keith From: Alex Deucher [alexdeuc...@gmail.com] Sent: Monday, December 21, 2009 10:18 AM To: tom fogal Cc: Mesa3D-Development Subject: Re: [Mesa3d-dev] Yet more r300g fear and loathing... > I work on real-time visualization apps; the one in particular I'm > thinking of does texture sampling of potentially-NPOT textures via > GLSL. If sampling a NPOT texture is not going to run in hardware, > the app is useless. Further, our app keeps track of the amount of GL > memory allocated for textures, FBOs and the like. If a texture is > going to be silently extended, that messes with our management routines > [1]. > The hardware supports rectangular texture sampling. What's missing is support for certain wrap modes and mipmaps with npot textures. Neither of which are used that often. -- 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...
DX9 did. I'm sure DX10 makes a firm choice one way or another and requires the driver to meet that level of functionality. From: Henri Verbeet [hverb...@gmail.com] Sent: Monday, December 21, 2009 10:21 AM To: Jakob Bornecrantz Cc: Corbin Simpson; Keith Whitwell; Mesa3D-Development Subject: Re: [Mesa3d-dev] Yet more r300g fear and loathing... 2009/12/21 Jakob Bornecrantz : > 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. > In that context, it's probably worth mentioning that D3D exposes this with D3DPTEXTURECAPS_NONPOW2CONDITIONAL. -- 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...
The use of fine-grained capability bits isn't really a path we intended to go down - it was fine for major blocks of functionality like GLSL, but adding caps for minor issues is a bit of a lazy trap we've fallen into because we didn't have ready workarounds for the cases where the hardware was missing something. From that point of view I'm very happy with the emergence of the blitter module and similar techniques to allow drivers to implement specific fallbacks internally. That said, I'm not terribly enthusiastic about the idea of a layer between the state-tracker and driver doing fallbacks, at least not one baked into the gallium architecture. The gallium interface really should be a one-way trip, not a back and forth negotiation. For instance, return values on function calls indicating fallback required would be out - this is even worse than fine-grained cap bits from my point of view. I know there are still some boolean return values on the draw calls, but they have never been respected and will go away in the next cleanup. If a driver internally wanted to insert a layer at its topmost interface, in a way that was undetectable from the outside, that would of course be fine. The draw module is effectively such a mechanism and already provides fallbacks for many common shortcomings -- polygon-stipple, line-stipple, aa-lines, aa-points. The blitter module is another. Does it make sense to bundle the two into one entity? I don't know, but one way to start would be to create such an entity that wraps the two existing fallback modules and experiment in that way. Keith From: Corbin Simpson [mostawesomed...@gmail.com] Sent: Monday, December 21, 2009 10:06 AM To: Jakob Bornecrantz Cc: Keith Whitwell; Mesa3D-Development Subject: 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. >>
Re: [Mesa3d-dev] Yet more r300g fear and loathing...
2009/12/21 Jakob Bornecrantz : > 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. > In that context, it's probably worth mentioning that D3D exposes this with D3DPTEXTURECAPS_NONPOW2CONDITIONAL. -- 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...
On Mon, Dec 21, 2009 at 12:49 PM, tom fogal wrote: > Corbin Simpson writes: >> So, yet another thing that r300 sucks balls at: NPOT textures. We've >> been talking it over on IRC, and here's the options. >> >> 1) Don't do NPOT. Stop advertising PIPE_CAP_NPOT, refuse to accept >> non-NPOT dimensions on textures. This sucks because it means that we >> don't get GL 2.0, which means most apps (bless their non-compliant >> souls) will refuse to attempt GLSL, which means that there's really >> no point in continuing this driver. > > What's the performance of NPOT when implemented in the driver? > > I work on real-time visualization apps; the one in particular I'm > thinking of does texture sampling of potentially-NPOT textures via > GLSL. If sampling a NPOT texture is not going to run in hardware, > the app is useless. Further, our app keeps track of the amount of GL > memory allocated for textures, FBOs and the like. If a texture is > going to be silently extended, that messes with our management routines > [1]. > The hardware supports rectangular texture sampling. What's missing is support for certain wrap modes and mipmaps with npot textures. Neither of which are used that often. Alex > We don't have the resources to maintain a card database of "this card > with this driver advertises but implements it in software", though > such a thing is desperately needed. It would be much easier for us if > "advertising means we implement it in HW". Incorrect reporting of > NPOT in particular is so prevalent that we have a settings dialog that > allows a user to "force power of two textures", causing us to silently > extend our textures before uploading them. Many of our users don't > even know what a GPU is. What else can we do, though? > > Anyway, all that said, if performance suffers in any way I vote for > not advertising the extension or GL 2.0. If an application is broken, > an application is broken. Maybe add a debug statement so that the > application author can figure out what they've done wrong, should they > ever find the desire to fix their code. > > I realize this is getting beyond the scope of your inquiry. GL really > needs a query that allows an application developer to figure out if a > feature is accelerated by the hardware or not. Since it lacks this, > the advertising of extensions is just about the only thing we, as app > developers, can use as a heuristic. > > -tom > > [1] ... maybe this isn't such a big deal. GL's memory management is > lame/opaque and as such we haven't found a way to utilize this > information usefully, yet. > > -- > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] 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 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 >>>
Re: [Mesa3d-dev] Yet more r300g fear and loathing...
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 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 npo
Re: [Mesa3d-dev] Yet more r300g fear and loathing...
Corbin Simpson writes: > So, yet another thing that r300 sucks balls at: NPOT textures. We've > been talking it over on IRC, and here's the options. > > 1) Don't do NPOT. Stop advertising PIPE_CAP_NPOT, refuse to accept > non-NPOT dimensions on textures. This sucks because it means that we > don't get GL 2.0, which means most apps (bless their non-compliant > souls) will refuse to attempt GLSL, which means that there's really > no point in continuing this driver. What's the performance of NPOT when implemented in the driver? I work on real-time visualization apps; the one in particular I'm thinking of does texture sampling of potentially-NPOT textures via GLSL. If sampling a NPOT texture is not going to run in hardware, the app is useless. Further, our app keeps track of the amount of GL memory allocated for textures, FBOs and the like. If a texture is going to be silently extended, that messes with our management routines [1]. We don't have the resources to maintain a card database of "this card with this driver advertises but implements it in software", though such a thing is desperately needed. It would be much easier for us if "advertising means we implement it in HW". Incorrect reporting of NPOT in particular is so prevalent that we have a settings dialog that allows a user to "force power of two textures", causing us to silently extend our textures before uploading them. Many of our users don't even know what a GPU is. What else can we do, though? Anyway, all that said, if performance suffers in any way I vote for not advertising the extension or GL 2.0. If an application is broken, an application is broken. Maybe add a debug statement so that the application author can figure out what they've done wrong, should they ever find the desire to fix their code. I realize this is getting beyond the scope of your inquiry. GL really needs a query that allows an application developer to figure out if a feature is accelerated by the hardware or not. Since it lacks this, the advertising of extensions is just about the only thing we, as app developers, can use as a heuristic. -tom [1] ... maybe this isn't such a big deal. GL's memory management is lame/opaque and as such we haven't found a way to utilize this information usefully, yet. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
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 correctly, since AFAIK you > could make even mipmaps work (on r300 at least). > > Roland > -- 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 Ve
Re: [Mesa3d-dev] Yet more r300g fear and loathing...
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 correctly, since AFAIK you could make even mipmaps work (on r300 at least). Roland -- 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...
On Mon, Dec 21, 2009 at 3:02 AM, Corbin Simpson wrote: > 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? NV30 is in the same boat IIRC, so something shareable would be nice. -- 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...
On Mon, Dec 21, 2009 at 09:13:12AM +0100, Michel Dänzer wrote: > On Mon, 2009-12-21 at 00:02 -0800, Corbin Simpson wrote: > > > > 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. > > These two seem like the most reasonable options. I'm leaning towards 3), > mostly for these reasons: > > * It's a limitation of out-of-production hardware, so the onus > should be on the driver[0]. > * 2) would require the same workarounds in more state trackers, > e.g. Xorg. > > [0] That said, it may make sense to implement it as a utility module. > I am voting like Michel :) and voting for [0] too. Cheers, Jerome -- 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...
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 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...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Corbin Simpson schrieb: > 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... Hmm, when the card can't really do ARB_npot, but we want to advertise false OpenGL 2.x support anyway, which needs nport this looks like a good idea: Otherwise OpenGL 1.x apps that do not require ARB_nport might see it in the extension string and use it, assuming it's fast and efficient. Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksvS7kACgkQbtUV+xsoLprlUQCgpFtxgA0BXz080stMEB6L917R qaUAoLONMbqxZL/XTgdAlJ/eQYGj60Lu =ztFa -END PGP SIGNATURE- -- 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...
On Mon, 2009-12-21 at 00:02 -0800, Corbin Simpson wrote: > > 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. These two seem like the most reasonable options. I'm leaning towards 3), mostly for these reasons: * It's a limitation of out-of-production hardware, so the onus should be on the driver[0]. * 2) would require the same workarounds in more state trackers, e.g. Xorg. [0] That said, it may make sense to implement it as a utility module. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- 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] 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
