On 08/12/2010 04:06 AM, Marek Olšák wrote:
> On Wed, Aug 11, 2010 at 10:07 PM, Luca Barbieri wrote:
>
>>> Because all nvidia hardware seems to have the normalized bit as a
>> property
>>> of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all
>> ATI
>>> hardware has the normalized
On Wed, Aug 11, 2010 at 10:07 PM, Luca Barbieri wrote:
> > Because all nvidia hardware seems to have the normalized bit as a
> property
> > of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all
> ATI
> > hardware has the normalized bit as part of the texture instruction (it's
> a
On Wed, Aug 11, 2010 at 6:34 PM, Marek Olšák wrote:
> On Wed, Aug 11, 2010 at 10:07 PM, Luca Barbieri
> wrote:
>>
>> > Because all nvidia hardware seems to have the normalized bit as a
>> > property
>> > of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all
>> > ATI
>> > hardwar
On Wed, Aug 11, 2010 at 10:07 PM, Luca Barbieri wrote:
> > Because all nvidia hardware seems to have the normalized bit as a
> property
> > of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all
> ATI
> > hardware has the normalized bit as part of the texture instruction (it's
> a
On Wed, Aug 11, 2010 at 1:07 PM, Luca Barbieri wrote:
>> Because all nvidia hardware seems to have the normalized bit as a property
>> of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all ATI
>> hardware has the normalized bit as part of the texture instruction (it's a
>> shader
> Because all nvidia hardware seems to have the normalized bit as a property
> of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all ATI
> hardware has the normalized bit as part of the texture instruction (it's a
> shader state, so a driver looks for TGSI_TEXTURE_RECT), I believe
On Wed, Aug 11, 2010 at 8:34 PM, Luca Barbieri wrote:
> > I agree that if a texture was created as GL_TEXTURE_RECTANGLE, meaning
> that
> > all shaders use the TGSI_TEXTURE_RECT sampler type, it makes sense to use
> > unnormalized coordinates. However if a texture is NPOT as in OpenGL,
> meaning
>
> With nv50 and nvc0 (Fermi), coordinate normalization is still part of
> the resource and not the sampler state. Even though the hardware does
> support mix and match of samplers and images, this normalization bit
> trashes the orthogonality/elegance.
Oh right, it's strange they didn't fix that i
On 08/11/2010 08:34 PM, Luca Barbieri wrote:
>> I agree that if a texture was created as GL_TEXTURE_RECTANGLE, meaning that
>> all shaders use the TGSI_TEXTURE_RECT sampler type, it makes sense to use
>> unnormalized coordinates
...
>
>> Some time ago I think Brian suggested to add PIPE_TEXTURE_RE
> I agree that if a texture was created as GL_TEXTURE_RECTANGLE, meaning that
> all shaders use the TGSI_TEXTURE_RECT sampler type, it makes sense to use
> unnormalized coordinates. However if a texture is NPOT as in OpenGL, meaning
> that all shaders use the TGSI_TEXTURE_2D sampler type, we should
On Wed, 2010-08-11 at 10:44 -0700, Marek Olšák wrote:
> I agree that if a texture was created as GL_TEXTURE_RECTANGLE, meaning
> that all shaders use the TGSI_TEXTURE_RECT sampler type, it makes
> sense to use unnormalized coordinates. However if a texture is NPOT as
> in OpenGL, meaning that all s
I agree that if a texture was created as GL_TEXTURE_RECTANGLE, meaning that
all shaders use the TGSI_TEXTURE_RECT sampler type, it makes sense to use
unnormalized coordinates. However if a texture is NPOT as in OpenGL, meaning
that all shaders use the TGSI_TEXTURE_2D sampler type, we shouldn't forc
> It might even be a good idea to split it in two flags, one for state
> tracker->driver communication, and another for the driver->state
> tracker.
> This way, r300g won't have to do anything.
On second thought, maybe not, since the normal thing is for the
driver to accept the state tracker's dem
> I am not sure if the following is legal, but I think we will just mask this
> unnormalized flag out in resource_create, because r300 doesn't like (read:
> doesn't support in hardware) unnormalized texture coordinates, and switching
> shaders just because of the flag is silly.
Hmm I thought it su
On Wed, Aug 11, 2010 at 5:41 PM, Luca Barbieri wrote:
> > I'm completely okay with this iteration of this patchset, since it
> > requires no Gallium API changes and seems very straightforward. I do
> > have a question, though, since I'm so unfamiliar with nvfx. In r300g
> > there is a fragment pro
> I'm completely okay with this iteration of this patchset, since it
> requires no Gallium API changes and seems very straightforward. I do
> have a question, though, since I'm so unfamiliar with nvfx. In r300g
> there is a fragment program rewrite to normalize texcoords
> unconditionally for r300
On Wed, Aug 11, 2010 at 4:44 AM, Luca Barbieri wrote:
> Currently Gallium doesn't know about GL_TEXTURE_RECTANGLE textures, except
> for the normalized coordinates bit in the sampler state.
> Also, internal code always use normalized coordinates.
>
> This works fine on new hardware, but on older h
Currently Gallium doesn't know about GL_TEXTURE_RECTANGLE textures, except
for the normalized coordinates bit in the sampler state.
Also, internal code always use normalized coordinates.
This works fine on new hardware, but on older hardware like nv30, coordinate
normalization is coupled to the re
18 matches
Mail list logo
