Ok, here is the bug:
https://llvm.org/bugs/show_bug.cgi?id=31296
Roland
Am 06.12.2016 um 18:47 schrieb Roland Scheidegger:
> Actually I've verified this quickly with llc.
> With -mattr=xop, it produces
>
> fetch_r32_float_float: # @fetch_r32_float_float
>
The bug in llvm has been fixed, can you confirm lp_test_format passes again?
Roland
Am 06.12.2016 um 19:00 schrieb Roland Scheidegger:
> Ok, here is the bug:
> https://llvm.org/bugs/show_bug.cgi?id=31296
>
> Roland
>
> Am 06.12.2016 um 18:47 schrieb Roland Scheidegger
Am 07.12.2016 um 17:26 schrieb Marek Olšák:
> Optimizing the CSO cache isn't exactly on the top of my list, so I
> can't really do that right now.
>
> I think that varying the LOD bias is starting to be common. It's used
> for smooth LOD transitions when loading textures during rendering.
> Games
Am 07.12.2016 um 21:46 schrieb Marek Olšák:
> On Wed, Dec 7, 2016 at 6:00 PM, Roland Scheidegger wrote:
>> Am 07.12.2016 um 17:26 schrieb Marek Olšák:
>>> Optimizing the CSO cache isn't exactly on the top of my list, so I
>>> can't really do that right now.
I haven't seen the driver author's opinion on this yet, so it's probably
fair to give him some more time to answer. It's not like this is really
urgent...
Roland
Am 08.12.2016 um 01:11 schrieb Edward O'Callaghan:
> Hi all,
>
> So I'll get right to the crux of this; In summary the consensus would
I'm wondering, isn't that actually a problem of the test, that is it
can't actually expect reasonable results with such input values?
Since within the shader languages those functions which are composed of
multiple other functions are usually allowed to basically accumulate all
the errors of said f
than zero) are ~2^-25 (whereas an
exact calculation could go down to 2^-127). So maybe the simplified
formula might actually be even a bit better there? glsl seems to be
quite lenient with required exp precision.
In any case,
Reviewed-by: Roland Scheidegger
Am 09.12.2016 um 18:41 schrieb Jason
adding CC: Charmaine
Am 12.12.2016 um 06:23 schrieb Edward O'Callaghan:
> Brian/Roland ping?
>
> On 12/07/2016 10:30 AM, Edward O'Callaghan wrote:
>> As per the C spec, it is illegal to alias pointers to different
>> types. This results in undefined behaviour after optimization
>> passes, resulti
Am 20.12.2016 um 00:12 schrieb Giuseppe Bilotta:
> Hello,
>
> I realize that I'm a little late to comment about this, but I think
> the formula used for
> tanh should be changed again. Specifically, as suggested by Roland
>
> On Fri, Dec 9, 2016 at 5:41 AM, Roland Sche
Am 20.12.2016 um 15:13 schrieb Jose Fonseca:
> On 12/12/16 00:11, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> We should do transpose, not extract/insert, at least with "sufficient"
>> amount
>> of channels (for 4 channels, extract/
to be available?
>>
>> No, expm1 doesn't exist in GLSL.
>
> This is extremely bothersome. Both the (exp(2x)-1)/(exp(2x)+1) and the
> 1-2/(exp(2x)+1) formulas give pretty good results when written
> in terms of expm1.
>
> On Tue, Dec 20, 2016 at 3:48 AM, Roland Sc
ion and added a lengthy comment explaining the
> reason for the alignment.
>
> Reported-by: Tim Rowley
> Tested-by: Tim Rowley
> Signed-off-by: Chuck Atkins
> Acked-by: Roland Scheidegger
> ---
> src/gallium/include/pipe/p_state.h | 12 +++-
> 1 file changed,
@@ util_can_blit_via_copy_region(const struct pipe_blit_info
> *blit)
>return FALSE;
> }
>
> - if (blit->alpha_blend)
> - return FALSE;
> -
> return TRUE;
> }
>
>
Now that you've simplified this, it looks to me like it should also
FORMAT_INVALID, 0 },
> { PIPE_FORMAT_I8_UINT, SVGA3D_FORMAT_INVALID,
> SVGA3D_FORMAT_INVALID, 0 },
>
I don't doubt that it didn't work, but I don't quite understand the
reasoning - R32G32B32_FLOAT seems to be supported?
Am 01.07.2016 um 00:59 schrieb Matt Turner:
> According to the referenced bug report, gcc-4.5 and newer do not inline
> memcmp(). I see no difference in performance of ipers with llvmpipe on a
> Sandybridge (which does not have "Enhanced REP MOVSB/STOSB") by removing
> this flag.
>
> I attempted t
;mask & mask) != mask ||
> blit->filter != PIPE_TEX_FILTER_NEAREST ||
> blit->scissor_enable ||
> + blit->num_window_rectangles > 0 ||
> blit->alpha_blend) {
>return FALSE;
> }
>
Reviewed-by: Roland Scheidegger
_
Am 05.07.2016 um 11:36 schrieb Marek Olšák:
> From: Marek Olšák
>
> RadeonSI stats: Mostly 0% difference, but Valley shows a small improvement:
>
> ApplicationFilesSGPRs VGPRs SpillSGPR SpillVGPR Code
> SizeLDSMax Waves Waits
> unigine_valley 2780
Am 06.07.2016 um 23:51 schrieb Tim Rowley:
> ---
> .../drivers/swr/rasterizer/jitter/builder_misc.cpp | 38
> --
> .../jitter/scripts/gen_llvm_ir_macros.py | 5 ---
> 2 files changed, 28 insertions(+), 15 deletions(-)
>
> diff --git a/src/gallium/drivers/swr/raster
Am 12.07.2016 um 13:40 schrieb Nicolai Hähnle:
> From: Nicolai Hähnle
>
> This fixes a regression introduced by commit d8d6091a8.
>
> Heap allocations may be only 8-byte aligned on 32-bit system, and so having
> members with 16-byte alignment (such as in the case where pipe_blend_color is
> embe
Am 12.07.2016 um 22:52 schrieb Marek Olšák:
> From: Marek Olšák
>
> Not sure if this is the right way to do it, but it seems to work.
> ---
> src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 9 +
> src/gallium/auxiliary/gallivm/lp_bld_misc.h | 3 +++
> 2 files changed, 12 insertions(+)
manager();
> extern void
> lp_free_memory_manager(LLVMMCJITMemoryManagerRef memorymgr);
>
> +extern void
> +lp_add_attr_dereferenceable(LLVMValueRef val, uint64_t bytes);
> +
> #ifdef __cplusplus
> }
> #endif
>
Reviewed-by: Roland Scheidegger
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Am 14.07.2016 um 15:25 schrieb Rob Conde:
> Hello,
>
>It occurred to me that the llvmpipe might be a good basis for a GLSL
> debugger. Has anyone thought about this and how it might be approached?
>
>
> Rob Conde
I'm not entirely sure what exactly you want to debug, but if you just
want to
ate functions that looks good (plus, buffers and textures
are quite different indeed). (We'll have some code to adapt of course,
but this should be trivial.)
So, Acked-by:
Roland Scheidegger
>
> Marek
>
> On Mon, Jul 18, 2016 at 2:25 PM, Marek Olšák wrote:
>> From: M
Am 29.07.2016 um 00:35 schrieb Matt Turner:
> ---
> src/gallium/auxiliary/Makefile.sources | 1 +
> src/gallium/auxiliary/util/u_bitcast.h | 57
> ++
> 2 files changed, 58 insertions(+)
> create mode 100644 src/gallium/auxiliary/util/u_bitcast.h
>
> diff --git a
Am 29.07.2016 um 06:55 schrieb Connor Abbott:
> On Thu, Jul 28, 2016 at 7:58 PM, Roland Scheidegger
> wrote:
>> Am 29.07.2016 um 00:35 schrieb Matt Turner:
>>> ---
>>> src/gallium/auxiliary/Makefile.sources | 1 +
>>> src/
ng.html&d=CwIFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=yFSuLWBBbLWZDrPaxDVOCjO0cX88sn16LdG-wdamPNQ&s=vIzvE6OQ57S1mnD6755iC9AOD57xXqJKUGtsk_DKBhs&e=
>
>
> Look especially at footnote 85 of 6.5.2.3.
>
> Regards,
> Gustaw Smolarczyk
>
This looks very bogus to me.
How is this supposed to work if you immediately close the library again?
The functions are still going to get used.
This just segfaults right, left and center.
If you want to fix this for real, some util_format_s3tc_exit() is
probably needed, albeit I'm not entirely su
what we were doing with the union was float <-> uint32_t bitcasts
> and the remaining 10% can be done with a sinmple left-shift by 23.
simple
For the series:
Reviewed-by: Roland Scheidegger
>
> Signed-off-by: Jason Ekstrand
> ---
&g
.h"
> #include "util/u_tile.h"
>
>
> diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
> b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
> index f838e74..f91f90b 100644
> --- a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.
Am 01.10.2013 03:57, schrieb Roland Mainz:
> On Tue, Oct 1, 2013 at 3:43 AM, Ian Romanick wrote:
>> On 09/30/2013 05:47 PM, Roland Mainz wrote:
>>> On Tue, Oct 1, 2013 at 2:27 AM, Ian Romanick wrote:
On 09/27/2013 04:46 PM, Kenneth Graunke wrote:
> This was only used for uploading batchb
That's news to me that all tests must be part of all.tests. You can
blame me for that, I thought there were others not being part of
all.tests, but the README indeed states all new tests must be part of
it. So maybe the only tests not added there are those I wrote :-).
Roland
Am 03.10.2013 01:20
Am 03.10.2013 21:39, schrieb Brian Paul:
> On 10/03/2013 09:42 AM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> They need some special handling. Quite complicated.
>> Additionally, use the same code for implicit derivatives too if
>> no_rho_approx
&
Am 08.10.2013 02:23, schrieb Brian Paul:
> The new function replaces four old functions: set_fragment/vertex/
> geometry/compute_sampler_views().
>
> Note: at this time, it's expected that the 'start' parameter will
> always be zero.
>
> ---
>
> This change touches quite a few files. I've proba
Am 08.10.2013 21:22, schrieb Zack Rusin:
> Both the imul_hi and umul_hi are working with this patch.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c | 60
> ++
> 1 file changed, 60 insertions(+)
>
> diff --git a/src/gallium/auxiliary
Am 08.10.2013 22:00, schrieb Matt Turner:
> Do the ARB_gpu_shader5 tests in piglit (fs-imulExtended,
> fs-umulExtended) tests pass?
Since the patch makes no attempt to translate it from glsl, I can't see
how it would. Might be a nice addition though, but it would require glsl
version and extension
Am 10.10.2013 02:01, schrieb jfons...@vmware.com:
> From: José Fonseca
>
> Unless the polygon fill mode is different PIPE_POLYGON_MODE_FILL, so
> checking the the polygon mode is sufficient.
>
> Testing done: no regression in polygon-mode-offset
> ---
> src/gallium/drivers/llvmpipe/lp_state_ras
Am 10.10.2013 23:12, schrieb Brian Paul:
> On 10/10/2013 11:37 AM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> Fix coord wrapping (and face selection too) in case of edges.
>> Unfortunately, the coord wrapping is way more complicated than what
>> t
Am 11.10.2013 16:21, schrieb Brian Paul:
> On 10/11/2013 07:11 AM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> The previous limit of of 128*1024 was reported to cause frequent
>> recompiles
>> in some apps due to shader variant thrashing
Am 12.10.2013 02:02, schrieb Brian Paul:
> On 10/11/2013 10:44 AM, Emil Velikov wrote:
>> Current mesa code(cso and drivers) expect and use only up-to 16
>> texture samplers.
>>
>> Verbatum copy from the nvc0 driver.
>>
>> Cc "9.1"
>> Cc "9.2"
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cg
Am 12.10.2013 17:19, schrieb Christoph Bumiller:
> On 12.10.2013 02:47, Emil Velikov wrote:
>> On 12/10/13 01:25, Roland Scheidegger wrote:
>>> Am 12.10.2013 02:02, schrieb Brian Paul:
>>>> On 10/11/2013 10:44 AM, Emil Velikov wrote:
>>>>> Current mesa
Am 15.10.2013 21:15, schrieb Dave Airlie:
> On Tue, Oct 15, 2013 at 7:58 PM, Jose Fonseca wrote:
>> - Original Message -
>>> Hi,
>>>
>>> I pulled Brian's patches and then hacked llvmpipe locally to claim GL 3.2,
>>> and ran piglit, fixed some of the obviously missing pieces and crashes.
>>
Pretty sure though we only implement half of it, as we should clamp
incoming depth values at depth buffer time (either coming from
interpolated depth or fragment shader output) to the near and far depth
range. So we only implement the part affecting the clipping, but don't
consider the consequences
Am 18.10.2013 16:34, schrieb Brian Paul:
> On 10/18/2013 12:39 AM, Kenneth Graunke wrote:
>> Mesa now supports OpenGL 3.3 and GLSL 3.30, so bump the Mesa major
>> version from 10 to 11 to reflect this.
>>
>> Also update the release notes, and add appropriate FAQ entries.
>>
>> http://en.wikipedia.o
Am 19.10.2013 00:40, schrieb Kenneth Graunke:
> On 10/17/2013 11:39 PM, Kenneth Graunke wrote:
>> Mesa now supports OpenGL 3.3 and GLSL 3.30, so bump the Mesa major
>> version from 10 to 11 to reflect this.
>>
>> Also update the release notes, and add appropriate FAQ entries.
>>
>> http://en.wikipe
Am 25.10.2013 22:33, schrieb Brian Paul:
> On 10/25/2013 10:14 AM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> The layer coming from GS needs to be clamped (not sure if that's actually
>> the correct error behavior but we need something) as the num
;context), 4),
> 0);
>LLVMValueRef clip_ptr;
>
>clip_ptr = LLVMBuildGEP(builder, clip_ptrs[j], indices, 2, "clipo");
>
Reviewed-by: Roland Scheidegger
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Am 04.11.2013 18:21, schrieb jfons...@vmware.com:
> From: José Fonseca
>
> Just happened to notice it was missing while looking at it.
> ---
> src/gallium/auxiliary/util/u_format.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_format.h
> b/src/gallium/
On 11/12/2013 06:50 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
In particular get rid of home-grown vector helpers which didn't add much.
And while here fix formatting a bit. No functional change.
---
src/gallium/drivers/llvmpipe/lp_state_setup.c |
Looks great to me. Just some minor nitpicks.
On 11/13/2013 05:37 PM, jfons...@vmware.com wrote:
From: José Fonseca
It is similar to tgsi_exec.c's DEBUG_EXECUTION compile flag.
I had prototyped this for a while while debugging an issue, but finally
cleaned this up and added a few more bells an
On 11/14/2013 11:53 PM, Mark Mueller wrote:
This and the subsequent patch are the first steps in adding support to load
textures
via GPU instead of CPU. This patch expands Mesa's gl_formats such that all
GLUser
format/type combinations are represented and thus can be communicated to lower
leve
On 11/14/2013 09:33 PM, Brian Paul wrote:
For DX9-level shaders, there's only limited support for indirect
indexing of registers (with the loop counter register, not the
general address register.)
---
src/gallium/drivers/svga/svga_tgsi_insn.c |4
1 file changed, 4 insertions(+)
diff
amp;
in_pv == out_pv)
{
+ /* Index translation not really needed */
if (in_index_size == 4)
*out_translate = translate_memcpy_uint;
else
Reviewed-by: Roland Scheidegger
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On 11/20/2013 03:23 PM, jfons...@vmware.com wrote:
From: José Fonseca
D3D9 Shader Model 2 restricted the fog register to one component,
http://msdn.microsoft.com/en-us/library/windows/desktop/bb172945.aspx ,
but that restriction no longer exists in Shader Model 3, and several
WHCK tests enforce
610,9 @@ exec_kill_if(struct tgsi_exec_machine *mach,
kilmask |= 1 << i;
}
+ /* restrict to fragments currently executing */
+ kilmask &= mach->ExecMask;
+
mach->Temps[TEMP_KILMASK_I].xyzw[TEMP_KILMASK_C].u[0] |= kilmask;
}
Reviewed-b
On 11/20/2013 10:04 PM, Kenneth Graunke wrote:
On 11/20/2013 09:45 AM, Ian Romanick wrote:
On 11/20/2013 09:08 AM, Kenneth Graunke wrote:
On 11/20/2013 03:27 AM, Tapani Pälli wrote:
Earlier comments suggest this was removed from GL core spec but it is
still there. Enabling makes 'texture_lod_b
Great!
Couple of comments inline.
On 11/21/2013 12:02 AM, Zack Rusin wrote:
8 bit precision is required by d3d10 but unfortunately
requires 64 bit rasterizer. This commit implements
64 bit rasterization with full support for 8bit subpixel
precision. It's a combination of all individual commits
On 11/21/2013 02:01 PM, jfons...@vmware.com wrote:
From: José Fonseca
These degenerate instructions can often be emitted by state trackers
when the semantics of instructions don't match precisely.
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 8
src/gallium/auxiliary/tgsi/tgsi_ureg.
break; /* can't happen */
+ input = get_eye_position_z(p);
+ emit_op1(p, OPCODE_ABS, fog, WRITEMASK_X, input);
+ break;
+ default:
+ assert(!"Bad fog mode in build_fog()");
+ break;
}
}
Reviewed-b
On 11/21/2013 06:03 PM, jfons...@vmware.com wrote:
From: José Fonseca
Several links contributed by Keith Whitwell and Roland Scheidegger.
---
docs/llvmpipe.html | 58 --
1 file changed, 56 insertions(+), 2 deletions(-)
diff --git a/docs
On 11/22/2013 05:29 AM, Zack Rusin wrote:
For me too, other than the fixed_position members, looks good. Thanks for
your perseverance on this Zack!
Thanks! ok, attached is a version that makes position and dx/dy 32bit again, it
seems to work great. I have a question for you guys if you run th
On 11/22/2013 03:03 PM, Jose Fonseca wrote:
Thanks for reviewing.
- Original Message -
On 11/21/2013 02:01 PM, jfons...@vmware.com wrote:
From: José Fonseca
These degenerate instructions can often be emitted by state trackers
when the semantics of instructions don't match precisely.
It is however illegal in d3d10 to have multiple render targets with
different dimensions (including array size):
http://msdn.microsoft.com/en-us/library/windows/desktop/bb205131%28v=vs.85%29.aspx
I don't know what happens if you try to bind such rendertargets.
FWIW when I implemented layered render
cate at least 64 bytes but I wouldn't really trust
texture wrapping code to work later) but this looks good to me. I guess
it could be alternatively more simply written as
(uint64_t)lpr->row_stride[level] * nblocksy > LP_MAX_TEXTURE_SIZE
but either way is fine by me.
Reviewed-by: Roland
se_depth_test(struct quad_stage *qs,
> depth &&
> depthwrite &&
> !occlusion &&
> +!clipped &&
> !stencil)
> {
>if (qs->softpipe->framebuffer.zsbuf->format == PIPE_FORMAT_Z16_UNORM
Am 10.06.2014 07:57, schrieb Dave Airlie:
> From: Dave Airlie
>
> This adds support for GL 3.2 layered rendering to softpipe.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/softpipe/sp_context.h | 3 ++
> src/gallium/drivers/softpipe/sp_quad.h | 1 +
> src/ga
Am 10.06.2014 07:57, schrieb Dave Airlie:
> From: Dave Airlie
>
> This crashes on softpipe due to a lack of output memory allocated,
>
> it appears we allocate memory for enough primtives, but not vertices
> so convert to number of vertices.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/
PIPE_CAP_TEXTURE_GATHER_SM5:
> case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
>
5-8 are
Reviewed-by: Roland Scheidegger
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
if (ir->op == ir_query_levels) {
> + /* the level is stored in W */
> + inst = emit(ir, opcode, st_dst_reg(levels_src), lod_info);
> + result_dst.writemask = WRITEMASK_X;
> + levels_src.swizzle = SWIZZLE_;
> + emit(ir, TGSI_OPCODE_MOV, result_dst, levels_src);
> + } else
> + inst = emit(ir, opcode, result_dst, lod_info);
> + } else if (opcode == TGSI_OPCODE_TXF) {
>inst = emit(ir, opcode, result_dst, coord);
> } else if (opcode == TGSI_OPCODE_TXL2 || opcode == TGSI_OPCODE_TXB2) {
>inst = emit(ir, opcode, result_dst, coord, lod_info);
>
For 1-3:
Reviewed-by: Roland Scheidegger
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
This looks ok to me though since tgsi currently doesn't have any double
opcodes (well the docs have them...) it doesn't really apply to most
drivers (at least I assume you don't want to add support for it for tgsi).
Roland
Am 17.06.2014 18:44, schrieb Tom Stellard:
> This is for reporting whethe
Am 18.06.2014 01:54, schrieb Dave Airlie:
> On 18 June 2014 05:08, Roland Scheidegger wrote:
>> This looks ok to me though since tgsi currently doesn't have any double
>> opcodes (well the docs have them...) it doesn't really apply to most
>> drivers (at least
Am 19.06.2014 03:14, schrieb Dave Airlie:
> On 18 June 2014 23:50, Roland Scheidegger wrote:
>> Am 18.06.2014 01:54, schrieb Dave Airlie:
>>> On 18 June 2014 05:08, Roland Scheidegger wrote:
>>>> This looks ok to me though since tgsi currently doesn't have any
_switch_state {
> ir_variable *is_break_var;
> class ast_switch_statement *switch_nesting_ast;
>
> + /** Used to set condition if 'default' label should be chosen. */
> + ir_variable *run_default;
> +
> /** Table of constant values already used in
Am 19.06.2014 09:54, schrieb Eric Anholt:
> Dave Airlie writes:
>
>>>
>>> I'm working toward building a Mesa driver for Broadcom VC4 (aka
>>> Raspberry Pi). At the moment I'm still bringing up the DRM side of
>>> things, but I hope to be doing bits of userspace in the next few days.
>>> Current
Am 21.06.2014 03:00, schrieb Ian Romanick:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
> Cc: Ilia Mirkin
> Cc: Marek Olšák
> Cc: Roland Scheidegger
> Cc: "10.2"
> ---
> src/mesa/main/mtypes.h | 32
>
Am 21.06.2014 03:00, schrieb Ian Romanick:
> This patch series fixes bugs in the i965 w.r.t. several uses of
> gl_VertexID. OpenGL (desktop and ES) have the following expectations of
> gl_VertexID:
>
> 1. When used with BaseVertex drawing commands, gl_VertexID will include
> the value of basevert
Am 22.06.2014 17:10, schrieb Ilia Mirkin:
> Signed-off-by: Ilia Mirkin
> ---
> docs/GL3.txt| 2 +-
> docs/relnotes/10.3.html | 2 +-
> src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 ++
> src/gallium/drivers/nouveau/nvc0/nvc0_screen
Am 23.06.2014 12:49, schrieb Roland Scheidegger:
> Am 22.06.2014 17:10, schrieb Ilia Mirkin:
>> Signed-off-by: Ilia Mirkin
>> ---
>> docs/GL3.txt| 2 +-
>> docs/relnotes/10.3.html | 2 +-
>>
Am 23.06.2014 16:43, schrieb Ilia Mirkin:
> On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin wrote:
>> On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin wrote:
>>> If multiple viewports are supported, that implies the presence of a GS
>>> and layered rendering, so we can enable ARB_fragment_layer_viewport
Am 23.06.2014 17:18, schrieb Ilia Mirkin:
> On Mon, Jun 23, 2014 at 11:06 AM, Roland Scheidegger
> wrote:
>> Am 23.06.2014 16:43, schrieb Ilia Mirkin:
>>> On Mon, Jun 23, 2014 at 9:51 AM, Ilia Mirkin wrote:
>>>> On Mon, Jun 23, 2014 at 9:39 AM, Ilia Mirkin w
Am 23.06.2014 21:14, schrieb Ilia Mirkin:
> On Mon, Jun 23, 2014 at 12:01 PM, Roland Scheidegger
> wrote:
>> Am 23.06.2014 17:18, schrieb Ilia Mirkin:
>>> On Mon, Jun 23, 2014 at 11:06 AM, Roland Scheidegger
>>> wrote:
>>>> Am 23.06.2014 16:43, schri
Am 24.06.2014 00:59, schrieb Carl Worth:
> Roland Scheidegger writes:
>> Am 07.06.2014 20:38, schrieb Johannes Obermayr:
>>> From: Takashi Iwai
>>>
>>> Fix the crash of "gnome-control-center info" invocation on QEMU where
>>> zero height is
Am 27.06.2014 14:39, schrieb Brian Paul:
> On 06/26/2014 06:39 PM, Ian Romanick wrote:
>> On 06/26/2014 05:30 PM, Jason Ekstrand wrote:
>>> Right now, the Intel driver is the only driver in mesa that implements
>>
>> Also as far as we can tell... it's the only driver that implements it.
>> git-blam
Am 27.06.2014 06:40, schrieb Ilia Mirkin:
> Signed-off-by: Ilia Mirkin
> ---
> src/gallium/auxiliary/hud/hud_driver_query.c | 6 +++---
> src/gallium/drivers/freedreno/freedreno_query.c | 2 +-
> src/gallium/drivers/galahad/glhd_context.c | 6 --
> src/gallium/drivers/i
rote:
>> On Fri, Jun 27, 2014 at 9:56 AM, Roland Scheidegger
>> wrote:
>>> Am 27.06.2014 06:40, schrieb Ilia Mirkin:
>>>> Signed-off-by: Ilia Mirkin
>>>> ---
>>>> src/gallium/auxiliary/hud/hud_driver_query.c | 6 +++---
>>>>
3-4 look alright to me. I wonder if the cap name is actually "correct"
or if it should have some STREAM_OUT in it. But doesn't really matter I
guess.
Longer term I think we might want to merge some caps. Everybody
(supporting stream out) will either support 1 or 4 streams along with
other functiona
Sure though it seems a bit unfortunate if all the code is already
there... Please also enable it for llvmpipe.
Roland
Am 30.06.2014 17:22, schrieb Ilia Mirkin:
> Looks like it'll be a while before someone can look at my r600 patch
> which makes layer/viewport available in the fragment shader. Rol
Am 30.06.2014 19:43, schrieb Ilia Mirkin:
> On Sat, Jun 28, 2014 at 8:44 AM, Roland Scheidegger
> wrote:
>> 3-4 look alright to me.
>
> Does this count as a R-b? Looks like the core changes have landed, so
> I'm going to be looking to push all this out ~tomorrow.
>
FORM_BLOCK_DATA_SIZE).
> */
> GLuint UniformBufferSize;
>
Series is:
Reviewed-by: Roland Scheidegger
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Am 01.07.2014 16:25, schrieb Ilia Mirkin:
> On Tue, Jul 1, 2014 at 8:39 AM, Roland Scheidegger wrote:
>> Am 30.06.2014 19:43, schrieb Ilia Mirkin:
>>> On Sat, Jun 28, 2014 at 8:44 AM, Roland Scheidegger
>>> wrote:
>>>> 3-4 look alright to me.
>>&
Am 01.07.2014 23:47, schrieb Emil Velikov:
> On 01/07/14 20:17, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> it looks since ce1a1372280d737a1b85279995529206586ae480 they are now included
>> in more places, in particular even for things buildable with msv
gt;Const.ViewportBounds.Max = 16384.0;
> ctx->Extensions.ARB_viewport_array = GL_TRUE;
> + ctx->Extensions.ARB_fragment_layer_viewport = GL_TRUE;
>}
> }
> if (ctx->Const.MaxProgramTextureGatherComponents > 0)
>
Reviewed-by: Roland Scheidegger
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
I don't have much of an idea how the interaction with per sample shading
should look like, but this looks alright to me.
Roland
Am 02.07.2014 03:55, schrieb Ilia Mirkin:
> Signed-off-by: Ilia Mirkin
> ---
>
> Not sure if this is the right approach or if I should combine it with Centroid
> more
ENTER 0
TGSI_INTERPOLATE_LOC_CENTROID 1
TGSI_INTERPOLATE_LOC_SAMPLE 2
Or something like that. Not sure though...
Roland
Am 02.07.2014 19:04, schrieb Roland Scheidegger:
> I don't have much of an idea how the interaction with per sample shading
> should look like, but this looks alright to me.
>
&
Reviewed-by: Roland Scheidegger
Am 03.07.2014 17:17, schrieb Ilia Mirkin:
> Now that this cap is used to determine the availability of both, adjust
> its name to reflect the new reality.
>
> Signed-off-by: Ilia Mirkin
> ---
> src/gallium/auxiliary/util/u_blitter.c
Am 03.07.2014 03:19, schrieb Ilia Mirkin:
> On Wed, Jul 2, 2014 at 4:03 PM, Roland Scheidegger wrote:
>> Actually on second thought, because centroid and sample are mutually
>> exclusive (or more generally, the "Interpolate" member determines "how"
>>
esource->width0) {
>usage |= PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE;
> } else {
>usage |= PIPE_TRANSFER_DISCARD_RANGE;
>
Reviewed-by: Roland Scheidegger
I guess it would be possible to also do this for non-buffer resources,
by checking all appro
= 1;
>break;
> case TGSI_TEXTURE_2D:
> + case TGSI_TEXTURE_2D_MSAA:
> case TGSI_TEXTURE_RECT:
>dims = 2;
>break;
> + case TGSI_TEXTURE_2D_ARRAY_MSAA:
> case TGSI_TEXTURE_2D_ARRAY:
>layer_coord = 2;
>dims = 2;
>
Reviewed-b
7;t neither).
In any case,
Reviewed-by: Roland Scheidegger
>
> Signed-off-by: Ilia Mirkin
> ---
>
> I tried to make sure I hit all the uses, but I guess a bunch of drivers don't
> look at the Centroid field at all?
Well drivers not doing msaa or just fake one like llvmpipe
Looks good to me. It is unfortunate I guess that shaders may need
recompilation just because the inputs are interpolated differently but I
don't see a easy way out there.
Roland
Am 05.07.2014 06:07, schrieb Ilia Mirkin:
> This enables a gallium driver not to care about the semantics of
> ARB_samp
x27;s done with southern
islands, but this one has a 4bit int to float instruction "to be used in
shader interpolation" so my guess is it will indeed take any float
natively. Didn't look at nvidia, but a float makes sense then if not all
hw agrees.
Reviewed-by: Roland Scheidegger
Am
301 - 400 of 2245 matches
Mail list logo
