Note: as usual, testing should use either Firefox Nightly (nightly.mozilla.org,
currently version 17.0a1) or Chromium / Chrome Canary.
Benoit
- Original Message -
> Hi,
>
> Just so you know: the WebGL 1.0.1 tests are now passing on 2 drivers
> on Linux: the Intel Mesa driver, and the NV
Hi,
Just so you know: the WebGL 1.0.1 tests are now passing on 2 drivers on Linux:
the Intel Mesa driver, and the NVIDIA driver.
Technically that's enough for us to claim conformance (we need to pass with 2
drivers on each OS we support).
But I'd really like to include the Radeon driver in the
https://bugs.freedesktop.org/show_bug.cgi?id=52167
Fabio Pedretti changed:
What|Removed |Added
CC||fabio@libero.it
--
Configure bugma
On Tue, Jul 31, 2012 at 10:53:11AM -0700, Kenneth Graunke wrote:
> On 07/31/2012 08:41 AM, Eric Anholt wrote:
> > Kenneth Graunke writes:
> >
> >> This reverts commit e72f20641a6ea7875b6021aac13e778ada3b3d50.
> >>
> >> The commit has two problems:
> >> - The commit message itself quotes language
In i965 Gen7, Mesa has for a long time used the "depth coordinate
offset X/Y" settings (in 3DSTATE_DEPTH_BUFFER) to cause the GPU to
render to miplevels other than 0. Unfortunately, this doesn't work,
because these offsets must be aligned to multiples of 8, and miplevels
in the depth buffer are on
In i965 Gen6, Mesa has for a long time used the "depth coordinate
offset X/Y" settings (in 3DSTATE_DEPTH_BUFFER) to cause the GPU to
render to miplevels other than 0. Unfortunately, this doesn't work,
because these offsets must be aligned to multiples of 8, and miplevels
in the depth buffer are on
Just looking for a quick patch review to make sure I've backported
these patches to 8.0 correctly (and also confirmation that this
backport is a good idea). These patches are intended to apply to the
8.0 branch.
The issue is that on Gen6 and Gen7, images rendered to depth and
stencil buffers must
Commit f0cecd43d6b6d moved the VUE map computation to be only once, at
VS compile time. However, it did so in slightly the wrong place: it
made the one call to brw_vue_compute_map happen right before the
allocation of dummy slots for replaced point sprite coordinates, causing
a different VUE map t
We are still 1 1/2 month into XDC 2012 so it's time to give
a status update and beat the drums some more:
- Registration Reminder:
So far we have 24 registered participants: there's plenty of
room for more - so if you haven't done so: register!
If you are in need for travel sponsorship plea
Couldn't spot any problem. Seems like a nice cleanup.
Reviewed-by: Jose Fonseca
Jose
- Original Message -
> ---
> src/mesa/state_tracker/st_atom_sampler.c |2 --
> src/mesa/state_tracker/st_atom_texture.c | 24
>
> src/mesa/state_tracker/st_context.c
- Original Message -
> Less code. And as with softpipe, if/when we consolidate the
> pipe_context
> functions for binding sampler state, this will make the llvmpipe
> changes
> trivial.
> ---
> src/gallium/drivers/llvmpipe/lp_state_sampler.c | 118
> ++-
> 1 files
Reviewed-by: Jose Fonseca
- Original Message -
> Fixes resource leak defect reported by Coverity.
>
> Signed-off-by: Vinson Lee
> ---
> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_glsl_
Looks good. Thanks.
Jose
- Original Message -
> Fixes uninitialized scalar field defect reported by Coverity.
>
> Signed-off-by: Vinson Lee
> ---
> src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/auxiliary/gallivm
See the preceding commit for a description of the problem.
NOTE: This is a candidate for stable release branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52129
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 60 ++
1 fil
Consider a texture call such as:
textureLod(s, coordinate, log2(...))
First, we begin setting up the sampler message by loading the texture
coordinates into MRFs, starting with m2. Then, we realize we need the
LOD, and go to compute it with:
ir->lod_info.lod->accept(this);
On Gen4-5, thi
With the textureRect support and GL_CLAMP workarounds, it's grown
sufficiently that it deserves its own function. Separating it out
makes the original function much more readable.
While we're refactoring it, tidy up a conditional. Instead of:
if (gen < 6 && rect)
...
else if (rect)
While working on
https://bugs.freedesktop.org/show_bug.cgi?id=52129
I discovered that we have a nasty bug in our texturing code, dating all
the way back to the advent of the new FS backend. If you generate a
sampler message whose subexpressions (like LOD or shadow comparitor)
require SENDs to ge
Setting the texture offset bits in the message header involves very
specific hardware register descriptions. As such, I feel it's better
suited for the lower level "generate" layer that has direct access to
the weird register layouts, rather than at the fs_inst abstraction layer.
This also parall
18 matches
Mail list logo
