https://bugs.freedesktop.org/show_bug.cgi?id=25872
Matt Turner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Please run "git clean -fdX" in the Mesa repository and then
reconfigure and rebuild.
Marek
On Fri, Aug 24, 2012 at 11:14 PM, wrote:
> Hello ,r300g driver in current git master was compiled fine, also I cannot
> see anything disturbing in logs.Unfortunatelly when I try to run any opengl
> app it
DRM 2.22.0 is required though. Also require the new DRM for r700, as
there are some important fixes for that generation too.
---
src/gallium/drivers/r600/r600_state.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/galliu
---
src/gallium/drivers/r600/r600_blit.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index e9ed074..5f39e0d 100644
--- a/src/gallium/drivers/r600/r600_blit.c
+++ b/src/gallium/drivers
The blend state is different and the resolve single-sample buffer must have
FMASK and CMASK enabled. I decided to have one CMASK and one FMASK
per context instead of per resource.
There are new FMASK and CMASK allocation helpers and a new buffer_create
helper for that.
---
src/gallium/drivers/r60
---
src/gallium/drivers/r600/r600_state.c | 35 ++---
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index 5b83f51..3e5958a 100644
--- a/src/gallium/drivers/r600/r600_state
The color resolve on r6xx needs PT_RECTLIST. Using conventional primitive
types (triangles and quads) produces an ugly line between two diagonally
opposite corners. I guess a rectangular point sprite would work too.
---
src/gallium/auxiliary/util/u_blitter.c | 21 +++-
src/gallium/auxi
This series implements MSAA for the R6xx family of GPUs.
The only problem is that the depth decompression doesn't work with MSAA depth
buffers, which means for the GL user that depth-stencil blitting and
depth-stencil resolve don't work, although those features are used very rarely,
if at all.
On Thu, Aug 23, 2012 at 11:39 PM, Paul Berry wrote:
> On 23 August 2012 10:42, Marek Olšák wrote:
>>
>> On Thu, Aug 23, 2012 at 6:42 PM, Paul Berry
>> wrote:
>> > On 22 August 2012 18:54, Marek Olšák wrote:
>> >>
>> >> The original samples positions took samples outside of the pixel
>> >> bound
This sets AR_HANDLE_NORMAL for RS880. I've added RS780 too, because I thought
it was a similar GPU, but I cannot test it.
I don't really know if this fix is correct. All I can say is that either
AR_HANDLE_RV6XX is broken (unlikely, but I cannot test it, because none
of my GPUs use it) or RS880 sho
There were no other cases that set it any more.
---
src/mesa/drivers/dri/i965/Makefile.sources |1 -
src/mesa/drivers/dri/i965/brw_draw.c | 30 -
src/mesa/drivers/dri/i965/brw_fallback.c | 84 --
src/mesa/drivers/dri/i965/brw_state.h|
I've reviewed the code, and the swrast callsites remaining are all in
drawpixels/copypixels/bitmap/accum, or _swrast_BlitFramebuffer that shouldn't
be hit. A piglit run with the context setup disabled on legacy GL and GLES2
showed regressions only in the copypixels and drawpixels tests.
If the co
---
src/mesa/drivers/dri/intel/intel_span.c | 28 ---
src/mesa/drivers/dri/intel/intel_tex_validate.c |3 +++
2 files changed, 3 insertions(+), 28 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_span.c
b/src/mesa/drivers/dri/intel/intel_span.c
index 3
swrast uses MapRenderbuffer, which leads to intel_miptree_map, which does the
depth resolve.
---
src/mesa/drivers/dri/intel/intel_span.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_span.c
b/src/mesa/drivers/dri/intel/intel_span.c
index b0dc720
It turns out it hasn't worked since at least 8.0.
---
src/mesa/drivers/dri/i965/brw_fallback.c |5 -
src/mesa/drivers/dri/intel/intel_context.c |2 ++
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fallback.c
b/src/mesa/drivers/dri/i965/
The Fallback field of the context struct doesn't work that way on i965, and
it's the only caller of FALLBACK() in the driver.
---
src/mesa/drivers/dri/i915/i830_state.c | 10 ++
src/mesa/drivers/dri/i915/i915_state.c | 10 ++
src/mesa/drivers/dri/intel/intel_context.c |
This code has been in the driver since the first commit. I think it was
trying to stop rendering from happening with a disabled position array. Core
mesa has since had changes to deal with disabled position arrays correctly.
---
src/mesa/drivers/dri/i965/brw_draw_upload.c |7 ---
1 file
On Fri, Aug 24, 2012 at 08:12:22AM -0700, Ian Romanick wrote:
> On 08/24/2012 03:16 AM, oliver.mcfad...@linux.intel.com wrote:
> > From: Oliver McFadden
> >
> > http://angleproject.googlecode.com/svn/trunk/extensions/ANGLE_texture_compression_dxt.txt
> >
>
> This might be a better link:
>
> http
Now that it's on by default, we may as well make it obey the flag,
for consistency's sake if nothing else.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/s
Precompiling the shader at link time often allows us to avoid compiling
it at the first use. This moves the expensive compilation and
optimization process to game or level load time, rather than at draw
time, where we really can't avoid any cycles and don't want to risk
stalling the GPU.
The down
This fixes a regression since 76d1301e8e8e50dc962601a9977bc52148798349:
I began setting SWIZZLE_XYZW for unused sampler units in the actual
program keys, since this matched the FS precompile behavior. However,
the VS precompile was expecting zero, so that commit made essentially
every vertex shade
Eric added support for WM key debugging. This adds it for the VS.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp | 3 +-
src/mesa/drivers/dri/i965/brw_vs.c | 71 +
src/mesa/drivers/dri/i965/brw_vs.h | 3 ++
3 files
Our previous assumption, SWIZZLE_XYZW, was completely bogus for depth
textures. There are no Y, Z, or W components.
DEPTH_TEXTURE_MODE has three options:
- GL_LUMINANCE:
- GL_INTENSITY:
- GL_ALPHA: <0, 0, 0, X>
The default value is GL_LUMINANCE, and most applications don't seem to
alter DE
Now that most things are based on the linker-assigned index, it makes
sense to convert the arrays in the VS/WM program key as well. It seems
silly to leave them indexed by texture unit.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
src/mesa/drivers/d
brw_wm_prog_key's proj_attrib_mask field is designed to enable an
optimization for fixed-function programs, letting us avoid projecting
attributes where the divisor is 1.0.
However, for shaders, this is not useful, and is pretty much impossible
to guess when building the FS precompile key. Turnin
It's only needed for Gen4/5 IZ lookup workarounds.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_wm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
b/src/mesa/drivers/dri/i965/brw_wm.c
index 8b7d069..9d96961 100644
-
It's only used by the old backend on pre-Sandybridge hardware.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 12
src/mesa/drivers/dri/i965/brw_wm.c | 3 ++-
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_f
We probably want to do something more sophisticated here, but this at
least makes it through L4D2 without dumping the program cache.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_state_cache.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/dri
Here's a follow-up to my last series. Now that the FS precompile
doesn't completely keel over in the face of texturing, I figured I'd
try to fix it up.
The result is pretty good: we now guess correctly most of the time.
On Sandybridge, my L4D2 timedemo has only 39 recompiles, as opposed to
206 be
Kenneth Graunke writes:
> On 08/21/2012 10:49 PM, Eric Anholt wrote:
>> I don't like the idea of losing 16-wide on apps where it might have
>> succeeded if we just tried. Note that a chunk of register space gets
>> eaten by things that don't scale with number of pixels, like attribute
>> setup,
On 08/24/2012 01:19 PM, Eric Anholt wrote:
Ian Romanick writes:
From: Eric Anholt
v2: Use API_OPENGL_CORE.
v3: Only require desktop GL. If a driver can't support TexBOs in a non-core
context, it should not enable them.
From the v3 comment, it sounds like you intend that i965 should not
https://bugs.freedesktop.org/show_bug.cgi?id=54080
Bug #: 54080
Summary: glXQueryDrawable fails with GLXBadDrawable for a
Window in direct context
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
32 matches
Mail list logo
