Given:
TEX foo,bar,texture[0],2D;
I need ‘foo’ to be sampled with the lod it would get from using ‘texcoord[something]’ and ‘texture[0]’.
*** How to do it? ***
note: i use ‘texcoord[something else]’ (could use texcoord[something] too i think) while calculating ‘bar’ - in case it matters.
Actually - i’m prety confused about the whole lod thing:
As ‘bar’ is calculated by me (=> not directly by rasterizer) i don’t see how it can come up with any meaningful lod at all?
Is there some simple explanation of how the lod gets together (ogl1.5 spec was/is a bitch at that … not really helpful at my level of english and fp arb spec points me to ogl spec )?
(NB! i do know what lod is - i just fail to see how the neccessary data to calculate lod gets together in arbfp [given my example problem])
(add new paragraph after first paragraph, p. 137) When fragment
program mode is enabled, the derivatives of the coordinates may be
ill-defined or non-existent. As a result, the implementation is
free to approximate these derivatives with such techniques as
differencing. The only requirement is that texture samples be
equivalent across the two modes. In other words, the texture sample
chosen for a fragment of a primitive must be invariant between
fragment program mode and conventional mode subject to the rules
set forth in Appendix A, Invariance."
Very funny … so, by the spec - a totally random (or read: aproximated to whatever using a method that sounds like producing random crap with anything more interesting as plain deforming) output is perfectly ok if i change the texcoord!?
(that is ok when the derivates are non existent - but what buzzles me with this is: when/how get things ill-defined? … what means ill-defined? … where are the derivates?)
Instead of complaining about the wording of the spec, you should just try it out. The fact of the matter is that it “just works”.
The spec language isn’t that fuzzy either. For a computed coord, there is no clear definition of a derivative. In place of a true derivative, it suggests using a differencing approach.
That does not mean that “normal” texture mapping uses a true derivative. It may very well be using the exact same differencing approach. But because that’s fully equivalent for linearly interpolated texcoords, this distinction is meaningless in practice and in terms of spec conformance. The issue only theoretically crops up with per-fragment computed texcoords, but has essentially been solved years before that.
If you happen to use TXP and/or 4D texcoords, watch out for the w components when computing texcoords in a fragment program. Otherwise everything will be just fine, honest.
The problem with “trying it out” is that my arbfp-able pc is at maintenance (geting back next/coming monday) and the replacemen’t just can’t do.
Also: just out of my previous experience with similar things i have often noticed bugs (tearing / pixelating when there are higher lod levels available) that i could only explain by use of wrong lod - but i can’t be sure.
Thous are the 2 reasons i made this thread.
Also, the fp i did come up with (and can’t just test it) is not just plain deforming the texture (a’la parallax / and the new impressive relief maping thing [that needs way too many indirections to work with my r9600 ]). If i can’t make it use the lod i noted in first post - i can’t see how it could get that lod itself (as the texcoords i use in TEX is not coherent and differs largely from ‘texcoord[something]’).
*** What does it difference? Has anyone a idea how the derivates get computed (just a idea?)? ***
Unfortunately - it seems that implementation is free to choose how to do it. => Depending on the method a implementation uses i could get exactly what i wan’t or pure garbage (assuming the best intentions from who made the implementation). So, even WHEN it works with my gpu it might not work with other gpu’s (or the same gpu and new drivers?).
I do hope that you are right and it works tho.
[About the “spec language isn’t that fuzzy”: well, it is. At least for me who can barely make himself understandable in the language used.]
Depending on the method a implementation uses i could get exactly what i wan’t of pure garbage (assuming the best intentions from who made the implementation). So, even WHEN it works with my gpu it might not work with other gpu’s (or the same gpu and new drivers?).
While I wouldn’t expect both GPU’s to give equal pixel-accurate results, I would expect them to give reasonably close ones.
The LOD computation is done based on the size relative to the texture of the pixel and the screen-space angle of that pixel, determined by the geometry. The only time this is unreasonable is if the texture is a lookup table rather than an imagemap. Even an environment map would use a modestly reasonable LOD. And, on texture units where you are using a lookup table, you probably don’t have mipmaps at all.
I would believe the partial derivatives (and thus LOD selection) to be done like so:
Graphics card rasterizes 4 fragments at a time, arranged in a 2x2 grid.
These fragments are calculated in parallel, hence the ubiquitousness of multiples of 4 in “number of pixel pipelines” (4, 8, 12, 16, …).
These 4 fragments share LOD parameters to some extent.
The LOD is calculated by taking the input values of the coordinates for all four texels at the same time, and comparing them across, and down, by doing simple differencing (i e, partial differences between neighbors). Note that each pixel may still end up with a different LOD, especially under anisotropic filtering, because the top and bottom crosswise differences may be different, as may the left and right heightwise differences.
As you can see, this way, the LOD is magically selected based on the coordinates used by your fragment program. Another surprising corollary is that if you rasterize VERY THIN, VERY LONG triangles, you may get only 1/2 the supposed fragment processing throughput, or less! The fragments will be ratsterized for LOD purposes, but discarded before they hit the framebuffer if they’re outside the actual primitive.
@Korval: i have a mix of lookup table and an imagemap. And that is why i fear of geting crap as result (noticed a typo in my post that you quoted also: “wan’t of pure garbage” should be “wan’t OR pure garbage”).
@jwatte: thought that myself too, but it would mean that the 4 fragments have to communicate between each other in the middle of processing the fragments. (do some work => calculate the used texcoord => wait for other 3 fragments to reach this far => get the differences => proceed with the rest of the shader) So, i don’t think it works like that. But it would be a working solution (which would guarantee bad results with my fp unfortunately) … can anyone confirm? Is something like that used?
i have a mix of lookup table and an imagemap. And that is why i fear of geting crap as result
As I said, your imagemap will be fine (nobody’s complained about odd LOD’s yet), and your lookup tables don’t (or, at least shouldn’t) have mipmaps. Since all the LOD controls is the mipmaps used, there’s no problem when no mipmaps are present.
noticed a typo in my post that you quoted also: “wan’t of pure garbage” should be “wan’t OR pure garbage”
While we’re on the subject of typos, since you brought it up, “wan’t” isn’t a word. “want” is probably what you were going for.
So, i don’t think it works like that.
But that’s exactly what it does, and here’s why. Your fragment programs run in lock-step for each pixel in the “pixel quad”. As such, when one asks for a texture fetch, they all do. This is all just one opcode, with 4 sets of parameters (4 sets of texture coordinates). The single texture unit simply takes the 4 sets of coordinates and, given the geometric relationship of the pixel quad (the screen-space angle) and the 4 sets of coordinates, determines an appropriate LOD for each of the four accesses. The results can be different for each pixel, but the geometric relationships relative to the 4 sets of texture coordinates are what feeds this computation.
Found out that my fears were reasoned (look at the end of this post) - can’t do it. Still - i really wan’t it. And re-found something …
More questions:
QUOTE:
(2) Should the LOD biased texture sample be optional?
RESOLVED: TXB support is mandatory. This exposes useful
functionality which enables blurring and sharpening effects. It
will be more useful to entirely override derivatives (scale
factor) rather than just biasing the level-of-detail. This would
be a future extension to fragment programs.
Any idea why it (override derivates) was not included to the extension?
Some hardware problems not-yet-solved?
Just wanted to get the arb out sooner rather than later?
Not enough interest to bother?
???
An instruction like:
Tsomething resultvector,texcoord,texcoordUsedForLODCalculation,texture,2D
would be perfect. Any idea - is it do-able with current hardware?
Originally posted by Korval: As I said, your imagemap will be fine (nobody’s complained about odd LOD’s yet), and your lookup tables don’t (or, at least shouldn’t) have mipmaps. Since all the LOD controls is the mipmaps used, there’s no problem when no mipmaps are present.
The lookup table has no mipmaps, but the texture it refers to has.
Btw: My tests showed that my current hardware draws in 8x8 pixel blocks (likely because beter texture cache usage) - 2x2 blocks at a time (and geting the derivates using pixels in 2x2 block).
=> Jep. 2x2 thing is right (thanks for clearing it up). => and my shader produces results with “randomly” appearing-disappearing 2x2 blocks of garbage (depending on where the ill-calculated derivates appear [in 2x2 block or between 2x2 blocks]).
There are derivative instructions in NV_fp (DDX, DDY) and GLSL (dFdx(), dFdy()). These instructions allow you to calculate a texture LOD for use with TXB or texture2DLod().
Hm… interesting. (Hello, ATI, why is it that with every passing day my list of, why geting a ATI card was a terrible mistake, grows? R9600 here )
Didn’t find any info about DDX and DDY, but TXL and TXD. This gives some hope. Unfortunately - i didn’t understand what was said about it in spec. Could someone explain/reword it (TXL/TXD) a bit?
GLSL: Well, haven’t touched it so far (but will sometime [soon hopefully]).
genType fwidth (genType p) - looks promising.
BUT: about texture2DLod() there is a odd line: “The built-ins suffixed with “Lod” are allowed only in a vertex shader. For the “Lod” functions, lod is
directly used as the level of detail.”
Originally posted by 1024: BUT: about texture2DLod() there is a odd line: “The built-ins suffixed with “Lod” are allowed only in a vertex shader. For the “Lod” functions, lod is directly used as the level of detail.”
I’ve asked myself and others the exact same question: see this thread . It works just fine in fragment shaders too, the spec just seems to be really badly worded.
Just had to test it out … and it doesn’t work with r9600 (As was also noted in the thread you noted) - hoped that it would fall to some software mode … nope:
“ERROR: 0:18: ‘texture2DLod’ : no matching overloaded function found.” + other resulting errors.
Excuse me if I’m saying something really stupid because I’ve not followed the whole thread, but IMHO you can enforce the LOD by simply providing the BASE and MAX levels of the GL_SGIS_texture_lod extension. The problem being, it can’t be specialized for every fragment (I mean, when rasterizing a single polygon you can’t use different LODs with this method … all the rasterized fragments will use the same LOD).
Originally posted by vincoof: … all the rasterized fragments will use the same LOD).
And that just isn’t enough. They have to use the right LOD - method you mentioned just can’t do it.
)?
(noticed a typo in my post that you quoted also: “wan’t of pure garbage” should be “wan’t OR pure garbage”).
