*ctx)
{
- GLbitfield legalTypesMask = ~0u; /* all */
+ GLbitfield legalTypesMask = ALL_TYPE_BITS;
if (_mesa_is_gles(ctx)) {
legalTypesMask = ~(FIXED_GL_BIT |
1/8, 2/8 are
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa
Am 08.08.2014 23:20, schrieb Brian Paul:
Silences MinGW warnings:
warning: unknown conversion type character ‘l’ in format [-Wformat]
warning: too many arguments for format [-Wformat-extra-args]
---
src/mesa/main/bufferobj.c | 33 +
src/mesa/main/varray.c
, GLuint id)
{
if (prog) {
init_program_struct(prog-Base, target, id);
5/8 and 6/8 are
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
Am 09.08.2014 02:24, schrieb Matt Turner:
Other than that, is there some recommendation wrt whitespace around that
ugly format specifier? Some places seem to use it, some don't. Either
way it's ugly dunno which one is worse. Would be nice though if we'd be
consistent imho.
I've always seen
did the copy because _mesa_drawbuffers will write the
same ctx-Color.DrawBuffer bits that are passed in as buffers. Looks
safe to me though so
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http
Am 08.08.2014 23:20, schrieb Brian Paul:
Fixes failed assertion when _mesa_update_draw_buffers() was called
with GL_DRAW_BUFFER == GL_FRONT_AND_BACK. The piglit gl30basic hit
this.
Cc: 10.2 mesa-sta...@lists.freedesktop.org
---
src/mesa/main/buffers.c |5 +++--
1 file changed, 3
On closer look, it looks to me like it wouldn't be all that difficult to
make proper sampler array dcls (as you apparently get them quite easily
from glsl) which is really my only problem with it but it's not really
all that important so
Reviewed-by: Roland Scheidegger srol...@vmware.com
Am
Am 09.08.2014 16:33, schrieb Ilia Mirkin:
On Sat, Aug 9, 2014 at 10:14 AM, Roland Scheidegger srol...@vmware.com
wrote:
On closer look, it looks to me like it wouldn't be all that difficult to
make proper sampler array dcls (as you apparently get them quite easily
If you can briefly
Am 09.08.2014 05:24, schrieb Connor Abbott:
On Wed, Aug 6, 2014 at 6:29 PM, Marek Olšák mar...@gmail.com wrote:
What IR? A flatland GLSL IR? A replacement for Mesa IR? Something else?
It's a flatland IR, similar to TGSI/Direct3D style with enough GLSL
IR-like stuff to get existing things
Am 09.08.2014 17:25, schrieb Ilia Mirkin:
On Sat, Aug 9, 2014 at 11:12 AM, Roland Scheidegger srol...@vmware.com
wrote:
Am 09.08.2014 16:33, schrieb Ilia Mirkin:
On Sat, Aug 9, 2014 at 10:14 AM, Roland Scheidegger srol...@vmware.com
wrote:
On closer look, it looks to me like it wouldn't
Am 11.08.2014 15:29, schrieb Brian Paul:
On 08/08/2014 06:15 PM, Roland Scheidegger wrote:
Am 08.08.2014 23:20, schrieb Brian Paul:
Silences MinGW warnings:
warning: unknown conversion type character ‘l’ in format [-Wformat]
warning: too many arguments for format [-Wformat-extra-args
Both patches
Reviewed-by: Roland Scheidegger srol...@vmware.com
Am 11.08.2014 17:24, schrieb Brian Paul:
Silences MinGW warnings:
warning: unknown conversion type character ‘l’ in format [-Wformat]
warning: too many arguments for format [-Wformat-extra-args]
v2: use signed types/formats
,
+ PIPE_FORMAT_BPTC_RGBA_UNORM = 255,
+ PIPE_FORMAT_BPTC_SRGBA_UNORM= 256,
+ PIPE_FORMAT_BPTC_RGB_FLOAT = 257,
+ PIPE_FORMAT_BPTC_RGB_UFLOAT = 258,
+
PIPE_FORMAT_COUNT
};
For the series:
Reviewed-by: Roland Scheidegger srol...@vmware.com
Am 11.08.2014 17:18, schrieb Ilia Mirkin:
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
This applies on top of my previous patch to allow dynamic sampler offsets.
Roland, I believe this should address your concerns. The generated code looks
like:
FRAG
PROPERTY
Am 11.08.2014 18:56, schrieb Ilia Mirkin:
On Mon, Aug 11, 2014 at 12:43 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 11.08.2014 17:18, schrieb Ilia Mirkin:
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
This applies on top of my previous patch to allow dynamic sampler offsets
Am 11.08.2014 00:51, schrieb Brian Paul:
On 08/08/2014 07:43 PM, Roland Scheidegger wrote:
Am 08.08.2014 23:20, schrieb Brian Paul:
Fixes failed assertion when _mesa_update_draw_buffers() was called
with GL_DRAW_BUFFER == GL_FRONT_AND_BACK. The piglit gl30basic hit
this.
Cc: 10.2 mesa-sta
Am 11.08.2014 21:07, schrieb Ilia Mirkin:
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Not 100% sure about the KHR_robust_buffer_access_behavior -- is that part of
GL4.5?
Well this is mostly the same as ARB_robust_buffer_access_behavior which
is core in 4.3. Except
Am 11.08.2014 22:56, schrieb Ilia Mirkin:
On Mon, Aug 11, 2014 at 4:34 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 11.08.2014 21:07, schrieb Ilia Mirkin:
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Not 100% sure about the KHR_robust_buffer_access_behavior -- is that part
This looks good to me. However I'm wondering if it would be better to
use a generic float/int union. I guess though these values actually
really are gl_constant_value type (as they come as gl params) so this
looks good.
Roland
Am 12.08.2014 20:04, schrieb Neil Roberts:
Hi,
Here is a
Am 06.08.2014 11:28, schrieb Michel Dänzer:
On 06.08.2014 03:08, Jason Ekstrand wrote:
Module: Mesa
Branch: master
Commit: 850fb0d1dca616179d3239a7b7bd94fe1979604c
URL:
.
Roland
Am 13.08.2014 19:35, schrieb Jason Ekstrand:
Roland,
I just sent the exact same patch.
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
mailto:jason.ekstr...@intel.com
On Wed, Aug 13, 2014 at 10:33 AM, srol...@vmware.com
mailto:srol...@vmware.com wrote:
From: Roland
:46, schrieb Roland Scheidegger:
Ha one minute faster :-).
FWIW interestingly this one also fixes the other conform failures I was
seeing (with GL_BYTE/GL_RGB data) when unconditionally disabling
texstore_swizzle so I guess the results of the swizzle path aren't quite
identical to the fallback
Reviewed-by: Roland Scheidegger srol...@vmware.com
Not sure though why you moved the function, it's declared elsewhere anyway.
(And I bet there's cases where transfer ops wouldn't actually be
required which aren't caught by this check, like for instance RGB
formats with only alpha pixel scale
Reviewed-by: Roland Scheidegger srol...@vmware.com
llvmpipe also already does the fine version. A coarse version (which we
indeed do when used implicitly for sampling though with some other
changes) might be minimally simpler though not even sure (might save a
shuffle instruction somewhere
texture sampling for multiple quads at once this is something which
needs to be handled in any case. I suspect hw being slower with
different effective lods per pixel has similar reasons - there's just
more work to be done.
Roland
On Thu, Aug 14, 2014 at 10:12 AM, Roland Scheidegger srol
Am 15.08.2014 00:33, schrieb Ilia Mirkin:
Hm, I wonder what GETPARAM_PCI_DEVICE returns for GK20A. Also, not
100% sure what UMA means, but GK20A (NVEA) would defnitely qualify.
Not sure about the other IGP's that steal vram from the system. All
IGPs end in 0xa-0xf though, so they're easy to
NAK.
This is unnecessary, the condition parameter can already handle that
(and was added for that purpose, though for d3d10 only at that time -
793e8e3d7ed816cc9a066245dde798afdcf8b581). Can't speak for other
drivers, but llvmpipe/softpipe already handle it in any case.
Otherwise, I'd still have
Am 16.08.2014 01:59, schrieb Tobias Klausmann:
with this we determine if the driver wants to enable
GL_ARB_conditional_render_inverted
Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de
---
src/gallium/docs/source/screen.rst | 2 ++
Am 16.08.2014 02:12, schrieb Connor Abbott:
I know what you might be thinking right now. Wait, *another* IR? Don't
we already have like 5 of those, not counting all the driver-specific
ones? Isn't this stuff complicated enough already? Well, there are some
pretty good reasons to start afresh
Am 18.08.2014 19:05, schrieb Connor Abbott:
On Mon, Aug 18, 2014 at 12:38 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Mon, Aug 18, 2014 at 12:25 PM, Connor Abbott cwabbo...@gmail.com wrote:
On Mon, Aug 18, 2014 at 11:47 AM, Jose Fonseca jfons...@vmware.com wrote:
On 18/08/14 14:21, Marek
reference counts) compared to
surface_create / surface_destroy which sounds fishy but in any case
1/6, 4/6, 5/6 are
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org
Am 18.08.2014 23:24, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/drivers/rbug/rbug_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/rbug/rbug_context.c
b/src/gallium/drivers/rbug/rbug_context.c
index
, rb_resource);
pipe_resource_reference(rb_resource-resource, NULL);
FREE(rb_resource);
I wonder if there would be some value in trying to make them
displayable? I guess though it would be pretty difficult without any
means to figure out what kind of data it is.
Reviewed-by: Roland
, ctx-velem_state);
/* set a framebuffer state */
1/6,2/6 are
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Series looks good to me too, just one minor nitpick below, otherwise
1-4, and 6 are
Reviewed-by: Roland Scheidegger srol...@vmware.com
Am 19.08.2014 00:06, schrieb Tobias Klausmann:
Also add an extension bit so we can safely enable
Signed-off-by: Tobias Klausmann tobias.johannes.klausm
Am 19.08.2014 01:35, schrieb Marek Olšák:
On Tue, Aug 19, 2014 at 1:10 AM, Roland Scheidegger srol...@vmware.com
wrote:
Am 18.08.2014 23:24, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/drivers/rbug/rbug_context.c | 2 +-
1 file changed, 1 insertion(+), 1
Am 19.08.2014 01:43, schrieb Marek Olšák:
On Tue, Aug 19, 2014 at 1:12 AM, Roland Scheidegger srol...@vmware.com
wrote:
Am 18.08.2014 23:24, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/drivers/rbug/rbug_context.c | 46
+
1
-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Am 19.08.2014 23:29, schrieb Enrico Horn:
Hi everyone,
tried to build mesa just now with llvm from git and get the following error:
gallivm/lp_bld_misc.cpp: In function 'LLVMBool
lp_build_create_jit_compiler_for_module(LLVMOpaqueExecutionEngine**,
lp_generated_code**, LLVMModuleRef,
Didn't look at it that closely, but I'm pretty surprised this really
works. One things ARB_texture_view can do is cast cube maps (and cube
map arrays) to 2d arrays and vice versa (also 1d/2d to the respective
array type), and we cannot express that in sampler views (yet) (we can't
express it in
?
On Wed, Aug 20, 2014 at 11:25 AM, Roland Scheidegger
srol...@vmware.com wrote:
Didn't look at it that closely, but I'm pretty surprised this really
works. One things ARB_texture_view can do is cast cube maps (and cube
map arrays) to 2d arrays and vice versa (also 1d/2d to the respective
array
suggestions on how to fix it? Should the target be added to
pipe_sampler_view?
On Wed, Aug 20, 2014 at 11:25 AM, Roland Scheidegger srol...@vmware.com
wrote:
Didn't look at it that closely, but I'm pretty surprised this really
works. One things ARB_texture_view can do is cast cube maps (and cube
map
Am 20.08.2014 18:12, schrieb Jose Fonseca:
On 20/08/14 17:02, Roland Scheidegger wrote:
Am 20.08.2014 17:47, schrieb Jose Fonseca:
On 20/08/14 16:31, Ilia Mirkin wrote:
Hm, it's not tested. And you're right, that would (most likely) mess
up, since it would only have the pipe_resource's target
Am 20.08.2014 18:33, schrieb Ilia Mirkin:
On Wed, Aug 20, 2014 at 12:22 PM, Jose Fonseca jfons...@vmware.com wrote:
On 20/08/14 17:14, Roland Scheidegger wrote:
Am 20.08.2014 17:55, schrieb Ilia Mirkin:
On Wed, Aug 20, 2014 at 11:47 AM, Jose Fonseca jfons...@vmware.com
wrote:
On 20/08/14
Am 20.08.2014 20:13, schrieb Kenneth Graunke:
On Wednesday, August 20, 2014 06:41:08 PM Michel Dänzer wrote:
On 20.08.2014 00:04, Connor Abbott wrote:
On Mon, Aug 18, 2014 at 8:52 PM, Michel Dänzer
mic...@daenzer.net wrote:
On 19.08.2014 01:28, Connor Abbott wrote:
On Mon, Aug 18, 2014 at
Am 20.08.2014 20:45, schrieb Matt Turner:
On Wed, Aug 20, 2014 at 11:28 AM, Roland Scheidegger srol...@vmware.com
wrote:
Am 20.08.2014 20:13, schrieb Kenneth Graunke:
For example, Debian was stuck on Mesa 9.2.2 for 4 months (2013-12-08
to 2014-03-22), and I was told this was because of LLVM
Am 20.08.2014 18:48, schrieb Roland Scheidegger:
Am 20.08.2014 18:33, schrieb Ilia Mirkin:
On Wed, Aug 20, 2014 at 12:22 PM, Jose Fonseca jfons...@vmware.com wrote:
On 20/08/14 17:14, Roland Scheidegger wrote:
Am 20.08.2014 17:55, schrieb Ilia Mirkin:
On Wed, Aug 20, 2014 at 11:47 AM, Jose
Am 20.08.2014 22:27, schrieb Ilia Mirkin:
On Wed, Aug 20, 2014 at 4:12 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 20.08.2014 18:48, schrieb Roland Scheidegger:
Am 20.08.2014 18:33, schrieb Ilia Mirkin:
On Wed, Aug 20, 2014 at 12:22 PM, Jose Fonseca jfons...@vmware.com wrote:
On 20
Am 21.08.2014 18:44, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
This is already supported by r600g and radeonsi.
Alex suggested this could be useful for video acceleration state trackers.
---
src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
*/
struct pipe_resource *texture; /** texture into which this is a view */
struct pipe_context *context; /** context this view belongs to */
It would be good though to get some other feedback, personally I think
this solution is ok.
1/4, 2/4 are
Reviewed-by: Roland Scheidegger srol
Am 21.08.2014 04:42, schrieb Ilia Mirkin:
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
v1 - v2:
- make use of new PIPE_CAP to determine whether ARB_texture_view is available
- set the gl_texture_object's Target in the sampler view object
src/mesa/state_tracker/st_atom_texture.c
Am 21.08.2014 19:39, schrieb Ilia Mirkin:
On Thu, Aug 21, 2014 at 1:35 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 21.08.2014 04:42, schrieb Ilia Mirkin:
This allows a sampler view to have a different texture target than the
underlying resource. This will be used to implement
Am 25.08.2014 07:56, schrieb Kenneth Graunke:
On Monday, August 25, 2014 12:05:07 AM Romain Failliot wrote:
Some folks helped me and a lot of detection bug have been fixed!
I have a question though (for my own culture): what's with the swrast, the
softpipe and the llvmpipe? Aren't they all
Am 24.08.2014 23:51, schrieb Marek Olšák:
On Sun, Aug 24, 2014 at 6:15 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Sun, Aug 24, 2014 at 7:44 AM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
This fixes crashes if the number of temporaries is greater than 4096.
might have bug reports saying that softpipe
is green but it's never mentioned in the original file)
2014-08-25 10:28 GMT-04:00 Roland Scheidegger srol...@vmware.com
mailto:srol...@vmware.com:
Am 25.08.2014 07 tel:25.08.2014%2007:56, schrieb Kenneth Graunke:
On Monday, August 25
Am 26.08.2014 01:58, schrieb Ian Romanick:
On 08/24/2014 02:51 PM, Marek Olšák wrote:
On Sun, Aug 24, 2014 at 6:15 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Sun, Aug 24, 2014 at 7:44 AM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
This fixes crashes if the
Reviewed-by: Roland Scheidegger srol...@vmware.com
Though I think most drivers can probably support a lot more (everything
draw based should be able to support virtually unlimited strides I
believe, up to max_int32 probably though this doesn't make much sense,
and I suspect that's true for all
cares
about that anyway). Don't know though how that could be fixed.
Roland
Am 28.08.2014 04:28, schrieb Ian Romanick:
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 08/27/2014 06:00 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
mesa was creating a cube map
Ahh wrong patch sent again. This one is unchanged.
Roland
Am 28.08.2014 18:17, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
Pretty trivial, just fill in the offsets and such. The implementation
is near 100% copy and paste from llvmpipe. Should be useful
Am 28.08.2014 18:19, schrieb Jose Fonseca:
On 28/08/14 04:15, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Pretty easy, just make sure that all paths testing for PIPE_TEXTURE_CUBE
also recognize PIPE_TEXTURE_CUBE_ARRAY, and add the layer * 6 calculation
Am 30.08.2014 01:44, schrieb Emil Velikov:
Hello list,
Another boring yet important series, if we are to have properly working
solution to package a mesa release tarball via 'make dist'.
This series covers a few state-tracker files missed out previously,
picks up all the gallium tests,
Am 29.08.2014 22:44, schrieb Ilia Mirkin:
Hello,
I've been thinking a bit about how to properly implement TCS outputs
in TGSI. As a quick reminder, there are per-vertex (i.e. invocation)
and per-patch outputs in TCS. And while you can only write to the
current invocation's per-vertex
Am 01.09.2014 17:55, schrieb Emil Velikov:
On 01/09/14 16:31, Roland Scheidegger wrote:
Am 30.08.2014 01:44, schrieb Emil Velikov:
Hello list,
Another boring yet important series, if we are to have properly working
solution to package a mesa release tarball via 'make dist'.
This series
Am 01.09.2014 18:19, schrieb Ilia Mirkin:
On Mon, Sep 1, 2014 at 12:00 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 29.08.2014 22:44, schrieb Ilia Mirkin:
Hello,
I've been thinking a bit about how to properly implement TCS outputs
in TGSI. As a quick reminder, there are per-vertex
Am 01.09.2014 18:53, schrieb Ilia Mirkin:
On Mon, Sep 1, 2014 at 12:47 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 01.09.2014 18:19, schrieb Ilia Mirkin:
On Mon, Sep 1, 2014 at 12:00 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 29.08.2014 22:44, schrieb Ilia Mirkin:
Hello
Oh, interesting. The patch though is
Reviewed-by: Roland Scheidegger srol...@vmware.com
Am 03.09.2014 04:36, schrieb Michel Dänzer:
From: Michel Dänzer michel.daen...@amd.com
Only MCJIT is available anymore.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/auxiliary
Am 06.09.2014 19:17, schrieb Mathias Froehlich:
Hi,
Please review:
Add support for the unclamped versions of glDepthRange
and relatives. Also starting with OpenGL 4.2 the traditional
functions for this should no longer clamp the values to [0, 1].
This looks wrong to me (the
Looks good to me if there's no piglit regressions.
Reviewed-by: Roland Scheidegger srol...@vmware.com
Am 09.09.2014 02:59, schrieb Ilia Mirkin:
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Roland, it was unclear to me whether you were happy with this change or not.
v2 - v3
Reviewed-by: Roland Scheidegger srol...@vmware.com
Am 10.09.2014 16:21, schrieb Brian Paul:
MSVC replaces the F in 255.0F with the macro argument which leads
to an error. s/F/FLT/ to avoid that.
It turns out we weren't using this macro at all on MSVC until the
recent mesa: Drop USE_IEEE
Am 15.09.2014 12:22, schrieb Dave Airlie:
We had a bug report from some screensavers in xscreensaver package
not working on ppc64be, I took a day out to cause myself undue pain.
I tracked it down to the depth buffer not being read correctly,
I've no idea if this is the proper fix for it, I
,
+ triangle_32_3_16,
+ triangle_32_4_16,
};
static const char *cmd_name(unsigned cmd)
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
,
};
#define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 0)
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net:
From: Mathias Fröhlich mathias.froehl...@gmx.net
Will be used in the implementation of NV_depth_buffer_float.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/mesa/main/glformats.c | 18 ++
Am 15.09.2014 16:41, schrieb Roland Scheidegger:
Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net:
From: Mathias Fröhlich mathias.froehl...@gmx.net
Will be used in the implementation of NV_depth_buffer_float.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/mesa
Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net:
From: Mathias Fröhlich mathias.froehl...@gmx.net
This is mostly support for the unclamped versions of
glDepthRangedNV, glClearDepthdNV and glDepthBoundsdNV.
Note that OpenGL 4.2 introduced that the traditonal
glDepthRange functions may
Am 15.09.2014 16:57, schrieb Roland Scheidegger:
Am 15.09.2014 16:41, schrieb Roland Scheidegger:
Am 14.09.2014 16:07, schrieb mathias.froehl...@gmx.net:
From: Mathias Fröhlich mathias.froehl...@gmx.net
Will be used in the implementation of NV_depth_buffer_float.
Signed-off-by: Mathias
Am 15.09.2014 18:28, schrieb Mathias Fröhlich:
Hi Roland,
On Monday, September 15, 2014 16:57:49 Roland Scheidegger wrote:
Hmm actually that wasn't right, it does make a difference if the nv or
core format enums are used, at least for texture specification (nv won't
clamp, whereas core
Am 15.09.2014 19:04, schrieb Mathias Fröhlich:
Hi again,
On Monday, September 15, 2014 18:11:51 Roland Scheidegger wrote:
btw I'm not entirely sure everything is really correct with llvmpipe wrt
that extension (the rasterization stuff, gallium isn't involved in the
texture conversion
Am 15.09.2014 21:00, schrieb Ilia Mirkin:
On Mon, Sep 15, 2014 at 2:51 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
sample opcodes don't have valid texture target information (and I don't think
this should be changed), however it would be nice if we had
Am 15.09.2014 22:48, schrieb Dave Airlie:
I never really looked at the big endian stuff so I have no idea if this
is right. I thought though the channel shift thing now should work
without endianness awareness if you fetch one 32bit number and then
break it up into parts with shifts due to
Am 15.09.2014 08:31, schrieb Kenneth Graunke:
Fredrik's implementation of ARB_vertex_attrib_binding introduced new
gl_vertex_attrib_array and gl_vertex_buffer_binding structures, and
converted Mesa's older gl_client_array to be derived state. Ultimately,
we'd like to drop gl_client_array and
Am 15.09.2014 21:28, schrieb Roland Scheidegger:
Am 15.09.2014 21:00, schrieb Ilia Mirkin:
On Mon, Sep 15, 2014 at 2:51 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
sample opcodes don't have valid texture target information (and I don't
think
this should
Am 16.09.2014 17:48, schrieb Brian Paul:
On 09/15/2014 06:00 PM, Roland Scheidegger wrote:
Am 15.09.2014 08:31, schrieb Kenneth Graunke:
Fredrik's implementation of ARB_vertex_attrib_binding introduced new
gl_vertex_attrib_array and gl_vertex_buffer_binding structures, and
converted Mesa's
Am 16.09.2014 18:41, schrieb Ilia Mirkin:
On Tue, Sep 16, 2014 at 12:29 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Sep 16, 2014 at 5:42 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
OK, so just to summarize:
The approach suggested by Roland is to have the outputs be
one-dimensional and
Am 16.09.2014 19:40, schrieb Marek Olšák:
On Tue, Sep 16, 2014 at 7:31 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 16.09.2014 18:41, schrieb Ilia Mirkin:
On Tue, Sep 16, 2014 at 12:29 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Sep 16, 2014 at 5:42 PM, Ilia Mirkin imir
Am 16.09.2014 08:28, schrieb Dave Airlie:
From: Richard Sandiford rsand...@linux.vnet.ibm.com
...i.e. formats in which the first listed component is in the least
significant byte of the integer. The corresponding UNORM aliases already
exist.
Signed-off-by: Richard Sandiford
Am 17.09.2014 02:13, schrieb Emil Velikov:
On 12/09/14 10:10, Emil Velikov wrote:
On 11/09/14 23:21, Ian Romanick wrote:
On 09/10/2014 05:45 AM, Emil Velikov wrote:
Hello all,
The original plan from Ian was to have four release candidates prior to the
final release. From what I can see
ARB_fragment_layer_viewport is enabled unconditionally if geometry
shaders / multiple viewports are also enabled. This seems reasonable,
though I noticed at least it won't work for llvmpipe - entirely due to
the requirement of the viewport/layer value being zero if it wasn't
output by the gs (or
Am 18.09.2014 00:28, schrieb Roland Scheidegger:
ARB_fragment_layer_viewport is enabled unconditionally if geometry
shaders / multiple viewports are also enabled. This seems reasonable,
though I noticed at least it won't work for llvmpipe - entirely due to
the requirement of the viewport/layer
Am 18.09.2014 00:37, schrieb Ilia Mirkin:
On Wed, Sep 17, 2014 at 6:28 PM, Roland Scheidegger srol...@vmware.com
wrote:
ARB_fragment_layer_viewport is enabled unconditionally if geometry
shaders / multiple viewports are also enabled. This seems reasonable,
I avoided adding a cap when
Am 17.09.2014 09:21, schrieb Mathias Fröhlich:
Good Morning,
On Monday, September 15, 2014 20:33:17 Roland Scheidegger wrote:
I don't really know what to do though. It looks like the implementation
doesn't really do what the nv spec claims anyway, so it's difficult to
even figure out what
Am 21.09.2014 16:40, schrieb Mathias Fröhlich:
Hi,
On Thursday, September 18, 2014 03:56:11 Roland Scheidegger wrote:
I agree it is something which would be nice to have in mesa, however I'm
not really a big proponent of implementing some half-baked bogus mess
extension, which is further
The series looks good to me, though could rename the (quite underused)
pipe_type enum to tgsi_return_type instead and leave tgsi_type alone?
Or for further clarity, rename both (to tgsi_opcode_type and
tgsi_ret_type or something). Either way though looks ok to me.
(That said, I don't understand
Reviewed-by: Roland Scheidegger srol...@vmware.com
Roland
Am 22.09.2014 21:36, schrieb Brian Paul:
The only place the enum pipe_type was used is for the TGSI sampler
view return type. So make it a TGSI type. Note: it appears this
part of TGSI isn't used by anyone so it may be removed
To: Jose Fonseca; mesa-dev@lists.freedesktop.org
Cc: Roland Scheidegger; 10.2 10.3
Subject: [PATCH] gallivm: fix idiv
From: Roland Scheidegger srol...@vmware.com
ffeb77c7b0552a8624e46e65d6347240ac5ae84d had a typo which turned all signed
integer divisions into unsigned ones. Oops.
This gets us
This change seems to cause compile failure with scons:
Compiling src/util/register_allocate.c ...
src/util/register_allocate.c:76:26: fatal error: main/imports.h: No such
file or directory
#include main/imports.h
Looks like it could be fixed by patching up the CPPPATH in the
SConscript file
.
-Brian
On 09/23/2014 04:26 PM, Roland Scheidegger wrote:
This change seems to cause compile failure with scons:
Compiling src/util/register_allocate.c ...
src/util/register_allocate.c:76:26: fatal error: main/imports.h: No such
file or directory
#include main/imports.h
Looks like
Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these
to util code. That plus the things I already mentioned should be all
needed I think. But I strongly believe either this needs to be done or
we should revert it.
Roland
Am 24.09.2014 00:44, schrieb Roland Scheidegger
Yes cubemaps should have array_size == 6 always in gallium. You just
have to be careful whenever translating things from mesa to gallium as
things like that won't be true in core mesa of course (similar to 1d
array textures having height and so on) due to OpenGL weirdness for
historical reasons.
this out tonight, pending a full piglit run.
On Wed, Sep 24, 2014 at 1:35 PM, Roland Scheidegger srol...@vmware.com
wrote:
Yes cubemaps should have array_size == 6 always in gallium. You just
have to be careful whenever translating things from mesa to gallium as
things like that won't be true
701 - 800 of 2156 matches
Mail list logo
