Re: [Mesa3d-dev] regression in r600g with a22aba4eae9b29db731487bce90e8292f7e82c72

[Marek Olšák]

On Sun, Apr 24, 2011 at 1:15 AM, Dave Airlie  wrote:

> Hi Brian,
>
> st/mesa: check image size before copy_image_data_to_texture()
>
> This causes a regression with NPOT textures in fbo-generate-mipmaps on
> r600g.
>

FWIW r300g and softpipe are broken too. The issue seems to be
driver-independent.

Marek
--
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been 
demonstrated beyond question. Learn why your peers are replacing JEE 
containers with lightweight application servers - and what you can gain 
from the move. http://p.sf.net/sfu/vmware-sfemails___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [Mesa-dev] [PATCH 0/6] ARB_texture_float

[Marek Olšák]

There won't be any other way. It should be the Linux distributors' decision
whether their users can use it or not.

Marek

On Fri, Apr 1, 2011 at 5:14 PM, Philipp Klaus Krause  wrote:

> Am 01.04.2011 15:56, schrieb Marek Olšák:
> > Hi,
> >
> > please read on.
> >
> > This patch series adds the last pieces of ARB_texture_float support
> > to Mesa and Gallium.
> >
> > The thing is Mesa and Gallium more or less already support float
> > textures and renderbuffers in master. Gallium has full floating-point
> > support in the interface and if it was a public API, people could
> > just expose it and not care. There is clearly a need for a configure
> > switch which can hide float renderbuffers from any interface, public
> > or private, and driver developers should use such a switch.
>
> Would there be a way to make this switch easier to flip by the user? As
> you state it this looks like a lot of work to users that want to have it
> enabled, at least when compared to the effort to get S3TC support.
>
> Philipp
>
--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH 0/6] [RFC] Formalization of the Gallium shader semantics linkage model

[Marek Olšák]

On Fri, Dec 17, 2010 at 4:32 PM, Brian Paul  wrote:

> Christoph,
>
> I don't see a patch for the st/mesa program translation code to check
> that we don't exceed the limit.  Were you doing to take care of that too?
>
> I guess we're assuming that the max number of generic inputs == max
> number of generic outputs.  I think that's OK until a counter case
> appears.
>

The way I understand it is that the max number of generic outputs is equal
to the max number of generic inputs in the next shader stage (the same logic
applies to some other shader caps too). I guess we need to use get_param to
determine which shader stages are supported by the driver to know which one
is next. The name *PIPE_SHADER_CAP_MAX_GENERIC_INPUT_INDEX* would be less
ambiguous (still not perfect though).

However I don't believe in usefulness of this new cap, at least not without
some serious state tracker work. I don't consider failing to translate a
shader if some CAP is too low particularly useful.

(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 back to life.
> >
> > Keith
> >
> > On Thu, 2010-12-16 at 07:47 -0800, Christoph Bumiller wrote:
> >> 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 support user
>  defined varyings and guarantees well defined behaviour only if
>  - varyings are declared inside the gl_PerVertex/gl_PerFragment block
> the
>  blocks match exactly in name, type, qualification, and (most
>  significantly) declaration order.
>  - varyings are assigned matching location qualifiers:
>  like: layout(location = 3) in vec4 normal
>  "The number of input locations available to a shader is limited."
> 
>  So, I propose to (loosely) identify GENERIC semantic indices with
> these
>  location qualifiers and let the pipe driver set a limit on the allowed
>  maximum (e.g PIPE_SHADER_CAP_MAX_INPUTS, and not demand to at least
>  support 219 of them - nvc0 offsers 0x200 bytes for generic
> inputs/outputs).
> >>>
> >>> This sounds fine actually.  We kicked this around before&  I was
> >>> basically ok with the last iteration of the proposal, but this seems ok
> >>> too.
> >>>
> >>> As far as I can tell from a gallium perspective you're really just
> >>> proposing a new pipe cap _MAX_INPUTS (actually _MAX_GENERIC_INDEX would
> >>> be clearer), which the state tracker thereafter has to respect?
> >>>
> >>> That would be fine with me.
> >> First attempt at a patch introducing such a cap attached.
> >>
> >>>
>  My motivation is mostly that the hardware routing table for shader
>  varyings that was present on nv50 has been removed with nvc0 (Fermi).
>  And I'm glad, because filling 4 routing tables (since we have 5 shader
>  types now) is somewhat annoying. And so applying relocations to
> shaders
>  - it can be done, it's probably not too time consuming, but it's just
>  plain *unnecessary* (and thus stupid) for OpenGL.
> 
>  Now about d3d9 ...
>  1. don't care, I don't see a d3d9 state tracker
>  2. http://msdn.microsoft.com/en-us/library/bb509647%28v=VS.85%29.aspx
>  says "n is an optional integer between 0 and the number of resources
>  supported" - what "supported" means here isn't clear to me, but, I
>  didn't find any example where someone used something OpenGL doesn't
> have
>  (like COLOR2).
>  3.
> 
> http://msdn.microsoft.com/en-us/library/bb944006%28v=vs.85%29.aspx#Varying_Shader_Inputs_and_Semantics
>  says "Input semantics are similar to the values in the D3DDECLUSAGE."
>  and
>  DECLUSAGE sounds like you're limited to sane values.
> >>>
> >>> I think you're on the right track with (1)...  It's fairly pointless
> >>> trying to discuss code here which isn't public&  I don't think people
> >>> need to be worrying about what may or may not be important for code
> they
> >>> can't see.
> >>>
> >>> I know this idea previously got tied up with speculation about what a
> >>> DX9 state tracker might or might not require, but in retrospect I wish
> >>> I'd been able to steer conversation away from that.
> >>>
> >>> The work on closed components may drive a lot of the feature
> development
> >>> and new interfaces, but there's usually enough flexibility that this
> >>> sort of cleanup isn't a big deal.
> >>>
> >>>
> >>> Keith
> >>>
>  Not sure if anyone wants to think about this issue at this time (since
>  implementation of ARB_separate_shader_objects is probably far in the
> GL4
>  future), but I'd be happy about any comments.
> 
>  Regards,
>  Christoph
> 
>  On 04/13/2010 12:55 PM, Luca Barbieri wrote:
> > This patc

Re: [Mesa3d-dev] RFC: allow resource_copy_region between different (yet compatabile) formats

[Marek Olšák]

On Mon, Sep 6, 2010 at 9:57 PM, José Fonseca  wrote:

> On Mon, 2010-09-06 at 10:22 -0700, Marek Olšák wrote:
> > On Mon, Sep 6, 2010 at 3:57 PM, José Fonseca 
> > wrote:
> > I'd like to know if there's any objection to change the
> > resource_copy_region semantics to allow copies between
> > different yet
> > compatible formats, where the definition of compatible formats
> > is:
> >
> >  "formats for which copying the bytes from the source resource
> > unmodified to the destination resource will achieve the same
> > effect of a
> > textured quad blitter"
> >
> > There is an helper function util_is_format_compatible() to
> > help making
> > this decision, and these are the non-trivial conversions that
> > this
> > function currently recognizes, (which was produced by
> > u_format_compatible_test.c):
> >
> >  b8g8r8a8_unorm -> b8g8r8x8_unorm
> >
> > This specific case (and others) might not work, because there are no
> > 0/1 swizzles when blending pixels with the framebuffer, e.g. see this
> > sequence of operations:
> > - Blit from b8g8r8a8 to b8g8r8x8.
> > - x8 now contains a8.
> > - Bind b8g8r8x8 as a colorbuffer.
> > - Use blending with the destination alpha channel.
> > - The original a8 is read instead of 1 (x8) because of lack of
> > swizzles.
>
> This is not correct. Or at least not my interpretation.
>
> The x in b8g8r8x8 means padding (potentially with with unitialized
> data). There is no implicit guarantee that it will contain 0xff or
> anything.
>
> When blending to b8g8r8x8, destination alpha is by definition 1.0. It is
> an implicit swizzle (see e.g., u_format.csv).
>
> If the hardware's fixed function blending doesn't understand bgrx
> formats natively, then the pipe driver should internally replace the
> destination alpha factor factor with one. It's really simple. See for
>

The dst blending parameter is just a factor the real dst value is multiplied
by (except for min/max). There is no way to multiply an arbitrary value by a
constant and get 1.0. But you can force 0, of course. I don't think there is
hardware which supports such flexible swizzling in the blender. If x8 is
just padding as you say, the value of it should be undefined and every
operation using the padding bits should be undefined too except for texture
sampling. It's not like I have any other choice.

Marek
--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] RFC: allow resource_copy_region between different (yet compatabile) formats

[Marek Olšák]

On Mon, Sep 6, 2010 at 3:57 PM, José Fonseca  wrote:

> I'd like to know if there's any objection to change the
> resource_copy_region semantics to allow copies between different yet
> compatible formats, where the definition of compatible formats is:
>
>  "formats for which copying the bytes from the source resource
> unmodified to the destination resource will achieve the same effect of a
> textured quad blitter"
>
> There is an helper function util_is_format_compatible() to help making
> this decision, and these are the non-trivial conversions that this
> function currently recognizes, (which was produced by
> u_format_compatible_test.c):
>
>  b8g8r8a8_unorm -> b8g8r8x8_unorm
>

This specific case (and others) might not work, because there are no 0/1
swizzles when blending pixels with the framebuffer, e.g. see this sequence
of operations:
- Blit from b8g8r8a8 to b8g8r8x8.
- x8 now contains a8.
- Bind b8g8r8x8 as a colorbuffer.
- Use blending with the destination alpha channel.
- The original a8 is read instead of 1 (x8) because of lack of swizzles.

The blitter and other util functions just need to be extended to explicitly
write 1 instead of copying the alpha channel. Something likes this is
already done in st/mesa, see the function compatible_src_dst_formats.

Marek

 a8r8g8b8_unorm -> x8r8g8b8_unorm
>  b5g5r5a1_unorm -> b5g5r5x1_unorm
>  b4g4r4a4_unorm -> b4g4r4x4_unorm
>  l8_unorm -> r8_unorm
>  i8_unorm -> l8_unorm
>  i8_unorm -> a8_unorm
>  i8_unorm -> r8_unorm
>  l16_unorm -> r16_unorm
>  z24_unorm_s8_uscaled -> z24x8_unorm
>  s8_uscaled_z24_unorm -> x8z24_unorm
>  r8g8b8a8_unorm -> r8g8b8x8_unorm
>  a8b8g8r8_srgb -> x8b8g8r8_srgb
>  b8g8r8a8_srgb -> b8g8r8x8_srgb
>  a8r8g8b8_srgb -> x8r8g8b8_srgb
>  a8b8g8r8_unorm -> x8b8g8r8_unorm
>  r10g10b10a2_uscaled -> r10g10b10x2_uscaled
>  r10sg10sb10sa2u_norm -> r10g10b10x2_snorm
>
> Note that format compatibility is not commutative.
>
> For software drivers this means that memcpy/util_copy_rect() will
> achieve the correct result.
>
> For hardware drivers this means that a VRAM->VRAM 2D blit engine will
> also achieve the correct result.
>
> So I'd expect no implementation change of resource_copy_region() for any
> driver AFAICT. But I'd like to be sure.
>
> Jose
>
>
>
> --
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>
--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] _mesa_init_texture_s3tc() vs util_format_s3tc_init()

[Marek Olšák]

On Mon, May 3, 2010 at 1:57 PM, José Fonseca  wrote:

> On Mon, 2010-05-03 at 01:36 -0700, Xavier Chantry wrote:
> > I am trying to understand the s3tc init code as nv50 gallium has a
> > problem with that.
> >
> > It looks like some drivers (r300g and llvmpipe) actually inits s3tc in
> > two places :
> > ./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc()
> > ./src/gallium/auxiliary/util/u_format_s3tc.c util_format_s3tc_init()
> >
> > Here is an extract of the backtrace calls while loading fgfs on llvmpipe
> :
> > driCreateScreen -> llvmpipe_create_screen -> util_format_s3tc_init
> > driCreateContext -> st_create_context -> _mesa_create_context_for_api
> > -> init_attrib_groups -> _mesa_init_texture_s3tc
> >
> > These two functions seem to do more or less the same job, and
> > apparently, the classic mesa init is unused for a gallium driver.
> > So I suppose that init is not necessary, but it happens because
> > gallium and mesa are tightly tied together, and create context is
> > handled similarly, but it shouldn't hurt ?
>
> Both inits are necessary. The same .so is used for both paths, but given
> that gallium and mesa do not depend on each other that's the way to do
> it. Gallium and mesa also have seperate format translation functions.
>
> At least until we start factoring code into a separate library. (I said
> I'd do it, but stuff came up and I couldn't do when I thought, and I
> don't know when I'll be able to do it...)
>
> > Additionally r300g and llvmpipe added util_format_s3tc_init to their
> > create_screen functions, and util/u_format_s3tc.c apparently contains
> > all the functions that a gallium driver uses.
> > So I suppose that nvfx and nv50 should do the same ?
> >
> > If that's correct, the patch below might not be completely wrong.
> >
> > On Mon, May 3, 2010 at 12:44 AM, Xavier Chantry
> >  wrote:
> > > flightgear now dies with :
> > > Mesa warning: external dxt library not available: texstore_rgba_dxt3
> > > util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: Assertion `0'
> failed.
> > >
> > > I don't really understand what these stubs are about, they were
> > > introduced by following commit :
> > > commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13
> > > Author: José Fonseca 
> > > Date:   Wed Apr 7 20:47:38 2010 +0100
> > >
> > >util: Use stubs for the dynamically loaded S3TC functions.
> > >
> > >Loosely based on Luca Barbieri's commit
> > >52e9b990a192a9329006d5f7dd2ac222effea5a5.
> > >
> > > Looking at llvm and r300 code and trying to guess, I came up with the
> > > following patch that allows flightgear to start again. But I don't
> > > really understand that stuff so it could be wrong.
> > > nvfx is probably affected as well.
> > >
> > >
> > > diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c
> > > b/src/gallium/drivers/nouveau/nouveau_screen.c
> > > index 233a91a..a91b00b 100644
> > > --- a/src/gallium/drivers/nouveau/nouveau_screen.c
> > > +++ b/src/gallium/drivers/nouveau/nouveau_screen.c
> > > @@ -5,6 +5,7 @@
> > >  #include "util/u_memory.h"
> > >  #include "util/u_inlines.h"
> > >  #include "util/u_format.h"
> > > +#include "util/u_format_s3tc.h"
> > >
> > >  #include 
> > >  #include 
> > > @@ -248,6 +249,8 @@ nouveau_screen_init(struct nouveau_screen *screen,
> > > struct nouveau_device *dev)
> > >pscreen->fence_signalled = nouveau_screen_fence_signalled;
> > >pscreen->fence_finish = nouveau_screen_fence_finish;
> > >
> > > +   util_format_s3tc_init();
> > > +
> > >return 0;
> > >  }
> > >
> > > diff --git a/src/gallium/drivers/nv50/nv50_screen.c
> > > b/src/gallium/drivers/nv50/nv50_screen.c
> > > index 2dd1042..0d74c90 100644
> > > --- a/src/gallium/drivers/nv50/nv50_screen.c
> > > +++ b/src/gallium/drivers/nv50/nv50_screen.c
> > > @@ -20,6 +20,7 @@
> > >  * SOFTWARE.
> > >  */
> > >
> > > +#include "util/u_format_s3tc.h"
> > >  #include "pipe/p_screen.h"
> > >
> > >  #include "nv50_context.h"
> > > @@ -72,10 +73,6 @@ nv50_screen_is_format_supported(struct pipe_screen
> *pscreen,
> > >case PIPE_FORMAT_A8_UNORM:
> > >case PIPE_FORMAT_I8_UNORM:
> > >case PIPE_FORMAT_L8A8_UNORM:
> > > -   case PIPE_FORMAT_DXT1_RGB:
> > > -   case PIPE_FORMAT_DXT1_RGBA:
> > > -   case PIPE_FORMAT_DXT3_RGBA:
> > > -   case PIPE_FORMAT_DXT5_RGBA:
> > >case PIPE_FORMAT_S8_USCALED_Z24_UNORM:
> > >case PIPE_FORMAT_Z24_UNORM_S8_USCALED:
> > >case PIPE_FORMAT_Z32_FLOAT:
> > > @@ -85,6 +82,11 @@ nv50_screen_is_format_supported(struct pipe_screen
> *pscreen,
> > >case PIPE_FORMAT_R16G16_SNORM:
> > >case PIPE_FORMAT_R16G16_UNORM:
> > >return TRUE;
> > > +   case PIPE_FORMAT_DXT1_RGB:
> > > +   case PIPE_FORMAT_DXT1_RGBA:
> > > +   case PIPE_FORMAT_DXT3_RGBA:
> > > +   case PIPE_FORMAT_DXT5_RGB

Re: [Mesa3d-dev] mesa commit e648d4a1d1c0c5f70916e38366b863f0bec79a62 st/mesa: ignore gl_texture_object::BaseLevel when allocating gallium textures

[Marek Olšák]

On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky wrote:

> This commit breaks compiz completely here on nvidia G50 (Geforce 8400M)
> Compiz shows dark screen.
> (Using nouveau drivers)
>
> Without this commit compiz works almost perfectly.
>
> The error messages from compiz:
>
>
> debug_get_bool_option: NV50_ALWAYS_PUSH = FALSE
> debug_get_bool_option: DRAW_FSE = FALSE
> debug_get_bool_option: DRAW_NO_FSE = FALSE
> debug_get_bool_option: GALLIUM_DUMP_VS = FALSE
> Mesa: Mesa 7.9-devel DEBUG build May  1 2010 19:02:06
> Mesa warning: software DXTn compression/decompression available
> debug_get_bool_option: MESA_MVP_DP4 = FALSE
> debug_get_flags_option: ST_DEBUG = 0x0
> Mesa: User error: GL_OUT_OF_MEMORY in glTexImage
> compiz (cube) - Warn: Failed to load
> slide: /usr/share/gdm/themes/Human/ubuntu.png
> ^CMesa: User error: GL_OUT_OF_MEMORY in glTexImage
>

The commit also causes surface_copy to be called with S3TC textures,
breaking loading of such textures in r300g. I am working on a fix for r300g
but I haven't expected to get such weird formats in surface_copy.

FYI Maxim, please use mesa-...@lists.freedesktop.org instead.

-Marek
--
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] gallium-resources branch merge

[Marek Olšák]

On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell  wrote:

> OK, it seems like quite a few cases had migrated to the new
> buffer_map_range() behaviour.  I've looked at all I can find and moved
> them back to the old behaviour.
>
> glean is passing now on softpipe.
>

There's now an assertion failure in pipe_buffer_flush_mapped_range. Given a
mapped range, the current behavior in debug build doesn't allow to flush its
subrange if it doesn't touch the last byte of the range. The attached patch
fixes that and changes u_uploadmgr for the mapped and flushed ranges to
match. Please review.

Other than that, it's stable as master. Thank you very much.

-Marek
From d351a37e320dcb027c43311dc620d44fdffa0a6d Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Sat, 3 Apr 2010 07:58:34 +0200
Subject: [PATCH] util: fix assertion failures in pipe_buffer_flush_mapped_range

---
 src/gallium/auxiliary/util/u_inlines.h|2 +-
 src/gallium/auxiliary/util/u_upload_mgr.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_inlines.h b/src/gallium/auxiliary/util/u_inlines.h
index b1f2285..f9cd4e1 100644
--- a/src/gallium/auxiliary/util/u_inlines.h
+++ b/src/gallium/auxiliary/util/u_inlines.h
@@ -223,7 +223,7 @@ pipe_buffer_flush_mapped_range(struct pipe_context *pipe,
 
assert(length);
assert(transfer->box.x <= offset);
-   assert(transfer->box.x + transfer->box.width <= offset + length);
+   assert(offset + length <= transfer->box.x + transfer->box.width);
 
/* Match old screen->buffer_flush_mapped_range() behaviour, where
 * offset parameter is relative to the start of the buffer, not the
diff --git a/src/gallium/auxiliary/util/u_upload_mgr.c b/src/gallium/auxiliary/util/u_upload_mgr.c
index f8c3954..75d4443 100644
--- a/src/gallium/auxiliary/util/u_upload_mgr.c
+++ b/src/gallium/auxiliary/util/u_upload_mgr.c
@@ -95,7 +95,7 @@ my_buffer_write(struct pipe_context *pipe,
assert(dirty_size >= size);
assert(size);
 
-   map = pipe_buffer_map_range(pipe, buf, offset, size, 
+   map = pipe_buffer_map_range(pipe, buf, offset, dirty_size,
PIPE_TRANSFER_WRITE |
PIPE_TRANSFER_FLUSH_EXPLICIT |
PIPE_TRANSFER_DISCARD |
-- 
1.6.3.3

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] gallium-resources branch merge

[Marek Olšák]

On Wed, Apr 7, 2010 at 7:01 PM, Keith Whitwell  wrote:

> On Tue, 2010-04-06 at 03:28 -0700, Keith Whitwell wrote:
> > On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote:
> > > There's something fishy in u_upload_mgr, could you please review the
> > > first two patches here?
> > > http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources<http://cgit.freedesktop.org/%7Emareko/mesa/log/?h=gallium-resources>
> > >
> > > With this, r300g works again.
> >
> > Hmm, I think the second of the patches (flush range relative to mapped
> > range vs whole buffer) may be addressing a regression that has creeped
> > into the -resources branch regarding this behaviour - ie. I think the
> > code you modified was actually correct, but that
> > pipe_flush_mapped_buffer_range() has changed to do the wrong thing.
> >
> > I'll try and figure out what should be happening.
>
> I've pushed a change which hopefully corrects the behaviour of the
> buffer_range inlines.  Can you give it a try?
>

Now glean/bufferObject fails on softpipe and r300g. I haven't tested other
drivers.

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] Gallium: EXT_gpu_program_parameters

[Marek Olšák]

Hi devs,

this extensions is extensively used in Wine for obvious performance reasons
and is quite popular in the GL community, therefore we should advertise it.
All needed code seems to be already in mesa/main, so unless I overlooked
something, the patch below is sufficient. Any comments, please?

-Marek

diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 0118c60..ae5e62b 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -183,6 +183,7 @@ void st_init_extensions(struct st_context *st)
ctx->Extensions.EXT_framebuffer_object = GL_TRUE;
ctx->Extensions.EXT_framebuffer_multisample = GL_TRUE;
ctx->Extensions.EXT_fog_coord = GL_TRUE;
+   ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE;
ctx->Extensions.EXT_multi_draw_arrays = GL_TRUE;
ctx->Extensions.EXT_pixel_buffer_object = GL_TRUE;
ctx->Extensions.EXT_point_parameters = GL_TRUE;
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Gallium: ARB_half_float_vertex

[Marek Olšák]

On Sun, Apr 4, 2010 at 10:28 PM, Luca Barbieri wrote:

> > Does it mean there will be format fallbacks? Because dword-unaligned but
> > still pretty common (i.e. GL1.1) vertex formats aren't supported by r300,
> > most often we hit R16G16B16. What will happen when is_format_supported
> says
> > NO to such a format? I hope it won't share the fate of PIPE_CAP_SM3,
> which
> > every in-tree state tracker ignores.
>
> I'm not sure I understand correctly what you are saying.
>
> The idea is to do like you did in your patch, but instead of calling
> screen->get_param(screen, PIPE_CAP_HALF_FLOAT_VERTEX), calling
> screen->is_format_supported(screen, PIPE_FORMAT_R16G16B16G16,
> PIPE_BUFFER, ..., ...).
>
> The PIPE_BUFFER target is supported in gallium-resources, but I'm not
> sure whether this way of querying vertex formats is supported; it
> would probably need to be added first.
>
> If you mean that r300 doesn't support R16G16B16, I suppose you can
> just use R16G16B16A16 and ignore the extra fetched w element (the
> vertex buffer stride will make this work properly).
>

I've tried to do it this way, it locks up (unless I am missing something).

However, if non-dword-aligned vertex buffer strides or vertex element
> offsets are not supported, I think you have a serious problem, which
> is however independent of half float vertices since I don't think
> OpenGL places any alignment constraints on those values (correct me if
> I'm wrong).
>

You're right.

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Gallium: ARB_half_float_vertex

[Marek Olšák]

On Sun, Apr 4, 2010 at 9:41 PM, Luca Barbieri wrote:

> There was some talk about doing the query with a vertex buffer target
> for is_format_supported.
>

Does it mean there will be format fallbacks? Because dword-unaligned but
still pretty common (i.e. GL1.1) vertex formats aren't supported by r300,
most often we hit R16G16B16. What will happen when is_format_supported says
NO to such a format? I hope it won't share the fate of PIPE_CAP_SM3, which
every in-tree state tracker ignores.

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] Gallium: ARB_half_float_vertex

[Marek Olšák]

Hi devs,

I (and Luca mostly) have made some simple patches which add
GL_ARB_half_float_vertex to Gallium.

Author: Marek Olšák 
r300g: enable half float vertex
st/mesa: query for half float vertex support

Author: Luca Barbieri 
st/mesa: half float vertex support

Please review the commits here:
http://cgit.freedesktop.org/~mareko/mesa/log/?h=half-float-vertex<http://cgit.freedesktop.org/%7Emareko/mesa/log/?h=half-float-vertex>

Please let me know whether I may push this.

Cheers

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler

[Marek Olšák]

On Sun, Apr 4, 2010 at 6:14 AM, Tom Stellard  wrote:

> On Sun, Apr 04, 2010 at 01:09:51AM +0200, Marek Olšák wrote:
> >
> > Since Nicolai has already implemented the branch emulation and some other
> > optimizations, it would be nice to take over his work. I tried to use the
> > branch emulation on vertex shaders and it did not work correctly, I guess
> it
> > needs little fixing. See this branch in his repo:
> > http://cgit.freedesktop.org/~nh/mesa/log/?h=r300g-glsl<http://cgit.freedesktop.org/%7Enh/mesa/log/?h=r300g-glsl>
> <http://cgit.freedesktop.org/%7Enh/mesa/log/?h=r300g-glsl>
> > Especially this commit implements exactly what you propose (see comments
> in
> > the code):
> >
> http://cgit.freedesktop.org/~nh/mesa/commit/?h=r300g-glsl&id=71c8d4c745da23b0d4f3974353b19fad89818d7f<http://cgit.freedesktop.org/%7Enh/mesa/commit/?h=r300g-glsl&id=71c8d4c745da23b0d4f3974353b19fad89818d7f>
> <
> http://cgit.freedesktop.org/%7Enh/mesa/commit/?h=r300g-glsl&id=71c8d4c745da23b0d4f3974353b19fad89818d7f
> >
> >
> > Reusing this code for Gallium seems more reasonable to me than
> reinventing
> > the wheel and doing basically the same thing elsewhere. I recommend
> > implementing a TGSI backend in the r300 compiler, which will make
> possible
> > using it with TGSI shaders. So basically a TGSI shader would be converted
> to
> > the RC representation the way it's done in r300g right now, and code for
> > converting RC -> hw code would get replaced by conversion RC -> TGSI.
> Both
> > RC and TGSI are very similar so it'll be pretty straightforward. With a
> TGSI
> > backend, another step would be to make a nice hw-independent and
> > configurable interface on top of it which should go to util. So far it's
> > simple, now comes some real work: fixing the branch emulation and
> continuing
> > from (2) in your list.
>
> I am not sure if I follow you here, so let me know if I am understanding
> this correctly.  What you are suggesting is to take Nicolai's branch,
> which right now does TGSI -> RC -> Branch Emulation in RC -> hw code and
> instead of converting from RC to hw code convert from RC back into TGSI.
>

That's right.


> Then, pull the TGSI -> RC -> Branch Emulation in RC -> TGSI path out of
> the r300 compiler and place it in gallium/auxillary/util so it can be used
> by other Gallium drivers that want to emulate branches.  Is this correct?
>

Sorry I should have been more clear. The whole RC may stay in
src/mesa/drivers/dri/r300/compiler as it is now.

I think these are parts that should go to util:
- TGSI -> RC conversion
- RC -> TGSI conversion
- Hw-independent interface to the compiler, i.e. one function (or more)
which takes a TGSI shader and returns a TGSI shader. It should do both
conversions above and use r300/compiler directly.

In the long-term, the compiler should probably be moved to src/compiler or
something like that (since both classic and gallium drivers may use it), but
you don't need to care about that if you don't want to.

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler

[Marek Olšák]

On Sun, Apr 4, 2010 at 1:07 AM, Luca Barbieri wrote:

> So basically the r300 optimization work looks doomed from the
> beginning to be eventually obsoleted.
>

Please consider there are hw-specific optimizations in place which I think
no other compiler framework provides, and I believe this SSA thing will do
even better job for superscalar r600. So yes, we need both LLVM to do global
optimizations and RC to efficiently map code to hw.

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler

[Marek Olšák]

On Sat, Apr 3, 2010 at 9:31 AM, Tom Stellard  wrote:

> 1. Enable branch emulation for Gallium drivers:
> The goal of this task will be to create an optional "optimization" pass
> over the TGSI code to translate branch instructions into instructions
> that are supported by cards without hardware branching.  The basic
> strategy for doing this translation will be:
>
> A. Copy values of in scope variables
> to a temporary location before executing the conditional statement.
>
> B. Execute the "if true" branch.
>
> C. Test the conditional expression.  If it evaluates to false, rollback
> all values that were modified in the "if true" branch.
>
> D. Repeat step 2 with the "if false" branch, and then step 3, but this
> time only rollback if the conditional expression evaluates to true.
>
> The TGSI instructions SLT, SNE, SGE, SEQ will be used to test the
> conditional expression and the instruction CND will be used to rollback
> the values.
>
> There will be two phases to this task.  For phase 1, I will implement a
> simple translator that will be able to translate the branch instructions
> with only one pass through the TGSI code.  This simple translator will
> copy all in scope variables to a temporary location before executing the
> conditional statement, even if those variables will not not be modified
> in either of the branches.
>
> Phase 2 will add a preliminary pass before to the code translation
> pass that will mark variables that might be modified by the conditional
> statement.  Then, during the translation pass, only the variables that
> could potentially be modified inside either of the conditional branches
> will be copied before the conditional statement is executed.
>

First I really appreciate you're looking into this. I'd like to propose
something doable in GSoC timeframe.

Since Nicolai has already implemented the branch emulation and some other
optimizations, it would be nice to take over his work. I tried to use the
branch emulation on vertex shaders and it did not work correctly, I guess it
needs little fixing. See this branch in his repo:
http://cgit.freedesktop.org/~nh/mesa/log/?h=r300g-glsl
Especially this commit implements exactly what you propose (see comments in
the code):
http://cgit.freedesktop.org/~nh/mesa/commit/?h=r300g-glsl&id=71c8d4c745da23b0d4f3974353b19fad89818d7f

Reusing this code for Gallium seems more reasonable to me than reinventing
the wheel and doing basically the same thing elsewhere. I recommend
implementing a TGSI backend in the r300 compiler, which will make possible
using it with TGSI shaders. So basically a TGSI shader would be converted to
the RC representation the way it's done in r300g right now, and code for
converting RC -> hw code would get replaced by conversion RC -> TGSI. Both
RC and TGSI are very similar so it'll be pretty straightforward. With a TGSI
backend, another step would be to make a nice hw-independent and
configurable interface on top of it which should go to util. So far it's
simple, now comes some real work: fixing the branch emulation and continuing
from (2) in your list.

Then it'll be up to developers of other drivers whether they want to
implement their own hw-specific optimization passes and lowering
transformations. Even linking various shaders would be much easier done with
the compiler (and more efficient with its elimination of dead-code due to
removed shader outputs/inputs), this is used in classic r300 and I recall
Luca wanted such a feature in nouveau drivers. There is also an emulation of
shadow samplers, WPOS, and an emulation of various instructions, so this is
a nice and handy tool. (I would do it but I have a lot of more important
stuff to do.)

This may really help Gallium drivers until a real optimization framework
emerges.

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler

[Marek Olšák]

On Sun, Apr 4, 2010 at 12:10 AM, Zack Rusin  wrote:

> I thought the initial proposal was likely a lot more feasible for a GSOC
> (of
> course there one has to point out that Mesa's GLSL compiler already does
> unroll loops and in general simplifies control-flow so the points #1 and #2
> are
> largely no-ops, but surely there's enough work on Gallium Radeon's drivers
> left to keep Tom busy). Otherwise having a well-defined and reduced scope
> with
> clear deliverables would be rather necessary for LLVM->TGSI code because
> that
> is not something that you could get rock solid over a summer.
>

It doesn't seem to simplify branches or unroll loops that much, if at all.
It fails even for the simplest cases like this one:

if (gl_Vertex.x < 30.0)
gl_FrontColor = vec4(1.0, 0.0, 0.0, 0.0);
else
gl_FrontColor = vec4(0.0, 1.0, 0.0, 0.0);

This gets translated to TGSI "as is", which is fairly... you know what.

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] gallium-resources branch merge

[Marek Olšák]

There's something fishy in u_upload_mgr, could you please review the first
two patches here?
http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources

With this, r300g works again.

-Marek

On Fri, Apr 2, 2010 at 4:17 PM, Roland Scheidegger wrote:

> I'm planning on merging the gallium-resources branch shortly (after
> easter). Due to the amount of code changed, it wouldn't be unexpected if
> some drivers break here and there. So it would be nice if the respective
> driver authors could take a look at that branch now.
>
> If you've missed the discussion about this branch and what this is
> about, here it is:
>
> http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12726.html
>
> I've also removed the video interfaces completely, as they weren't
> ported to the interface changes and actually some of the video code
> missed some earlier interface changes so didn't build anyway. Video
> related work should be done on pipe-video branch which had newer stuff
> (for video) already.
>
>
> Roland
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

[Marek Olšák]

On Tue, Mar 30, 2010 at 10:26 AM, Nicolai Haehnle wrote:

> On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák  wrote:
> > Another idea was to convert TGSI to a SSA form. That would make unrolling
> > branches much easier as the Phi function would basically become a linear
> > interpolation, loops and subroutines with conditional return statements
> > might be trickier. The r300 compiler already uses SSA for its
> optimization
> > passes so maybe you wouldn't need to mess with TGSI that much...
>
> Note that my Git repository already contains an implementation of
> branch emulation and some additional optimizations, see here:
> http://cgit.freedesktop.org/~nh/mesa/log/?h=r300g-glsl<http://cgit.freedesktop.org/%7Enh/mesa/log/?h=r300g-glsl>
>
> Shame on me for abandoning it - I should really get around to make
> sure it fits in with recent changes and merge it to master. The main
> problem is that it produces "somewhat" inefficient code. Adding and
> improving peephole and similar optimizations should help tremendously.
>

Well it's either this or nothing so I guess I am not the only one to prefer
to get it merged. ;) However that kinda slightly changes Tom's plan for the
GSoC project.

On a different note, considering that the r300 compiler has basically 2
frontends (Mesa IR and TGSI) and 3 backends (r300 VS & FS, r500 FS), would
it be feasible to add yet another backend - TGSI? That would turn the
compiler into a generic Gallium shader optimizer with the lowering tools it
already has (or will have) and more people would be interested in adding new
features and improvements in it.

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

[Marek Olšák]

On Tue, Mar 30, 2010 at 7:09 AM, Tom Stellard  wrote:

> On Sat, Mar 27, 2010 at 02:11:54AM +0100, Marek Olšák wrote:
> >
> > From the driver point of view, we don't have to work on the GLSL compiler
> > itself. The Mesa state tracker compiles GLSL to an assembler-like
> language
> > called TGSI which is then translated ([1]) to the R300 compiler ([2])
> shader
> > representation. The more TGSI we handle, the more GLSL support we get.
> >
>
> Is adding support for the TGSI opcodes that are currently ignored by
> r300_tgsi_to_rc.c something that needs to be done?  If so, are there
> some opcodes you would prefer to see done first?
>

One of the goals might be to pass all relevant piglit tests including
glean/glsl1 which exercises various opcodes but it's not so important and
I'd be surprised if you would make it in your timeframe. You may use it for
testing though.


> > So now the status. r300g GLSL is missing the following features:
> >
> > 1) Branching and looping
> >
> > This is the most important one and there are 3 things which need to be
> done.
> > * Unrolling loops and converting conditionals to multiplications. This is
> > crucial for R3xx-R4xx GLSL support. I don't say it will work in all cases
> > but should be fine for the most common ones. This is kind of a standard
> in
> > all proprietary drivers supporting shaders 2.0. It would be nice have it
> > work with pure TGSI shaders so that drivers like nvfx can reuse it too
> and I
> > personally prefer to have this feature first before going on.
>
> Would you be able to provide a small example of how to convert the
> conditionals to multiplications?  I understand the basic idea is to mask
> values based on the result of the conditional, but it would help me to see
> an example.  On IRC, eosie mentioned an alternate technique for emulating
> conditionals: Save the values of variables that might be affected by
> the conditional statement.  Then, after executing both the if and the else
> branches, roll back the variables that were affected by the branch that
> was not supposed to be taken. Would this technique work as well?
>

Well, I am eosie, thanks for the info, it's always cool to be reminded what
I've written on IRC. ;)

Another idea was to convert TGSI to a SSA form. That would make unrolling
branches much easier as the Phi function would basically become a linear
interpolation, loops and subroutines with conditional return statements
might be trickier. The r300 compiler already uses SSA for its optimization
passes so maybe you wouldn't need to mess with TGSI that much...


> Is the conditional translation something that only needs to be done
> in the Gallium drivers, or would it be useful to apply the translation
> before the Mesa IR is converted into TGSI?  Are any of the other drivers
> (Gallium or Mesa) currently doing this kind of translation?
>

Not that I know of. You may do it wherever you want theoretically, even in
the r300 compiler and leaving TGSI untouched, but I think most people would
appreciate if these translation were done in TGSI.


> > * Teaching the R300 compiler loops and conditionals for R500 fragment
> > shaders. Note that R500 supports the jump instruction so besides adding
> new
> > opcodes, the compiler optimization passes should be updated too (I think
> > they haven't been designed with loops in mind).
> > * The same but for R500 vertex shaders. The difference is conditionals
> must
> > be implemented using predication opcodes and predication writes (stuff
> gets
> > masked out). I think this only affects the conversion to machine code at
> the
> > end of the pipeline.
> >
> > 2) Derivatives instructions fix
> >
> > It's implemented but broken. From docs: "If src0 is computed in the
> previous
> > instruction, then a NOP needs to be inserted between the two
> instructions.
> > Do this by setting the NOP flag in the previous instruction. This is not
> > required if the previous instruction is a texture lookup." .. and that
> > should be the fix.
>
> Is the only problem here that NOP is being inserted after texture
> lookups when it shouldn't be?
>

Well the derivatives don't work and NOP is not being inserted anywhere. The
quoted statement from the docs was supposed to give you a clue. NOP after a
texture lookup is *not required*, that means it would be just silly to put
it there but it shouldn't break anything.

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [PATCH] glsl: optimize sqrt

[Marek Olšák]

We were talking a bit on IRC that the GLSL compiler implements the sqrt
function somewhat inefficiently. Instead of rsq+rcp+cmp instructions as is
in the original code, the proposed patch uses just rsq+mul. Please see the
patch log for further explanation, and please review.

-Marek
From 9b834a79a1819f3b4b9868be3e2696667791c83e Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Sat, 27 Mar 2010 13:49:09 +0100
Subject: [PATCH] glsl: optimize sqrt

The new version can be derived from sqrt as follows:

sqrt(x) =
sqrt(x)^2 / sqrt(x) =
x / sqrt(x) =
x * rsqrt(x)

Also the need for the CMP instruction is gone because there is no division
by zero.
---
 .../shader/slang/library/slang_common_builtin.gc   |   22 +++
 1 files changed, 4 insertions(+), 18 deletions(-)

diff --git a/src/mesa/shader/slang/library/slang_common_builtin.gc b/src/mesa/shader/slang/library/slang_common_builtin.gc
index a25ca55..3f6596c 100644
--- a/src/mesa/shader/slang/library/slang_common_builtin.gc
+++ b/src/mesa/shader/slang/library/slang_common_builtin.gc
@@ -602,50 +602,36 @@ vec4 exp2(const vec4 a)
 
 float sqrt(const float x)
 {
-   const float nx = -x;
float r;
__asm float_rsq r, x;
-   __asm float_rcp r, r;
-   __asm vec4_cmp __retVal, nx, r, 0.0;
+   __retVal = r * x;
 }
 
 vec2 sqrt(const vec2 x)
 {
-   const vec2 nx = -x, zero = vec2(0.0);
vec2 r;
__asm float_rsq r.x, x.x;
__asm float_rsq r.y, x.y;
-   __asm float_rcp r.x, r.x;
-   __asm float_rcp r.y, r.y;
-   __asm vec4_cmp __retVal, nx, r, zero;
+   __retVal = r * x;
 }
 
 vec3 sqrt(const vec3 x)
 {
-   const vec3 nx = -x, zero = vec3(0.0);
vec3 r;
__asm float_rsq r.x, x.x;
__asm float_rsq r.y, x.y;
__asm float_rsq r.z, x.z;
-   __asm float_rcp r.x, r.x;
-   __asm float_rcp r.y, r.y;
-   __asm float_rcp r.z, r.z;
-   __asm vec4_cmp __retVal, nx, r, zero;
+   __retVal = r * x;
 }
 
 vec4 sqrt(const vec4 x)
 {
-   const vec4 nx = -x, zero = vec4(0.0);
vec4 r;
__asm float_rsq r.x, x.x;
__asm float_rsq r.y, x.y;
__asm float_rsq r.z, x.z;
__asm float_rsq r.w, x.w;
-   __asm float_rcp r.x, r.x;
-   __asm float_rcp r.y, r.y;
-   __asm float_rcp r.z, r.z;
-   __asm float_rcp r.w, r.w;
-   __asm vec4_cmp __retVal, nx, r, zero;
+   __retVal = r * x;
 }
 
 
-- 
1.6.3.3

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

[Marek Olšák]

On Tue, Mar 23, 2010 at 8:46 PM, Tom Stellard  wrote:

> On Tue, Mar 23, 2010 at 12:13:25AM -0700, Corbin Simpson wrote:
> > On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard 
> wrote:
> > >
> > > Thanks for the information.
> > >
> > > After spending some time learning about the Gallium driver
> architecture, I
> > > think it might be better to set a goal to implement or improve a
> specific
> > > feature of the Gallium R300 driver rather than trying to get a specific
> > > game or application to work.  Is there a feature that is currently
> missing
> > > from the R300 driver that might make a good project for the summer?
> >
> > Good question. There's a handful of things. Passing piglit might be a
> > good goal. Bumping the GL version further up, or solidifying the GLSL
> > support, might be good too.
> >
>
> I think the GLSL compiler would be an interesting project for me to work
> on.  What is the current status of GLSL on R300 cards?


>From the driver point of view, we don't have to work on the GLSL compiler
itself. The Mesa state tracker compiles GLSL to an assembler-like language
called TGSI which is then translated ([1]) to the R300 compiler ([2]) shader
representation. The more TGSI we handle, the more GLSL support we get.

So now the status. r300g GLSL is missing the following features:

1) Branching and looping

This is the most important one and there are 3 things which need to be done.
* Unrolling loops and converting conditionals to multiplications. This is
crucial for R3xx-R4xx GLSL support. I don't say it will work in all cases
but should be fine for the most common ones. This is kind of a standard in
all proprietary drivers supporting shaders 2.0. It would be nice have it
work with pure TGSI shaders so that drivers like nvfx can reuse it too and I
personally prefer to have this feature first before going on.
* Teaching the R300 compiler loops and conditionals for R500 fragment
shaders. Note that R500 supports the jump instruction so besides adding new
opcodes, the compiler optimization passes should be updated too (I think
they haven't been designed with loops in mind).
* The same but for R500 vertex shaders. The difference is conditionals must
be implemented using predication opcodes and predication writes (stuff gets
masked out). I think this only affects the conversion to machine code at the
end of the pipeline.

2) Derivatives instructions fix

It's implemented but broken. From docs: "If src0 is computed in the previous
instruction, then a NOP needs to be inserted between the two instructions.
Do this by setting the NOP flag in the previous instruction. This is not
required if the previous instruction is a texture lookup." .. and that
should be the fix.

3) Perspective, flat, and centroid varying modifiers, gl_FrontFacing

I think this is specific to the rasterizer (RS) block in hw ([3]).

[1] src/gallium/drivers/r300/r300_tgsi_to_rc.c
[2] src/mesa/drivers/dri/r300/compiler/
[3] src/gallium/drivers/r300/r300_state_derived.c


 Would something
> like passing a subset of the GLSL piglit tests, or being able to correctly
> handle a certain version of GLSL be a good goal for the summer?
>

I guess this question is for Corbin. ;)

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] configure.ac: Bump LIBDRM_RADEON_REQUIRED to 2.4.19

[Marek Olšák]

On Tue, Mar 23, 2010 at 1:57 PM, Sedat Dilek wrote:

> Thanks for the turbo fix, but you workarounded the "real" bug.
>

Frankly, the Mesa build system isn't my area and I don't want to have
anything to do with it.

The square microtiling is now disabled on both older kernels which don't
support it and older libdrm's which don't have the flag defined. No need to
have bleeding-edge stuff of everything is the way to go as long as it
doesn't get messy.

-Marek


> With my patch I get here in build.log:
> ...
> checking for LIBDRM... yes
> ...
> checking for LIBDRM_RADEON... no
> ...
>
> With setting LIBDRM_RADEON_REQUIRED=2.4.19 I expected that the build
> should immediately stop while libdrm package here has version 2.4.18.
> BUT, that is not the case!
>
> Intel_drm has in configure.ac:
> ...
> case $DRI_DIRS in
> *i915*|*i965*)
>PKG_CHECK_MODULES([INTEL], [libdrm_intel >= 2.4.19])
>;;
> esac
> ...
>
> radeon_libdrm on the contrary:
> ...
> case $DRI_DIRS in
> *radeon*|*r200*|*r300*|*r600*)
>PKG_CHECK_MODULES([LIBDRM_RADEON],
>  [libdrm_radeon libdrm >= $LIBDRM_RADEON_REQUIRED],
>  HAVE_LIBDRM_RADEON=yes,
>  HAVE_LIBDRM_RADEON=no)
>
>if test "$HAVE_LIBDRM_RADEON" = yes; then
>RADEON_CFLAGS="-DHAVE_LIBDRM_RADEON=1 $LIBDRM_RADEON_CFLAGS"
>RADEON_LDFLAGS=$LIBDRM_RADEON_LIBS
>fi
>;;
> esac
> ...
>
> IMO checking for LIBDRM_RADEON_REQUIRED has no real effect, but I am
> not an autotools expert.
> I am not sure if the LIBDRM_RADEON_REQUIRED part could/should be
> handled like in libdrm_intel (...be removed and simplified).
>
> Feedback welcome!
>
> --
> Sedat
>
> On Tue, Mar 23, 2010 at 1:41 PM, Marek Olšák  wrote:
> > Fixed in master without requiring new libdrm.
> >
> > -Marek
> >
> > On Tue, Mar 23, 2010 at 1:01 PM, Sedat Dilek  >
> > wrote:
> >>
> >> Fixes here latest issues with mesa master GIT [1].
> >>
> >> --
> >> Sedat
> >>
> >> [1] http://marc.info/?l=mesa3d-dev&m=126934502904478&w=2
> >>
> >>
> >>
> --
> >> Download Intel® Parallel Studio Eval
> >> Try the new software tools for yourself. Speed compiling, find bugs
> >> proactively, and fine-tune applications for parallel performance.
> >> See why Intel Parallel Studio got high marks during beta.
> >> http://p.sf.net/sfu/intel-sw-dev
> >> ___
> >> Mesa3d-dev mailing list
> >> Mesa3d-dev@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> >>
> >
> >
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

[Marek Olšák]

I've updated the TODO list with the stuff from my private one, in case you
guys think there are too few things to do. ;)

http://dri.freedesktop.org/wiki/R300ToDo?action=diff

-Marek

On Tue, Mar 23, 2010 at 8:16 AM, Corbin Simpson
wrote:

> On Tue, Mar 23, 2010 at 12:13 AM, Corbin Simpson
>  wrote:
> > Good question. There's a handful of things. Passing piglit might be a
> > good goal. Bumping the GL version further up, or solidifying the GLSL
> > support, might be good too.
>
> Oh, and how could I forget this? We have a sizeable todo list:
> http://dri.freedesktop.org/wiki/R300ToDo
>
> ~ C.
>
> --
> When the facts change, I change my mind. What do you do, sir? ~ Keynes
>
> Corbin Simpson
> 
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] configure.ac: Bump LIBDRM_RADEON_REQUIRED to 2.4.19

[Marek Olšák]

Fixed in master without requiring new libdrm.

-Marek

On Tue, Mar 23, 2010 at 1:01 PM, Sedat Dilek wrote:

> Fixes here latest issues with mesa master GIT [1].
>
> --
> Sedat
>
> [1] http://marc.info/?l=mesa3d-dev&m=126934502904478&w=2
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] New branch to switch st/dri to st_api.h

[Marek Olšák]

Please do "git pull --rebase origin" instead of "git pull origin" to avoid
"Merge branch 'master' of ..." commits.

-Marek

On Sun, Mar 21, 2010 at 2:40 PM, George Sapountzis wrote:

> That was commit 9ec29e31919e85f9230867f43841c0e74be930d3 when doing a
> pristine build. I reverted it for now.
>
> On Sun, Mar 21, 2010 at 2:31 PM, STEVE555 
> wrote:
> >
> > Hi Chia-I Wu,
> >   I've just updated my copy of Mesa master today after
> your
> > merge and the latest commits(from about 11:30 am GMT).I build Mesa with
> > these configure options:
> > ./configure --prefix=/usr --enable-32-bit --enable-xcb
> > --enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es
> > --enable-motif --enable-gl-osmesa --disable-gallium-intel
> > --disable-gallium-radeon --with-expat=/usr/lib
> > --with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast
> > --enable-gallium-swrast --enable-gallium-svga --with-max-width=4096
> > --with-max-height=4096 --enable-debug.
> >
> > I've used both gmake and make after ./configure,and Mesa keeps hitting
> this
> > error when it tries to build the svga state-tracker:
> >
> > gmake[4]: Entering directory `/opt/mesa/src/gallium/drivers/svga'
> > rm -f depend
> > touch depend
> > /usr/bin/makedepend -fdepend
> -I/usr/lib/gcc/i686-redhat-linux/4.4.3/include
> > -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary
> > -I../../../../src/gallium/drivers
> > -I../../../../src/gallium/drivers/svga/include -std=gnu99
> > -fvisibility=hidden -DHAVE_STDINT_H -DHAVE_SYS_TYPES_H
> > svgadump/svga_shader_dump.c svgadump/svga_shader_op.c
> svgadump/svga_dump.c
> > svga_cmd.c svga_context.c svga_draw.c svga_draw_arrays.c
> > svga_draw_elements.c svga_pipe_blend.c svga_pipe_blit.c svga_pipe_clear.c
> > svga_pipe_constants.c svga_pipe_depthstencil.c svga_pipe_draw.c
> > svga_pipe_flush.c svga_pipe_fs.c svga_pipe_misc.c svga_pipe_query.c
> > svga_pipe_rasterizer.c svga_pipe_sampler.c svga_pipe_vertex.c
> svga_pipe_vs.c
> > svga_screen.c svga_screen_buffer.c svga_screen_texture.c
> svga_screen_cache.c
> > svga_state.c svga_state_need_swtnl.c svga_state_constants.c
> > svga_state_framebuffer.c svga_state_rss.c svga_state_tss.c
> > svga_state_vdecl.c svga_state_fs.c svga_state_vs.c svga_swtnl_backend.c
> > svga_swtnl_draw.c svga_swtnl_state.c svga_tgsi.c svga_tgsi_decl_sm20.c
> > svga_tgsi_decl_sm30.c svga_tgsi_insn.c2> /dev/null
> > gmake[4]: *** No rule to make target `depend', needed by `default'.
>  Stop.
> > gmake[4]: Leaving directory `/opt/mesa/src/gallium/drivers/svga'
> > gmake[3]: *** [default] Error 1
> > gmake[3]: Leaving directory `/opt/mesa/src/gallium/drivers'
> > gmake[2]: *** [default] Error 1
> > gmake[2]: Leaving directory `/opt/mesa/src/gallium'
> > make[1]: *** [subdirs] Error 1
> > make[1]: Leaving directory `/opt/mesa/src'
> > make: *** [default] Error 1
> > Regards,
> >STEVE555
> >
> >
> > Sedat Dilek wrote:
> >>
> >> On Sun, Mar 21, 2010 at 10:33 AM, Chia-I Wu  wrote:
> >>> On Sun, Mar 21, 2010 at 5:19 PM, Sedat Dilek <
> sedat.di...@googlemail.com>
> >>> wrote:
> >> [...]
>  Even I see OpenArena got a boost from ~25fps (7.8 GIT) to ~32fps
>  (master GIT incl. gallium-st-api-dri merge)
>  $ cat oa_benchmark.txt
>  s...@seduxbox:~/src/anholt_oa-benchmark$ openarena +exec anholt 2>&1 |
>  egrep -e '[0-9]+ frames'
>  840 frames 26.3 seconds 31.9 fps 9.0/31.3/90.0/9.9 ms
>  Thanks for your work!
> >>> Unless I have some magic power that I am not aware of, the boost should
> >>> be
> >>> attributed to r300g developers.
> >>>
> >>
> >> I think, it is helpful to benchmark from time to time.
> >> I was comparing the both branches 7.8 and 7.9-devel in general and
> >> especiall r300g dri/st.
> >> Indeed, Chapeau to all contributors to r300g development.
> >>
> >> --
> >> Sedat
> >>
> >>
> --
> >> Download Intel® Parallel Studio Eval
> >> Try the new software tools for yourself. Speed compiling, find bugs
> >> proactively, and fine-tune applications for parallel performance.
> >> See why Intel Parallel Studio got high marks during beta.
> >> http://p.sf.net/sfu/intel-sw-dev
> >> ___
> >> Mesa3d-dev mailing list
> >> Mesa3d-dev@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> >>
> >>
> >
> > --
> > View this message in context:
> http://old.nabble.com/New-branch-to-switch-st-dri-to-st_api.h-tp27940955p27975796.html
> > Sent from the mesa3d-dev mailing list archive at Nabble.com.
> >
> >
> >
> --
> > Download Intel® Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev

Re: [Mesa3d-dev] [mesa] r300g dri/st: OpenArena corruptions with mesa-7.8 and master GIT

[Marek Olšák]

On Fri, Mar 19, 2010 at 11:36 AM, Sedat Dilek wrote:

> Hi,
>
> the last days I was testing Alex Deucher's power-management-2 patches
> for radeon OSS driver.
>
> While testing I saw that especially r300g dri/statetracker with
> OpenArena have problems with mesa 7.8/master GIT branch.
> Mesa r300 "classic" (KMS/DRI2) is working fine here on RV515.
>
> 7.8 GIT:
> Scenes have a "red-ish" background.
> There should be a fix in master.
> But I can't remember when and which patch fixed it, but Dave Airlied
> noticed the same color corruptions.
>

Apply this one from master:
821c830f11fc1c3529a186ace1d1ba3ddeab4957
If it helps, someone could cherry-pick the commit to the 7.8 branch.


> master GIT (merged gallium-st-api-dri into it):
> Some objects in the scene are not displayed with correct colors -
> objects look/have like turquoise and black triangles.
>

What levels have this issue? How can I reproduce it?
There is a breakage with Dave's screen/winsys rework (
68e58a96e80865878e6881dc4d34fcc3ec24eb19),
especially in these piglit tests: cubemap, gen-teximage, levelclamp,
lodclamp, texredefine.
Could you please check if the incorrect rendering in openarena has anything
to do with the rework?

-Marek


> commit 8e1768cfd32a4fa47dd5d4e8f5434fafc3b3120
> "gallium/docs: Fix a couple ReST errors."
>
> I played a bit with glxinfo (output see file-attachment):
>
> $ LIBGL_DEBUG=verbose RADEON_DEBUG=all ST_DEBUG=mesa glxinfo > glxinfo.txt
>
> The log of OA got big (dunno if you are interested in):
>
> $ LIBGL_DEBUG=verbose RADEON_DEBUG=all ST_DEBUG=mesa openarena
> 2>openarena.log
>
> Any hints for digging deeper into this?
>
> Kind Regards,
> - Sedat -
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] util_format cleanup leftover: Gallium BGRA vertex swizzles

[Marek Olšák]

Please see this commit:
http://cgit.freedesktop.org/~mareko/mesa/commit/?id=177a4432aa88fc68d83895ae71b7ad2c86a1e7e3

Subject: [PATCH] gallium: fix BGRA vertex color swizzles

The mapping for vertex_array_bgra:
(gl -> st -> translate)
GL_RGBA -> PIPE_FORMAT_R8G8B8A8 (RGBA) -> no swizzle (XYZW)
GL_BGRA -> PIPE_FORMAT_A8R8G8B8 (ARGB) -> ZYXW (BGRA again??)

Iẗ́'s pretty clear that PIPE_FORMAT_A8R8G8B8 here is wrong. This commit
fixes the pipe format and removes obvious workarounds in util/translate.

Tested with: softpipe, llvmpipe, r300g.

Please review.

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?

[Marek Olšák]

On Thu, Mar 11, 2010 at 4:41 PM, Luca Barbieri wrote:

> I've looked into the issue, and found a workaround by looking at what
> st_renderbuffer_alloc_storage (which is called to create the depth
> buffer with ST_SURFACE_DEPTH != BUFFER_DEPTH) does.
>
> Adding:
> if(ctx) ctx->NewState |= _NEW_BUFFERS;
>
> at the end of st_set_framebuffer_surface seems to solve the warsow
> problem with no other regressions.
>
> Brian, is this the right fix?
> Marek, does it fix your r300g problems too?
>

Mesa master merged with 7.8 fixes all the glean regressions. Thanks.
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?

[Marek Olšák]

I second that. The commit breaks 6 glean tests (api2, clipFlat, fragProg1,
occluQry, pointAtten, texCombine4) with r300g.

-Marek

On Wed, Mar 10, 2010 at 10:50 PM, Luca Barbieri wrote:

> In mesa_7_7_branch, 52d83efdbc4735d721e6fc9b44f29bdd432d4d73 reverts
> commit 9d17ad2891b58de9e33e943ff918a678c6a3c2bd.
>
> How about cherry-picking that commit into master, until a fix for the
> bugs the revert commit introduces are found?
>
> The reverted commit currently breaks the Warsow main menu for me,
> making it show garbage.
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] r300g color bug with VBO

[Marek Olšák]

Also I've fixed GL_RGBA in master so now only GL_BGRA remains unresolved...

On Tue, Mar 9, 2010 at 1:29 AM, Tom  wrote:

> Hi people,
>
> With the r300g driver (git ~today) drawing tris with color pointer like so:
>
> glColorPointer(4, GL_UNSIGNED_BYTE, sizeof(struct vtx_data), blah);
>
> Seems to invert the RGBA -> ABGR.
>
> This short program shows the bug. It should display a yellow tri, and
> instead on r300g it shows a blue tri.
>
> http://tom.noflag.org.uk/misc/r300g_color_bug.c
>
> Not sure if you want user bug reports of this kind yet, but anyway...
>
> --
> Tom
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] r300g color bug with VBO

[Marek Olšák]

Yes, this is a known issue. The problem is that GL_RGBA and GL_BGRA map to
PIPE_FORMAT_R8G8B8A8 (RGBA) and PIPE_FORMAT_A8R8G8B8 (ARGB), respectively,
which is wrong. The attached patch fixes it for r300g but breaks other
drivers which depend on Draw (softpipe, llvmpipe). The reason is that Draw
seems to interpret A8R8G8B8 as BGRA, clearly hiding the bug.

The possibilites are:
- implement the same hack in r300g
- fix Draw (I'd prefer this one)

I hope I'll find some time this week to resolve this issue if no one else do
it.

-Marek

On Tue, Mar 9, 2010 at 1:29 AM, Tom  wrote:

> Hi people,
>
> With the r300g driver (git ~today) drawing tris with color pointer like so:
>
> glColorPointer(4, GL_UNSIGNED_BYTE, sizeof(struct vtx_data), blah);
>
> Seems to invert the RGBA -> ABGR.
>
> This short program shows the bug. It should display a yellow tri, and
> instead on r300g it shows a blue tri.
>
> http://tom.noflag.org.uk/misc/r300g_color_bug.c
>
> Not sure if you want user bug reports of this kind yet, but anyway...
>
> --
> Tom
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 32b9a47..4b48c16 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -183,7 +183,7 @@ st_pipe_vertex_format(GLenum type, GLuint size, GLenum format,
   /* this is an odd-ball case */
   assert(type == GL_UNSIGNED_BYTE);
   assert(normalized);
-  return PIPE_FORMAT_A8R8G8B8_UNORM;
+  return PIPE_FORMAT_B8G8R8A8_UNORM;
}
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] dri-extension branch - clean up advertising extensions in Gallium

[Marek Olšák]

Alright, I will add driInitExtensions(ctx, NULL, TRUE) at the end of
st_init_extensions. Anything else I missed or is it OK?

-Marek

On Mon, Mar 8, 2010 at 4:25 PM, Roland Scheidegger wrote:

> On 08.03.2010 14:22, Joakim Sindholt wrote:
> > On Mon, 2010-03-08 at 13:16 +0100, Roland Scheidegger wrote:
> >> On 07.03.2010 20:26, Marek Olšák wrote:
> >>>  This branch is aimed to address the following issues:
> >>> * Extensions are advertised in both st/mesa and st/dri, doing the same
> >>> thing in two places.
> >>> * The inability to disable extensions in pipe_screen::get_param because
> >>> st/dri overrides the decisions of st/mesa.
> >>>
> >>> Here's the branch:
> >>> http://cgit.freedesktop.org/~mareko/mesa/log/?h=dri-extensions<http://cgit.freedesktop.org/%7Emareko/mesa/log/?h=dri-extensions>
> >>>
> >>> The first commit moves the differences between st/dri and st/mesa to
> the
> >>> latter and removes dri_init_extensions from st/dri. It doesn't remove
> >>> any extensions from the list except for those not advertised by
> pipe_screen.
> >>>
> >>> The second commit enables texture_rectangle by default in Gallium. To
> my
> >>> knowledge any Gallium hardware can do this and I suspect it was
> >>> dependent on NPOT textures by accident.
> >>>
> >>> All this is of course tested with piglit and glean.
> >>>
> >>> Please review. In case it's not OK, please let me know what needs to be
> >>> done.
> >> The second commit looks fine to me.
> >> The first one, I'm not sure. Maybe that's ok, but if so I'm wondering
> >> why, since this skips all the mapping business driInitExtensions did and
> >> just sets the extension enable bits to true. At least I'm fairly sure it
> >> was needed in the past...
> >>
> >> Roland
> >
> > I believe airlied pointed out earlier that
> >
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=17ef1f6074d6107c167f1956a5c60993904c0b72fixed
>  that problem.
>
> But even with that commit, all drivers still call driInitExtensions at
> least once, though the parameter list can be NULL. I don't see that
> happening here.
>
> Roland
>
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] dri-extension branch - clean up advertising extensions in Gallium

[Marek Olšák]

This branch is aimed to address the following issues:
* Extensions are advertised in both st/mesa and st/dri, doing the same thing
in two places.
* The inability to disable extensions in pipe_screen::get_param because
st/dri overrides the decisions of st/mesa.

Here's the branch:
http://cgit.freedesktop.org/~mareko/mesa/log/?h=dri-extensions

The first commit moves the differences between st/dri and st/mesa to the
latter and removes dri_init_extensions from st/dri. It doesn't remove any
extensions from the list except for those not advertised by pipe_screen.

The second commit enables texture_rectangle by default in Gallium. To my
knowledge any Gallium hardware can do this and I suspect it was dependent on
NPOT textures by accident.

All this is of course tested with piglit and glean.

Please review. In case it's not OK, please let me know what needs to be
done.

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex.

[Marek Olšák]

The attached patches change softpipe and llvmpipe so that they never provoke
the first vertex for quads. Please review. I think that these and the
Corbin's one could be pushed by now, couldn't they?

-Marek

On Thu, Feb 11, 2010 at 4:03 PM, Brian Paul  wrote:

> Corbin Simpson wrote:
> >>From 215714d54a7f38b9add236bcc1c795e8b5d92867 Mon Sep 17 00:00:00 2001
> > From: Corbin Simpson 
> > Date: Wed, 10 Feb 2010 10:39:18 -0800
> > Subject: [PATCH] mesa/st: Gallium quads, by spec, never change provoking
> vertex.
> >
> > Fixes glean/clipFlat. Softpipe might be broken; I haven't figured out
> > how to test it in this new API world. :T
> > ---
> >  src/mesa/state_tracker/st_extensions.c |3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/src/mesa/state_tracker/st_extensions.c
> > b/src/mesa/state_tracker/st_extensions.c
> > index d5f5854..e2d871b 100644
> > --- a/src/mesa/state_tracker/st_extensions.c
> > +++ b/src/mesa/state_tracker/st_extensions.c
> > @@ -137,6 +137,9 @@ void st_init_limits(struct st_context *st)
> > /* XXX separate query for early function return? */
> > st->ctx->Shader.EmitContReturn =
> >screen->get_param(screen, PIPE_CAP_TGSI_CONT_SUPPORTED);
> > +
> > +   /* Quads always follow GL provoking rules. */
> > +   c->QuadsFollowProvokingVertexConvention = GL_FALSE;
> >  }
>
> This causes the glean clipFlat test to fail with softpipe.  The
> gallium softpipe driver _does_ implement the "quad follows provoking
> vertex" convention.
>
> I don't have time right now to update the softpipe driver so this
> patch will have to wait a while.  Maybe someone else can look at it
> sooner.
>
> -Brian
>
>
> --
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
From 861dd9a4e5d2fc3e0892d76d8f0ac929e186a88a Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Sun, 7 Mar 2010 04:54:43 +0100
Subject: [PATCH 1/2] llvmpipe: do not follow the provoking vertex convention for quads

---
 src/gallium/drivers/llvmpipe/lp_setup_vbuf.c |  129 +++--
 1 files changed, 36 insertions(+), 93 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c b/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c
index 24291da..671e744 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c
@@ -231,57 +231,29 @@ lp_setup_draw(struct vbuf_render *vbr, const ushort *indices, uint nr)
   break;
 
case PIPE_PRIM_QUADS:
-  if (setup->flatshade_first) {
- for (i = 3; i < nr; i += 4) {
-setup->triangle( setup,
- get_vert(vertex_buffer, indices[i-2], stride),
- get_vert(vertex_buffer, indices[i-1], stride),
- get_vert(vertex_buffer, indices[i-3], stride) );
-setup->triangle( setup,
- get_vert(vertex_buffer, indices[i-1], stride),
- get_vert(vertex_buffer, indices[i-0], stride),
- get_vert(vertex_buffer, indices[i-3], stride) );
- }
-  }
-  else {
- for (i = 3; i < nr; i += 4) {
-setup->triangle( setup,
- get_vert(vertex_buffer, indices[i-3], stride),
- get_vert(vertex_buffer, indices[i-2], stride),
- get_vert(vertex_buffer, indices[i-0], stride) );
+  for (i = 3; i < nr; i += 4) {
+ setup->triangle( setup,
+  get_vert(vertex_buffer, indices[i-3], stride),
+  get_vert(vertex_buffer, indices[i-2], stride),
+  get_vert(vertex_buffer, indices[i-0], stride) );
 
-setup->triangle( setup,
- get_vert(vertex_buffer, indices[i-2], stride),
- get_vert(vertex_buffer, indices[i-1], stride),
- get_vert(vertex_buffer, indices[i-0], stride) );
- }
+ setup->triangle( setup,
+  get_vert(vertex_buffer, indices[i-2], stride),
+  get_vert(vertex_buffer, indices[i-1], stride),
+  get_vert(vertex_buffer, indices[i-0], stride) );
   }
   break;
 
case PIPE_PRIM_QUAD_STRIP:
-  if (setup->flatshade_first) {
- for (i = 3; i < nr; i += 2) {
-setup->triangle( setup,
- get_vert(vertex_buffer, indices[i-0], stride),
- get_vert(vertex_buffer, indices[i-1], stride),
- 

Re: [Mesa3d-dev] Mesa (master): mesa: Export GL_EXT_texture_cube_map.

[Marek Olšák]

I can see this extension in ATI Catalyst 9.3.

-Marek

On Sat, Mar 6, 2010 at 1:16 AM, Ian Romanick  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jose Fonseca wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 744994a9c6b972a737e432cf1b699f232e2c5bfd
> > URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=744994a9c6b972a737e432cf1b699f232e2c5bfd
> >
> > Author: José Fonseca 
> > Date:   Sat Feb 13 15:10:24 2010 +
> >
> > mesa: Export GL_EXT_texture_cube_map.
> >
> > Still used by some applications.
>
> Holy smokes.  Just out of curiosity, which applications?  I didn't think
> anyone ever actually shipped this extension.  I guess Nvidia might have..
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuRnucACgkQX1gOwKyEAw/IDwCcCTnVTTHB2QOLZbDEVZmniYq/
> mHkAmwaXt1ZzjGigifaqdyhkzf3/fxQ8
> =umX/
> -END PGP SIGNATURE-
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?

[Marek Olšák]

On Tue, Mar 2, 2010 at 10:20 PM, Luca Barbieri wrote:

> On Tue, Mar 2, 2010 at 10:00 PM, Corbin Simpson
>  wrote:
> > FYI r300 only supports 24 interpolators: 16 linear and 8 perspective.
> > (IIRC; not in front of the docs right now.) r600 supports 256 fully
> > configurable interpolators.
>
> Yes, but if you raised ATTR_GENERIC_COUNT, the current driver would
> support higher semantic indices right? (of course, with a limit of
> 8/24 different semantic indices used at once).
>
> That's right.
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [RFC] gallium-no-rhw-position branch merge

[Marek Olšák]

Ahhh, I am a bad liar. The attached patch fixes the regressions.

-Marek

On Tue, Mar 2, 2010 at 2:08 AM, Marek Olšák  wrote:

> Hi Michal,
>
> This branch breaks 2 piglit tests with r300g:
>
> depthrange-clear
> texdepth
>
> However I haven't investigated these and won't get to them until the
> weekend. I personally don't mind fixing the regressions after the merge (but
> I'm not the maintainer of r300g). Anyway I'm glad to see
> bypass_vs_clip_and_viewport dying.
>
> -Marek
>
>
> On Mon, Mar 1, 2010 at 5:08 PM, michal  wrote:
>
>> Hi,
>>
>> This branch removes bypass_vs_clip_and_viewport flag from pipe
>> rasterizer state. The benefits of having this bit around were dubious
>> for everybody and burdensome for driver writers.
>>
>> All the utility code that relied on this flag have been rewritten to
>> pass vertex positions in clip space and set clip and viewport state. I
>> would like to ask the maintainers of u_blitter module to please test my
>> changes and provide feedback.
>>
>> Please review.
>>
>> Thanks.
>>
>>
>>
>> --
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> ___
>> Mesa3d-dev mailing list
>> Mesa3d-dev@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>>
>
>
From fe8c9e902b3cb6392979aeecf03b17d303210eba Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Tue, 2 Mar 2010 02:37:45 +0100
Subject: [PATCH] util/blitter: Fix the viewport transformation for Z coordinates

When clearing buffers, the depth is specified in the range [0, 1]
and should be passed through blitter "as is".
---
 src/gallium/auxiliary/util/u_blitter.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_blitter.c b/src/gallium/auxiliary/util/u_blitter.c
index f93c69d..0ba09d3 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -320,11 +320,11 @@ static void blitter_set_rectangle(struct blitter_context_priv *ctx,
/* viewport */
ctx->viewport.scale[0] = 0.5f * width;
ctx->viewport.scale[1] = 0.5f * height;
-   ctx->viewport.scale[2] = 0.5f;
+   ctx->viewport.scale[2] = 1.0f;
ctx->viewport.scale[3] = 1.0f;
ctx->viewport.translate[0] = 0.5f * width;
ctx->viewport.translate[1] = 0.5f * height;
-   ctx->viewport.translate[2] = 0.5f;
+   ctx->viewport.translate[2] = 0.0f;
ctx->viewport.translate[3] = 0.0f;
ctx->pipe->set_viewport_state(ctx->pipe, &ctx->viewport);
 
-- 
1.6.3.3

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [RFC] gallium-no-rhw-position branch merge

[Marek Olšák]

Hi Michal,

This branch breaks 2 piglit tests with r300g:

depthrange-clear
texdepth

However I haven't investigated these and won't get to them until the
weekend. I personally don't mind fixing the regressions after the merge (but
I'm not the maintainer of r300g). Anyway I'm glad to see
bypass_vs_clip_and_viewport dying.

-Marek

On Mon, Mar 1, 2010 at 5:08 PM, michal  wrote:

> Hi,
>
> This branch removes bypass_vs_clip_and_viewport flag from pipe
> rasterizer state. The benefits of having this bit around were dubious
> for everybody and burdensome for driver writers.
>
> All the utility code that relied on this flag have been rewritten to
> pass vertex positions in clip space and set clip and viewport state. I
> would like to ask the maintainers of u_blitter module to please test my
> changes and provide feedback.
>
> Please review.
>
> Thanks.
>
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Gallium software fallback/draw command failure

[Marek Olšák]

On Mon, Mar 1, 2010 at 3:02 PM, Jerome Glisse wrote:

> On Mon, Mar 01, 2010 at 12:24:19PM +, Keith Whitwell wrote:
> > On Mon, 2010-03-01 at 04:07 -0800, Keith Whitwell wrote:
> > > On Mon, 2010-03-01 at 03:55 -0800, Jerome Glisse wrote:
> > > > On Mon, Mar 01, 2010 at 11:46:08AM +, Keith Whitwell wrote:
> > > > > On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote:
> > > > > > On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I am a bit puzzled, how a pipe driver should handle
> > > > > > > draw callback failure ? On radeon (pretty sure nouveau
> > > > > > > or intel hit the same issue) we can only know when one
> > > > > > > of the draw_* context callback is call if we can do
> > > > > > > the rendering or not.
> > > > > > >
> > > > > > > The failure here is dictated by memory constraint, ie
> > > > > > > if user bind big texture, big vbo ... we might not have
> > > > > > > enough GPU address space to bind all the desired object
> > > > > > > (even for drawing a single triangle) ?
> > > > > > >
> > > > > > > What should we do ? None of the draw callback can return
> > > > > > > a value ? Maybe for a GL stack tracker we should report
> > > > > > > GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line
> > > > > > > is i think pipe driver are missing something here. Any
> > > > > > > idea ? Thought ? Is there already a plan to address that ? :)
> > > > > >
> > > > > > Gallium draw calls had return codes before. They were used for
> the
> > > > > > fallover driver IIRC and were recently deleted.
> > > > > >
> > > > > > Either we put the return codes back, or we add a new
> > > > > > pipe_context::validate() that would ensure that all necessary
> conditions
> > > > > > to draw successfully are met.
> > > > > >
> > > > > > Putting return codes on bind time won't work, because one can't
> set all
> > > > > > atoms simultaneously -- atoms are set one by one, so when one's
> setting
> > > > > > the state there are state combinations which may exceed the
> available
> > > > > > resources but that are never drawn with. E.g. you have a huge VB
> you
> > > > > > finished drawing, and then you switch to drawing with a small VB
> with a
> > > > > > huge texture, but in between it may happen that you have both
> bound
> > > > > > simultaneously.
> > > > > >
> > > > > > If ignoring is not an alternative, then I'd prefer a validate
> call.
> > > > > >
> > > > > > Whether to fallback to software or not -- it seems to me it's
> really a
> > > > > > problem that must be decided case by case. Drivers are supposed
> to be
> > > > > > useful -- if hardware is so limited that it can't do anything
> useful
> > > > > > then falling back to software is sensible. I don't think that a
> driver
> > > > > > should support every imaginable thing -- apps should check
> errors, and
> > > > > > users should ensure they have enough hardware resources for the
> > > > > > workloads they want.
> > > > > >
> > > > > > Personally I think state trackers shouldn't emulate anything with
> CPU
> > > > > > beyond unsupported pixel formats. If a hardware is so limited
> that in
> > > > > > need CPU assistence this should taken care transparently by the
> pipe
> > > > > > driver. Nevertheless we can and should provide auxiliary
> libraries like
> > > > > > draw to simplify the pipe driver implementation.
> > > > >
> > > > >
> > > > > My opinion on this is similar: the pipe driver is responsible for
> > > > > getting the rendering done.  If it needs to pull in a fallback
> module to
> > > > > achieve that, it is the pipe driver's responsibility to do so.
> > > > >
> > > > > Understanding the limitations of hardware and the best ways to work
> > > > > around those limitations is really something that the driver itself
> is
> > > > > best positioned to handle.
> > > > >
> > > > > The slight quirk of OpenGL is that there are some conditions where
> > > > > theoretically the driver is allowed to throw an OUT_OF_MEMORY error
> (or
> > > > > similar) and not render.  This option isn't really available to
> gallium
> > > > > drivers, mainly because we don't know inside gallium whether the
> API
> > > > > permits this.  Unfortunately, even in OpenGL, very few applications
> > > > > actually check the error conditions, or do anything sensible when
> they
> > > > > fail.
> > > > >
> > > > > I don't really like the idea of pipe drivers being able to fail
> render
> > > > > calls, as it means that every state tracker and every bit of
> utility
> > > > > code that issues a pipe->draw() call will have to check the return
> code
> > > > > and hook in fallback code on failure.
> > > > >
> > > > > One interesting thing would be to consider creating a layer that
> exposes
> > > > > a pipe_context interface to the state tracker, but revives some of
> the
> > > > > failover ideas internally - maybe as a first step just lifting the
> draw
> > > > > module usage up to a layer above the actual hardware driver.
>

Re: [Mesa3d-dev] [PATCH] st/mesa: do not advertise S3TC if the external lib is not available

[Marek Olšák]

OK thanks, I pushed what you suggested.

-Marek

On Sat, Feb 27, 2010 at 9:44 PM, José Fonseca  wrote:

> On Sat, 2010-02-27 at 09:15 -0800, Marek Olšák wrote:
> > Hi,
> >
> > S3TC shouldn't be advertised without the external lib and the attached
> > patch fixes that. Please review.
>
> Hi Marek,
>
> Actually it is a bit more subtle.
>
> S3TC can and should be advertised if the pipe driver supports ST3C
> decompression and *compression*.
>
> No real hardware has circuitry for S3TC compression, granted. But the
> vwmare svga gallium driver does it, by deferring everything to the host.
>
> It was the best solution we found to supporting S3TC without having to
> rely on closed source or questionable bits in the guest.
>
> So the right fix should be:
>
> screen->is_format_supported(screen, PIPE_FORMAT_DXT5_RGBA,
>PIPE_TEXTURE_2D,
>PIPE_TEXTURE_USAGE_SAMPLER, 0) &&
> (ctx->Mesa_DXTn || screen->is_format_supported(screen,
> PIPE_FORMAT_DXT5_RGBA, PIPE_TEXTURE_2D, PIPE_TEXTURE_USAGE_RENDERTARGET,
> 0)
>
> Jose
>
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [PATCH] st/mesa: do not advertise S3TC if the external lib is not available

[Marek Olšák]

Hi,

S3TC shouldn't be advertised without the external lib and the attached patch
fixes that. Please review.

-Marek
From 94c58ff449b3818a378ad4ab5787151bc0a9ea6f Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Sat, 27 Feb 2010 03:20:58 +0100
Subject: [PATCH] st/mesa: do not advertise S3TC if the external lib is not available

---
 src/mesa/state_tracker/st_extensions.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c
index d5f5854..7b720b3 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -298,7 +298,8 @@ void st_init_extensions(struct st_context *st)
}
 
/* s3tc support */
-   if (screen->is_format_supported(screen, PIPE_FORMAT_DXT5_RGBA,
+   if (ctx->Mesa_DXTn &&
+   screen->is_format_supported(screen, PIPE_FORMAT_DXT5_RGBA,
PIPE_TEXTURE_2D, 
PIPE_TEXTURE_USAGE_SAMPLER, 0)) {
   ctx->Extensions.EXT_texture_compression_s3tc = GL_TRUE;
-- 
1.6.3.3

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Mesa (master): r300/compiler: Assert that array index is not negative.

[Marek Olšák]

We actually hit this assertion when we get:

FRAG
DCL IN[0], COLOR, PERSPECTIVE
  0: END

See piglit/glsl-bug-22603.

-Marek

On Fri, Feb 26, 2010 at 10:18 AM, Corbin Simpson
wrote:

> > Module: Mesa
> > Branch: master
> > Commit: e5c691f445e1c02e6e2f75b817b13d7024f7a3a6
> > URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=e5c691f445e1c02e6e2f75b817b13d7024f7a3a6
> >
> > Author: Vinson Lee 
> > Date:   Fri Feb 26 00:17:03 2010 -0800
> >
> > r300/compiler: Assert that array index is not negative.
> >
> > ---
> >
> > .../drivers/dri/r300/compiler/r500_fragprog_emit.c |2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
> b/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
> > index 829f028..710cae7 100644
> > --- a/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
> > +++ b/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
> > @@ -469,6 +469,8 @@ void r500BuildFragmentProgramHwCode(struct
> r300_fragment_program_compiler *compi
> > if (compiler->Base.Error)
> > return;
> >
> > + assert(code->inst_end >= 0);
> > +
> > if ((code->inst[code->inst_end].inst0 & R500_INST_TYPE_MASK) !=
> R500_INST_TYPE_OUT) {
> > /* This may happen when dead-code elimination is disabled or
> > * when most of the fragment program logic is leading to a KIL */
>
> Sorry, is this actually a problem? If this assertion is actually being
> hit, it sure would be nice to hear about it since it. Empty shaders
> shouldn't just be handled with debugging code.
>
> --
> Only fools are easily impressed by what is only
> barely beyond their reach. ~ Unknown
>
> Corbin Simpson
> 
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] st/dri: don't enable EXT_draw_buffers2 by default

[Marek Olšák]

On Tue, Feb 23, 2010 at 2:49 AM, Marek Olšák  wrote:

> On Mon, Feb 22, 2010 at 4:23 PM, Brian Paul wrote:
>
>> On Sun, Feb 21, 2010 at 8:00 AM, Marek Olšák  wrote:
>> > Hi,
>> >
>> > the attached patch modifies st/dri to not enable EXT_draw_buffers2 by
>> > default because r300g and most probably even some other drivers can't
>> > support this extension. The drivers reporting support of
>> > PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch.
>> >
>> > Please review.
>>
>> Hmm, I believe the extensions listed in dri_extensions.c are those
>> that _may_ be supported by drivers.  But its the st_extensions.c code
>> that queries the driver for various caps (such as
>> PIPE_CAP_INDEP_BLEND_ENABLE) and then turns on the extension if
>> applicable.
>>
>
> I stand corrected.
>
>
I was actually right the first time. The list in dri_extensions.c is being
advertised *regardless* of what a driver reports (tested and debugged). None
of the extensions on the list can be disabled using pipe_screen::get_param,
making the majority of feature caps useless. However, I can enable/disable
any extension which is *not* on the list using appropriate caps (if they
exist).

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Gallium format swizzles (Was: util: fix swizzles in the format table for 8-bits-per-channel formats)

[Marek Olšák]

I am basically ok with anything that would let me correctly convert the
format description into hardware-specific bits with *no* workarounds (for
both vertex data and samplers).

On Tue, Feb 23, 2010 at 6:20 PM, José Fonseca  wrote:

> On Mon, 2010-02-22 at 06:34 -0800, José Fonseca wrote:
> > On Sun, 2010-02-21 at 06:40 -0800, Marek Olšák wrote:
> > > Hi José,
> > >
> > > the attached patch fixes incorrect swizzles in u_format.csv. There are
> > > basically just 2 drivers which depend on the swizzles in this table:
> > > llvmpipe and r300g. Since r300g started supporting pretty much every
> > > texture format except SCALED ones, a few regressions have showed up.
> > > This patch resolves all issues I had, especially with the SRGB formats
> > > but I decided to clean it up all. git log:
> > >
> > > util: fix swizzles in the format table for 8-bits-per-channel
> > > formats
> > >
> > > The 8-bits-per-channel formats having the same channel order had
> > > completely
> > > different swizzles, and at the same time, the same swizzles were
> > > used for
> > > completely different channel orders of 8bpc formats.
> > >
> > > This made the whole table self-contradicting, caused headaches,
> > > and last
> > > but not least, incorrent rendering for the drivers relying on
> > > these swizzles.
> > >
> > > I hope I got it right. I didn't make a special distinction between the
> > > array and arith layouts. All I did was to make sure that if I grep
> > > e.g. A8R8G8B8, I'll get the same swizzles and not entirely different
> > > ones.
> >
> > Hi Marek,
> >
> > I'll need a bit more time to investigate this.
> >
> > One problem is that the interpretation of the swizzle varies with array
> > vs arith. The ordering for array is the lowest significant word to the
> > highest significant word (where word for 8bit formats is a byte), where
> > for arith it goes from least significant bit to the highest significant
> > bit. This is the same difference as array indexation and bit shifts.
> >
> > There is also the problem of byte order which affects the bit shift
> > interpretation...
> >
> > I admit thet the current format description table is terribly
> > underdocumented/confusing and likely broken in several ways. I wrote it
> > to be able to code generate pixel format translation (which is wroking
> > reasonably) and never expected people to use it for hardware drivers as
> > well, although it is perfectly legitimate use.
> >
> > I have my own interpretation of these concepts, you and others hw driver
> > writers have their own different interpretation. Furthermore in
> > draw/translate/util modules there are some inconsistencies in these
> > interpretations too. So I need to read the GL and DX10 specs very well,
> > see how current drivers are using the descriptions, and come up with
> > something that makes sense for everybody.
> >
> > So please hold on to your patch for a couple of days.
> >
> > I'd appreciate if the interested parties could take a good look to
> > u_format.h comments, and summarize what they think the format semantics
> > should be.
> >
> > Jose
>
>
> There are two inconsistencies in formats ATM:
> a) the notation used in PIPE_FORMAT_xxx, and
> b) the values in util_format_description::swizzles .
>
>
> There's a D3D9 <-> D3D10 format conversion table  in
>
> http://msdn.microsoft.com/en-us/library/ee415668(VS.85).aspx#Porting_Content<http://msdn.microsoft.com/en-us/library/ee415668%28VS.85%29.aspx#Porting_Content>
> and D3D9 <-> GL format table in
>
> http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/utils.c;hb=HEAD.
>
> D3D10 dropped all arithmetically encoded formats, and inverted the
> swizzle notation (e.g., D3DFMT_A2B10G10R10 and  DXGI_FORMAT_R10G10B10A2
> are equivalent).
>
> Gallium has to represent both kinds and mixes both notations (the
> MSB->LSB notation traditionally used for texture formats, the LSB->MSB
> for vertex declarations). So instead of the current inconsistencies,
> both on p_format.h and u_format.csv, I suggest we all normalize on one
> notation, lets say MSB->LSB for pixel/vertex formats.
>
> For example, the vertex format
>
>   struct vertex {
>  float x;
>  float y;
>   };
>
> should be described the format PIPE_FORMAT_G32R32_FLOAT (not the current
> PIPE_FORMAT_R32G32_FLOAT), which is equivalent:
> - D3D9's D3DFMT_G32R32F te

Re: [Mesa3d-dev] [PATCH] st/dri: don't enable EXT_draw_buffers2 by default

[Marek Olšák]

On Mon, Feb 22, 2010 at 4:23 PM, Brian Paul  wrote:

> On Sun, Feb 21, 2010 at 8:00 AM, Marek Olšák  wrote:
> > Hi,
> >
> > the attached patch modifies st/dri to not enable EXT_draw_buffers2 by
> > default because r300g and most probably even some other drivers can't
> > support this extension. The drivers reporting support of
> > PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch.
> >
> > Please review.
>
> Hmm, I believe the extensions listed in dri_extensions.c are those
> that _may_ be supported by drivers.  But its the st_extensions.c code
> that queries the driver for various caps (such as
> PIPE_CAP_INDEP_BLEND_ENABLE) and then turns on the extension if
> applicable.
>

I stand corrected.


>
> Is GL_EXT_draw_buffers2 really being advertised by glxinfo with r300g?
>

Unfortunately yes, it is.

-Marek
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [PATCH] st/dri: don't enable EXT_draw_buffers2 by default

[Marek Olšák]

Hi,

the attached patch modifies st/dri to not enable EXT_draw_buffers2 by
default because r300g and most probably even some other drivers can't
support this extension. The drivers reporting support of
PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch.

Please review.

Marek
From ddda2c19b74780263f848ffafe10809bd6385d01 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Sun, 21 Feb 2010 01:27:09 +0100
Subject: [PATCH 2/2] st/dri: don't enable EXT_draw_buffers2 by default

---
 src/gallium/state_trackers/dri/dri_extensions.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/src/gallium/state_trackers/dri/dri_extensions.c b/src/gallium/state_trackers/dri/dri_extensions.c
index 1259813..7f8ceef 100644
--- a/src/gallium/state_trackers/dri/dri_extensions.c
+++ b/src/gallium/state_trackers/dri/dri_extensions.c
@@ -99,7 +99,6 @@ static const struct dri_extension card_extensions[] = {
{"GL_EXT_blend_minmax", GL_EXT_blend_minmax_functions},
{"GL_EXT_blend_subtract", NULL},
{"GL_EXT_cull_vertex", GL_EXT_cull_vertex_functions},
-   {"GL_EXT_draw_buffers2", GL_EXT_draw_buffers2_functions},
{"GL_EXT_fog_coord", GL_EXT_fog_coord_functions},
{"GL_EXT_framebuffer_object", GL_EXT_framebuffer_object_functions},
{"GL_EXT_multi_draw_arrays", GL_EXT_multi_draw_arrays_functions},
-- 
1.6.3.3

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [PATCH] util: fix swizzles in the format table for 8-bits-per-channel formats

[Marek Olšák]

Hi José,

the attached patch fixes incorrect swizzles in u_format.csv. There are
basically just 2 drivers which depend on the swizzles in this table:
llvmpipe and r300g. Since r300g started supporting pretty much every texture
format except SCALED ones, a few regressions have showed up. This patch
resolves all issues I had, especially with the SRGB formats but I decided to
clean it up all. git log:

util: fix swizzles in the format table for 8-bits-per-channel formats

The 8-bits-per-channel formats having the same channel order had
completely
different swizzles, and at the same time, the same swizzles were used
for
completely different channel orders of 8bpc formats.

This made the whole table self-contradicting, caused headaches, and last
but not least, incorrent rendering for the drivers relying on these
swizzles.

I hope I got it right. I didn't make a special distinction between the array
and arith layouts. All I did was to make sure that if I grep e.g. A8R8G8B8,
I'll get the same swizzles and not entirely different ones.

Please review.

Best regards

Marek
From 53b1acea3cd5386d1f81a186f959d32b25c62f42 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Sat, 20 Feb 2010 18:36:16 +0100
Subject: [PATCH 1/2] util: fix swizzles in the format table for 8-bits-per-channel formats

The 8-bits-per-channel formats having the same channel order had completely
different swizzles, and at the same time, the same swizzles were used for
completely different channel orders of 8bpc formats.

This made the whole table self-contradicting, caused headaches, and last
but not least, incorrent rendering for the drivers relying on these swizzles.
---
 src/gallium/auxiliary/util/u_format.csv |   44 +++---
 1 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_format.csv b/src/gallium/auxiliary/util/u_format.csv
index 01f7931..6139e16 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/gallium/auxiliary/util/u_format.csv
@@ -67,37 +67,37 @@ PIPE_FORMAT_R8G8B8_UNORM  , array , 1, 1, un8 , un8 , un8 , , zyx1,
 PIPE_FORMAT_R8G8B8A8_UNORM, array , 1, 1, un8 , un8 , un8 , un8 , wzyx, rgb
 PIPE_FORMAT_R8G8B8X8_UNORM, array , 1, 1, un8 , un8 , un8 , un8 , wzy1, rgb
 PIPE_FORMAT_R8_USCALED, array , 1, 1, u8  , , , , x001, rgb
-PIPE_FORMAT_R8G8_USCALED  , array , 1, 1, u8  , u8  , , , xy01, rgb
-PIPE_FORMAT_R8G8B8_USCALED, array , 1, 1, u8  , u8  , u8  , , xyz1, rgb
-PIPE_FORMAT_R8G8B8A8_USCALED  , array , 1, 1, u8  , u8  , u8  , u8  , xyzw, rgb
-PIPE_FORMAT_R8G8B8X8_USCALED  , array , 1, 1, u8  , u8  , u8  , u8  , xyz1, rgb
+PIPE_FORMAT_R8G8_USCALED  , array , 1, 1, u8  , u8  , , , yx01, rgb
+PIPE_FORMAT_R8G8B8_USCALED, array , 1, 1, u8  , u8  , u8  , , zyx1, rgb
+PIPE_FORMAT_R8G8B8A8_USCALED  , array , 1, 1, u8  , u8  , u8  , u8  , wzyx, rgb
+PIPE_FORMAT_R8G8B8X8_USCALED  , array , 1, 1, u8  , u8  , u8  , u8  , wzy1, rgb
 PIPE_FORMAT_R8_SNORM  , array , 1, 1, sn8 , , , , x001, rgb
-PIPE_FORMAT_R8G8_SNORM, array , 1, 1, sn8 , sn8 , , , xy01, rgb
-PIPE_FORMAT_R8G8B8_SNORM  , array , 1, 1, sn8 , sn8 , sn8 , , xyz1, rgb
-PIPE_FORMAT_R8G8B8A8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , xyzw, rgb
-PIPE_FORMAT_R8G8B8X8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , xyz1, rgb
+PIPE_FORMAT_R8G8_SNORM, array , 1, 1, sn8 , sn8 , , , yx01, rgb
+PIPE_FORMAT_R8G8B8_SNORM  , array , 1, 1, sn8 , sn8 , sn8 , , zyx1, rgb
+PIPE_FORMAT_R8G8B8A8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , wzyx, rgb
+PIPE_FORMAT_R8G8B8X8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , wzy1, rgb
 PIPE_FORMAT_B6G5R5_SNORM  , arith , 1, 1, sn5 , sn5 , sn6 , , xyz1, rgb
-PIPE_FORMAT_A8B8G8R8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , wzyx, rgb
-PIPE_FORMAT_X8B8G8R8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , wzy1, rgb
+PIPE_FORMAT_A8B8G8R8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , xyzw, rgb
+PIPE_FORMAT_X8B8G8R8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , xyz1, rgb
 PIPE_FORMAT_R8_SSCALED, array , 1, 1, s8  , , , , x001, rgb
-PIPE_FORMAT_R8G8_SSCALED  , array , 1, 1, s8  , s8  , , , xy01, rgb
-PIPE_FORMAT_R8G8B8_SSCALED, array , 1, 1, s8  , s8  , s8  , , xyz1, rgb
-PIPE_FORMAT_R8G8B8A8_SSCALED  , array , 1, 1, s8  , s8  , s8  , s8  , xyzw, rgb
-PIPE_FORMAT_R8G8B8X8_SSCALED  , array , 1, 1, s8  , s8  , s8  , s8  , xyz1, rgb
+PIPE_FORMAT_R8G8_SSCALED  , array , 1, 1, s8  , s8  , , , yx01, rgb
+PIPE_FORMAT_R8G8B8_SSCALED, array , 1, 1, s8  , s8  , s8  , , zyx1, rgb
+PIPE_FORMAT_R8G8B8A8_SSCALED  , array , 1, 1, s8  , s8  , s8  , s8  , wzyx, rgb
+PIPE_FORMAT_R8G8B8X8_SSCALED  , a

Re: [Mesa3d-dev] Mesa (master): r300g: remove L8_UNORM from colorbuffer formats

[Marek Olšák]

I still think st/xorg should use R8, which is well defined as to which
component to store, rather than L8. That's also the reason L8 is not
renderable in OpenGL.


2010/2/19 Corbin Simpson 

> Yeah, I would have nak'd this. Will revert when I get home.
>
> Posting from a mobile, pardon my terseness. ~ C.
>
> On Feb 19, 2010 12:56 AM, "Michel Dänzer"  wrote:
>
> On Thu, 2010-02-18 at 19:24 -0800, Marek Olk wrote:
> > Module: Mesa
> > Branch: master
> > Commit: fc427d23439a2702068209957f08990ea29fe21b
> > URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=fc427d23439a2702068209957f08990ea29fe21b
> >
> > Author: Marek Olšák 
> > Date:   Fri Feb 19 04:23:06 2010 +0100
> >
> > r300g: remove L8_UNORM from colorbuffer formats
> >
> > Not renderable in OpenGL anyway.
>
> The Xorg state tracker uses it though.
>
>
> --
> Earthling Michel Dänzer   |http://www.vmware.com
> Libre software enthusiast |  Debian, X and DRI developer
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Mesa (master): r300g: remove L8_UNORM from colorbuffer formats

[Marek Olšák]

Sorry about that. Blitting from L8 to L8 is now broken anyway, I'll look
into it today or tomorrow.

2010/2/19 Corbin Simpson 

> Yeah, I would have nak'd this. Will revert when I get home.
>
> Posting from a mobile, pardon my terseness. ~ C.
>
> On Feb 19, 2010 12:56 AM, "Michel Dänzer"  wrote:
>
> On Thu, 2010-02-18 at 19:24 -0800, Marek Olk wrote:
> > Module: Mesa
> > Branch: master
> > Commit: fc427d23439a2702068209957f08990ea29fe21b
> > URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=fc427d23439a2702068209957f08990ea29fe21b
> >
> > Author: Marek Olšák 
> > Date:   Fri Feb 19 04:23:06 2010 +0100
> >
> > r300g: remove L8_UNORM from colorbuffer formats
> >
> > Not renderable in OpenGL anyway.
>
> The Xorg state tracker uses it though.
>
>
> --
> Earthling Michel Dänzer   |http://www.vmware.com
> Libre software enthusiast |  Debian, X and DRI developer
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Mesa (master): util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats .

[Marek Olšák]

Just an idea...

For hardware supporting arbitrary xyzw01 swizzles, reporting that e.g.
PIPE_CAP_TEXTURE_SWIZZLE is supported should be sufficient. For the other
hardware like i965, a new "swizzle[4]" parameter would need to be added to
is_format_supported. This doesn't raise hardware requirements while allowing
for more flexibility at the same time.

Marek

On Fri, Feb 12, 2010 at 6:28 PM, José Fonseca  wrote:

> On Fri, 2010-02-12 at 06:43 -0800, Roland Scheidegger wrote:
> > On 12.02.2010 14:44, michal wrote:
> > > Keith Whitwell wrote on 2010-02-12 14:28:
> > >> On Fri, 2010-02-12 at 05:09 -0800, michal wrote:
> > >>
> > >>> Keith Whitwell wrote on 2010-02-12 13:39:
> > >>>
> >  On Fri, 2010-02-12 at 04:32 -0800, Micha?? Kr??l wrote:
> > 
> > 
> > > Module: Mesa
> > > Branch: master
> > > Commit: aa0b671422880b99dc178d43d1e4e1a3f766bf7f
> > > URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=aa0b671422880b99dc178d43d1e4e1a3f766bf7f
> > >
> > > Author: Michal Krol 
> > > Date:   Fri Feb 12 13:32:35 2010 +0100
> > >
> > > util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats.
> > >
> > >
> >  Michal,
> > 
> >  Is this more like two different users expecting two different
> results in
> >  those unused columns?
> > 
> >  In particular, we definitely require the missing elements to be
> extended
> >  to (0,0,0,1) when fetching vertex data, and probably also in OpenGL
> >  texture sampling (if we supported these formats for that).
> > 
> > 
> > 
> > >>> Gallium should follow D3D rules, so I've been following D3D here.
> Also,
> > >>> util_unpack_color_ub() in u_pack_color.h already sets the remaining
> > >>> fields to 0xff.
> > >>>
> > >>> Note that D3D doesn't have the problem with expanding vertex
> attribute
> > >>> data since you can't have X or XY vertex positions, only XYZ (with W
> > >>> extended to 1 as in GL) and XYZW.
> > >>>
> > >> But surely D3D permits two-component texture coordinates, which would
> be
> > >> PIPE_FORMAT_R32G32_FLOAT, and expanded as (r,g,0,1)...
> > >>
> > >>
> >  Brian added a table of differences between GL and other APIs
> recently to
> >  gallium/docs - does your change agree with that?
> > 
> > 
> > 
> > >>> Where's that exactly, I can't find it?
> > >>>
> > >> It seems like we'd want to be able to support both usages - the
> > >> alternative in texture sampling would be forcing the state tracker to
> > >> generate varients of the shader when 2-component textures are bound.
>  I
> > >> would say that's an unreasonable requirement on the state tracker.
> > >>
> > >> It seems like in GL would want (0,0,0,1) expansion everywhere, but D3D
> > >> would want differing expansions in different parts of the pipeline.
> > >> That indicates a single flag in the context somewhere isn't sufficient
> > >> to choose between the two.
> > >>
> > >> Maybe there need to be two versions of these PIPE_FORMAT_ enums to
> > >> capture the different values in the missing components?
> > >>
> > >> EG:
> > >>
> > >>PIPE_FORMAT_R32G32_0001_FLOAT
> > >>PIPE_FORMAT_R32G32__FLOAT
> > >>
> > >> ? or something along those lines??
> > >>
> > >>
> > >
> > > You are right.
> > >
> > > Alternatively, follow the more sane API (GL apparently), assume 0001 as
> > > default and use the  infix to override.
> >
> > Note it's not just GL. D3D10 uses same expansion. Only D3D9 is
> > different. Well for texture sampling anyway, I don't know what d3d does
> > for vertex formats.
> >
> > Though for most hardware it would make sense to have only one format per
> > different expansion, and use some swizzling parameter for sampling,
> > because that's actually how the hardware works. But not all drivers will
> > be able to do this, unfortunately.
>
> You mean, having a swizzle in pipe_sampler_state ?
>
> It sounds a good idea.
>
> In the worst case some component will inevitably need to make shader
> variants with different swizzles. In this case it probably makes sense
> to be the pipe driver -- it's a tiny shader variation which could be
> done without recompiling the whole shader, but if the state tracker does
> it then the pipe driver will always have to recompile.
>
> In the best case it is handled by the hardware's texture sampling unit.
>
> It's in theory similar to baking the swizzle in the format as Keith
> suggested, but cleaner IMHO. The question is whether it makes sense to
> have full xwyz01 swizzles, or just 01 swizzles.
>
> Jose
>
>
>
> --
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH 0/6] piglit relax precision requirements

[Marek Olšák]

Eric,

yes, it does.

I decided to resolve my precision issues using glDisable(GL_DITHER). The two
patches disable dithering, the former in piglit and the latter in glean. I
see no point in separating them to smaller ones but I can do that if you
like. Since it's tricky to test dithering anyway, disabling it is
preferable. Could you please push the first one if there are no objections?

Brian,

Could you please push the second one into glean if there are no objections?

-Marek

On Thu, Feb 11, 2010 at 1:42 AM, Eric Anholt  wrote:

> On Sun, 7 Feb 2010 05:38:01 +0100, Marek Olšák  wrote:
> > The attached patch series relaxes precision requirements for 6 tests to
> pass
> > on r300g.
> >
> > Please review/push.
>
> I just pushed a change to do the r300relax type path always on cubemap
> and fbo-cubemap.  It sounds like the decision was that the dithering at
> 32bpp was doing strange things and the solution was to just disable it
> in that case -- right?  If so, does that leave any patches still to be
> committed for the piglit side of things?
>
>
From dc274f1caf050f23f8489f316c52621df679e87b Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Wed, 10 Feb 2010 02:00:17 +0100
Subject: [PATCH 1/4] copytexsubimage,fbo-pbo-readpixels-small,tex3d: disable dithering

---
 tests/fbo/fbo-pbo-readpixels-small.c |2 ++
 tests/texturing/copytexsubimage.c|2 ++
 tests/texturing/tex3d.c  |2 ++
 3 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/tests/fbo/fbo-pbo-readpixels-small.c b/tests/fbo/fbo-pbo-readpixels-small.c
index 09740d2..1f50700 100644
--- a/tests/fbo/fbo-pbo-readpixels-small.c
+++ b/tests/fbo/fbo-pbo-readpixels-small.c
@@ -161,4 +161,6 @@ void piglit_init(int argc, char **argv)
 {
 	piglit_require_extension("GL_EXT_framebuffer_object");
 	piglit_require_extension("GL_ARB_pixel_buffer_object");
+
+	glDisable(GL_DITHER);
 }
diff --git a/tests/texturing/copytexsubimage.c b/tests/texturing/copytexsubimage.c
index 481c731..2e79174 100644
--- a/tests/texturing/copytexsubimage.c
+++ b/tests/texturing/copytexsubimage.c
@@ -264,6 +264,8 @@ static void display(void)
 
 static void init(void)
 {
+	glDisable(GL_DITHER);
+
 	glMatrixMode( GL_PROJECTION );
 	glPushMatrix();
 	glLoadIdentity();
diff --git a/tests/texturing/tex3d.c b/tests/texturing/tex3d.c
index c3854f9..1647d82 100644
--- a/tests/texturing/tex3d.c
+++ b/tests/texturing/tex3d.c
@@ -226,6 +226,8 @@ piglit_init(int argc, char **argv)
 
 	glutReshapeFunc(Reshape);
 
+	glDisable(GL_DITHER);
+
 	glGenTextures(1, &Texture);
 	glBindTexture(GL_TEXTURE_3D, Texture);
 	Reshape(piglit_width, piglit_height);
-- 
1.6.3.3

From 7e9a5849689b78f0ac0275e9fde6b4b78f1aab1d Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Thu, 11 Feb 2010 00:16:56 +0100
Subject: [PATCH 4/4] glean/clipFlat,fbo,texture_srgb: disable dithering

---
 tests/glean/tclipflat.cpp |1 +
 tests/glean/tfbo.cpp  |2 ++
 tests/glean/ttexture_srgb.cpp |2 ++
 3 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/tests/glean/tclipflat.cpp b/tests/glean/tclipflat.cpp
index a2798c0..db5726d 100644
--- a/tests/glean/tclipflat.cpp
+++ b/tests/glean/tclipflat.cpp
@@ -200,6 +200,7 @@ ClipFlatTest::setup(void)
glFrontFace(GL_CW);
glCullFace(GL_FRONT);
glEnable(GL_CULL_FACE);
+   glDisable(GL_DITHER);
 
provoking_vertex_first = GLUtils::haveExtension("GL_EXT_provoking_vertex");
 
diff --git a/tests/glean/tfbo.cpp b/tests/glean/tfbo.cpp
index d76fc2d..fda1da0 100644
--- a/tests/glean/tfbo.cpp
+++ b/tests/glean/tfbo.cpp
@@ -85,6 +85,8 @@ FBOTest::setup(void)
 glDrawBuffer(GL_FRONT);
 glReadBuffer(GL_FRONT);
 
+glDisable(GL_DITHER);
+
 // compute error tolerances (may need fine-tuning)
 int bufferBits[5];
 
diff --git a/tests/glean/ttexture_srgb.cpp b/tests/glean/ttexture_srgb.cpp
index e27081b..7a85a3d 100644
--- a/tests/glean/ttexture_srgb.cpp
+++ b/tests/glean/ttexture_srgb.cpp
@@ -172,6 +172,8 @@ TextureSRGBTest::testTextureFormat(GLenum intFormat, GLint components,
 	glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
 	glEnable(GL_TEXTURE_2D);
 
+	glDisable(GL_DITHER);
+
 	glDrawBuffer(GL_FRONT);
 	glReadBuffer(GL_FRONT);
 
-- 
1.6.3.3

--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] piglit statistics of swrast, softpipe, r300c, and r300g

[Marek Olšák]

Hi,

I noticed that quite a lot of piglit tests fail with swrast and softpipe. I
was asked for sending my stats to ML so that people working on the software
rasterizers are aware of that (I guess they already know). Please see this
page:

http://storm.unas.cz/drivers_compared/

The parser tests and some pretty long tests are not included. The ratio
pass/all is highest for r300c and lowest for more feature-rich r300g but
swrast is worse than softpipe which is a shame.

Tested with git master on 6th February 2010.
r300g stats are the only ones not tested with pure git master but with my
own additional patches in my private (localhost) repo.

Best regards

Marek
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH 0/6] piglit relax precision requirements

[Marek Olšák]

On Mon, Feb 8, 2010 at 6:48 PM, Eric Anholt  wrote:

> On Sun, 7 Feb 2010 05:38:01 +0100, Marek Olšák  wrote:
> > The attached patch series relaxes precision requirements for 6 tests to
> pass
> > on r300g.
> >
> > Please review/push.
>
> Have you tried getting the glean components pushed to the glean project?
> I'd rather not carry functional differences from glean where we don't
> have to.
>
I was under the impression that glean has been merged into piglit. Is there
any reason to keep it separate?


>
> Intel has issues on the cubemap tests at 2x2 and lower as well.  I'm
> wondering -- are closed drivers the same in this respect?
>
Unfortunately yes, they are.
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH 0/6] piglit relax precision requirements

[Marek Olšák]

The real issue is that dithering is enabled on all framebuffer formats,
including 32 bpp ones. This way I "think" the R300 hardware can make the
resulting image be perceived as having more bpp than 32. Maybe I should have
consulted this feature with other Radeon developers to see whether this is
true or not. However I am pretty sure that at least 4 tests fail because of
this. glDisable(GL_DITHER) would help too.

On Mon, Feb 8, 2010 at 4:38 PM, Keith Whitwell  wrote:

> On Mon, 2010-02-08 at 07:20 -0800, Brian Paul wrote:
> > be propagated through the pipeline when doing flat
> > shading, no lighting, etc.
>
> Is this is the perennial problem that GL's float->unorm and unorm->float
> conversion rules are not strict inverses of one another?  IE, if you
> take 255, convert to float, convert back to int, do you get 255?
>
> Keith
>
>
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [PATCH 0/6] piglit relax precision requirements

[Marek Olšák]

The attached patch series relaxes precision requirements for 6 tests to pass
on r300g.

Please review/push.

Marek
From cf3ce2ffd3171fdefb4c9948d33353e0172499ce Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Tue, 24 Nov 2009 12:37:04 +0100
Subject: [PATCH 1/6] texture_srgb: add 1 bit tolerance

---
 tests/glean/ttexture_srgb.cpp |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tests/glean/ttexture_srgb.cpp b/tests/glean/ttexture_srgb.cpp
index e27081b..d138289 100644
--- a/tests/glean/ttexture_srgb.cpp
+++ b/tests/glean/ttexture_srgb.cpp
@@ -155,7 +155,7 @@ TextureSRGBTest::testTextureFormat(GLenum intFormat, GLint components,
 
 	glGetIntegerv(GL_RED_BITS, &redBits);
 	glGetIntegerv(GL_ALPHA_BITS, &alphaBits);
-	const float tolerance = 1.0 / ((1 << redBits) - 1);
+	const float tolerance = 1.0 / ((1 << (redBits - 1)) - 1);
 
 	// setup matrices
 	glMatrixMode(GL_PROJECTION);
-- 
1.6.3.3

From 0aee398474de76ba552593d1e4b5d5800ae18bc8 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Tue, 24 Nov 2009 12:38:16 +0100
Subject: [PATCH 2/6] copytexsubimage: add 1 bit tolerance

---
 tests/texturing/copytexsubimage.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/texturing/copytexsubimage.c b/tests/texturing/copytexsubimage.c
index 481c731..c073c84 100644
--- a/tests/texturing/copytexsubimage.c
+++ b/tests/texturing/copytexsubimage.c
@@ -84,9 +84,9 @@ check_results(int dstx, int dsty, int w, int h)
 expected[2] = 0.0;
 			}
 
-			if (results[(y * w + x) * 4 + 0] != expected[0] ||
-			results[(y * w + x) * 4 + 1] != expected[1] ||
-			results[(y * w + x) * 4 + 2] != expected[2]) {
+			if (abs(results[(y * w + x) * 4 + 0] - expected[0]) > 1 ||
+			abs(results[(y * w + x) * 4 + 1] - expected[1]) > 1 ||
+			abs(results[(y * w + x) * 4 + 2] - expected[2]) > 1) {
 printf("Expected at (%d,%d): %f,%f,%f\n",
    x, y,
    expected[0], expected[1], expected[2]);
-- 
1.6.3.3

From 012a1059888f080caef56627aafe434b8ccc65c3 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Tue, 24 Nov 2009 12:41:22 +0100
Subject: [PATCH 3/6] tex3d: add 1 bit tolerance

---
 tests/texturing/tex3d.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tests/texturing/tex3d.c b/tests/texturing/tex3d.c
index c3854f9..92fa6f1 100644
--- a/tests/texturing/tex3d.c
+++ b/tests/texturing/tex3d.c
@@ -132,7 +132,7 @@ static int render_and_check(int w, int h, int d, GLenum format, float q, unsigne
 int i;
 expected_rgba(format, texp, expected);
 for(i = 0; i < 4; ++i) {
-	if (expected[i] != readp[i]) {
+	if (abs(expected[i] - readp[i]) > 1) {
 		fprintf(stderr, "%s: Mismatch at %ix%ix%i\n", test, x, y, z);
 		fprintf(stderr, " Expected: %i,%i,%i,%i\n",
 			expected[0], expected[1], expected[2], expected[3]);
-- 
1.6.3.3

From 37e30f15094d8d59358a6bcd63e09ae006609d87 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Fri, 27 Nov 2009 02:51:34 +0100
Subject: [PATCH 4/6] fbo-cubemap: relax requirements for r300 in a way similar to texturing/cubemap

---
 tests/fbo/fbo-cubemap.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/tests/fbo/fbo-cubemap.c b/tests/fbo/fbo-cubemap.c
index 5836ce6..7e76a4c 100644
--- a/tests/fbo/fbo-cubemap.c
+++ b/tests/fbo/fbo-cubemap.c
@@ -38,6 +38,7 @@
 int piglit_width = 200;
 int piglit_height = 100;
 int piglit_window_mode = GLUT_DOUBLE | GLUT_RGB;
+static GLboolean hack_r300relax = GL_FALSE;
 
 float face_color[7][4] = {
 	{1.0, 0.0, 0.0, 0.0},
@@ -193,6 +194,9 @@ piglit_display(void)
 		int level = 0;
 
 		for (dim = BUF_WIDTH; dim > 0; dim >>= 1) {
+			if (hack_r300relax && dim <= 2)
+break;
+
 			pass &= test_face_drawing(x, y, dim,
 		  get_face_color(face, level));
 			y += dim + 1;
@@ -209,6 +213,14 @@ piglit_display(void)
 
 void piglit_init(int argc, char **argv)
 {
+	int i;
+
+	for (i = 1; i < argc; i++)
+	if (!strcmp(argv[i], "-r300relax")) {
+	hack_r300relax = GL_TRUE;
+	break;
+	}
+
 	piglit_require_extension("GL_EXT_framebuffer_object");
 	piglit_require_extension("GL_ARB_texture_cube_map");
 }
-- 
1.6.3.3

From ab823f6a6437f8b6e44e7c0cb18de7e98eea4662 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Mon, 14 Dec 2009 07:18:12 +0100
Subject: [PATCH 5/6] glean/clipFlat: relax requirements to pass

---
 tests/glean/tclipflat.cpp |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tests/glean/tclipflat.cpp b/tests/glean/tclipflat.cpp
index a2798c0..db8581e 100644
--- a/tests/glean/tclipflat.cpp
+++ b/tests/glean/tclipflat.cpp
@@ -271,7 +271,7 @@ ClipFlatTest::checkResult(Window &w, GLfloat badColor[3])
 // black - OK
  }
  else if (image[k + 0] == 0 &&
-  image[k + 1] == 255 &&
+  image[k + 1] >= 2

Re: [Mesa3d-dev] [PATCH] gallium, r300g: add PIPE_CAP_QUADS_DONT_FLATSHADE_FIRST

[Marek Olšák]

OK then, I attached another patch which fixes st/mesa to match the docs.

On Sat, Feb 6, 2010 at 9:57 PM, Corbin Simpson wrote:

> I addressed this in the docs already, see the note in flatshade_first in
> Rasterizer. In short, we should always provoke quads GL-style.
>
> Posting from a mobile, pardon my terseness. ~ C.
>
> On Feb 6, 2010 12:39 PM, "Marek Olšák"  wrote:
>
> Hi,
>
> I got some time to revisit the issue from December regarding quads not
> following the first provoking vertex convention.
>
> The attached patch adds PIPE_CAP_QUADS_DONT_FLATSHADE_FIRST to gallium,
> which gets propagated to the return value of
> glGet*(GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION, ...).
>
> Please review/push.
>
> Marek
>
> On Fri, Dec 18, 2009 at 10:58 AM, José Fonseca wrote:
>
>> On Thu, 2009-12-17 at 20:41 -0800, Marek Olšák wrote:
>> > 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 for this capability in
>> > Gallium, as it appears R3xx-R5xx hardware doesn't support the first
>> > vertex convention for quads and I'd like the driver to behave
>> > correctly. Fortunately, other primitive types are supported.
>> >
>> > I decided to use the name "quads follow flatshade_first convention"
>> > instead of "provoking vertex convention" because the actual state
>> > variable in pipe_rasterizer_state is called flatshade_first.
>> >
>> > The attached patch:
>> > - adds PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION
>> > - adds the query in the Mesa state tracker
>> > - and updates softpipe and llvmpipe to return 1 when this cap is
>> > queried, and r300g to explicitly return 0
>> >
>> > Please review/push.
>> >
>> > Cheers.
>> >
>> > Marek
>>
>> Hi Marek,
>>
>> One problem I have with this patch and many of past get_param changes
>> for that matter, is that it changes default behavior and forces all pipe
>> drivers to be updated. It is not the first time that a get_param changes
>> broke drivers because it. I happened with
>> PIPE_CAP_BLEND_EQUATION_SEPARATE.
>>
>> As the number of drivers is increases this is a no-no. It also
>> complicates writing drivers since they have to answer a large number of
>> queries, most of which are specific to one or two particular hardware
>> devices.
>>
>> IMO, there are two ways to overcome this:
>>
>> a) when introducing new PIPE_CAP_xxx have its semantics such that 0 will
>> yield the previous behavior
>>
>> b) change get_param/paramf prototype so that it is passed the default
>> value as an argument.
>>
>> That said, reading
>> http://www.opengl.org/registry/specs/EXT/provoking_vertex.txt , issue #2
>> (How should quads be handled?) it seems that 0 is actually a better
>> default -- provoking vertex of quads does not apply to D3D and is only
>> relevant for that extension. So I don't oppose for this to go in as is.
>>
>> But, independent of this change, lets fix the get_param/paramf calls.
>> Keith, does b) above sound good to you?
>>
>> Jose
>>
>>
>
>
> --
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>
From 428df3b258826857eb225b6eaf142fa2c80b649e Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Sat, 6 Feb 2010 23:24:27 +0100
Subject: [PATCH] st/mesa: set QuadsFollowProvokingVertexConvention to GL_FALSE

As per gallium docs.
---
 src/mesa/state_tracker/st_extensions.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c
index f2a62f9..993f36b 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -124,6 +124,8 @@ void st_init_li

[Mesa3d-dev] [PATCH] gallium, r300g: add PIPE_CAP_QUADS_DONT_FLATSHADE_FIRST

[Marek Olšák]

Hi,

I got some time to revisit the issue from December regarding quads not
following the first provoking vertex convention.

The attached patch adds PIPE_CAP_QUADS_DONT_FLATSHADE_FIRST to gallium,
which gets propagated to the return value of
glGet*(GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION, ...).

Please review/push.

Marek

On Fri, Dec 18, 2009 at 10:58 AM, José Fonseca  wrote:

> On Thu, 2009-12-17 at 20:41 -0800, Marek Olšák wrote:
> > 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 for this capability in
> > Gallium, as it appears R3xx-R5xx hardware doesn't support the first
> > vertex convention for quads and I'd like the driver to behave
> > correctly. Fortunately, other primitive types are supported.
> >
> > I decided to use the name "quads follow flatshade_first convention"
> > instead of "provoking vertex convention" because the actual state
> > variable in pipe_rasterizer_state is called flatshade_first.
> >
> > The attached patch:
> > - adds PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION
> > - adds the query in the Mesa state tracker
> > - and updates softpipe and llvmpipe to return 1 when this cap is
> > queried, and r300g to explicitly return 0
> >
> > Please review/push.
> >
> > Cheers.
> >
> > Marek
>
> Hi Marek,
>
> One problem I have with this patch and many of past get_param changes
> for that matter, is that it changes default behavior and forces all pipe
> drivers to be updated. It is not the first time that a get_param changes
> broke drivers because it. I happened with
> PIPE_CAP_BLEND_EQUATION_SEPARATE.
>
> As the number of drivers is increases this is a no-no. It also
> complicates writing drivers since they have to answer a large number of
> queries, most of which are specific to one or two particular hardware
> devices.
>
> IMO, there are two ways to overcome this:
>
> a) when introducing new PIPE_CAP_xxx have its semantics such that 0 will
> yield the previous behavior
>
> b) change get_param/paramf prototype so that it is passed the default
> value as an argument.
>
> That said, reading
> http://www.opengl.org/registry/specs/EXT/provoking_vertex.txt , issue #2
> (How should quads be handled?) it seems that 0 is actually a better
> default -- provoking vertex of quads does not apply to D3D and is only
> relevant for that extension. So I don't oppose for this to go in as is.
>
> But, independent of this change, lets fix the get_param/paramf calls.
> Keith, does b) above sound good to you?
>
> Jose
>
>
From b386423ae0d465ec8d38192a6b47d7b2aed6c95a Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Fri, 18 Dec 2009 05:10:27 +0100
Subject: [PATCH] gallium,r300g: add PIPE_CAP_QUADS_DONT_FLATSHADE_FIRST

---
 src/gallium/drivers/r300/r300_screen.c |2 ++
 src/gallium/include/pipe/p_defines.h   |1 +
 src/mesa/state_tracker/st_extensions.c |3 +++
 3 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/src/gallium/drivers/r300/r300_screen.c b/src/gallium/drivers/r300/r300_screen.c
index 18eecf7..5a2ec59 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/gallium/drivers/r300/r300_screen.c
@@ -165,6 +165,8 @@ static int r300_get_param(struct pipe_screen* pscreen, int param)
 case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
 case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER:
 return 0;
+case PIPE_CAP_QUADS_DONT_FLATSHADE_FIRST:
+return 1;
 default:
 debug_printf("r300: Implementation error: Bad param %d\n",
 param);
diff --git a/src/gallium/include/pipe/p_defines.h b/src/gallium/include/pipe/p_defines.h
index 63ba311..edcd7f7 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -413,6 +413,7 @@ enum pipe_transfer_usage {
 #define PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT 37
 #define PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER 38
 #define PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER 39
+#define PIPE_CAP_QUADS_DONT_FLATSHADE_FIRST 40
 
 
 /**
diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c
index f2a62f9..f0eb98c 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -124,6 +124,9 @@ void st_init_limits(struct st_context *st)
   = CLAMP(screen->get_param(screen, PIPE_CAP_MAX_RENDER_TARGETS),
   1, MAX_DRAW_BUFFERS);
 
+   c->QuadsFollowProvokingVertex

Re: [Mesa3d-dev] Grab bag of random questions (whoo)

[Marek Olšák]

On Sun, Jan 31, 2010 at 1:37 AM, Roland Scheidegger wrote:
>
>
>>7) Is there more information on the dual-source blend modes? I'm not
>>sure if I can do them; might have to bug AMD for the register values.
>>
>> I bet R300 can't do these modes. It's only a Direct3D 10.0 feature, not
>> present in Direct3D 10.1. MS must have a good reason to remove it.
>>
> Where did you see that it's removed in 10.1?
> Here's a list of blend ops in d3d11:
> http://msdn.microsoft.com/en-us/library/ee416042(VS.85).aspx
> Note this feature can be present (via cap bits in some limited form) in
> D3D9Ex too, and I thought windows actually used it for (antialiased) text
> rendering (but don't quote me on that).

You're right. My source was incorrect (OpenGL.org forums).
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Grab bag of random questions (whoo)

[Marek Olšák]

Hi Corbin,

On Sat, Jan 30, 2010 at 1:06 PM, Corbin Simpson
wrote:

> 5) ... Also, on the topic of framebuffers, is
> it okay to refuse to render if no MRTs or Z buffer are present?
>
Do you mean color-only and depth-only rendering? This is a must. Shadow
mapping heavily relies on depth-only rendering. OTOH post-processing effects
like HDR, bloom, depth of field, later parts of deferred-rendering methods,
and many other advanced methods require color-only rendering. The FBO
extensions allows either no color attachment or no depth-stencil attachment.
I know there are inter-CSO depedencies in r300g because of this, but I don't
see any other way around it.

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 the extension could be added to Gallium since the r300 compiler can
generate code for it.

Another
> comment reads, "Gallium doesn't provide us with any information
> regarding this mode, so we are screwed. I'm setting 0 = LUMINANCE,"
> above the texture compare modes. I don't really like that section of
> code, but it probably can't get cleaner, right?
>
Even though this is a rarely used feature in OpenGL nowadays, it should get
fixed if we want to be GL-compliant. That means adding depth texture modes
in pipe_sampler_state and setting them in the Mesa state tracker. The R300
compiler can already generate code for these modes as well.

7) Is there more information on the dual-source blend modes? I'm not
> sure if I can do them; might have to bug AMD for the register values.
>
I bet R300 can't do these modes. It's only a Direct3D 10.0 feature, not
present in Direct3D 10.1. MS must have a good reason to remove it.

BTW I looked at some of your patches and r3xx-r5xx cards don't even support
separate blend enables, therefore the cap should be 0. Or are you going to
emulate this using independent color channel masks and two rendering passes?
That could be done in the state tracker. Also, I think the indep. color
masks are r5xx-only.

Cheers.

Marek
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH 0/2] st/mesa: EXT_framebuffer_multisample and CopyTex[Sub]Image acceleration

[Marek Olšák]

Yes, your patch solves my problem. Thanks.

Marek

On Wed, Jan 20, 2010 at 2:00 AM, Brian Paul  wrote:

> Marek Olšák wrote:
>
>> Hi Brian,
>>
>>
>> On Mon, Jan 18, 2010 at 6:18 PM, Brian Paul > bri...@vmware.com>> wrote:
>>
>>The second patch enables hardware-accelerated CopyTex[Sub]Image
>>in cases when the RGB and RGBA destination formats are used
>>regardless of source formats. The idea is that if the
>>colorbuffer is of RGB or RGBA format, the format conversion for
>>copying between two different surfaces is basically done in
>>texture units (using swizzles), therefore there is no reason to
>>use software fallback. Without this patch, openarena fallbacks
>>to software when bloom is enabled.
>>
>>
>>Did you read the comment at line 1498?  I remember specifically
>>adding this check to fix some issues when copying an RGBA
>>framebuffer to a RGB texture.
>>
>>
>> The behavior of copying an RGBA framebuffer to an RGB texture is not
>> changed by this patch, it is only generalized to support other formats. I
>> agree the diff file is a little bit confusing. See the code before:
>>
>>   else if (srcFormat == GL_RGBA &&
>>dstLogicalFormat == GL_RGB) {
>>  /* Add a single special case to cope with RGBA->RGB transfers,
>>   * setting A to 1.0 to cope with situations where the RGB
>>   * destination is actually stored as RGBA.
>>   */
>>  return TGSI_WRITEMASK_XYZ; /* A ==> 1.0 */
>>   }
>>   else {
>>
>> The code after:
>>
>>   else if (dstLogicalFormat == GL_RGBA) {
>>  /* In theory, any format can be converted to GL_RGBA.
>>   */
>>  return TGSI_WRITEMASK_XYZW;
>>   }
>>   else if (dstLogicalFormat == GL_RGB) {
>>  /* Add a special case to cope with transfers into RGB,
>>   * setting A to 1.0 to cope with situations where the RGB
>>   * destination is actually stored as RGBA.
>>   */
>>  return TGSI_WRITEMASK_XYZ; /* A ==> 1.0 */
>>   }
>>   else {
>>
>> Are you ok with that?
>>
>
> No.  But don't feel bad, I think my original code is broken too. :(
>
> See the attached patch.  It has a bunch of comments that explain what's
> going on.
>
> If you can test this and it seems to solve your problem, I'll commit it.
>
>
>
>  BTW could you please push the first patch (and the second one if you
>> agree)? My account hasn't been created yet. Thank you.
>>
>
> Yes, done.
>
> -Brian
>
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH 0/2] st/mesa: EXT_framebuffer_multisample and CopyTex[Sub]Image acceleration

[Marek Olšák]

Hi Brian,

On Mon, Jan 18, 2010 at 6:18 PM, Brian Paul  wrote:

> The second patch enables hardware-accelerated CopyTex[Sub]Image in cases
>> when the RGB and RGBA destination formats are used regardless of source
>> formats. The idea is that if the colorbuffer is of RGB or RGBA format, the
>> format conversion for copying between two different surfaces is basically
>> done in texture units (using swizzles), therefore there is no reason to use
>> software fallback. Without this patch, openarena fallbacks to software when
>> bloom is enabled.
>>
>
> Did you read the comment at line 1498?  I remember specifically adding this
> check to fix some issues when copying an RGBA framebuffer to a RGB texture.
>

The behavior of copying an RGBA framebuffer to an RGB texture is not changed
by this patch, it is only generalized to support other formats. I agree the
diff file is a little bit confusing. See the code before:

   else if (srcFormat == GL_RGBA &&
dstLogicalFormat == GL_RGB) {
  /* Add a single special case to cope with RGBA->RGB transfers,
   * setting A to 1.0 to cope with situations where the RGB
   * destination is actually stored as RGBA.
   */
  return TGSI_WRITEMASK_XYZ; /* A ==> 1.0 */
   }
   else {

The code after:

   else if (dstLogicalFormat == GL_RGBA) {
  /* In theory, any format can be converted to GL_RGBA.
   */
  return TGSI_WRITEMASK_XYZW;
   }
   else if (dstLogicalFormat == GL_RGB) {
  /* Add a special case to cope with transfers into RGB,
   * setting A to 1.0 to cope with situations where the RGB
   * destination is actually stored as RGBA.
   */
  return TGSI_WRITEMASK_XYZ; /* A ==> 1.0 */
   }
   else {

Are you ok with that?

BTW could you please push the first patch (and the second one if you agree)?
My account hasn't been created yet. Thank you.

Best regards.

Marek
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots

[Marek Olšák]

On Mon, Jan 18, 2010 at 3:22 PM, Luca Barbieri wrote:

> > I think this is not necessary and fixing the rasterizer setup in the
> driver
> > would by better than fixing the state tracker.
> >
> > In r300g, we dynamically allocate rasterizer units based on vertex shader
> > outputs. If the vertex shader uses slots 1, 5, 20, 100, the driver
> maps
> > them to units 1,2,3,4.
>
> But what if the fragment shader has inputs 1, 2, 5, 20, 100?
> If you remap the fragment shader to 1, 2, 3, 4, 5, then they will mismatch.
>
> You would need to either:
> 1. Generate shaders in the driver for the fragment/vertex combination
> instead of each one separately
> 2. Require that vertex shader outputs match fragment shader inputs exactly
>
> (1) makes the driver much more complex and slow. I think we should try
> to make it possible to avoid this, unless the hardware absolutely
> requires it.
> (2) will probably break the existing fixed pipeline and ARB_fp/vp
> support, and also make the driver more complex than necessary.
>
> Does r300g compile both fragment and vertex shader together?
>
> Also note that all Gallium-capable hardware should support 8 varying
> slots, so anything that uses only "texture coordinates" should not
> need any remapping.
>

I was talking about the rasterizer (interpolator) units, which, on r300, are
quite flexible and can read an arbitrary vertex shader output and write it
to an arbitrary fragment shader input (= register address). Given this
flexibility, fragment and vertex shaders are compiled separately in r300g
and semantic indices don't matter, just the total number of varyings.
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots

[Marek Olšák]

Hi Luca,

I think this is not necessary and fixing the rasterizer setup in the driver
would by better than fixing the state tracker.

In r300g, we dynamically allocate rasterizer units based on vertex shader
outputs. If the vertex shader uses slots 1, 5, 20, 100, the driver maps
them to units 1,2,3,4.

Marek

On Sun, Jan 17, 2010 at 8:05 PM, Luca Barbieri wrote:

> The current GLSL linker puts varyings in slots starting from *_VAR0,
> leaving the *_TEX slots used only for gl_TexCoord[i].
>
> This results in TGSI programs that start using generic input/outputs
> with index 10.
>
> Unfortunately, some drivers (e.g. pre-nv50 nouveau) support only 8
> vertex program outputs, and this causes GLSL to not work at all.
> On other cards, GLSL works, but 8 varying slots are lost.
>
> This patch solves the problem by modifying the GLSL linker to allocate
> varyings in texcoord slots that neither vertex nor fragment shader uses.
>
> Note that the GLSL linker is the only place where this can be done,
> because it is the only place that sees both the vertex and fragment
> programs at once.
>
> The only known issue is that if the GLSL program has an indirect
> reference to gl_TexCoord[i], no varyings will be put in texcoord slots.
> This may or may not be desirable.
>
> This makes (a subset of) GLSL work on NV30/NV40 and improves the
> chances of complex programs working on other cards.
>
> Signed-off-by: Luca Barbieri 
> ---
>  src/mesa/shader/slang/slang_link.c |   62
> ++-
>  1 files changed, 46 insertions(+), 16 deletions(-)
>
> diff --git a/src/mesa/shader/slang/slang_link.c
> b/src/mesa/shader/slang/slang_link.c
> index ed27821..889a811 100644
> --- a/src/mesa/shader/slang/slang_link.c
> +++ b/src/mesa/shader/slang/slang_link.c
> @@ -99,9 +99,9 @@ bits_agree(GLbitfield flags1, GLbitfield flags2,
> GLbitfield bit)
>  */
>  static GLboolean
>  link_varying_vars(GLcontext *ctx,
> -  struct gl_shader_program *shProg, struct gl_program
> *prog)
> +  struct gl_shader_program *shProg, struct gl_program
> *prog, GLbyte* varying_slots)
>  {
> -   GLuint *map, i, firstVarying, newFile;
> +   GLuint *map, i, firstTex, firstVarying, newFile;
>GLbitfield *inOutFlags;
>
>map = (GLuint *) _mesa_malloc(prog->Varying->NumParameters *
> sizeof(GLuint));
> @@ -114,13 +114,15 @@ link_varying_vars(GLcontext *ctx,
> * Also, replace File=PROGRAM_VARYING with File=PROGRAM_INPUT/OUTPUT.
> */
>if (prog->Target == GL_VERTEX_PROGRAM_ARB) {
> -  firstVarying = VERT_RESULT_VAR0;
> +  firstTex = VERT_RESULT_TEX0;
> +  firstVarying = VERT_RESULT_VAR0 - 8;
>   newFile = PROGRAM_OUTPUT;
>   inOutFlags = prog->OutputFlags;
>}
>else {
>   assert(prog->Target == GL_FRAGMENT_PROGRAM_ARB);
> -  firstVarying = FRAG_ATTRIB_VAR0;
> +  firstTex = FRAG_ATTRIB_TEX0;
> +  firstVarying = FRAG_ATTRIB_VAR0 - 8;
>   newFile = PROGRAM_INPUT;
>   inOutFlags = prog->InputFlags;
>}
> @@ -173,9 +175,12 @@ link_varying_vars(GLcontext *ctx,
>   {
>  GLint sz = var->Size;
>  while (sz > 0) {
> -inOutFlags[firstVarying + j] = var->Flags;
> +int v = varying_slots[j];
> +v += ((v < 8) ? firstTex : firstVarying);
> +inOutFlags[v] = var->Flags;
> /*printf("Link varying from %d to %d\n", i, j);*/
> -map[i++] = j++;
> +map[i++] = v;
> +++j;
> sz -= 4;
>  }
>  i--; /* go back one */
> @@ -192,13 +197,13 @@ link_varying_vars(GLcontext *ctx,
>
>   if (inst->DstReg.File == PROGRAM_VARYING) {
>  inst->DstReg.File = newFile;
> - inst->DstReg.Index = map[ inst->DstReg.Index ] + firstVarying;
> + inst->DstReg.Index = map[ inst->DstReg.Index ];
>   }
>
>   for (j = 0; j < 3; j++) {
>  if (inst->SrcReg[j].File == PROGRAM_VARYING) {
> inst->SrcReg[j].File = newFile;
> -inst->SrcReg[j].Index = map[ inst->SrcReg[j].Index ] +
> firstVarying;
> +inst->SrcReg[j].Index = map[ inst->SrcReg[j].Index ];
>  }
>   }
>}
> @@ -790,14 +795,39 @@ _slang_link(GLcontext *ctx,
>   ASSERT(shProg->FragmentProgram->Base.RefCount == 1);
>}
>
> -   /* link varying vars */
> -   if (shProg->VertexProgram) {
> -  if (!link_varying_vars(ctx, shProg, &shProg->VertexProgram->Base))
> - return;
> -   }
> -   if (shProg->FragmentProgram) {
> -  if (!link_varying_vars(ctx, shProg, &shProg->FragmentProgram->Base))
> - return;
> +   {
> +  GLuint texcoord_mask = 0;
> +  GLbyte varying_slots[MAX_VARYING];
> +  GLuint next_varying = 0;
> +
> +  if(shProg->VertexProgram)
> +  {
> +_slang_update_inputs_outputs(&shProg->VertexProgram->Base);
> +texcoord_mask |= (shProg->VertexProgram->Base.OutputsWritten
> >> VERT_RESULT_TEX0) & 0xff;
> +  }
> +  if(shProg->FragmentPr

[Mesa3d-dev] [PATCH 0/2] st/mesa: EXT_framebuffer_multisample and CopyTex[Sub]Image acceleration

[Marek Olšák]

Hi,

the first patch enables EXT_framebuffer_multisample in st/mesa. This
extension appears to alias ARB_fbo functions and there's no other checking
for multisampling in st/mesa where ARB_fbo is being enabled, so
fbo_multisample could be enabled by default.

The second patch enables hardware-accelerated CopyTex[Sub]Image in cases
when the RGB and RGBA destination formats are used regardless of source
formats. The idea is that if the colorbuffer is of RGB or RGBA format, the
format conversion for copying between two different surfaces is basically
done in texture units (using swizzles), therefore there is no reason to use
software fallback. Without this patch, openarena fallbacks to software when
bloom is enabled.

Please review.

Best regards.

Marek
From 80d9b69f00f72b106784c21a7d5a63c985e3bc0a Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Wed, 6 Jan 2010 14:27:50 +0100
Subject: [PATCH 1/2] st/mesa: enable EXT_framebuffer_multisample

---
 src/mesa/state_tracker/st_extensions.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c
index 35e0874..a94236b 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -168,6 +168,7 @@ void st_init_extensions(struct st_context *st)
ctx->Extensions.EXT_blend_subtract = GL_TRUE;
ctx->Extensions.EXT_framebuffer_blit = GL_TRUE;
ctx->Extensions.EXT_framebuffer_object = GL_TRUE;
+   ctx->Extensions.EXT_framebuffer_multisample = GL_TRUE;
ctx->Extensions.EXT_fog_coord = GL_TRUE;
ctx->Extensions.EXT_multi_draw_arrays = GL_TRUE;
ctx->Extensions.EXT_pixel_buffer_object = GL_TRUE;
-- 
1.6.3.3

From d41fc110bf5a32ecf44e74b6094140610d643739 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Tue, 29 Dec 2009 15:17:13 +0100
Subject: [PATCH 2/2] st/mesa: always use accelerated CopyTex[Sub]Image for RGB and RGBA dest buffers

Later on we might do the same thing for R/RG buffers.
---
 src/mesa/state_tracker/st_cb_texture.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_texture.c b/src/mesa/state_tracker/st_cb_texture.c
index f01053c..d57304e 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1381,9 +1381,13 @@ compatible_src_dst_formats(const struct gl_renderbuffer *src,
*/
   return TGSI_WRITEMASK_XYZW;
}
-   else if (srcFormat == GL_RGBA &&
-dstLogicalFormat == GL_RGB) {
-  /* Add a single special case to cope with RGBA->RGB transfers,
+   else if (dstLogicalFormat == GL_RGBA) {
+  /* In theory, any format can be converted to GL_RGBA.
+   */
+  return TGSI_WRITEMASK_XYZW;
+   }
+   else if (dstLogicalFormat == GL_RGB) {
+  /* Add a special case to cope with transfers into RGB,
* setting A to 1.0 to cope with situations where the RGB
* destination is actually stored as RGBA.
*/
-- 
1.6.3.3

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Running with scissors

[Marek Olšák]

It was NOT intended to be a performance optimization, it's a fix. I added it
because kernel would have rejected the command stream if everything had been
culled by scissoring.

Marek

On Mon, Jan 11, 2010 at 4:39 PM, Corbin Simpson
wrote:

> Pardon the subject pun, it was totally necessary at this early hour. :3
>
> If the scissor test is enabled, and the scissors obscure the entire
> framebuffer, should drawing calls still be run? Talking on IRC, it
> seems like there's a valid use-case for performance testing, and I'm
> of the mind that anybody that deliberately sets up the pipeline and
> scissor that way probably intended for it.
>
> I just want a clarification so I know whether I should revert
> bfcafbe15dc, and also I wanted to document it.
>
> ~ C.
>
> --
> Only fools are easily impressed by what is only
> barely beyond their reach. ~ Unknown
>
> Corbin Simpson
> 
>
>
> --
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] geometry shading patches

[Marek Olšák]

Zack,

to be honest, Direct3D 11 can report geometry shaders are not supported
through so-called feature levels. There are six levels to my knowledge (9_1,
9_2, 9_3, 10_0, 10_1, 11_0). i915 is 9_1, R300 is 9_2, R500 is 9_3, and so
on. Direct3D 11 is indeed accelerated on those pieces of hardware and,
though the feature set is a little limited, the hardware support is covered
well. Is Direct3D 11 generations past because of that? No, it isn't.

Let's say I have R500 and I want to use geometry shaders in Direct3D 11.
What are my options? I can't use my R500 and I must manually switch to the
device called WARP (Windows Advanced Rasterization Platform), which reports
the 10_1 feature level. This kind of device is very similar to llvmpipe in
Gallium.

In the past you said we should do it the same way as Direct3D, so why should
Gallium be different now? Moreover, if applications decide to use geometry
shaders to emulate point sprites or wide lines, we'll be screwed. If they
decide to do texture fetches in geometry shaders, we'll be screwed even more
because we'll have to move textures out of VRAM and that will be a total
performance killer. So I agree with Corbin that the CAP for geometry shaders
should be added and we should let drivers decide what's best for them.

Marek

On Fri, Dec 25, 2009 at 5:11 PM, Zack Rusin  wrote:

> On Friday 25 December 2009 07:03:02 Corbin Simpson wrote:
> > Isn't this incredibly at odds with our previous discussion, in which
> > we generally agreed to not advertise support for unaccelerated things?
>
> No, it's really not. We don't have caps for core features, e.g we don't
> have
> caps for vertex shaders and this goes hand in hand with that. Geometry
> shaders
> are optional in the pipeline meaning that unlike fragment shaders they can
> be
> absent in which case the pipeline behaves just like it would if the api
> didn't
> have geometry shaders exposed at all i.e. vertex shader outputs go directly
> do
> the fragment shader. So for games/apps that don't use geometry shaders this
> won't matter at all. And games/app that are so new that they actually check
> for geometry shaders will already be slow on i915 and r300 not because of
> geometry shaders, but because they're running on it on i915 or r300 =)
>
> Not to mention that this is not a fringe feature that will be present only
> in
> super high-end and futuristic hardware.
>
> All in all it's a bit like fixed-point hardware - programmable hardware is
> not
> a cap because it's what Gallium models. We can't just keep the Gallium
> interface at i915 level and mark everything above that as a cap, it'd be
> silly
> given that we're generations past that now.
>
> z
>
>
> --
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Yet more r300g fear and loathing...

[Marek Olšák]

I am not very fond of the idea having another layer of function-call
indirections and state management between a driver and a state tracker. I
kinda succeed in making the failover driver work with some hacks and
limitations (e.g. no textures). Even if I use it as a simple pass-through
driver, it results in 40% performance drop in glxgears and 10% performance
drop in progs/perf/draw_overhead. The driver overhead is a real issue here
and it might be much higher with a full-blown fallback driver, and nobody
wants the performance to suck so much. Also I'd like the applications which
don't hit any fallback path to not be affected by this additional overhead,
so putting a fallback driver on top of a real driver should be deferred if
possible which makes this whole thing non-trivial.

In the meantime I think we could lie that NPOTs are supported and implement
only the functionality state trackers really want (2D textures with the
repeat wrap mode and bilinear filtering done in the shader [0]). That would
make all state trackers happy except the Mesa one, but doing software
fallback instead would not make it happy either. We're talking about turning
unavailable features to unusable ones, is it worth it?

[0] I think I could do it if someone tells me how to easily replace TEX
instructions with my own code in TGSI.

Marek

On Mon, Dec 21, 2009 at 6:57 PM, Jakob Bornecrantz  wrote:

> To be honest I'm way more in favor off doing 4 and/or with a env
> variable to switch between incorrect rendering and software fallbacks,
> but maybe we can do 3 but with another solution.
>
> At some point the Gallium interface was a expression of what hardware
> could do not a interface to program against. Another guiding rule was
> that it should be easy to write a pipe driver, putting all the hard
> stuff in the state tracker.
>
> Now we are starting to see a lot of state trackers and its becoming
> harder and harder to implement all the work around for the different
> caps. Even tho the fallback/workaround code is in a module that can be
> shared its still a pain to integrate and a lot of boiler plate code
> needs to be written and maintained.
>
> Maybe we should revive the fallback module or make a another module
> like it that takes care of all these shortcomings of the hardware. But
> it is optional to the state tracker. That it is optional to the state
> tracker is the big thing.
>
> So an usecase:
> The mesa state tracker takes a look at the pipe caps of the r300
> driver and notices something bad no CAP_NPOT but CAP_TEXRECT. It then
> wraps the pipe driver with the fallback pipe driver and uses that. And
> all the NPOT badness is hidden from the state tracker.
>
> The code to switch between software and and hardwware rendering only
> needs to be written once this includes the code to detect IF we should
> switch to software and code to select between different modes of
> handling of different type of errors, like FALLBACK_CONFORM,
> FALLBACK_BAD_RENDERING.
>
> The good part with this is that the fallback module is optional and
> for state trackers that can handle some of the possible shortcomings
> or doesn't need all of the functionality don't need to wrap the pipe
> driver.
>
> We get clean drivers, clean state tracker but a heap of code in the
> fallback module...
>
> I could also see the blitter module getting sucked into the fallback
> module.
>
> Comments please?
>
> Cheers Jakob.
>
>
> --
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] Mystery of u_format.csv

[Marek Olšák]

Hi,

I noticed that gallium/auxiliary/util/u_format.csv contains some weird
swizzling, for example see this:

$ grep zyxw u_format.csv
PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 ,
zyxw, rgb
PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 ,
zyxw, rgb
PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 ,
zyxw, rgb
PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 ,
zyxw, rgb
PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8  , u8  , u8  , u8  ,
zyxw, srgb

It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling.
Let's continue our journey:

$ grep A8R8G8B8 u_format.csv
PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 ,
zyxw, rgb
PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8  , u8  , u8  , u8  ,
wxyz, srgb

Same formats, different swizzling? Also:

$ grep B8G8R8A8 u_format.csv
PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 ,
yzwx, rgb
PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8  , u8  , u8  , u8  ,
zyxw, srgb

Same formats, different swizzling? I don't really get it. And there's much
more cases like these. Could someone tell me what the intended order of
channels should be? (or possibly propose a fix) The meaning of the whole
table is self-contradictory and it's definitely the source of some r300g
bugs.

Marek
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION

[Marek Olšák]

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 for this capability in
Gallium, as it appears R3xx-R5xx hardware doesn't support the first
vertex convention for quads and I'd like the driver to behave
correctly. Fortunately, other primitive types are supported.

I decided to use the name "quads follow flatshade_first convention"
instead of "provoking vertex convention" because the actual state
variable in pipe_rasterizer_state is called flatshade_first.

The attached patch:
- adds PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION
- adds the query in the Mesa state tracker
- and updates softpipe and llvmpipe to return 1 when this cap is
queried, and r300g to explicitly return 0

Please review/push.

Cheers.

Marek
From bbf279f81e03a6872507cbf533b382748c4ae015 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Fri, 18 Dec 2009 05:10:27 +0100
Subject: [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION

---
 src/gallium/drivers/llvmpipe/lp_screen.c |2 ++
 src/gallium/drivers/r300/r300_screen.c   |2 ++
 src/gallium/drivers/softpipe/sp_screen.c |2 ++
 src/gallium/include/pipe/p_defines.h |1 +
 src/mesa/state_tracker/st_extensions.c   |4 
 5 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c
index 9b47415..fa786f9 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -110,6 +110,8 @@ llvmpipe_get_param(struct pipe_screen *screen, int param)
   return 1;
case PIPE_CAP_BLEND_EQUATION_SEPARATE:
   return 1;
+   case PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION:
+  return 1;
default:
   return 0;
}
diff --git a/src/gallium/drivers/r300/r300_screen.c b/src/gallium/drivers/r300/r300_screen.c
index c2ea9b6..0b75ecf 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/gallium/drivers/r300/r300_screen.c
@@ -138,6 +138,8 @@ static int r300_get_param(struct pipe_screen* pscreen, int param)
 return 0;
 case PIPE_CAP_BLEND_EQUATION_SEPARATE:
 return 1;
+case PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION:
+return 0;
 default:
 debug_printf("r300: Implementation error: Bad param %d\n",
 param);
diff --git a/src/gallium/drivers/softpipe/sp_screen.c b/src/gallium/drivers/softpipe/sp_screen.c
index bd3532d..510150b 100644
--- a/src/gallium/drivers/softpipe/sp_screen.c
+++ b/src/gallium/drivers/softpipe/sp_screen.c
@@ -91,6 +91,8 @@ softpipe_get_param(struct pipe_screen *screen, int param)
   return 1;
case PIPE_CAP_BLEND_EQUATION_SEPARATE:
   return 1;
+   case PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION:
+  return 1;
default:
   return 0;
}
diff --git a/src/gallium/include/pipe/p_defines.h b/src/gallium/include/pipe/p_defines.h
index fe1390d..6a37893 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -393,6 +393,7 @@ enum pipe_transfer_usage {
 #define PIPE_CAP_MAX_PREDICATE_REGISTERS 30
 #define PIPE_CAP_MAX_COMBINED_SAMPLERS   31  /*< Maximum texture image units accessible from vertex
  and fragment shaders combined */
+#define PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION 32
 
 
 /**
diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c
index ef3cbc5..db3380b 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -125,6 +125,10 @@ void st_init_limits(struct st_context *st)
   = CLAMP(screen->get_param(screen, PIPE_CAP_MAX_RENDER_TARGETS),
   1, MAX_DRAW_BUFFERS);
 
+   c->QuadsFollowProvokingVertexConvention
+  = CLAMP(screen->get_param(screen, PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION),
+  0, 1);
+
/* Is TGSI_OPCODE_CONT supported? */
/* XXX separate query for early function return? */
st->ctx->Shader.EmitContReturn =
-- 
1.6.3.3

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Mesa (master): r300g: flush CS if a buffer being deleted is referenced by it

[Marek Olšák]

2009/12/16 Michel Dänzer :
> On Tue, 2009-12-15 at 19:04 -0800, Corbin Simpson wrote:
>> Module: Mesa
>> Branch: master
>> Commit: 417ce06306962a9355cbb35cefcdea1951b0ce85
>> URL:    
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=417ce06306962a9355cbb35cefcdea1951b0ce85
>>
>> Author: Marek Olšák 
>> Date:   Sat Dec 12 23:44:02 2009 +0100
>>
>> r300g: flush CS if a buffer being deleted is referenced by it
>
> [...]
>
>> diff --git a/src/gallium/winsys/drm/radeon/core/radeon_buffer.c 
>> b/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
>> index 2a8daed..76acc99 100644
>> --- a/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
>> +++ b/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
>> @@ -131,6 +132,11 @@ static void radeon_buffer_del(struct pipe_buffer 
>> *buffer)
>>  {
>>      struct radeon_pipe_buffer *radeon_buffer =
>>          (struct radeon_pipe_buffer*)buffer;
>> +    struct radeon_winsys_priv *priv = radeon_buffer->ws->priv;
>> +
>> +    if (radeon_bo_is_referenced_by_cs(radeon_buffer->bo, priv->cs)) {
>> +        priv->cs->space_flush_fn(priv->cs->space_flush_data);
>> +    }
>
> Why would this be necessary?
>
>
> --
> Earthling Michel Dänzer           |                http://www.vmware.com
> Libre software enthusiast         |          Debian, X and DRI developer
>

Oh, it doesn't seem to be needed at all. Feel free to revert this commit.

Marek

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] gallium: add blitter

[Marek Olšák]

On Tue, Dec 15, 2009 at 11:27 AM, Keith Whitwell  wrote:
> On Tue, 2009-12-15 at 01:49 -0800, Marek Olšák wrote:
>> On Tue, Dec 15, 2009 at 10:28 AM, Keith Whitwell  wrote:
>> > On Mon, 2009-12-14 at 16:31 -0800, Marek Olšák wrote:
>> >> On Mon, Dec 14, 2009 at 5:42 PM, Corbin Simpson
>> >>  wrote:
>> >> > As far as immediate verts, why don't we just add support to r300g to 
>> >> > switch
>> >> > to immediate mode for small VBOs?
>> >> >
>> >> > Posting from a mobile, pardon my terseness. ~ C.
>> >> >
>> >>
>> >> Corbin,
>> >>
>> >> that seems reasonable, and it's the reason I killed the draw_quad
>> >> function. BTW immediate mode doubles the performance in glxgears.
>> >
>> > Shouldn't gears upload its vertices one time only and then leave them
>> > resident in VRAM?
>> >
>> > Keith
>> >
>> >
>>
>> I meant the clear path with a quad using immediate mode, that made the
>> difference in comparison with a straightforward VBO path.
>
> OK, understood.
>
> I'm interested to understand why the VBO path is slow.  Is it the
> allocation of the VBO itself?  Mapping & uploading the vertices?
> Command submission (the extra reloc)?
>
> It seems to me that none of these should be taking half your time.  In
> fact, it makes me wonder if there wasn't something else going on -- eg.
> was the same buffer getting reused to hold those 4 vertices frame after
> frame, resulting in a sync when the driver tried to map the buffer?
>
> That could be happening in the state tracker or in the driver, I guess.
>
> Keith
>

Yes, the same buffer was getting reused every frame causing sync when
mapping the buffer. However, it will no longer be an issue once
immediate mode gets implemented. Using DONT_WAIT would probably also
help here.

Please, could you possibly look at the patches I sent to you
approximately 16 hours ago? (there are 7 of them)

Marek

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] Fwd: gallium: add blitter

[Marek Olšák]

On Tue, Dec 15, 2009 at 10:28 AM, Keith Whitwell  wrote:
> On Mon, 2009-12-14 at 16:31 -0800, Marek Olšák wrote:
>> On Mon, Dec 14, 2009 at 5:42 PM, Corbin Simpson
>>  wrote:
>> > As far as immediate verts, why don't we just add support to r300g to switch
>> > to immediate mode for small VBOs?
>> >
>> > Posting from a mobile, pardon my terseness. ~ C.
>> >
>>
>> Corbin,
>>
>> that seems reasonable, and it's the reason I killed the draw_quad
>> function. BTW immediate mode doubles the performance in glxgears.
>
> Shouldn't gears upload its vertices one time only and then leave them
> resident in VRAM?
>
> Keith
>
>

I meant the clear path with a quad using immediate mode, that made the
difference in comparison with a straightforward VBO path.

Marek

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] gallium: add blitter

[Marek Olšák]

On Mon, Dec 14, 2009 at 5:42 PM, Corbin Simpson
 wrote:
> As far as immediate verts, why don't we just add support to r300g to switch
> to immediate mode for small VBOs?
>
> Posting from a mobile, pardon my terseness. ~ C.
>

Corbin,

that seems reasonable, and it's the reason I killed the draw_quad
function. BTW immediate mode doubles the performance in glxgears.

To others:
I noticed that there is a weird optimization in u_gen_mipmaps. It
allocates a large vertex buffer and uses small chunks of it to render
consecutive quads (one for each mipmap level and cubemap face). If we
implement switching to immediate mode, it would be nice for VBOs to be
as small as possible so that the driver can easily recognize the most
efficient path. The simplest solution (4 vertices in a VBO) may end up
being the fastest one here.

Marek

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] gallium: let drivers fallback on framebuffer clearing

[Marek Olšák]

Keith,

I've taken your comment into consideration and started laying out a
new simple driver module which I call Blitter. The idea is to provide
acceleration for operations like clear, surface_copy, and
surface_fill. The module doesn't depend on a CSO context, instead, a
driver must call appropriate util_blitter_save* functions to save CSOs
and a blit operation takes care of their restoration once it's done.

I attached a patch illustrating the idea with the clear implemented
and a working example of usage, but it's not ready to get pushed yet.

Please tell me what you think about it.

Marek


On Tue, Dec 8, 2009 at 1:42 PM, Keith Whitwell  wrote:
> On Mon, 2009-12-07 at 05:01 -0800, Marek Olšák wrote:
>> Hi,
>>
>> Because some hardware under some circumstances (e.g. disabled tiling)
>> may not be able to use a hardware-specific clear path, it would be
>> nice to let a state tracker do the clearing by drawing a
>> screen-aligned quad. I am proposing to change the pipe_context->clear
>> function to return TRUE if buffers were cleared by the driver, and
>> FALSE if the state tracker should do the clearing by taking a generic
>> path.
>>
>> As an example, r300g can use the fast clearing only if colorbuffers
>> and zbuffers are micro-tiled, otherwise it must draw a screen-aligned
>> quad and doing it in the driver is really messy.
>>
>> The attached patch implements this interface change and adapts all
>> state trackers and drivers.
>>
>> I noticed that a lot of drivers still use slow util_clear, so they
>> will greatly benefit from this patch. It's up to their maintainers
>> whether they enable it, I suspect some unstable drivers may not be
>> able to draw a quad without visual errors.
>>
>> Please review.
>
> Marek,
>
> I think I'd prefer a scheme where we make it easier for the drivers to
> do whatever they need internally to get clears done.  This is mainly for
> consistency with the rest of Gallium, where once we ask a driver to do
> something, the contract is that it will get done, and that the
> state-tracker can have a good idea about what a driver's capabilities
> are ahead of time.
>
> In terms of this, it seems what we're really missing to allow drivers to
> call equivalents of util_draw_quad() and friends is a way to
> save/restore the current bound state which will get clobbered running
> the quad blitter.
>
> Providing a general facility to support this in the driver gives the
> equivalent functionality of this fallback patch on every path which
> could potentially do this type of fallback, as opposed to adding return
> values and dealing with fallbacks in every state tracker.
>
> So, I think I'll be naking this patch, but I recognise the issue and
> would be interested to see ways that we can enable the driver to call
> some driver-side equivalent of util_draw_quad() or similar to achieve
> the clear.
>
> Keith
>
>
From 518c29f9c1860a7e58f4e2c793af1b41350922e5 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Thu, 10 Dec 2009 10:25:33 +0100
Subject: [PATCH 1/2] util: add blitter

---
 src/gallium/auxiliary/util/Makefile|1 +
 src/gallium/auxiliary/util/SConscript  |1 +
 src/gallium/auxiliary/util/u_blitter.c |  271 
 src/gallium/auxiliary/util/u_blitter.h |  153 ++
 4 files changed, 426 insertions(+), 0 deletions(-)
 create mode 100644 src/gallium/auxiliary/util/u_blitter.c
 create mode 100644 src/gallium/auxiliary/util/u_blitter.h

diff --git a/src/gallium/auxiliary/util/Makefile b/src/gallium/auxiliary/util/Makefile
index 1d8bb55..8df7445 100644
--- a/src/gallium/auxiliary/util/Makefile
+++ b/src/gallium/auxiliary/util/Makefile
@@ -9,6 +9,7 @@ C_SOURCES = \
 	u_debug_symbol.c \
 	u_debug_stack.c \
 	u_blit.c \
+	u_blitter.c \
 	u_cache.c \
 	u_cpu_detect.c \
 	u_draw_quad.c \
diff --git a/src/gallium/auxiliary/util/SConscript b/src/gallium/auxiliary/util/SConscript
index 8d99106..45d89c0 100644
--- a/src/gallium/auxiliary/util/SConscript
+++ b/src/gallium/auxiliary/util/SConscript
@@ -23,6 +23,7 @@ util = env.ConvenienceLibrary(
 	source = [
 		'u_bitmask.c',
 		'u_blit.c',
+		'u_blitter.c',
 		'u_cache.c',
 		'u_cpu_detect.c',
 		'u_debug.c',
diff --git a/src/gallium/auxiliary/util/u_blitter.c b/src/gallium/auxiliary/util/u_blitter.c
new file mode 100644
index 000..9433c1a
--- /dev/null
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -0,0 +1,271 @@
+/**
+ *
+ * Copyright 2009 Marek Olšák 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated

[Mesa3d-dev] gallium: let drivers fallback on framebuffer clearing

[Marek Olšák]

Hi,

Because some hardware under some circumstances (e.g. disabled tiling)
may not be able to use a hardware-specific clear path, it would be
nice to let a state tracker do the clearing by drawing a
screen-aligned quad. I am proposing to change the pipe_context->clear
function to return TRUE if buffers were cleared by the driver, and
FALSE if the state tracker should do the clearing by taking a generic
path.

As an example, r300g can use the fast clearing only if colorbuffers
and zbuffers are micro-tiled, otherwise it must draw a screen-aligned
quad and doing it in the driver is really messy.

The attached patch implements this interface change and adapts all
state trackers and drivers.

I noticed that a lot of drivers still use slow util_clear, so they
will greatly benefit from this patch. It's up to their maintainers
whether they enable it, I suspect some unstable drivers may not be
able to draw a quad without visual errors.

Please review.

Best regards
Marek Olšák
From a6d16e7bce330900d496593054ec6aeb3ed51a2f Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Mon, 7 Dec 2009 00:33:17 +0100
Subject: [PATCH] gallium: let drivers fallback on framebuffer clearing

A driver can either clear a framebuffer by itself or can tell the state tracker
to draw a screen-aligned quad if a hardware-specific clear path is not
available.
---
 src/gallium/drivers/cell/ppu/cell_clear.c|4 +++-
 src/gallium/drivers/cell/ppu/cell_clear.h|3 ++-
 src/gallium/drivers/i915/i915_clear.c|3 ++-
 src/gallium/drivers/i915/i915_context.h  |4 ++--
 src/gallium/drivers/identity/id_context.c|   12 ++--
 src/gallium/drivers/llvmpipe/lp_clear.c  |4 +++-
 src/gallium/drivers/llvmpipe/lp_clear.h  |2 +-
 src/gallium/drivers/nv04/nv04_clear.c|   10 ++
 src/gallium/drivers/nv04/nv04_context.h  |4 ++--
 src/gallium/drivers/nv10/nv10_clear.c|3 ++-
 src/gallium/drivers/nv10/nv10_context.h  |2 +-
 src/gallium/drivers/nv20/nv20_clear.c|3 ++-
 src/gallium/drivers/nv20/nv20_context.h  |2 +-
 src/gallium/drivers/nv30/nv30_clear.c|3 ++-
 src/gallium/drivers/nv30/nv30_context.h  |2 +-
 src/gallium/drivers/nv40/nv40_clear.c|3 ++-
 src/gallium/drivers/nv40/nv40_context.h  |2 +-
 src/gallium/drivers/nv50/nv50_clear.c|4 +++-
 src/gallium/drivers/nv50/nv50_context.h  |2 +-
 src/gallium/drivers/r300/r300_clear.c|   11 ++-
 src/gallium/drivers/r300/r300_clear.h|   12 +++-
 src/gallium/drivers/softpipe/sp_clear.c  |5 +++--
 src/gallium/drivers/softpipe/sp_clear.h  |2 +-
 src/gallium/drivers/svga/svga_context.h  |   10 +-
 src/gallium/drivers/svga/svga_pipe_clear.c   |3 ++-
 src/gallium/drivers/trace/tr_context.c   |7 +--
 src/gallium/include/pipe/p_context.h |4 +++-
 src/gallium/state_trackers/vega/api_masks.c  |   11 +++
 src/gallium/state_trackers/vega/vg_context.c |6 +-
 src/gallium/state_trackers/vega/vg_tracker.c |8 ++--
 src/gallium/state_trackers/xorg/xorg_exa.c   |7 +--
 src/mesa/state_tracker/st_cb_clear.c |   12 +---
 32 files changed, 107 insertions(+), 63 deletions(-)

diff --git a/src/gallium/drivers/cell/ppu/cell_clear.c b/src/gallium/drivers/cell/ppu/cell_clear.c
index 79ad687..553d924 100644
--- a/src/gallium/drivers/cell/ppu/cell_clear.c
+++ b/src/gallium/drivers/cell/ppu/cell_clear.c
@@ -48,7 +48,7 @@
 /**
  * Called via pipe->clear()
  */
-void
+boolean
 cell_clear(struct pipe_context *pipe, unsigned buffers, const float *rgba,
double depth, unsigned stencil)
 {
@@ -89,4 +89,6 @@ cell_clear(struct pipe_context *pipe, unsigned buffers, const float *rgba,
   clr->surface = surfIndex;
   clr->value = clearValue;
}
+
+   return TRUE;
 }
diff --git a/src/gallium/drivers/cell/ppu/cell_clear.h b/src/gallium/drivers/cell/ppu/cell_clear.h
index 08e091a..9fc3a01 100644
--- a/src/gallium/drivers/cell/ppu/cell_clear.h
+++ b/src/gallium/drivers/cell/ppu/cell_clear.h
@@ -29,11 +29,12 @@
 #ifndef CELL_CLEAR_H
 #define CELL_CLEAR_H
 
+#include "pipe/p_compiler.h"
 
 struct pipe_context;
 
 
-extern void
+extern boolean
 cell_clear(struct pipe_context *pipe, unsigned buffers, const float *rgba,
double depth, unsigned stencil);
 
diff --git a/src/gallium/drivers/i915/i915_clear.c b/src/gallium/drivers/i915/i915_clear.c
index 90530f2..21528e5 100644
--- a/src/gallium/drivers/i915/i915_clear.c
+++ b/src/gallium/drivers/i915/i915_clear.c
@@ -39,10 +39,11 @@
  * Clear the given buffers to the specified values.
  * No masking, no scissor (clear entire buffer).
  */
-void
+boolean
 i915_clear(struct pipe_context *pipe, unsigned buffers, const float *rgba,
 	   double depth, unsigned stencil)
 {
util_clear(pipe, &i915_context(pipe)->

Re: [Mesa3d-dev] st_shader-varients merge tomorrow

[Marek Olšák]

Hi Roland,

r300g doesn't use *semantic_index at all and due to this some shaders are
broken on it. Merging the branch probably can't make it worse, so go for it.
I already have fixes for this driver here and I am about to send them soon.

Marek

On Wed, Nov 25, 2009 at 4:47 AM, Roland Scheidegger wrote:

> I'm planning to merge st_shader-varients branch to master tomorrow.
>
> This should not adversely affect drivers, unless they rely on generics
> inputs/outputs semantic_index always starting at 0 without holes
> (something that they shouldn't do but it would have worked previously).
> Feedback for hw drivers welcome, I'll try i915 myself, but I can't test
> the others, though some quick glance seemed to suggest they should be ok.
>
> Roland
>
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] mesa/st: fix crash when drawing stencil pixels outside the drawbuffer

[Marek Olšák]

Hi Brian,

I tried your patch and it solves the buffer-mapping issue.

I attached a new patch that fixes the clipping issue. Please, review/push.

Best regards
Marek Olšák


On Mon, Nov 2, 2009 at 6:12 PM, Brian Paul  wrote:

> Marek Olšák wrote:
>
>> Hi,
>>
>> the attached patch fixes a possible crash in function draw_stencil_pixels
>> in mesa/state_tracker. I've also updated the list of formats we read from to
>> prevent an assertion failing later in the code.
>>
>> This makes glean/depthStencil work on r300g and softpipe.
>>
>> Best regards
>> Marek Olšák
>>
>>
> diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
> b/src/mesa/state_tracker/st_cb_drawpixels.c
> index 0a6bfcd..0699404 100644
> --- a/src/mesa/state_tracker/st_cb_drawpixels.c
> +++ b/src/mesa/state_tracker/st_cb_drawpixels.c
> @@ -669,6 +669,12 @@ draw_stencil_pixels(GLcontext *ctx, GLint x, GLint y,
>strb = st_renderbuffer(ctx->DrawBuffer->
>   Attachment[BUFFER_STENCIL].Renderbuffer);
>
> +   /* Do not draw outside the drawbuffer */
> +   if (x + width > ctx->DrawBuffer->Width)
> +  width = ctx->DrawBuffer->Width - x;
> +   if (y + height > ctx->DrawBuffer->Height)
> +  height = ctx->DrawBuffer->Height - y;
>
> I think you can use _mesa_clip_drawpixels() here instead.  See swrast or
> other drivers for example usage.
>
>
> The second change should be a totally separate patch since it's independent
> of the drawpixels clipping issue.
>
>
> diff --git a/src/mesa/state_tracker/st_cb_texture.c
> b/src/mesa/state_tracker/st_cb_texture.c
> index 878a40f..6f287ff 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -1309,7 +1309,8 @@ fallback_copy_texsubimage(GLcontext *ctx, GLenum
> target, GLint level,
>   srcX, srcY,
>   width, height);
>
> -   if (baseFormat == GL_DEPTH_COMPONENT &&
> +   if ((baseFormat == GL_DEPTH_COMPONENT ||
> +baseFormat == GL_DEPTH24_STENCIL8) &&
>pf_is_depth_and_stencil(stImage->pt->format))
>   transfer_usage = PIPE_TRANSFER_READ_WRITE;
>else
>
>
> I think there's a few things wrong with the depth/stencil path in this
> code.  Can you try the attached patch?
>
> I also suspec that util_blit_pixels_writemask() isn't working properly when
> blitting depth/stencil pixels.
>
> -Brian
>
> diff --git a/src/mesa/state_tracker/st_cb_texture.c
> b/src/mesa/state_tracker/st_cb_texture.c
> index 878a40f..00a0e4c 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -1309,7 +1309,8 @@ fallback_copy_texsubimage(GLcontext *ctx, GLenum
> target, GLint level,
>   srcX, srcY,
>   width, height);
>
> -   if (baseFormat == GL_DEPTH_COMPONENT &&
> +   if ((baseFormat == GL_DEPTH_COMPONENT ||
> +baseFormat == GL_DEPTH_STENCIL) &&
>pf_is_depth_and_stencil(stImage->pt->format))
>   transfer_usage = PIPE_TRANSFER_READ_WRITE;
>else
> @@ -1322,7 +1323,7 @@ fallback_copy_texsubimage(GLcontext *ctx, GLenum
> target, GLint level,
>   destX, destY, width, height);
>
>if (baseFormat == GL_DEPTH_COMPONENT ||
> -   baseFormat == GL_DEPTH24_STENCIL8) {
> +   baseFormat == GL_DEPTH_STENCIL) {
>   const GLboolean scaleOrBias = (ctx->Pixel.DepthScale != 1.0F ||
>  ctx->Pixel.DepthBias != 0.0F);
>   GLint row, yStep;
> @@ -1455,7 +1456,7 @@ st_copy_texsubimage(GLcontext *ctx,
>struct gl_texture_image *texImage =
>   _mesa_select_tex_image(ctx, texObj, target, level);
>struct st_texture_image *stImage = st_texture_image(texImage);
> -   const GLenum texBaseFormat = texImage->InternalFormat;
> +   const GLenum texBaseFormat = texImage->_BaseFormat;
>struct gl_framebuffer *fb = ctx->ReadBuffer;
>struct st_renderbuffer *strb;
>struct pipe_context *pipe = ctx->st->pipe;
> @@ -1476,12 +1477,9 @@ st_copy_texsubimage(GLcontext *ctx,
>
>/* determine if copying depth or color data */
>if (texBaseFormat == GL_DEPTH_COMPONENT ||
> -   texBaseFormat == GL_DEPTH24_STENCIL8) {
> +   texBaseFormat == GL_DEPTH_STENCIL) {
>   strb = st_renderbuffer(fb->_DepthBuffer);
>}
> -   else if (texBaseFormat == GL_DEPTH_STENCIL_EXT) {
> -  strb = st_renderbuffer(fb->_StencilBuffer);
> -   }
>e

[Mesa3d-dev] [PATCH] mesa/st: fix crash when drawing stencil pixels outside the drawbuffer

[Marek Olšák]

Hi,

the attached patch fixes a possible crash in function draw_stencil_pixels in
mesa/state_tracker. I've also updated the list of formats we read from to
prevent an assertion failing later in the code.

This makes glean/depthStencil work on r300g and softpipe.

Best regards
Marek Olšák
From 2b79c8adc5a92410cdfe4ae8c15880a73f839159 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Sat, 31 Oct 2009 19:38:29 +0100
Subject: [PATCH] mesa/st: fix crash when drawing stencil pixels outside the drawbuffer

Also, add a missing depth-stencil format to the list of formats we want
to read from.
---
 src/mesa/state_tracker/st_cb_drawpixels.c |6 ++
 src/mesa/state_tracker/st_cb_texture.c|3 ++-
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c b/src/mesa/state_tracker/st_cb_drawpixels.c
index 0a6bfcd..0699404 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -669,6 +669,12 @@ draw_stencil_pixels(GLcontext *ctx, GLint x, GLint y,
strb = st_renderbuffer(ctx->DrawBuffer->
   Attachment[BUFFER_STENCIL].Renderbuffer);
 
+   /* Do not draw outside the drawbuffer */
+   if (x + width > ctx->DrawBuffer->Width)
+  width = ctx->DrawBuffer->Width - x;
+   if (y + height > ctx->DrawBuffer->Height)
+  height = ctx->DrawBuffer->Height - y;
+
if (st_fb_orientation(ctx->DrawBuffer) == Y_0_TOP) {
   y = ctx->DrawBuffer->Height - y - height;
}
diff --git a/src/mesa/state_tracker/st_cb_texture.c b/src/mesa/state_tracker/st_cb_texture.c
index 878a40f..6f287ff 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1309,7 +1309,8 @@ fallback_copy_texsubimage(GLcontext *ctx, GLenum target, GLint level,
 	   srcX, srcY,
 	   width, height);
 
-   if (baseFormat == GL_DEPTH_COMPONENT &&
+   if ((baseFormat == GL_DEPTH_COMPONENT ||
+baseFormat == GL_DEPTH24_STENCIL8) &&
pf_is_depth_and_stencil(stImage->pt->format))
   transfer_usage = PIPE_TRANSFER_READ_WRITE;
else
-- 
1.6.3.3

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev