Re: [Mesa-dev] [PATCH 1/2] gallium: add texture gather support to gallium

On 07.02.2014 23:25, Dave Airlie wrote: >>> Doh, yes because GL has ARB_texture_gather then has stuff hidden away >>> in ARB_gpu_shader5 I forgot to add the extra bits which I suppose we should >>> do. >>> >>> So I've reposted with the component selection in src1 now. >> Hmm seems a bit excessive

[Mesa-dev] [PATCH] mesa/st: expose ARB_texture_rgb10_a2ui if R10G10B10A2_UINT is supported v2

--- src/mesa/state_tracker/st_extensions.c | 4 +++- src/mesa/state_tracker/st_format.c | 6 +- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index 5e4a3b3..8c49e54 100644 --- a/src/mesa/state

[Mesa-dev] [PATCH 2/3] nv50: add more RGB10A2 formats

--- src/gallium/drivers/nouveau/nv50/nv50_formats.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_formats.c b/src/gallium/drivers/nouveau/nv50/nv50_formats.c index 0a7e812..b301890 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_formats.c +++

[Mesa-dev] [PATCH 3/3] mesa/st: expose ARB_texture_rgb10_a2ui if R10G10B10A2_UINT is supported

--- src/mesa/state_tracker/st_extensions.c | 4 +++- src/mesa/state_tracker/st_format.c | 2 +- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index 5e4a3b3..8c49e54 100644 --- a/src/mesa/state_tra

[Mesa-dev] [PATCH 1/3] st/mesa: fix GS varyings for PIPE_CAP_TGSI_TEXCOORD

--- src/mesa/state_tracker/st_program.c | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/src/mesa/state_tracker/st_program.c b/src/mesa/state_tracker/st_program.c index f72122b..f13132e 100644 --- a/src/mesa/state_tracker/st_program.c +++ b/src/mesa/state_t

Re: [Mesa-dev] [PATCH] nv50: implement multisample textures

On 25.10.2013 23:51, Bryan Cain wrote: > On 10/25/2013 04:11 PM, Christoph Bumiller wrote: >> On 25.10.2013 20:35, Emil Velikov wrote: >>> On 21/10/13 23:23, Bryan Cain wrote: >>>> This is a port of 4da54c91d24da ("nvc0: implement multisample textures") t

Re: [Mesa-dev] [PATCH] nv50: implement multisample textures

On 25.10.2013 20:35, Emil Velikov wrote: > On 21/10/13 23:23, Bryan Cain wrote: >> This is a port of 4da54c91d24da ("nvc0: implement multisample textures") to >> nv50. >> >> When coupled with the patch to only report 16 texture samplers (to fix >> crashes), all of the Piglit tests in spec/arb_textu

Re: [Mesa-dev] [PATCH] nv50: report only 16 texure_samplers

On 12.10.2013 18:52, Roland Scheidegger wrote: > 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: >>>>&g

Re: [Mesa-dev] [PATCH] nv50: report only 16 texure_samplers

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 code(cso and drivers) expect and use only up-to 16 texture samplers. Verbatum copy fro

Re: [Mesa-dev] regression on nvc0 since floating point compare instructions

On 12.09.2013 16:14, Roland Scheidegger wrote: > Am 12.09.2013 03:40, schrieb Dave Airlie: >>> Maybe the type isn't set correctly? Looks to me like these instructions >>> end up in mkCmp, which will set both src and dst type but ignore src >>> type and set both according to the same type (which was

Re: [Mesa-dev] regression on nvc0 since floating point compare instructions

On 10.09.2013 06:55, Dave Airlie wrote: > On Tue, Sep 10, 2013 at 12:04 PM, Dave Airlie wrote: >> On Tue, Sep 10, 2013 at 11:59 AM, Dave Airlie wrote: >>> Hey, >>> >>> so virgl stopped working on nouveau the other day and I bisected it to >>> the enable of the floating point compare instructions

Re: [Mesa-dev] [PATCH] r600g/llvm: don't export more colors than the number of CBs

On 24.08.2013 11:44, Christian König wrote: > Am 24.08.2013 03:30, schrieb Vadim Girlin: >> Currently llvm backend always exports at least one color in pixel >> shader even if no color buffers are enabled. With depth/stencil exports >> this can result in the following code: >> >> EXPORT

Re: [Mesa-dev] [PATCH 2/4] nv50: implement new float comparison instructions

On 13.08.2013 19:04, srol...@vmware.com wrote: > From: Roland Scheidegger > > untested. Looks like it should work though, thanks. nv50 only supported u32 result all along and on nvc0 both cases are already handled by the rest of the code, too. > --- > .../drivers/nv50/codegen/nv50_ir_from_tgsi.

Re: [Mesa-dev] [RFC]: gallium: add new float comparison opcodes returning integer booleans

On 09.08.2013 20:42, Roland Scheidegger wrote: > This is a proposal for new comparison instructions, as the old ones > don't really fit modern (graphic or opencl I guess for that matter) > languages well. > If you've got objections, think the naming is crazy or whatnot I'm open > for suggestions :-

Re: [Mesa-dev] [PATCH 4/6] i965/fs: Optimize IF/MOV/ELSE/MOV/ENDIF to SEL when possible.

On 06.08.2013 19:19, Matt Turner wrote: > On Tue, Aug 6, 2013 at 4:14 AM, Christoph Bumiller > wrote: >> On 06.08.2013 03:28, Kenneth Graunke wrote: >>> Many GLSL shaders contain code of the form: >>> >>>x = condition ? foo : bar >>> >>&

Re: [Mesa-dev] [PATCH 4/6] i965/fs: Optimize IF/MOV/ELSE/MOV/ENDIF to SEL when possible.

On 06.08.2013 03:28, Kenneth Graunke wrote: > Many GLSL shaders contain code of the form: > >x = condition ? foo : bar > > The compiler emits an ir_if tree for this, since each subexpression > might be a complex tree that could have side-effects and short-circuit > logic operations. > > Howe

Re: [Mesa-dev] [PATCH 08/34] mesa/st: Add VARYING_SLOT_TEX[1-7] to st_translate_geometry_program().

On 29.07.2013 08:03, Paul Berry wrote: > From: Bryan Cain > > v2 (Paul Berry : Split out to separate patch > (previously this was part of "glsl: add builtins for geometry > shaders.") > --- > src/mesa/state_tracker/st_program.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/src/m

Re: [Mesa-dev] [PATCH] st/mesa: expose EXT_framebuffer_multisample_blit_scaled if MSAA is supported

On 17.07.2013 02:05, Marek Olšák wrote: > No, it's not faster, but it's not slower either. > > Now that I think about it, I can't come up with a good shader-based > algorithm for the resolve operation. > > I don't think Christoph's approach that an MSAA texture can be viewed > as a larger single-sa

Re: [Mesa-dev] [PATCH] st/mesa: expose EXT_framebuffer_multisample_blit_scaled if MSAA is supported

On 17.07.2013 00:12, Grigori Goronzy wrote: > On 16.07.2013 19:26, Marek Olšák wrote: >> Surprisingly all drivers supporting MSAA can already do this (r300g >> and r600g >> for sure) and I think Christoph wanted to have this feature for his >> Nouveau >> drivers anyway. > > OK, they can do it, but

[Mesa-dev] Direct3D 9 state tracker

So, about two months ago I had the insane idea to pick up Joakim Sindholt's Direct3D 9 state tracker that he'd started about 3 years ago with the goal to make it run StarCraft 2 so I could finally play at a reasonable frame rate ... With help from Joakim and advice from the wine developers, as wel

Re: [Mesa-dev] [PATCH 3/3] tgsi: rename the TGSI fragment kill opcodes

On 12.07.2013 16:06, Jose Fonseca wrote: > The tradition has been to use "C" suffix for conditional opcodes, instead of > "_IF". That said, I don't feel too strongly either way. > Except the 'C' suffix usually (ok, we only have BREAKC) indicates a single condition value where non-zero means tru

Re: [Mesa-dev] [PATCH 2/3] tgsi: fix-up KILP comments

On 12.07.2013 01:26, Brian Paul wrote: > KILP is really unconditional fragment kill. > > We've had KIL and KILP transposed forever. I'll fix that next. I think the 'P' meant to indicate that the condition, if there is any, would be a predicate register, whereas KIL no-P is supposed to represent t

Re: [Mesa-dev] [PATCH 1/3] gallium: add expand_resource interface

On 11.07.2013 20:15, Marek Olšák wrote: > Hi Roland, > > The fast color clear on Radeon doesn't touch the memory of the texture > resource. Instead, it changes some GPU meta data that say the resource > is cleared (the location of the meta data is stored in pipe_resource). > This works fine as long

Re: [Mesa-dev] [PATCH] gallium/util: use explicily sized types for {un, }pack_rgba_{s, u}int

On 08.07.2013 22:32, Marek Olšák wrote: > Hi Emil, > > What issue does this patch fix? Is there a nonarchaic CPU architecture > or a compiler where "int" doesn't have 32 bits? Yes, on x86_128 an int will be 64 bit. It says "(Un)pack pixel blocks to/from R32G32B32A32_UINT", and not PIPE_FORMAT_RSI

[Mesa-dev] [PATCH] r600g: x/y coordinates must be divided by block dim in dma blit

From: Christoph Bumiller --- src/gallium/drivers/r600/evergreen_state.c | 10 -- src/gallium/drivers/r600/r600_state.c | 10 -- 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/r600/evergreen_state.c b/src/gallium/drivers/r600

Re: [Mesa-dev] RFC: more changes to render_condition

On 22.06.2013 16:36, Roland Scheidegger wrote: > We decided to drop predicated transfers already. State tracker can > emulate this by using another resource and doing a (predicated) > resource_copy_region, might be slightly suboptimal but predicated > transfers really sound strange. > As for resour

Re: [Mesa-dev] [PATCH 2/2] gallium/draw: add limits to the clip and cull distances

On 12.06.2013 15:57, Jose Fonseca wrote: > > > - Original Message - >> Am 11.06.2013 05:39, schrieb Zack Rusin: >>> There are strict limits on those registers. Define the maximums >>> and use them instead of magic numbers. Also allows us to add >>> some extra sanity checks. >>> Suggested

Re: [Mesa-dev] [PATCH 03/13] gallium: Introduce 32-bit bytewise format names

On 06.06.2013 10:34, Richard Sandiford wrote: > Michel Dänzer writes: >> On Die, 2013-06-04 at 10:47 +0100, Richard Sandiford wrote: >>> (2) it uses PIPE_FORMAT_INT_* names with the lsb first rather than the >>> mesa-like ones with msb first. (I'm happy to change the names to >>> somethin

Re: [Mesa-dev] [PATCH] gallium: add support for layered rendering

On 01.06.2013 01:02, Alex Deucher wrote: > On Fri, May 31, 2013 at 6:54 PM, Roland Scheidegger > wrote: >> Am 31.05.2013 23:43, schrieb srol...@vmware.com: >>> From: Roland Scheidegger >>> >>> Since pipe_surface already has all the necessary fields no interface >>> changes are necessary except a

Re: [Mesa-dev] Instancing support in r300g?

you to loop in the driver ... the only "hardware support" for instancing they added is a builtin counter. > Marek > > On Sat, May 18, 2013 at 4:59 PM, Lauri Kasanen wrote: >> On Sat, 18 May 2013 17:46:32 +0300 >> Lauri Kasanen wrote: >> >>> On

Re: [Mesa-dev] Instancing support in r300g?

On 18.05.2013 13:05, Lauri Kasanen wrote: > Hi, > > The 'net claims that instancing is a SM3 feature[1] (r500), but also > supported on SM2 ATI cards[2] (r300-r400). > > Yet r300g claims no support for it, and it seems that even Nvidia's r300_get_param: case PIPE_CAP_VERTEX_ELEMENT_INSTANCE_DIVISO

Re: [Mesa-dev] [PATCH] gallium/tgsi: clarify (possibly change) TGSI_OPCODE_UCMP definition

On 08.05.2013 03:48, srol...@vmware.com wrote: > From: Roland Scheidegger > > UCMP while an integer opcode isn't really consistently implemented as > having all integer arguments. softpipe will assume all arguments are > ints, whereas gallivm has the arguments defined as untyped which > means the

Re: [Mesa-dev] [PATCH] nouveau: emit and flush fence in fence_signalled if needed

On 07.05.2013 19:25, Bryan Cain wrote: > The Mesa state tracker expects us to emit the fence even if it doesn't call > fence_finish. Notably, this occurs when glClientWaitSync is called with > timeout 0. > > Fixes Portal and Left 4 Dead 2, which were both stalling on startup by > repeatedly calli

Re: [Mesa-dev] RFC: tgsi opcodes for 32x32 muls with 64bit results

On 03.05.2013 16:32, Jose Fonseca wrote: > > - Original Message - >> Am 03.05.2013 06:58, schrieb Jose Fonseca: >>> >>> - Original Message - Currently, there's no way to get the high bits of a 32x32 signed/unsigned integer multiplication with tgsi. However, all of d3d

Re: [Mesa-dev] [PATCH 2/5] gallium: increase the number of available stream output decls

On 25.04.2013 19:22, Roland Scheidegger wrote: > Am 24.04.2013 00:58, schrieb Zack Rusin: >> There can be more stream output decls than shader outputs because >> individual components from them can be split and distributed >> among different so buffers. >> >> Signed-off-by: Zack Rusin >> --- >> s

Re: [Mesa-dev] [PATCH 2/2] gallium: Replaced gl_rasterization_rules with lower_left_origin and half_pixel_center.

On 23.04.2013 18:28, Jose Fonseca wrote: > Ok. I've moved the docs to src/gallium/docs/source/cso/rasterizer.rst , and > renamed `lower_left_origin` to `bottom_edge_rule`. > Well, that doesn't work for NV, but it's at least less invasive for radeon since you don't have to change the state tracke

Re: [Mesa-dev] [PATCH 2/2] gallium: Replaced gl_rasterization_rules with lower_left_origin and half_pixel_center.

On 21.04.2013 14:35, Jose Fonseca wrote: > > > - Original Message - >> On 21.04.2013 13:18, Jose Fonseca wrote: >> >> I think that drivers can just report all 4 CAPs as supported and do the >> adjustment in the shader themselves (no need for recompilation, just use >> uniforms, the st alr

Re: [Mesa-dev] [PATCH 2/2] gallium: Replaced gl_rasterization_rules with lower_left_origin and half_pixel_center.

On 21.04.2013 13:18, Jose Fonseca wrote: > > - Original Message - >> On 21.04.2013 09:36, Jose Fonseca wrote: >>> - Original Message - Do we really need the lower_left_origin state? I think I can't implement it for radeon and it's the kind of stuff that should be take

Re: [Mesa-dev] [PATCH 2/2] gallium: Replaced gl_rasterization_rules with lower_left_origin and half_pixel_center.

On 21.04.2013 12:34, Dave Airlie wrote: > On Sun, Apr 21, 2013 at 5:36 PM, Jose Fonseca wrote: >> - Original Message - >>> Do we really need the lower_left_origin state? I think I can't >>> implement it for radeon and it's the kind of stuff that should be >>> taken care of by the state tra

Re: [Mesa-dev] [PATCH 2/2] gallium: Replaced gl_rasterization_rules with lower_left_origin and half_pixel_center.

On 21.04.2013 09:36, Jose Fonseca wrote: > - Original Message - >> Do we really need the lower_left_origin state? I think I can't >> implement it for radeon and it's the kind of stuff that should be >> taken care of by the state tracker anyway. > My understanding is that hardware had switc

Re: [Mesa-dev] [PATCH 02/14] st/mesa: add a simple path to BufferData if it only discards buffer contents

On 19.04.2013 14:08, Marek Olšák wrote: > That's not true. PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE does not copy > data in radeon drivers. It really does what st/mesa does - it creates > a new buffer and throws away the old one, which doesn't take any GPU > bandwidth. Doing that at a lower level shoul

Re: [Mesa-dev] [PATCH 2/5] gallium: document breakc and switch/case/default/endswitch

On 19.04.2013 09:26, Jose Fonseca wrote: > > - Original Message - >> From: Roland Scheidegger >> >> docs were missing, especially the opcode-from-hell switch however is anything >> but obvious. >> --- >> src/gallium/docs/source/tgsi.rst | 57 >> ++ >>

[Mesa-dev] [PATCH] st/mesa: optionally apply texture swizzle to border color v2

From: Christoph Bumiller This is the only sane solution for nv50 and nvc0 (really, trust me), but since on other hardware the border colour is tightly coupled with texture state they'd have to undo the swizzle, so I've added a cap. The dependency of update_sampler on the texture u

Re: [Mesa-dev] [PATCH] st/mesa: optionally apply texture swizzle to border color

On 14.04.2013 15:34, Jose Fonseca wrote: > > - Original Message - >> On 14.04.2013 13:44, Jose Fonseca wrote: >>> - Original Message - >>>> From: Christoph Bumiller >>>> >>>> This is the only sane solution for nv50 and nvc0

Re: [Mesa-dev] [PATCH] st/mesa: optionally apply texture swizzle to border color

On 14.04.2013 14:33, Christoph Bumiller wrote: > > === > In the format description (including swizzle), each color component of > RGBA (as seen by the shader) gets mapped a memory component > {C0,C1,C2,C3} or {ZERO,ONE_INT,ONE_FLOAT}. > > When a memory (!) component (Cx)

Re: [Mesa-dev] [PATCH] st/mesa: optionally apply texture swizzle to border color

On 14.04.2013 13:50, Jose Fonseca wrote: > - Original Message - > >> Not to mention the sheer insanity, ugliness and emotional pain incurred >> when writing that code when it COULD be so easy and simple in the state >> tracker where you know that textures and samplers are tightly coupled, >

Re: [Mesa-dev] [PATCH] st/mesa: optionally apply texture swizzle to border color

On 14.04.2013 13:44, Jose Fonseca wrote: > - Original Message - >> From: Christoph Bumiller >> >> This is the only sane solution for nv50 and nvc0 (really, trust me), >> but since on other hardware the border colour is tightly coupled with >> texture stat

[Mesa-dev] [PATCH] nv50/ir: handle TGSI_OPCODE_IF(float) properly

You can merge this with the original UIF patch if you want. --- .../drivers/nv50/codegen/nv50_ir_from_tgsi.cpp |7 ++- .../drivers/nv50/codegen/nv50_ir_lowering_nv50.cpp |2 +- .../drivers/nvc0/codegen/nv50_ir_lowering_nvc0.cpp |2 +- 3 files changed, 4 insertions(+), 7 deletio

Re: [Mesa-dev] [PATCH resend] mesa: Add core support for the GL_AMD_performance_monitor extension.

On 12.04.2013 21:14, Kenneth Graunke wrote: > This provides an interface for applications (and OpenGL-based tools) to > access GPU performance counters. Since the exact performance counters > available vary between vendors and hardware generations, the extension > provides an API the application c

[Mesa-dev] [PATCH] st/mesa: optionally apply texture swizzle to border color

From: Christoph Bumiller This is the only sane solution for nv50 and nvc0 (really, trust me), but since on other hardware the border colour is tightly coupled with texture state they'd have to undo the swizzle, so I've added a cap. The name of the cap could be changed to be more d

Re: [Mesa-dev] [PATCH resend] mesa: Add core support for the GL_AMD_performance_monitor extension.

On 12.04.2013 21:14, Kenneth Graunke wrote: > This provides an interface for applications (and OpenGL-based tools) to > access GPU performance counters. Since the exact performance counters > available vary between vendors and hardware generations, the extension > provides an API the application c

Re: [Mesa-dev] [PATCH 2/2] radeonsi: add support for compressed texture

On 08.04.2013 12:03, Marek Olšák wrote: > On Mon, Apr 8, 2013 at 11:29 AM, Michel Dänzer > wrote: > > On Fre, 2013-04-05 at 17:36 -0400, j.gli...@gmail.com > wrote: > > From: Jerome Glisse mailto:jgli...@redhat.com>> > > >

[Mesa-dev] [PATCH] mesa: add indirect drawing buffer parameter to draw functions v3

Split from patch implementing ARB_draw_indirect. v2: Const-qualify the struct gl_buffer_object *indirect argument. v3: Fix up some more draw calls for new argument. Sorry, it's getting a bit spammy I guess. --- src/mesa/drivers/dri/i965/brw_draw.c |3 ++- src/mesa/drivers/dri/i9

[Mesa-dev] [PATCH] mesa/draw_indirect: fix index bounds

(Will be merged into the original patches.) Calculating the actual limits is impossible, and softpipe drops vertices that lie outside the specified range. --- src/gallium/auxiliary/util/u_draw.c |4 src/mesa/state_tracker/st_draw.c|3 +++ src/mesa/vbo/vbo_exec_array.c |

[Mesa-dev] [PATCH] st/mesa: add support for indirect drawing v2

v2: Fix for constness of indirect buffer argument. Remove separate extension enable for multi_draw_indirect. --- src/mesa/state_tracker/st_cb_bufferobjects.c |3 +++ src/mesa/state_tracker/st_cb_bufferobjects.h |6 ++ src/mesa/state_tracker/st_draw.c | 11 ++- src

[Mesa-dev] [PATCH 4/5] gallium: add facilities for indirect drawing

v2: Added comments to util_draw_indirect, clarified and fixed map size. Removed unlikely(). --- src/gallium/auxiliary/util/u_draw.c | 43 ++ src/gallium/auxiliary/util/u_draw.h |8 src/gallium/auxiliary/util/u_dump_state.c|3 ++

[Mesa-dev] [PATCH 2/5] mesa: implement GL_ARB_draw_indirect and GL_ARB_multi_draw_indirect

v2: Removed some stray extern qualifiers. Documented use of Draw*IndirectCommand sizes. Removed separate extension enable flag for ARB_multi_draw_indirect since this can always be supported by looping. Kept generation of GL_INVALID_OPERATION in display list compile. The spec doesn't say anything

[Mesa-dev] [PATCH 5/5] st/mesa: add support for indirect drawing

--- src/mesa/state_tracker/st_cb_bufferobjects.c |3 +++ src/mesa/state_tracker/st_draw.c | 11 ++- src/mesa/state_tracker/st_extensions.c |3 ++- 3 files changed, 15 insertions(+), 2 deletions(-) diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c b/src

[Mesa-dev] [PATCH 1/5] mesa: add indirect drawing buffer parameter to draw functions

Split from patch implementing ARB_draw_indirect. v2: Const-qualify the struct gl_buffer_object *indirect argument. --- src/mesa/drivers/dri/i965/brw_draw.c |3 ++- src/mesa/drivers/dri/i965/brw_draw.h |3 ++- src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c |9 ++--- s

[Mesa-dev] [PATCH 3/5] gallium: add PIPE_BIND_COMMAND_ARGS_BUFFER

Intended for use with GL_ARB_draw_indirect's DRAW_INDIRECT_BUFFER target or for D3D11_RESOURCE_MISC_DRAWINDIRECT_ARGS. --- src/gallium/docs/source/screen.rst |3 +++ src/gallium/include/pipe/p_defines.h |1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/gallium/docs

Re: [Mesa-dev] [PATCH 1/4] mesa: implement GL_ARB_draw_indirect

On 05.04.2013 13:32, Christoph Bumiller wrote: > On 04.04.2013 21:17, Brian Paul wrote: >> I just did a quick skim and found a few minor things. >> >> First, the subject might be "mesa: implement GL_ARB_draw_indirect and >> GL_ARB_multi_draw_indirect" >>

Re: [Mesa-dev] [PATCH 1/4] mesa: implement GL_ARB_draw_indirect

On 04.04.2013 21:17, Brian Paul wrote: > I just did a quick skim and found a few minor things. > > First, the subject might be "mesa: implement GL_ARB_draw_indirect and > GL_ARB_multi_draw_indirect" > > This is a big patch and I think it could have been broken down into > smaller pieces, but I know

Re: [Mesa-dev] [PATCH 2/4] gallium: add PIPE_BIND_COMMAND_BUFFER

On 04.04.2013 21:53, Christoph Bumiller wrote: > On 04.04.2013 21:44, Jose Fonseca wrote: >> I think that PIPE_BIND_INDIRECT_BUFFER would be more self-descriptive. Marek suggested PIPE_BIND_DRAW_INDIRECT_BUFFER, but I think that's too specific because there's also a DISPATCH_

Re: [Mesa-dev] [PATCH 2/4] gallium: add PIPE_BIND_COMMAND_BUFFER

On 04.04.2013 21:44, Jose Fonseca wrote: > I think that PIPE_BIND_INDIRECT_BUFFER would be more self-descriptive. > > Or do you envision other uses of such buffer? It's possible that at some point we add a mechanism to let the driver store arbitrary commands into a buffer created by the st, or hav

[Mesa-dev] [PATCH] mesa: implement GL_ARB_draw_indirect (added missing ARB_draw_indirect.xml)

--- src/mapi/glapi/gen/ARB_draw_indirect.xml | 45 + src/mapi/glapi/gen/Makefile.am |1 + src/mapi/glapi/gen/gl_API.xml|4 +- src/mesa/drivers/dri/i965/brw_draw.c |3 +- src/mesa/drivers/dri/i965/brw_draw.h |3 +- src/mesa/dri

[Mesa-dev] [PATCH 3/4] gallium: add facilities for indirect drawing

--- src/gallium/auxiliary/util/u_draw.c | 39 ++ src/gallium/auxiliary/util/u_draw.h |5 +++ src/gallium/auxiliary/util/u_dump_state.c|3 ++ src/gallium/docs/source/screen.rst |3 ++ src/gallium/drivers/freedreno/fre

[Mesa-dev] [PATCH 4/4] st/mesa: add support for indirect drawing

--- src/mesa/state_tracker/st_cb_bufferobjects.c |3 +++ src/mesa/state_tracker/st_draw.c | 11 ++- src/mesa/state_tracker/st_extensions.c |4 +++- 3 files changed, 16 insertions(+), 2 deletions(-) diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c b/sr

[Mesa-dev] [PATCH 1/4] mesa: implement GL_ARB_draw_indirect

--- src/mapi/glapi/gen/Makefile.am |1 + src/mapi/glapi/gen/gl_API.xml|4 +- src/mesa/drivers/dri/i965/brw_draw.c |3 +- src/mesa/drivers/dri/i965/brw_draw.h |3 +- src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c |9 +- src/mesa/main/a

[Mesa-dev] [PATCH 2/4] gallium: add PIPE_BIND_COMMAND_BUFFER

Intended for use with GL_ARB_draw_indirect's DRAW_INDIRECT_BUFFER target or for D3D11_RESOURCE_MISC_DRAWINDIRECT_ARGS. --- src/gallium/docs/source/screen.rst |2 ++ src/gallium/include/pipe/p_defines.h |1 + 2 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/gallium/docs/

Re: [Mesa-dev] [PATCH] tgsi: Add a conditional move inststruction

On 04.04.2013 17:23, Jose Fonseca wrote: > > - Original Message - >> On 04.04.2013 17:01, Jose Fonseca wrote: >>> - Original Message - > On 04.04.2013 03:45, Zack Rusin wrote: >> It's part of SM4 (http://goo.gl/4IpeK). It's also fairly >> painful to emulate without branc

Re: [Mesa-dev] [PATCH] tgsi: Add a conditional move inststruction

On 04.04.2013 17:01, Jose Fonseca wrote: > > - Original Message - >>> On 04.04.2013 03:45, Zack Rusin wrote: It's part of SM4 (http://goo.gl/4IpeK). It's also fairly painful to emulate without branching. Most hardware supports it natively and even llvm has a 'select' opcode >

Re: [Mesa-dev] [PATCH] tgsi: Add a conditional move inststruction

On 04.04.2013 16:53, Zack Rusin wrote: >> On 04.04.2013 03:45, Zack Rusin wrote: >>> It's part of SM4 (http://goo.gl/4IpeK). It's also fairly >>> painful to emulate without branching. Most hardware >>> supports it natively and even llvm has a 'select' opcode >>> which can handle it without too much

Re: [Mesa-dev] [PATCH] tgsi: Add a conditional move inststruction

On 04.04.2013 03:45, Zack Rusin wrote: > It's part of SM4 (http://goo.gl/4IpeK). It's also fairly > painful to emulate without branching. Most hardware > supports it natively and even llvm has a 'select' opcode > which can handle it without too much hassle. > > diff --git a/src/gallium/docs/source/

Re: [Mesa-dev] [PATCH] st/mesa: fix bitmap, drawpix, drawtex for PIPE_CAP_TGSI_TEXCOORD

On 02.04.2013 16:39, Brian Paul wrote: > On 03/30/2013 08:11 AM, Christoph Bumiller wrote: >> NOTE: Changed the semantic index for the drawtex coordiante to >> be the texture unit index instead of always 0. >> Not sure if this is correct but since the value seems to depend &g

[Mesa-dev] [PATCH] st/mesa: fix bitmap, drawpix, drawtex for PIPE_CAP_TGSI_TEXCOORD

NOTE: Changed the semantic index for the drawtex coordiante to be the texture unit index instead of always 0. Not sure if this is correct but since the value seems to depend on the unit it would make sense to use different varying slots. --- src/mesa/state_tracker/st_cb_bitmap.c |1 + src/

[Mesa-dev] [PATCH] gallium/docs: fix definition of PIPE_QUERY_SO_STATISTICS

--- src/gallium/docs/source/context.rst |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/src/gallium/docs/source/context.rst b/src/gallium/docs/source/context.rst index 9e57930..2cc1848 100644 --- a/src/gallium/docs/source/context.rst +++ b/src/gallium/docs/source/c

[Mesa-dev] [PATCH] gallium/hud: add support for PIPE_QUERY_PIPELINE_STATISTICS

Also, renamed "pixels-rendered" to "samples-passed" because the occlusion counter increments even if colour and depth writes are disabled, or (on some implementations) for killed that passed the depth test when early_fragment_tests has been set for the PS. --- src/gallium/auxiliary/hud/hud_context

[Mesa-dev] [PATCH] gallium: add PIPE_CAP_QUERY_PIPELINE_STATISTICS

--- src/gallium/docs/source/screen.rst |2 ++ src/gallium/drivers/freedreno/freedreno_screen.c |1 + src/gallium/drivers/i915/i915_screen.c |1 + src/gallium/drivers/llvmpipe/lp_screen.c |2 ++ src/gallium/drivers/nv30/nv30_screen.c |1

Re: [Mesa-dev] [PATCH] r600g: fix range handling for tgsi input/output declarations

On 29.03.2013 10:56, Christian König wrote: > Am 28.03.2013 20:34, schrieb Vadim Girlin: >> On 03/28/2013 01:01 PM, � wrote: >>> Am 27.03.2013 20:37, schrieb Vadim Girlin: Signed-off-by: Vadim Girlin --- src/gallium/drivers/r600/r600_shader.c | 19 +++ 1 file

Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers

On 26.03.2013 12:18, Vadim Girlin wrote: > On 03/26/2013 02:00 AM, Marek Olšák wrote: >> On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek >> wrote: >>> On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote: Hi everyone, one image is better than a thousand words: ... >>> >>> Hi, >>> >>>

Re: [Mesa-dev] RFC: TGSI scalar arrays

On 20.03.2013 18:30, Roland Scheidegger wrote: > Am 20.03.2013 17:46, schrieb Christoph Bumiller: >> On 20.03.2013 17:05, Roland Scheidegger wrote: >>> >>> Not sure I fully understand this, but I'm thinking "whenever in doubt, >>> use something close t

Re: [Mesa-dev] RFC: TGSI scalar arrays

On 20.03.2013 17:05, Roland Scheidegger wrote: > Am 20.03.2013 15:41, schrieb Christoph Bumiller: >> Sorry, this has become longer than I anticipated ... >> >> I've been toying with adding support for TGSI_FILE_INPUT/OUTPUT arrays >> because, since I cannot allocate

[Mesa-dev] RFC: TGSI scalar arrays

Sorry, this has become longer than I anticipated ... I've been toying with adding support for TGSI_FILE_INPUT/OUTPUT arrays because, since I cannot allocate varyings in the same order that the register index specifies, I need it: === EXAMPLE: OUT[0], CLIPDIST[1], must be allocated at address 0x2c

Re: [Mesa-dev] [PATCH] gallium: add TGSI_SEMANTIC_TEXCOORD, PCOORD v3

On 15.03.2013 22:16, Christoph Bumiller wrote: > This makes it possible to identify gl_TexCoord and gl_PointCoord > for drivers where sprite coordinate replacement is restricted. > > The new PIPE_CAP_TGSI_TEXCOORD decides whether these varyings > should be hidden behind the GENERIC

Re: [Mesa-dev] [PATCH 9/9] tgsi: add ArrayID documentation

On 17.03.2013 18:04, Christoph Bumiller wrote: > On 17.03.2013 16:30, Christian König wrote: >> Am 15.03.2013 18:58, schrieb Christoph Bumiller: >>> On 15.03.2013 13:08, Christian König wrote: >>>> Am 14.03.2013 15:53, schrieb Christoph Bumiller: >>>>&g

Re: [Mesa-dev] [PATCH 9/9] tgsi: add ArrayID documentation

On 17.03.2013 16:30, Christian König wrote: > Am 15.03.2013 18:58, schrieb Christoph Bumiller: >> On 15.03.2013 13:08, Christian König wrote: >>> Am 14.03.2013 15:53, schrieb Christoph Bumiller: >>>> On 14.03.2013 15:20, Christian König wrote: >>>>> Fro

[Mesa-dev] [PATCH] gallium: add TGSI_SEMANTIC_TEXCOORD,PCOORD v3

This makes it possible to identify gl_TexCoord and gl_PointCoord for drivers where sprite coordinate replacement is restricted. The new PIPE_CAP_TGSI_TEXCOORD decides whether these varyings should be hidden behind the GENERIC semantic or not. With this patch only nvc0 and nv30 will request that t

Re: [Mesa-dev] [PATCH 9/9] tgsi: add ArrayID documentation

On 15.03.2013 13:08, Christian König wrote: > Am 14.03.2013 15:53, schrieb Christoph Bumiller: >> On 14.03.2013 15:20, Christian König wrote: >>> From: Christian König >>> >>> Signed-off-by: Christian König >>> --- >>> src/gallium/doc

[Mesa-dev] [PATCH] gallium: add TGSI_SEMANTIC_TEXCOORD, PCOORD (CAP variant)

--- src/gallium/auxiliary/draw/draw_pipe_wide_point.c | 46 +-- src/gallium/auxiliary/tgsi/tgsi_dump.c|1 + src/gallium/auxiliary/tgsi/tgsi_strings.c |4 +- src/gallium/docs/source/cso/rasterizer.rst|5 ++ src/gallium/docs/source/screen.rst

Re: [Mesa-dev] [PATCH 9/9] tgsi: add ArrayID documentation

On 14.03.2013 15:20, Christian König wrote: > From: Christian König > > Signed-off-by: Christian König > --- > src/gallium/docs/source/tgsi.rst | 16 > 1 file changed, 16 insertions(+) > > diff --git a/src/gallium/docs/source/tgsi.rst > b/src/gallium/docs/source/tgsi.rst >

Re: [Mesa-dev] [PATCH] gallium: add TGSI_SEMANTIC_TEXCOORD,PCOORD

On 13.03.2013 21:24, Jose Fonseca wrote: > - Original Message - >> Second attempt, 2 years ago no one replied or cared ... >> >> We really need to know about these on nvc0 because there are only 8 >> fixed hardware locations that can be overwritten by sprite coordinates, >> and one location

[Mesa-dev] [PATCH] gallium: add TGSI_SEMANTIC_TEXCOORD,PCOORD

Second attempt, 2 years ago no one replied or cared ... We really need to know about these on nvc0 because there are only 8 fixed hardware locations that can be overwritten by sprite coordinates, and one location that represents gl_PointCoord and unconditionally returns sprite coordinates. So far

Re: [Mesa-dev] [RFC] Solving the TGSI indirect addressing optimization problem

On 12.03.2013 12:10, Christoph Bumiller wrote: > On 12.03.2013 10:31, Christian König wrote: >> Am 12.03.2013 02:48, schrieb Marek Olšák: >>> On Mon, Mar 11, 2013 at 1:44 PM, Christian König >>> wrote: >>>> Hi everybody, >>>> >>>> t

Re: [Mesa-dev] [RFC] Solving the TGSI indirect addressing optimization problem

On 12.03.2013 10:31, Christian König wrote: > Am 12.03.2013 02:48, schrieb Marek Olšák: >> On Mon, Mar 11, 2013 at 1:44 PM, Christian König >> wrote: >>> Hi everybody, >>> >>> this problem has been open for quite some time now, with a bunch of >>> different >>> opinions and sometimes even patches

Re: [Mesa-dev] [RFC] Solving the TGSI indirect addressing optimization problem

On 11.03.2013 19:33, Brian Paul wrote: > On 03/11/2013 06:44 AM, Christian König wrote: >> Hi everybody, >> >> this problem has been open for quite some time now, with a bunch of >> different >> opinions and sometimes even patches floating on the list. >> >> The solutions proposed or implemented so

Re: [Mesa-dev] [RFC] Solving the TGSI indirect addressing optimization problem

On 11.03.2013 15:38, Christian König wrote: > Am 11.03.2013 14:47, schrieb Christoph Bumiller: >> On 11.03.2013 13:44, Christian König wrote: >>> Hi everybody, >>> >>> this problem has been open for quite some time now, with a bunch of >>> different >

Re: [Mesa-dev] [RFC] Solving the TGSI indirect addressing optimization problem

On 11.03.2013 13:44, Christian König wrote: > Hi everybody, > > this problem has been open for quite some time now, with a bunch of different > opinions and sometimes even patches floating on the list. Nice, finally someone implements a proper solution. However, it seems like this isn't used for ar

Re: [Mesa-dev] [PATCH 1/2] d3d1x: Remove.

On 11.03.2013 11:26, Jose Fonseca wrote: > First email was too long, so re-sending just the interesting bits) Please tell me removing this came to mind because you're going to release a better D3D9,10/11 state tracker :) (Nah I guess it would be too much trouble if there's no users for it ...) Th

Re: [Mesa-dev] [RFC] GLX_MESA_query_renderer

On 02.03.2013 00:14, Ian Romanick wrote: > Since last September I've been gradually working on an extension to > let applications query information about the renderer before (and > after) creating a context. I've talked it over with a few ISVs and > with various other folks. I also gathered some

Re: [Mesa-dev] RFC: enforcing gallium resource bind flags

On 01.03.2013 11:30, Jose Fonseca wrote: > - Original Message - >> On Fri, Mar 1, 2013 at 12:31 AM, Roland Scheidegger >> wrote: >>> Hi, >>> >>> there is some sloppy usage of bind flags in the opengl state tracker >>> (that is, resources get used for things which they didn't have the bind

  1   2   3   4   >