Re: [Mesa-dev] [RFC] [PATCH 0/2] Allow mesa/st to inform driver of GL_TEXTURE_RECTANGLE

Luca Barbieri wrote: How about moving normalized_coords from the sampler state to the sampler view? As far as I can tell: ARB_sampler_objects doesn't seem to include the texture target or a normalization in the sampler object. DirectX 10 does not support unnormalized coordinates at all. Not sure

Re: [Mesa-dev] [RFC] [PATCH 0/2] Allow mesa/st to inform driver of GL_TEXTURE_RECTANGLE

Marek Olšák wrote: On Thu, Apr 15, 2010 at 10:13 PM, Luca Barbieri > wrote: How about moving normalized_coords from the sampler state to the sampler view? For r300, that's basically the same thing as having it in the sampler_state -- the driver still ne

Re: [Mesa-dev] [RFC] [PATCH 0/2] Allow mesa/st to inform driver of GL_TEXTURE_RECTANGLE

As said on IRC, there is this unfortunate problem: cl_sampler clCreateSampler ( cl_context context, cl_bool normalized_coords, cl_addressing_mode addressing_mode, cl_filter_mode filter_mode, cl_int *errcode_ret) addressing_mode Specifies how out-of-range image c

Re: [Mesa-dev] [RFC] [PATCH 0/2] Allow mesa/st to inform driver of GL_TEXTURE_RECTANGLE

On Thu, Apr 15, 2010 at 10:13 PM, Luca Barbieri wrote: > How about moving normalized_coords from the sampler state to the sampler > view? > For r300, that's basically the same thing as having it in the sampler_state -- the driver still needs to recompile the shader. Also, please ban all the repe

Re: [Mesa-dev] [RFC] [PATCH 0/2] Allow mesa/st to inform driver of GL_TEXTURE_RECTANGLE

Correction: OpenCL has normalized_coords in the sampler state. So I think we should just add the hint I proposed and keep it that way. nv50 will need to create two TIC entries if necessary and switch between them depending on the sampler state: this seems unavoidable given OpenCL support. ___

Re: [Mesa-dev] [RFC] [PATCH 0/2] Allow mesa/st to inform driver of GL_TEXTURE_RECTANGLE

How about moving normalized_coords from the sampler state to the sampler view? As far as I can tell: ARB_sampler_objects doesn't seem to include the texture target or a normalization in the sampler object. DirectX 10 does not support unnormalized coordinates at all. Not sure about pre-DX10, but th

Re: [Mesa-dev] glean pointSprite test

On Wed, Apr 14, 2010 at 8:01 PM, Keith Whitwell wrote: > On Tue, 2010-04-13 at 23:27 -0700, Dave Airlie wrote: >> So I've finished the r300g point sprite code and this test fails, >> fglrx fails the exact same way. >> >> http://people.freedesktop.org/~airlied/piglit/fglrx/fglrxr500/test_glean__poi

Re: [Mesa-dev] [RFC] [PATCH 0/2] Allow mesa/st to inform driver of GL_TEXTURE_RECTANGLE

On 04/15/2010 07:54 PM, Marek Olšák wrote: > Honestly I'd like to have one way to recognize that a texture is addressed > by non-normalized coordinates. > > Right now we have two: > 1) in TGSI via TGSI_TEXTURE_RECT (like OpenGL) > 2) in pipe_sampler_state via normalized_coord (like OpenCL) > > An

[Mesa-dev] [Bug 27654] Remote opengl from Linux client to OSX server fails using LIBGL_ALWAYS_INDIRECT

https://bugs.freedesktop.org/show_bug.cgi?id=27654 Jeremy Huddleston changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

Re: [Mesa-dev] [RFC] [PATCH 0/2] Allow mesa/st to inform driver of GL_TEXTURE_RECTANGLE

Honestly I'd like to have one way to recognize that a texture is addressed by non-normalized coordinates. Right now we have two: 1) in TGSI via TGSI_TEXTURE_RECT (like OpenGL) 2) in pipe_sampler_state via normalized_coord (like OpenCL) And Luca's proposal completes the OpenGL way. I think the fi

[Mesa-dev] piglit list (was: [PATCH 1/2] fdo25614-genmipmap: Require OpenGL 1.3.)

Xavier Chantry wrote: On Wed, Apr 14, 2010 at 10:38 PM, Brian Paul wrote: Xavier Chantry wrote: glActiveTexture is available only if the GL version is 1.3 or greater. Committed. Thanks. We should really have a new mailing list for piglit... That would only work if all the concerned and/o

Re: [Mesa-dev] [PATCH 0/2] swrastg: Don't use drm_api

On Thu, Apr 15, 2010 at 6:22 PM, George Sapountzis wrote: > On Thu, Apr 15, 2010 at 1:31 AM, Jakob Bornecrantz > wrote: >> Hi George >> >> These two patches refactor st/dri and change st/drisw from using drm_api. >> We do not gain anything from using drm_api and it makes it impossible >> to defi

[Mesa-dev] [Bug 27654] Remote opengl from Linux client to OSX server fails using LIBGL_ALWAYS_INDIRECT

https://bugs.freedesktop.org/show_bug.cgi?id=27654 --- Comment #4 from Jeremy Huddleston 2010-04-15 10:29:35 PDT --- Yeah... mesa is asking for an unsupported __GLXconfig We're seeing this logged: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xquartz/GL/indirect.c?id=9ddbb03fa56aa73c3f417d8e

Re: [Mesa-dev] [PATCH 0/2] swrastg: Don't use drm_api

On Thu, Apr 15, 2010 at 1:31 AM, Jakob Bornecrantz wrote: > Hi George > > These two patches refactor st/dri and change st/drisw from using drm_api. > We do not gain anything from using drm_api and it makes it impossible > to define the meaning of struct winsys_handle to something other then > what

[Mesa-dev] [PATCH] savage: call _mesa_meta_init/free()

Fixes crash when using _mesa_CopyTexImage2D. Bug #27652. Signed-off-by: Tormod Volden --- I see this was done for intel/nouveau/radeon/swrast. Maybe it is needed for more drivers as well. src/mesa/drivers/dri/savage/savage_xmesa.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-)

Re: [Mesa-dev] [RFC] [PATCH 0/2] Allow mesa/st to inform driver of GL_TEXTURE_RECTANGLE

On 15.04.2010 19:07, Luca Barbieri wrote: >> So, since one layout requires pot sizes, I guess the problem you have is >> if a texture rectangle just happens to be POT you don't know that in the >> driver upon texture creation time? > > Yes, exactly. > >> It's quite common for hw to have different

Re: [Mesa-dev] [RFC] [PATCH 0/2] Allow mesa/st to inform driver of GL_TEXTURE_RECTANGLE

> So, since one layout requires pot sizes, I guess the problem you have is > if a texture rectangle just happens to be POT you don't know that in the > driver upon texture creation time? Yes, exactly. > It's quite common for hw to have different layouts for pot and npot, > though normally they do

Re: [Mesa-dev] [RFC] [PATCH 0/2] Allow mesa/st to inform driver of GL_TEXTURE_RECTANGLE

On 15.04.2010 09:36, Luca Barbieri wrote: > See also the RFC-gallium-unnormalized-coords-hint branch. > > Currently the Gallium driver has no way of telling that a texture was created > with GL_TEXTURE_RECTANGLE as opposed to GL_TEXTURE_2D. > > Unfortunately, some hardware like nv30 has two textu

[Mesa-dev] [Bug 24093] can't render stuff using webgl on intel

https://bugs.freedesktop.org/show_bug.cgi?id=24093 Kristian Høgsberg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

Re: [Mesa-dev] [Mesa3d-dev] ARB draw buffers + texenv program

On Thu, Apr 15, 2010 at 11:17 AM, Roland Scheidegger wrote: > On 15.04.2010 02:03, Alex Deucher wrote: >> On Wed, Apr 14, 2010 at 5:05 PM, Brian Paul wrote: >>> Moving this to the new mesa-dev list... >>> >>> Roland Scheidegger wrote: On 14.04.2010 00:38, Dave Airlie wrote: > On Wed, Apr

Re: [Mesa-dev] [Mesa3d-dev] ARB draw buffers + texenv program

On 15.04.2010 02:03, Alex Deucher wrote: > On Wed, Apr 14, 2010 at 5:05 PM, Brian Paul wrote: >> Moving this to the new mesa-dev list... >> >> Roland Scheidegger wrote: >>> On 14.04.2010 00:38, Dave Airlie wrote: On Wed, Apr 14, 2010 at 8:33 AM, Roland Scheidegger wrote: > On 13.04.

Re: [Mesa-dev] [PATCH] piglit/general/texunits: fix to check the correct extension and be less pedantic

Luca Barbieri wrote: First of all, according to http://www.opengl.org/registry/api/enumext.spec, the correct extension to check is ARB_vertex_shader. Second, if that is not exposed, the OpenGL implementation can't tell us exactly what it supports, and thus some things that are allowed to fail co

Re: [Mesa-dev] [Mesa3d-dev] Move lists to freedesktop.org?

On Wed, Apr 14, 2010 at 11:16 PM, Brian Paul wrote: > Dan Nicholson wrote: >> >> On Wed, Apr 14, 2010 at 1:52 PM, Brian Paul wrote: >>> >>> Matthew W. S. Bell wrote: On Thu, 2010-04-08 at 16:37 -0700, Jesse Barnes wrote: > > On Thu, 8 Apr 2010 18:38:03 -0400 > Alex Deucher

[Mesa-dev] [PATCH] piglit/general/texunits: fix to check the correct extension and be less pedantic

First of all, according to http://www.opengl.org/registry/api/enumext.spec, the correct extension to check is ARB_vertex_shader. Second, if that is not exposed, the OpenGL implementation can't tell us exactly what it supports, and thus some things that are allowed to fail could succeed instead. I

[Mesa-dev] [PATCH 2/2] st/mesa: set PIPE_RESOURCE_FLAG_UNNORMALIZED_COORDS_HINT for GL_TEXTURE_RECTANGLE

Allow to pass flags to st_texture_create and take advantage of that in the obvious way. --- src/mesa/state_tracker/st_atom_pixeltransfer.c |2 +- src/mesa/state_tracker/st_cb_bitmap.c |4 ++-- src/mesa/state_tracker/st_cb_drawpixels.c |2 +- src/mesa/state_tracker/st_cb_t

[Mesa-dev] [PATCH 1/2] gallium: add PIPE_RESOURCE_FLAG_UNNORMALIZED_COORDS_HINT

This allows the OpenGL state tracker to inform the driver that we are using GL_TEXTURE_RECTANGLE as opposed to GL_TEXTURE_2D. --- src/gallium/include/pipe/p_defines.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/gallium/include/pipe/p_defines.h b/src/gallium/i

[Mesa-dev] [RFC] [PATCH 0/2] Allow mesa/st to inform driver of GL_TEXTURE_RECTANGLE

See also the RFC-gallium-unnormalized-coords-hint branch. Currently the Gallium driver has no way of telling that a texture was created with GL_TEXTURE_RECTANGLE as opposed to GL_TEXTURE_2D. Unfortunately, some hardware like nv30 has two texture layouts, and the first only works with unnormalized