On 14 November 2011 14:49, Vadim Girlin vadimgir...@gmail.com wrote:
By the way, which drivers do not support reading outputs? I haven't done
a full piglit run with llvmpipe, but IIRR the single test mentioned
above was also fixed for llvmpipe without this output replacement.
IIRC both GLSL IR
On 14 November 2011 17:29, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
And r600, I think, just stores them all in TEMP space and exports them
in the end, so it's rather a property of the shader backend that the
device (I may be wrong though).
Instructions generally all work on GPRs
On 15 November 2011 14:52, Jose Fonseca jfons...@vmware.com wrote:
Developer time is important too. And having more code paths shared with other
drivers (even at the expense of a few extra CPU cycles every time a shader is
created) means that developers has more time to focus on features that
This has no piglit regressions on r600g and softpipe.
Signed-off-by: Henri Verbeet hverb...@gmail.com
---
src/mesa/state_tracker/st_cb_texture.c | 174 +---
1 files changed, 91 insertions(+), 83 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src
On 19 July 2011 21:39, tom fogal tfo...@sci.utah.edu wrote:
I think you have misinterpreted my question.
Why not just have glGetString's prototype be:
const char* glGetString(GLenum);
? Then (sans the missing const :), your code below would work on *all*
platforms, MIPSpro or not, with or
On 23 July 2011 10:58, Ian Romanick i...@freedesktop.org wrote:
+ * explose the 3dc formats through this mechanism.
Typo.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 23 July 2011 16:58, Brian Paul brian.e.p...@gmail.com wrote:
Also, look for comptaibility
Looks like that is actually in the extension spec like that.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Without this we'd miss an update when doing a sequence like {COLOR0, COLOR1},
{COLOR0}, {COLOR0, COLOR1}.
NOTE: This is a candidate for the 7.10 and 7.11 branches.
Signed-off-by: Henri Verbeet hverb...@gmail.com
---
src/mesa/main/buffers.c |5 -
1 files changed, 4 insertions(+), 1
On 26 July 2011 01:02, Eric Anholt e...@anholt.net wrote:
I don't see that, because the while (buf MaxDrawBuffers) loop would
notice the change from COLOR1 - NONE.
That loop doesn't happen because n == 1 for {COLOR0} (as opposed to
{COLOR0, NONE}). Perhaps we should always explicitly set any
On 26 July 2011 02:21, Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/25/2011 01:23 PM, Henri Verbeet wrote:
Without this we'd miss an update when doing a sequence like {COLOR0, COLOR1},
{COLOR0}, {COLOR0, COLOR1}.
Is there a piglit test
On 7 August 2011 19:03, Lauri Kasanen c...@gmx.com wrote:
+ /* floor(a + 0.5) */
Why not use RNDNE?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 8 August 2011 02:24, Jose Fonseca jfons...@vmware.com wrote:
There's no wrong or right when there are two equidistant integers -- it's
all a matter of convention.
But note that rounding to nearest even is a slightly better convention
in terms of rounding bias. I.e., not using RNDNE is both
On 8 August 2011 03:58, Jose Fonseca jfons...@vmware.com wrote:
It's subjective. It depends on the expected input distribution, which is
effectively impossible to characterize in general. One can easily find
datasets where one method gives biased results and the other not, and vice
versa.
On 9 August 2011 23:45, Marek Olšák mar...@gmail.com wrote:
texture, so we'd be noncompliant. Noncompliant is probably better than
not working at all. So what do you guys think?
In the general case, no. A missing extension is something applications
can deal with if they care to, a broken
On 17 September 2011 19:33, Brian Paul brian.e.p...@gmail.com wrote:
From: Brian Paul bri...@vmware.com
If we're generating a mipmap for an sRGB texture we need to bypass
sRGB-linear conversion. Otherwise the destination mipmap level
(drawn with a textured quad) will have the wrong colors.
On 19 September 2011 19:23, Ian Romanick i...@freedesktop.org wrote:
Direct3D 9 calls the eye radial fog distance mode range-based fog
and Wine's D3D9 implementation will use NV_fog_distance to
implement it. Several other open source game engines in Google Code
Search use the eye radial fog
On 22 September 2011 01:10, Eric Anholt e...@anholt.net wrote:
wined3d is the only potential consumer I've ecountered. I don't think I
Yeah, although I'm not entirely convinced of the usefulness of wined3d
using the extension either. Apple seems to have their fair share of
APPLE_client_storage
for
output colors beyond n is set to NONE., and this is queryable state.
This fixes piglit arb_draw_buffers-state_change.
NOTE: This is a candidate for the 7.10 and 7.11 branches.
Signed-off-by: Henri Verbeet hverb...@gmail.com
---
src/mesa/main/buffers.c | 27 ---
1 files
On 23 September 2011 01:48, Eric Anholt e...@anholt.net wrote:
In the case of n == 1 with more than one bit set, doesn't this stomp the
_ColorDrawBufferIndexes[] we just calculated between n and
_NumColorDrawBuffers - 1? Looks like splitting that loop into two would
work well.
You're right,
On 14 February 2013 11:42, Christian König deathsim...@vodafone.de wrote:
nice work, I think you've made quite a progress here, but on the other hand
it should be clear that the LLVM backend is the future and we should
concentrate on that.
I'm not sure that's really true. My impression is that
On 14 February 2013 12:28, Christian König deathsim...@vodafone.de wrote:
Well apart from a bit strange coding style and the use of SVN, I can't
really see any problems that are related to using LLVM as it is.
Well, for one, I don't think LLVM believes in stable APIs or shared
libraries, and I
On 24 February 2013 17:07, Vadim Girlin vadimgir...@gmail.com wrote:
If you'd like to help me with debugging the issues on cayman, then please
read the regression debugging section in the r600-sb branch notes [1] (or
possibly more up-to-date source here - [2]), it explains how to find the
Great, I'll do some testing again when I get the chance.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
All the Wine D3D tests now (3931289ab5fc7c7e2ab46e6316e55adc19ec3cfc)
pass for me on Cayman. I may be able to do some more testing later,
and do e.g. a piglit run.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On 2 March 2013 00:14, Ian Romanick i...@freedesktop.org wrote:
I added some comments, but I think the extension is pretty much fine
for at least Wine's purposes.
GLX_ARB_create_context and GLX_ARB_create_context_profile are required.
It's probably not a big deal since just about everyone
On 12 March 2013 17:46, Ian Romanick i...@freedesktop.org wrote:
Right... the extension also adds an attribute that can only be used with
glXCreateContextAttribsARB.
Yeah, all I was saying is that it probably wouldn't be too hard to
word things along the lines of If glXCreateContextAttribsARB()
On 19 April 2013 16:48, Vadim Girlin vadimgir...@gmail.com wrote:
In the previous status update I said that the r600-sb branch is not ready to
be merged yet, but recently I've done some cleanups and reworks, and though
I haven't finished everything that I planned initially, I think now it's in
On 19 April 2013 18:01, Vadim Girlin vadimgir...@gmail.com wrote:
The choice of C++ (unlike in my previous branch that used C) was mostly
driven by the fact that optimization algorithms usually deal with a lot of
different complex data structures, containers, etc, and C++ allows to
isolate
On 3 June 2013 22:16, Kenneth Graunke kenn...@whitecape.org wrote:
I don't think we should implement front buffer rendering for EGL unless
someone presents a compelling use case. In my mind, front buffer rendering
is only something used historically...it has all kinds of caveats about
On 22 July 2013 18:48, Stefan Dösinger stefandoesin...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-07-22 15:39, schrieb Jose Fonseca:
It seems to me that this would be more useful if the state tracker
targeted not the D3D9 API, but the WDDM D3D9 DDI [2]. Targeting
On 9 August 2013 22:40, Marek Olšák mar...@gmail.com wrote:
Tested by examining generated TGSI shaders from piglit/glsl-routing.
This fixes the relevant Wine d3d9 test, thanks. No piglit changes on Cayman.
Reviewed-by: Henri Verbeet hverb...@gmail.com
Tested-by: Henri Verbeet hverb
isn't very stable to begin with
when fog start and end are close together, it seems best to just leave it
alone.
This fixes a couple of Wine D3D tests. No piglit changes on Cayman.
Signed-off-by: Henri Verbeet hverb...@gmail.com
---
src/mesa/program/prog_statevars.c |3 +--
1 file changed, 1
On 18 August 2013 05:23, Ian Romanick i...@freedesktop.org wrote:
Since this also fixes an application, do you have any idea what could be
done to make a piglit test to reproduce the failure? We have some folks
writing piglit tests for us this summer, and this sounds like a good one for
them.
On 22 August 2013 00:31, Ian Romanick i...@freedesktop.org wrote:
Section 2.1.1 (Floating-point computation) says:
The result of providing a value that is not a floating-point
number to such a command is unspecified, but must not lead to
GL interruption or termination. In IEEE
I assume this should have been part of commit
7727fbb7c5d64348994bce6682e681d6181a91e9. This (obviously) fixes a lot tests.
Signed-off-by: Henri Verbeet hverb...@gmail.com
---
src/gallium/drivers/r600/r600_shader.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
On 28 August 2013 12:17, Marek Olšák mar...@gmail.com wrote:
Yeah, st/mesa also compiles shaders on the first use, so we've got 3
places to fix: Wine, st/mesa, the driver.
For what it's worth, while Wine definitely has some room for
improvement in this regard, in some cases we don't get the
On 3 September 2013 13:19, Rico Schüller kgbric...@web.de wrote:
So yes, we agree here, the version number needs to be fixed. The simplest
one is to just change the number. I'm fine with it. I have no strong
opinion about it. Though I think it should be consistent across all
initialization
On 1 August 2012 03:04, Eric Anholt e...@anholt.net wrote:
Prior to GL 4.2 spec, there was no guidance on how to implement
BlitFramebuffer for sRGB. Mesa chose to implement skipping decode and encode,
providing a reasonable behavior for sRGB - sRGB or RGB - RGB, but providing
something absurd
On 2 November 2012 22:22, Marek Olšák mar...@gmail.com wrote:
Yeah. However as far as I know, the desktop GL doesn't have a (good)
S3TC extension which doesn't require on-line compression. With what
you say, it looks like such an extension would be useful for us. Don't
you think it would be
On 6 December 2012 21:34, Tom Stellard t...@stellard.net wrote:
I asked idr about this on IRC and he said that IEEE rules are required for
GLSL = 1.30 and they are compliant, but not required for GLSL 1.30.
stringfellow added that the d3d9 spec required 0*anything = 0, which is
probably why
On 8 December 2012 16:01, Alex Deucher alexdeuc...@gmail.com wrote:
What about a mesa specific extension? Most people will be using wine
on Linux anyway.
Sure, that works for us. Assuming Mesa is interested in a such an
extension, of course.
___
On 11 December 2012 13:57, Marek Olšák mar...@gmail.com wrote:
We already have the Mesa version in the version string, isn't that enough
to detect Mesa?
In theory, although the vendor string would IMO be the expected place for that.
___
mesa-dev
This is used by st_BlitFramebuffer() / r600_blit(), and ARB_fbo allows
overlapped blits, even though the result is undefined. No piglit regressions
on r600g / CYPRESS.
---
src/gallium/auxiliary/util/u_blitter.c | 28
1 files changed, 0 insertions(+), 28 deletions(-)
On 14 December 2012 09:27, Michel Dänzer mic...@daenzer.net wrote:
On Fre, 2012-12-14 at 06:04 +0100, Henri Verbeet wrote:
This is used by st_BlitFramebuffer() / r600_blit(), and ARB_fbo allows
overlapped blits, even though the result is undefined. No piglit regressions
on r600g / CYPRESS
On 19 April 2010 15:38, José Fonseca jfons...@vmware.com wrote:
A big user of this extension would be wine, but I've checked their
source code and they don't use it yet. Actually, they just set negative
vertex buffers offsets as a unsigned and pray that the two's complement
arithmetic inside
---
src/mesa/drivers/dri/r600/r700_fragprog.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/r600/r700_fragprog.c
b/src/mesa/drivers/dri/r600/r700_fragprog.c
index 80fab71..fbb808e 100644
---
So X can't be sourced from W for sRGB formats.
---
src/mesa/drivers/dri/r600/r600_blit.c | 10 ++
src/mesa/drivers/dri/r600/r600_texstate.c | 11 +++
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/r600/r600_blit.c
---
src/mesa/drivers/dri/r600/r700_fragprog.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/r600/r700_fragprog.c
b/src/mesa/drivers/dri/r600/r700_fragprog.c
index bf17a97..fa01890 100644
--- a/src/mesa/drivers/dri/r600/r700_fragprog.c
+++
On 19 July 2010 23:13, Matt Turner matts...@gmail.com wrote:
I can't speak to the meaning of this change, but the use of ^ and !!
is just an abuse of the language.
^ is binary XOR. Logical XOR is !=.
Let's write this like
if ((ctx-Point.SpriteOrigin == GL_LOWER_LEFT) !=
This supersedes
http://lists.freedesktop.org/archives/mesa-dev/2010-July/001442.html.
---
src/mesa/drivers/dri/r600/r700_fragprog.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/r600/r700_fragprog.c
b/src/mesa/drivers/dri/r600/r700_fragprog.c
On 20 July 2010 01:02, Dave Airlie airl...@gmail.com wrote:
Its abuse because if you read that your brain would have to go wtf at
least twice,
I don't mind !!, since your brain can deal with that, but using binary
operators where you really want logical is really bad for the reader.
Open
On 22 July 2010 17:18, Alex Deucher alexdeuc...@gmail.com wrote:
Is there any value to keeping these around for future shader compiler work?
I doubt it. These are all trivial, the commented out code mostly
doesn't even compile, and the vfetch stuff should be handled by
Clean_Up_Shader().
On 3 August 2010 15:52, Brian Paul bri...@vmware.com wrote:
Axes, Henri and Macij should double-check their patches but I'm OK with the
If that's a64b14fdcfdc045e027c4d81e0add1a85e381619 and
b132401075bd9c358c30211a0b364699ab6f7463, I think those should be safe
enough. Note that passing -x to
On 3 August 2010 18:21, Alex Deucher alexdeuc...@gmail.com wrote:
On Tue, Aug 3, 2010 at 10:41 AM, Henri Verbeet hverb...@gmail.com wrote:
On 3 August 2010 15:52, Brian Paul bri...@vmware.com wrote:
Axes, Henri and Macij should double-check their patches but I'm OK with the
If that's
On 5 August 2010 18:51, Chia-I Wu olva...@gmail.com wrote:
The GL rule is last vertex last for each primitive. The D3D rule is first
vertex first. My idea is to have draw_decompose_tmp.h use a local variable,
last_vertex_last, to select the rules. In draw_gs_tmp.h and
draw_so_emit_tmp.h,
There may actually be something mapped in that range, especially for large
buffers like e.g. the GL Drawable. Should it ever be valid to destroy a bo
that's still mapped in the first place though?
---
src/gallium/winsys/r600/drm/radeon_bo.c |4 +++-
1 files changed, 3 insertions(+), 1
---
src/mesa/drivers/dri/r600/r700_assembler.c | 25 +++--
src/mesa/drivers/dri/r600/r700_assembler.h |2 +-
2 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/r600/r700_assembler.c
b/src/mesa/drivers/dri/r600/r700_assembler.c
index
On 21 September 2010 10:42, Keith Whitwell kei...@vmware.com wrote:
I don't see any reason not to merge this to master straight away -- this
is all self-contained in its own directory doesn't seem like it will
regress anything else...
Since this is derived from code in the DDK, this will
On 21 September 2010 13:13, Luca Barbieri l...@luca-barbieri.com wrote:
Why are you claiming this?
I assume it's because of the comment in tpf.h, which states that it
has been written according to Microsoft's documentation, which is
available solely from reading the
---
src/mesa/state_tracker/st_cb_texture.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 866426a..14d33f7 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++
Base level and min LOD aren't equivalent. In particular, min LOD has no
effect on image array selection for magnification and non-mipmapped
minification.
---
src/mesa/state_tracker/st_atom_sampler.c |9 +++--
src/mesa/state_tracker/st_atom_texture.c |4 +++-
2 files changed, 6
2011/1/10 Andy Furniss andy...@ukfsn.org:
r600_asm.c: In function 'r600_bc_dump':
r600_asm.c:2334: error: 'struct r600_bc_cf' has no member named
'kcache0_mode'
r600_asm.c:2335: error: 'struct r600_bc_cf' has no member named
'kcache0_bank'
r600_asm.c:2336: error: 'struct r600_bc_cf' has no
On 13 January 2011 06:49, Dave Airlie airl...@gmail.com wrote:
I'd really like to make sure someone else has read EXT_texture_sRGB
and agrees with me ;-)
Makes sense to me at least.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On 4 January 2011 22:05, Henri Verbeet hverb...@gmail.com wrote:
Base level and min LOD aren't equivalent. In particular, min LOD has no
effect on image array selection for magnification and non-mipmapped
minification.
---
src/mesa/state_tracker/st_atom_sampler.c | 9 +++--
src/mesa
On 15 January 2011 11:56, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
On 14.01.2011 17:47, Henri Verbeet wrote:
On 14 January 2011 16:49, Brian Paul bri...@vmware.com wrote:
This isn't fresh in my head any more, but the code as-is matches the
behaviour of NVIDIA's driver (and fixed
On 14 January 2011 16:49, Brian Paul bri...@vmware.com wrote:
I applied your patch and now mipmap_limits no longer matches NVIDIA.
The attached mipmap.mbox series should fix the issues I found for
softpipe, r300g and r600g. I can't easily verify or fix the other
drivers, though in principle not
On 23 January 2011 18:20, Brian Paul bri...@vmware.com wrote:
The vega state tracker casts back and forth between pointers and the handle
types (VGHandle, VGPath, VGImage, etc). Since handles are always 32-bit
VGuints, casting like this doesn't work with 64-bit pointers.
This patch series
On 20 January 2012 03:24, Eric Anholt e...@anholt.net wrote:
So is it also allowed to blit from S8Z24 to Z24S8 ? Could we also allow
to blit from RGBA8 to BGRA8 then, please ?
That's already allowed.
Yeah, but not for multisampled framebuffers, unless RGBA8 and BGRA8
are considered identical
On 1 February 2012 23:12, Brian Paul bri...@vmware.com wrote:
+static void
+unpack_uint_z_Z32_FLOAT(const void *src, GLuint *dst, GLuint n)
+{
+ const float *s = ((const float *)src);
More parens than necessary there.
The entire cast is unnecessary, IMO. But of course that would apply to
2012/3/6 Benoit Jacob bja...@mozilla.com:
The goal is to help port real-world applications such as games. Besides
OpenGL [ES], the other API that is widely used in the real world is Direct3D
(9 and 10), so that's what would be the most interesting. I've heard about a
Direct3D implementation
On 18 March 2012 17:47, Matt Turner matts...@gmail.com wrote:
SC2's call chain for unpack_uint_z_X8_Z24 is
unpack_uint_z_X8_Z24
- _mesa_unpack_uint_z_row
- _mesa_readpixels
- intelReadPixels
- copy_tex_sub_image.isra.3
- intelCopyTexSubImage2D
- copyteximage
-
On 30 March 2012 03:29, Ian Romanick i...@freedesktop.org wrote:
I'm not super excited about GL_EXT_gpu_shader4. Do we know of any
applications that use that EXT and don't use either GLSL 1.30 or GLSL 1.40?
Wine will use it for the texture sampling functions with explicit
derivatives, but it
On 30 September 2012 21:51, Marek Olšák mar...@gmail.com wrote:
Wine or a windows app changes fpucw to 0x7f, causing doubles to be equivalent
to floats, which broke the calculation of FPS.
For reference, this is done by for example d3d9 when a D3D device is
created without D3DCREATE_FPU_PRESERVE
On 28 January 2011 21:09, Paulo Zanoni przan...@gmail.com wrote:
As a consequence of moving images/ to data/, the patch file is 3.9MB
long, so you can grab it here:
http://www.inf.ufpr.br/paulo/0002-Add-with-system-data-files-option.patch
If you pass -M to format-patch, it becomes a lot
---
src/glx/drisw_glx.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index 237ce17..5c7f40c 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -452,8 +452,10 @@ driCreateScreen(int screen, struct glx_display
On 31 January 2011 17:43, Julien Cristau jcris...@debian.org wrote:
On Sun, Jan 30, 2011 at 00:00:48 +0100, Henri Verbeet wrote:
@@ -918,12 +921,15 @@ dri2CreateScreen(int screen, struct glx_display * priv)
return psc-base;
handle_error:
+ if (psc-fd)
+ close(psc-fd);
0
The attached patch should do.
From ab34026885f98914efa6ad671f3446621124a55a Mon Sep 17 00:00:00 2001
From: Henri Verbeet hverb...@gmail.com
Date: Mon, 31 Jan 2011 18:09:19 +0100
Subject: [PATCH 1/1] glx: Properly check for a valid fd in dri2CreateScreen().
---
src/glx/dri2_glx.c |4 +++-
1
On 4 February 2011 23:21, Benoit Jacob bja...@mozilla.com wrote:
glXDestroyContext(...)
in your code. If that crashes, there's a bug in the implementation, so
report it and let's get it fixed!
This is for Web browsers. This would be considered a security flaw.
Considering the difficulty of
On 10 February 2011 09:47, José Fonseca Wouldn't it be
easier/cleaner if sRGB sampling/rendering support was not
done through formats, but through enable/disable bits in
pipe_sampler_view/pipe_rt_blend_state?
The issue with that is that sRGB only really makes sense for the 8-bit
RGBA formats.
On 14 February 2011 18:07, Fabian Bieler der.f...@gmx.net wrote:
This patch fixes the fbo/fbo-clear-formats piglit test.
As PIPE_FORMAT_B10G10R10A2_UNORM is the only format the mesa state tracker
uses, this is the only format I actualy tested.
Evergreen likely needs the same fix. Please keep
Instead of using the current gl_fragment_program. These aren't necessarily
the same, for example when translate_program() is called by
i915ValidateFragmentProgram().
---
src/mesa/drivers/dri/i915/i915_fragprog.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git
---
configs/autoconf.in |1 +
src/glx/Makefile|1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/configs/autoconf.in b/configs/autoconf.in
index a3c69e1..4e931a3 100644
--- a/configs/autoconf.in
+++ b/configs/autoconf.in
@@ -149,6 +149,7 @@ DRI_LIB_DEPS =
---
src/mesa/drivers/dri/i915/intel_tris.c | 22 +++---
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/intel_tris.c
b/src/mesa/drivers/dri/i915/intel_tris.c
index cf9291c..7bcb72f 100644
--- a/src/mesa/drivers/dri/i915/intel_tris.c
+++
2011/3/9 Christian König deathsim...@vodafone.de:
before I create another regression with my patches, could you guys
please test the attached patch and see if it causes another regression
on your hardware? Especially evergreen and any of the R600 chipsets?
I didn't test the patch, do you have
On 9 March 2011 07:00, Ferry Huberts maili...@hupie.com wrote:
I've been wondering about this for a while: is there a structure in
which information is stored that is tied to the card with which the code
is dealing, and if not, isn't it a good idea to introduce one?
This patch triggered this
2011/3/9 Christian König deathsim...@vodafone.de:
So hey guys what do you think about it?
And to make my own opinion clear:
I also really prefer tables, but didn't used them in the past because I
wasn't 100% sure which feature depends on what and which approach we
really want.
I don't think
to improve this?
Personally I just use vim with an appropriate vimrc. For r600g I have
au! BufRead,BufNewFile *src/gallium/*/r600/* setlocal noet sw=8
sts=8. Also, listchars is really useful.
By the way: What should be the correct line to add to the commit
message, Reviewed-by: Henri Verbeet hverb
Blits between sRGB and linear formats should happen in linear color space.
This fixes piglit fbo/fbo-srgb-blit.
---
src/gallium/auxiliary/util/u_blit.c| 57
src/gallium/auxiliary/util/u_blitter.c |3 +-
src/mesa/state_tracker/st_cb_texture.c |2 +-
3
2011/3/9 Christian König deathsim...@vodafone.de:
So please take a look at the attached patch, it shouldn't change the
generated bytecode a bit, but just makes the code more readable (at
least I think so) and easier to extend.
The general approach makes sense to me. Having flags may be nicer
2011/3/12 Mathias Fröhlich mathias.froehl...@gmx.net:
Attached is a patch to the r600g driver that avoids setting one specific gpu
register multiple times within a r600_pipe_state struct.
Is this supposed to fix anything in particular? The patch makes sense
to me as an optimization, but if it
2011/3/13 Mathias Fröhlich mathias.froehl...@gmx.net:
It does not fix anything. This change is supposed to produce the same command
stream than before.
I discovered that r600_context_pipe_state_set is one of the userspace
functions that are high in profiles for my use cases, I was looking for
On 14 March 2011 18:24, Rafael Monica monr...@gmail.com wrote:
The patch fixes 7 piglit tests and fixes GPU lockups with 3 tests, how
is that not an improvement? Perhaps FLT_TO_INT_FLOOR is more efficient
than FLOOR + FLT_TO_INT, but it seems to be pretty broken. Feel free
to fix it though.
On 14 March 2011 19:22, Rafael Monica monr...@gmail.com wrote:
I'm not interested in making a convincing case. I lack time, interest
and probably knowledge in tracking down and fixing any underlying bug.
Fair enough.
___
mesa-dev mailing list
On 18 March 2011 14:19, Petr Sebor p...@scssoft.com wrote:
I know that at least our games would benefit from this feature immediately,
but I guess Wine people might welcome this as well, where 'benefit' means -
do not have to
painfully install the external DXT library, which is very likely not
On 19 March 2011 12:24, Petr Sebor p...@scssoft.com wrote:
But just because we are all 'used to' simply check for the existence
of the GL_EXT_texture_compression_s3tc doesn't mean we really want to use it
at all.
Many of the current applications do not. Limited ARB_texture_compression is
On 20 March 2011 00:42, Petr Sebor p...@scssoft.com wrote:
And this is not an undocumented hack. ARB_texture_compression explicitly
defines mechanisms to work with 'unknown' formats providing a safe
passthrough.
Thats what glCompressedTexImage actually is for.
Sure, the CompressedTexImage*
On 23 March 2011 20:23, Henri Verbeet hverb...@gmail.com wrote:
meaningful. However, I could imagine that clearing an obviously
contiguous block of memory might be somewhat friendlier on the cache
than interleaving it with various other memory accesses. That's
Actually, ignore that, it's
On 24 March 2011 10:26, Fabian Bieler der.f...@gmx.net wrote:
if (inst-Texture.Texture == TGSI_TEXTURE_CUBE) {
- static const unsigned src0_swizzle[] = {2, 2, 0, 1};
- static const unsigned src1_swizzle[] = {1, 0, 2, 2};
+ unsigned src0_swizzle[4];
+
You don't want that, the state tracker should just set first_level
correctly. In particular, with something like r600g the hardware
already takes care of this and min_lod ends up being ignored when
mipmapping is disabled. Another consideration is that with sampler
objects you could have multiple
On 30 March 2011 23:43, Julian Adams joo...@gmail.com wrote:
---
src/gallium/drivers/r600/r600_state.c | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
Evergreen probably needs the same fix.
+ for (int i = 0, j = 0; i 8; i++) {
+ /*
1 - 100 of 162 matches
Mail list logo
