S OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Dave Airlie
+ * Christoph Bu
n
PIPE_SHADER_CAP_MAX_INPUTS/OUTPUTS after all.
Christoph
> (posting to mesa-dev as well)
>
> Marek
>
>
> -Brian
>
>
> On 12/17/2010 05:28 AM, Keith Whitwell wrote:
> > Christoph,
> >
> > This looks good. Thanks for bringing this b
On 12/14/2010 12:36 PM, Keith Whitwell wrote:
> On Mon, 2010-12-13 at 12:01 -0800, Christoph Bumiller wrote:
>> I want to warm this up again adding nvc0 and
>> GL_ARB_separate_shader_objects to the picture.
>>
>> The latter extends GL_EXT_separate_shader_objects to suppo
I want to warm this up again adding nvc0 and
GL_ARB_separate_shader_objects to the picture.
The latter extends GL_EXT_separate_shader_objects to support user
defined varyings and guarantees well defined behaviour only if
- varyings are declared inside the gl_PerVertex/gl_PerFragment block the
bloc
On 04/13/2010 08:07 AM, Luca Barbieri wrote:
> On nv30/nv40 support for patching fragment programs is already
> necessary (constants must be patched in as immediates), and this can
> be handled by just patching the end of the fragment program to include
> a variable number of instructions to copy a
On 13.03.2010 01:10, Xavier Chantry wrote:
> Signed-off-by: Xavier Chantry
> ---
> src/gallium/drivers/nv50/nv50_screen.c |1 -
> src/gallium/drivers/nv50/nv50_screen.h |2 --
> 2 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/nv50/nv50_screen.c
> b/s
On 12.03.2010 15:08, michal wrote:
> Keith Whitwell wrote on 2010-03-12 14:46:
>
>> Michal,
>>
>> Is the intention to have >1 sampler view active in the Mesa state
>> tracker, specifically in the cases where min_lod varies?
>>
>> In other words, you seem to have two ways of specifying the same s
Sorry, forgot to reply-all ...
Original Message
Subject:Re: [Mesa3d-dev] Gallium questions ...
Date: Thu, 11 Mar 2010 18:29:10 +0100
From: Christoph Bumiller
To: Jerome Glisse
On 11.03.2010 18:13, Jerome Glisse wrote:
> Hi all,
>
> I have been a l
On 25.02.2010 19:00, Brian Paul wrote:
> Roland Scheidegger wrote:
>
>> On 25.02.2010 18:39, michal wrote:
>>
>>> Roland Scheidegger wrote on 2010-02-24 15:18:
>>>
>>>> On 24.02.2010 12:48, Christoph Bumiller wrote:
>>>>
This wasn't a problem before because textures and samplers were
linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch,
this coordinate normalization bit becomes a problem.
NV50 hardware has that bit in the RESOURCE binding, and not the
SAMPLER binding, and you can imagine that this wi
On 02/11/2010 10:10 PM, Roland Scheidegger wrote:
> On 11.02.2010 21:42, Christoph Bumiller wrote:
>> On 02/11/2010 09:02 PM, Roland Scheidegger wrote:
>>> Hi,
>>>
>>> could one of the nouveau developers please take a look at the nv30
>>> changes
On 02/11/2010 09:02 PM, Roland Scheidegger wrote:
> Hi,
>
> could one of the nouveau developers please take a look at the nv30
> changes I did for the stencil ref changes in gallium-dynamicstencilref
> branch?
> I've just done that in a way I think it might make sense, but I've
> absolutely no ide
On 02/06/2010 05:05 PM, Christoph Bumiller wrote:
> On 02/05/2010 11:01 AM, Keith Whitwell wrote:
>> We've had a couple of cleanups that we've wanted to do in gallium for
>> as long as I can remember. One of which is to remove all the random
>> context-creatio
mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>From 4aea3df06bb7d366bea76b7173c19419f0d20630 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Sat, 6 Feb 2010 17:03:43 +0100
Subject: [PATCH] nouveau: fix gallium-screen-c
On 01.02.2010 21:44, Brian Paul wrote:
> Christoph Bumiller wrote:
>> I just noticed that alienarena fails to create an FBO for depth
>> rendering
>> because on st_validate_framebuffer, the depth attachment contains a pt
>> in the stObj with format XR8G8B8_UNORM,
On 01.02.2010 18:37, Roland Scheidegger wrote:
> On 31.01.2010 18:41, Christoph Bumiller wrote:
>
>> On 31.01.2010 01:37, Roland Scheidegger wrote:
>>
>>> Marek Olšák wrote:
>>>
>>>
>>>> 6) GL_ARB_shadow_ambient a
any
apps will use two sided lighting nowadays I suppose.
>
> From: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca
> Barbieri [l...@luca-barbieri.com]
> Sent: Monday, February 01, 2010 7:29 AM
> To: Christoph Bumiller
> Cc: Keith Whitwell;
I just noticed that alienarena fails to create an FBO for depth rendering
because on st_validate_framebuffer, the depth attachment contains a pt
in the stObj with format XR8G8B8_UNORM, which nv50 (contrary to sp)
reports as not supported in screen->is_format_supported if usage is ZS.
This happens
On 01.02.2010 15:32, Luca Barbieri wrote:
> An overview of the possible options.
> Let's call vertex shader outputs "v" and fragment shader inputs "f"
> Let v -> f mean that v connects to f.
> NUM_INTERPOLATORS is the number of available interpolators. It is
> usually between 8 and 32.
>
> 1. Curre
On 31.01.2010 01:37, Roland Scheidegger wrote:
> Marek Olšák wrote:
>
>> 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in
>> the fragment constants reads, "Since Gallium doesn't support
>> GL_ARB_shadow_ambient, this is always (0,0,0,0), right?"
>>
>> I think th
On 26.01.2010 18:16, Keith Whitwell wrote:
> On Tue, 2010-01-26 at 09:05 -0800, Christoph Bumiller wrote:
>
>> On 26.01.2010 17:03, Roland Scheidegger wrote:
>>
>>> Oh, I should have added the PIPE_CAP bits (even if not supported) to all
>>> drivers. Go
On 26.01.2010 17:03, Roland Scheidegger wrote:
> Oh, I should have added the PIPE_CAP bits (even if not supported) to all
> drivers. Good catch. I'll do that for the other drivers now.
>
>
Ohhh sorry, I wanted to push the nv50 support for separate blend
to the perrtblend branch and accidentally
On 26.01.2010 12:11, Keith Whitwell wrote:
> Luca,
>
> I would have expected fragment coord conventions to be device state, not
> a part of the shader.
>
>
In OpenGL you specify the convention in the shader source,
e.g. with "layout(...) in vec4 gl_FragCoord", so they _are_ part
of the shader; I
On 22.01.2010 18:12, Christoph Bumiller wrote:
> On 22.01.2010 17:41, Keith Whitwell wrote:
>
>> Christoph,
>>
>> The vertex usage issue is a bug and can be fixed.
>>
>>
>>
> Oh ... I thought it was intentional, and relied on it to decide w
using buffer memory for you (userspace
> sub-allocation), so the weight of the ttm calls you are making may be less
> than you suspect.
>
> Keith
> ____
> From: Christoph Bumiller [e0425...@student.tuwien.ac.at]
> Sent: Friday, January 22, 2010 8:
reate function literally and
ask TTM to create a new buffer object every time it's called ... I admit
that
this whole thing is a pipe driver specific issue.
> Keith
> ____
> From: Christoph Bumiller [e0425...@student.tuwien.ac.at]
> Sent: T
On 21.01.2010 20:20, michal wrote:
> Hi,
>
> This simple feature branch adds support for two-dimensional constant
> buffers in TGSI.
>
> An example shader would look like this:
>
> FRAG
>
> DCL IN[0], COLOR, LINEAR
> DCL OUT[0], COLOR
> DCL CONST[1][1..2]
>
> MAD OUT[0], IN[0], CONST[1][2], CONST[
On 21.01.2010 22:08, Brian Paul wrote:
> GL3/GL_ARB_uniform_buffer allows querying per shader stage. But I'd
> be OK with just returning the minimum until we find good reason to do
> otherwise.
>
> -Brian
>
>
Isn't the minimum number 1 ?
It certainly is not PIPE_MAX_CONSTANT (32).
> Keith Whi
On 21.01.2010 21:28, Roland Scheidegger wrote:
> On 21.01.2010 20:20, michal wrote:
>
>> Hi,
>>
>> This simple feature branch adds support for two-dimensional constant
>> buffers in TGSI.
>>
>> An example shader would look like this:
>>
>> FRAG
>>
>> DCL IN[0], COLOR, LINEAR
>> DCL OUT[0], COLO
On 01/20/10 16:21, Brian Paul wrote:
> Luca Barbieri wrote:
>> Investigating a vertical flipping problem in Doom 3, I discovered that
>> fragment shader wpos handling is incorrect in the nv40 driver.
>>
>> The issue is that nv40 provides a "position" register with OpenGL
>> semantics, so if TGSI_SE
On 15.01.2010 09:52, Michel Dänzer wrote:
> On Fri, 2010-01-15 at 16:32 +0800, Chia-I Wu wrote:
>
>> 2010/1/15 Michel Dänzer :
>>
>>> On Fri, 2010-01-15 at 10:48 +0800, Chia-I Wu wrote:
>>>
On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz
wrote:
> Som
On 01/07/2010 12:50 PM, José Fonseca wrote:
> On Wed, 2010-01-06 at 15:56 -0800, Zack Rusin wrote:
>> On Wednesday 06 January 2010 14:56:35 Igor Oliveira wrote:
>>> Hi,
>>>
>>> the patches add support to double opcodes in gallium/tgsi.
>>> It just implement some opcodes i like to know if someone ha
On 06.01.2010 08:36, michal wrote:
> michal wrote on 2010-01-06 07:58:
>> michal wrote on 2009-12-22 10:00:
>>
>>> Marek Olšák wrote on 2009-12-22 08:40:
>>>
Hi,
I noticed that gallium/auxiliary/util/u_format.csv contains some
weird swizzling, for example see this:
On 01.01.2010 00:57, Brian Paul wrote:
> The BY_REGION modes indicate that it's OK for the GPU to discard the
> fragments in the region(s) which failed the occlusion test (perhaps
> skipping other per-fragment ops that would have otherwise occurred).
> See the spec at
> http://www.opengl.org/regist
On 31.12.2009 15:55, Keith Whitwell wrote:
> On Thu, 2009-12-31 at 05:28 -0800, Christoph Bumiller wrote:
>
>> On 31.12.2009 12:05, Keith Whitwell wrote:
>>
>>> Luca,
>>>
>>> This is an impressive body of work. I want to give Jose a chanc
On 31.12.2009 12:05, Keith Whitwell wrote:
> Luca,
>
> This is an impressive body of work. I want to give Jose a chance to
> review the EGL/GLX extensions before pushing, but in the meantime I hope
> it's ok if I make a couple of quick suggestions/requests:
>
> Firstly, we're going to be evolving
In case no one noticed, since this patch
(22370990f28987b361c6adf8e81c5a18184e88ea)
invalid tokens are generated for some shaders, probably everything
that involes indirect register access.
I can't think of any official test program right now, and I don't
particularly like to dig into that part of
might plug a cube in there and expect it
to work) and the texture is clamped to the first face.
Something like the attached patch would fix it, make demos/cube
look correct.
Christoph
>From 70cf7eef14068c00bf6c34accf5b76695012dc2b Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Mon, 2
Hi,
I'd expect util_format_get_blocksize to return the
size in bytes needed to store a whole block, not just
a pixel.
In case of DXT1, you get 4 bits per pixel, and trigger
the assertion that bpp must be a multiple of 8.
Christoph
diff --git a/src/gallium/auxiliary/util/u_format.h
b/src/gallium/a
being drawn* is
quirky.
I realize < nv50 don't follow the convention for quads (at least that's
what the spec says), so I'm outnumbered, but I don't see the harm in
following what OpenGL does here, i.e. just have the query.
>
> On Fri, Dec 18, 2009 at
Marek Olšák schrieb:
> Hi,
>
> GL_ARB_provoking_vertex states that quads are not required to abide
> the provoking vertex convention, and the actual hardware and/or driver
> behavior can be queried with
> GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION.
>
> I'd like to add a new PIPE_CAP_* to query f
José Fonseca schrieb:
> On Tue, 2009-12-08 at 09:00 -0800, Christoph Bumiller wrote:
>> michal schrieb:
>>> This branch simplifies pipe/p_format.h by making enum pipe_format what
>>> it should have been -- an enum.
>>>
>>> ...
>>>
>>
michal schrieb:
> Christoph Bumiller pisze:
>> michal schrieb:
>>
>>> This branch simplifies pipe/p_format.h by making enum pipe_format
>>> what it should have been -- an enum.
>>>
>>> ...
>>>
>>> I would like to hear from
michal schrieb:
> This branch simplifies pipe/p_format.h by making enum pipe_format what
> it should have been -- an enum.
>
> ...
>
> I would like to hear from r300 and nouveau guys, as those drivers were
> using some internal macros and I weren't 100% sure I got the conversion
> right.
>
Hi
Roland Scheidegger schrieb:
> Hi,
>
> I'm planning to merge gallium-noblocks branch to master soon. This api
> change may affect your driver, statetracker, whatever. I _should_ have
> fixed up all in tree stuff using it, but that's not a guarantee it will
> still run correctly (nv50 driver was str
tom fogal schrieb:
> Christoph Bumiller writes:
>
>> Hi. Now that there's util_bitcount in u_math, I'd like to have a
>> bswap helper as well,
>> I need to swap the stipple pattern on nv50. Any objections ?
>>
> [snip]
>
Hi. Now that there's util_bitcount in u_math, I'd like to have a bswap
helper as well,
I need to swap the stipple pattern on nv50. Any objections ?
Christoph
>From c5cd44843e45b37fac4aef1ebc494ab12ccfe54d Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Thu, 26 Nov 2009 1
Hi, I just noticed I get the stipple pattern in gallium in a wrong
byte ordering (as if they were 32 bit buggy endian words).
Is there a good reason why we mess up the bitmap ? If so I'll just
byte swap again in the pipe driver, but, I just thought normally you
wouldn't expect that you'd have to do
Corbin Simpson schrieb:
> URL:
> http://cgit.freedesktop.org/~csimpson/mesa/log/?h=gallium-blitter
>
> So, with r600g right around the corner, I'd like to do something about
> this blitter/no blitter thing.
>
> This patch series contains one new getparam, PIPE_CAP_BLITTER, and a
> proposed ABI chan
Keith Whitwell schrieb:
> On Fri, 2009-09-25 at 02:02 -0700, Christoph Bumiller wrote:
>> Module: Mesa
>> Branch: master
>> Commit: 513cadf5afad18516f7299ade246f59d520753d0
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=513cadf5afad18516f72
Zitat von Michel Dänzer :
> On Tue, 2009-07-28 at 16:47 -0700, Ben Skeggs wrote:
>> Module: Mesa
>> Branch: master
>> Commit: d1b9183e64e819d389688074c3db338bd0d2d80e
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=d1b9183e64e819d389688074c3db338
Michel Dänzer schrieb:
> On Tue, 2009-07-28 at 16:47 -0700, Ben Skeggs wrote:
>> Module: Mesa
>> Branch: master
>> Commit: d1b9183e64e819d389688074c3db338bd0d2d80e
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=d1b9183e64e819d389688074c3db338
52 matches
Mail list logo
