Am 04.11.2011 18:49, schrieb Dave Airlie:
From: Dave Airlie airl...@redhat.com
the meta mipmap generator on rv100 is passing a s,t,r coordinate, but r100
is ancient so has no r handling in hw, so we have to pass a s,t,q with q
set to 1.
/me dares someone to review this :)
Am 25.11.2011 09:15, schrieb Jose Fonseca:
- Original Message -
While Ian and I may take a more idealist stance (favoring strict
compliance), and you perhaps a more pragmatic view (get more apps
running), we're all working toward the same goal: to build great
OpenGL drivers and
Am 30.11.2011 21:43, schrieb Jose Fonseca:
- Original Message -
On 11/30/2011 09:10 PM, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
This fixes the firefox crash but I've no idea if its correct.
I don't think it is. Visual.samples is the value passed to
Ah index scanning...
I don't like that this will map/unmap the ib once for each prim, though
I don't really see a nice way to avoid that (I think if you have to
actually map the ib, you lose anyway). Hopefully won't hit that
performance hog often...
A comment inline.
Am 31.12.2011 07:32, schrieb
Am 04.01.2012 04:20, schrieb Yuanhan Liu:
On Tue, Jan 03, 2012 at 08:25:31PM +0100, Roland Scheidegger wrote:
Ah index scanning...
I don't like that this will map/unmap the ib once for each prim,
Me either :)
though
I don't really see a nice way to avoid that (I think if you have
Am 04.01.2012 04:59, schrieb Yuanhan Liu:
On Wed, Jan 04, 2012 at 11:20:07AM +0800, Yuanhan Liu wrote:
On Tue, Jan 03, 2012 at 08:25:31PM +0100, Roland Scheidegger wrote:
Ah index scanning...
I don't like that this will map/unmap the ib once for each prim,
Me either :)
though
I don't
Am 05.01.2012 17:27, schrieb Alex Deucher:
On Thu, Jan 5, 2012 at 11:10 AM, Andre Maasikas amaasi...@gmail.com wrote:
On Thu, Jan 5, 2012 at 4:58 PM, Marek Olšák mar...@gmail.com wrote:
On Thu, Jan 5, 2012 at 9:13 AM, Vadim Girlin vadimgir...@gmail.com wrote:
Rendering in two-sided mode is
Enough to get it to work though I guess the libs should be added somewhere
else (gallium.py? x11.py?)
---
src/glx/SConscript |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/src/glx/SConscript b/src/glx/SConscript
index fc8ad77..7cbb170 100644
---
Jose,
Ah yes and actually cleanly - I could have sworn I updated that tree
before :-).
I'll go add the clientinfo.c file, should fix the USE_XCB case.
Roland
Am 13.01.2012 21:46, schrieb Jose Fonseca:
Hi Roland.
Most of this is already fixed in commit
This only checks power of 2 sample counts for now, but maybe we would
like to probe the values in between too ...
Looks good to me. I don't think anyone ever supported odd sample counts (and no
quincunx doesn't count...) though pre-r600 radeons supported 2,4,6. In any case
if someone wants to
Resolve via glBlitFramebuffer allows resolving a sub-region of a
renderbuffer to a different location in any mipmap level of some
other texture, therefore location and size parameters are needed.
The mask parameter was added because resolving only depth or only
stencil of a combined buffer
On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
Resolve via glBlitFramebuffer allows resolving a sub-region of a
renderbuffer to a different location in any mipmap level of some
other texture, therefore location and size parameters are needed.
The mask parameter was added because
On Mon, Jul 25, 2011 at 7:54 PM, Roland Scheidegger
srol...@vmware.com wrote:
You cannot resolve depth and stencil buffers in d3d10/11 and I'm
not convinced it even makes a whole lot of sense (especially for
the stencil buffer). Some hw will potentially be unable to do this
(I don't know
On 07/25/2011 09:03 PM, Roland Scheidegger wrote:
On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
Resolve via glBlitFramebuffer allows resolving a sub-region of a
renderbuffer to a different location in any mipmap level of some
other texture, therefore location and size parameters
On 07/25/2011 10:43 PM, Roland Scheidegger wrote:
On 07/25/2011 09:03 PM, Roland Scheidegger wrote:
On 07/25/2011 07:54 PM, Roland Scheidegger wrote:
Resolve via glBlitFramebuffer allows resolving a sub-region of
a
renderbuffer to a different location in any mipmap level of
some
(Strange thought sent that before - mail client going crazy...)
Resolving color buffers is pretty well defined (for standard msaa at
least). I have no idea how that's supposed to be defined for depth
and stencil values. Frankly I'm not sure what glBlitFramebuffer is
supposed to do here, maybe
On 07/26/2011 01:49 AM, Roland Scheidegger wrote:
(Strange thought sent that before - mail client going crazy...)
Resolving color buffers is pretty well defined (for standard msaa
at
least). I have no idea how that's supposed to be defined for depth
and stencil values. Frankly I'm
On 07/27/2011 01:25 AM, Roland Scheidegger wrote:
On 07/26/2011 01:49 AM, Roland Scheidegger wrote:
(Strange thought sent that before - mail client going crazy...)
Resolving color buffers is pretty well defined (for standard
msaa
at
least). I have no idea how that's supposed
On 08/02/2011 07:20 PM, Roland Scheidegger wrote:
Since noone else chimed in and said it's not a good idea I won't
hold you up :-).
I'd like to see a little more documentation though what it can
(e.g. depth resolve especially what it actually should do) and
can't do in context.rst
This looks like the right approach to me.
Note that RNDNE is in fact the default rounding mode for IEEE_754-2008
(in fact it was the default for earlier ieee-754 too).
So I see no reason to deviate from that unless there would be some very
good reason, even if it may look wrong for humans.
Roland
Am 01.09.2011 17:23, schrieb Younes Manton:
On Thu, Sep 1, 2011 at 11:08 AM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
On 01.09.2011 17:02, Younes Manton wrote:
On Thu, Sep 1, 2011 at 10:56 AM, Michel Dänzer mic...@daenzer.net wrote:
On Don, 2011-09-01 at 15:50 +0200, Christian
Am 06.09.2011 22:13, schrieb Ian Romanick:
From: Ian Romanick ian.d.roman...@intel.com
Core Mesa already does the dispatch offset remapping for every
function that could possibly ever be supported. There's no need to
continue using that cruft in the driver.
Since the call to
Am 07.09.2011 02:00, schrieb Stéphane Marchesin:
2011/9/6 Roland Scheidegger srol...@vmware.com:
Am 07.09.2011 00:01, schrieb Stéphane Marchesin:
2011/9/3 Jose Fonseca jfons...@vmware.com:
- Original Message -
2011/9/2 Stéphane Marchesin stephane.marche...@gmail.com:
2011/9/2 Jose
Am 07.09.2011 07:33, schrieb Stéphane Marchesin:
2011/9/2 Jose Fonseca jfons...@vmware.com:
- Original Message -
Hi,
While debugging some code I ran across the following situation:
- pipe_context c1 is created
- pipe_surface s1 is created
- strb- surface is set to s1 (s1's
Am 08.09.2011 09:08, schrieb Marek Olšák:
2011/9/7 Roland Scheidegger srol...@vmware.com:
That said I'm not really sure why pipe_sampler_view and pipe_surface
actually have a context pointer in them, since they are only supposed to
be used with the context in which they were created I think
Am 08.09.2011 19:59, schrieb Eric Anholt:
On Thu, 08 Sep 2011 10:53:45 -0700, Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/06/2011 03:21 PM, Roland Scheidegger wrote:
EXT_blend_equation_separate allows some unholy combinations which the
r200
Am 08.09.2011 19:53, schrieb Ian Romanick:
On 09/06/2011 03:21 PM, Roland Scheidegger wrote:
Am 06.09.2011 22:13, schrieb Ian Romanick:
From: Ian Romanick ian.d.roman...@intel.com
Core Mesa already does the dispatch offset remapping for every
function that could possibly ever be supported
Am 08.09.2011 21:03, schrieb Roland Scheidegger:
Am 08.09.2011 19:53, schrieb Ian Romanick:
On 09/06/2011 03:21 PM, Roland Scheidegger wrote:
Am 06.09.2011 22:13, schrieb Ian Romanick:
From: Ian Romanick ian.d.roman...@intel.com
Core Mesa already does the dispatch offset remapping for every
Am 08.09.2011 23:13, schrieb Marek Olšák:
On Thu, Sep 8, 2011 at 9:03 PM, Roland Scheidegger srol...@vmware.com wrote:
Am 08.09.2011 19:53, schrieb Ian Romanick:
On 09/06/2011 03:21 PM, Roland Scheidegger wrote:
Am 06.09.2011 22:13, schrieb Ian Romanick:
From: Ian Romanick ian.d.roman
Am 08.09.2011 21:43, schrieb Ian Romanick:
On 09/08/2011 12:18 PM, Roland Scheidegger wrote:
Am 08.09.2011 21:03, schrieb Roland Scheidegger:
Am 08.09.2011 19:53, schrieb Ian Romanick:
On 09/06/2011 03:21 PM, Roland Scheidegger wrote:
Am 06.09.2011 22:13, schrieb Ian Romanick:
From: Ian
Am 13.09.2011 18:31, schrieb Jose Fonseca:
- Original Message -
Am 13.09.2011 00:33, schrieb Jose Fonseca:
I admit I'm not very familiar how hardware currently supports
native double formats. Or how likely it is for hardware to have
native 4 x double register support in the
Am 13.09.2011 20:45, schrieb Jose Fonseca:
- Original Message -
José, Roland,
there is a problem with the proposed approach of having the
convert_to_float flag. That flag might not be supported for
certain integer formats. We would need to update some more places,
e.g.
Am 13.09.2011 21:39, schrieb Jose Fonseca:
- Original Message -
Am 13.09.2011 20:45, schrieb Jose Fonseca:
- Original Message -
José, Roland,
there is a problem with the proposed approach of having the
convert_to_float flag. That flag might not be supported for
Am 15.09.2011 15:35, schrieb Dave Airlie:
From: Dave Airlie airl...@redhat.com
This moves the gallium interface for clears from using a pointer to 4 floats
to a pointer to a union of float/unsigned/int values. This is step one
in allowing integer clears. I've tried to build as many
Am 15.09.2011 19:11, schrieb Dave Airlie:
This moves the gallium interface for clears from using a pointer to 4 floats
to a pointer to a union of float/unsigned/int values. This is step one
in allowing integer clears. I've tried to build as many drivers/pieces
as I could, but I think I missed
Am 20.09.2011 12:35, schrieb Keith Whitwell:
On Tue, 2011-09-20 at 10:59 +0200, Fabio wrote:
There was a discussion some months ago about using -fno-builtin-memcmp for
improving memcmp performance:
http://lists.freedesktop.org/archives/mesa-dev/2011-June/009078.html
Since then, was it
Am 20.09.2011 16:15, schrieb Keith Whitwell:
On Tue, 2011-09-20 at 16:02 +0200, Roland Scheidegger wrote:
Am 20.09.2011 12:35, schrieb Keith Whitwell:
On Tue, 2011-09-20 at 10:59 +0200, Fabio wrote:
There was a discussion some months ago about using -fno-builtin-memcmp for
improving memcmp
Am 20.09.2011 16:35, schrieb Roland Scheidegger:
Am 20.09.2011 16:15, schrieb Keith Whitwell:
On Tue, 2011-09-20 at 16:02 +0200, Roland Scheidegger wrote:
Am 20.09.2011 12:35, schrieb Keith Whitwell:
On Tue, 2011-09-20 at 10:59 +0200, Fabio wrote:
There was a discussion some months ago about
performance
On Tue, 2011-09-20 at 16:35 +0200, Roland Scheidegger wrote:
Am 20.09.2011 16:15, schrieb Keith Whitwell:
On Tue, 2011-09-20 at 16:02 +0200, Roland Scheidegger wrote:
Am 20.09.2011 12:35, schrieb Keith Whitwell:
On Tue, 2011-09-20 at 10:59 +0200, Fabio wrote:
There was a discussion some
Am 12.10.2011 16:31, schrieb Christoph Bumiller:
So do we need to go in and add PIPE_BIND_BLENDABLE to all of our
existing surface-create calls in the state tracker, etc?
Well, that depends on whether we want to put blending fallbacks at the
state tracker level (OpenGL is probably the only
Am 12.10.2011 19:35, schrieb Christoph Bumiller:
On 12.10.2011 19:17, Roland Scheidegger wrote:
Am 12.10.2011 16:31, schrieb Christoph Bumiller:
So do we need to go in and add PIPE_BIND_BLENDABLE to all of our
existing surface-create calls in the state tracker, etc?
Well, that depends
Am 20.10.2011 18:10, schrieb Dave Airlie:
So, Radeon maintainers, what do you think? And, does anyone else want
to test it on the other drivers? I caught two bugs in my r300 testing
(one too many lines cut in one r300 commit, and I had also removed the
texsubimage code in an
Am 20.10.2011 18:59, schrieb Dave Airlie:
On Thu, Oct 20, 2011 at 5:59 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 20.10.2011 18:10, schrieb Dave Airlie:
So, Radeon maintainers, what do you think? And, does anyone else want
to test it on the other drivers? I caught two bugs in my
Am 23.10.2011 02:25, schrieb Kenneth Graunke:
On 10/21/2011 08:45 PM, Chad Versace wrote:
For all texture targets except GL_TEXTURE_CUBE_MAP, the 'nr_images' and
'depth' fields of intel_mipmap_level were identical. In the exceptional
case, nr_images == 6 and depth == 1.
It is simple to
I'm quite sure there are g965 boards around which indeed support Pentium
4 (and P4-based Celerons) (but yes I guess cmov and at least sse2 are
safe - not that the p4 had a usable cmov implementation as it was
incredibly slow IIRC but it should at least work).
Roland
Am 25.01.2013 04:33, schrieb
Am 26.01.2013 18:26, schrieb Daniel Vetter:
On Fri, Jan 25, 2013 at 11:03:35PM -0800, Kenneth Graunke wrote:
On 01/25/2013 03:13 PM, Roland Scheidegger wrote:
I'm quite sure there are g965 boards around which indeed support Pentium
4 (and P4-based Celerons) (but yes I guess cmov and at least
Am 01.02.2013 19:44, schrieb Christoph Bumiller:
On 01.02.2013 19:29, Brian Paul wrote:
The glsl-to-tgsi translater will emit SQRT to implement GLSL's sqrt()
and distance() functions if the PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED
query says it's supported by the driver.
Otherwise, sqrt(x) is
Am 01.02.2013 21:00, schrieb Brian Paul:
On 02/01/2013 12:39 PM, srol...@vmware.com wrote:
From: Roland Scheideggersrol...@vmware.com
They are similar to old-style tex opcodes but with separate sampler and
texture units (and other arguments in different places).
Also adjust the debug tgsi
No that's not true. These 4 operations don't represent the 4 channels
rather the 2x2 blocks the tgsi exec code is working on.
I do wonder though about the fabsf, I think it might do more harm than
good. glsl seems to be content with undefined results for sqrt(), but
really for IEEE it should be
the latter two there is a sampler associated with
the instruction, but all the resource info will come from the wrong
resource). But anyway the broken code at least seems to look less broken -).
Roland
Am 06.02.2013 04:20, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
Am 08.02.2013 15:32, schrieb Jose Fonseca:
Looks good.
Should PIPE_TEXTURE_RECT be allowed too?
Texture rectangles don't support repeat wrap, so testing for them
wouldn't really help much.
Jose
- Original Message -
From: Roland Scheidegger srol...@vmware.com
This optimized
srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
link up the fs outputs and blend inputs, and make sure the second blend source
is correctly loaded and converted (which is quite complex).
There's a slight refactoring of the monster generate_unswizzled_blend()
function where
Am 08.02.2013 16:22, schrieb Brian Paul:
On 02/06/2013 10:59 AM, srol...@vmware.com wrote:
From: Roland Scheideggersrol...@vmware.com
This should handle the new lod_zero modifier more correctly.
The runtime-conditional is a bit more complex however we now also do
scalar lod computation when
Am 12.02.2013 08:06, schrieb Michel Dänzer:
On Mon, 2013-02-11 at 20:47 +0100, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
It looks like using coord.w as explicit lod value is a mistake, most likely
because some dx10 docs had it specified that way. Seems
is needed to handle offsets.
(In any case the gallivm code was wrong in using the
Inst-Texture.Texture field before since these weren't texture opcodes.)
Roland
Am 15.02.2013 03:18, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
We need to encode them as Texture
Am 15.02.2013 04:41, schrieb Dave Airlie:
From: Roland Scheidegger srol...@vmware.com
Need to take the type into account. Also, if we want to allow
mov's with modifiers we need to pick a type (assume float).
Just FYI, the r600g hw all ignores modifiers on non-floating types from
memory
Am 15.02.2013 15:55, schrieb Jose Fonseca:
- Original Message -
From: Roland Scheidegger srol...@vmware.com
Need to take the type into account. Also, if we want to allow
mov's with modifiers we need to pick a type (assume float).
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.c
Message -
From: Roland Scheidegger srol...@vmware.com
Need to take the type into account. Also, if we want to allow
mov's with modifiers we need to pick a type (assume float).
v2: don't allow all modifiers on all type, in particular don't allow
absolute on non-float types and don't allow
Am 18.02.2013 19:14, schrieb Michel Dänzer:
From: Michel Dänzer michel.daen...@amd.com
11 more little piglits.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
Any ideas why this seems necessary with radeonsi but not with r600g?
(not that it makes much difference since util_copy_box will just
call util_copy_rect repeatedly but it is definitely nicer style).
Roland
Jose
- Original Message -
From: Roland Scheidegger srol...@vmware.com
These used to be illegal a very long time ago, then for some more time
nothing really
, and
everything else (calculating sampler offset in the key, tgsi dump, code
generation) would use the shader information?
Roland
Jose
- Original Message -
From: Roland Scheidegger srol...@vmware.com
Some parts calculated key size by using shader information, others by using
Am 19.02.2013 18:54, schrieb Jose Fonseca:
- Original Message -
Am 19.02.2013 15:57, schrieb Jose Fonseca:
There may be more vertex elements that used in the shader. But why should
the key contain those elements? Won't this cause needless recompilations
(e.g., in situations where
Not much to say about the code (the theory sounds sane) but I was
wondering about the comment.
Why did glsl implement this really as x * (1 - a) + y * a?
The usual way for lerp would be (y - x) * a + x, i.e. two ops for most
gpus (sub+mad, or sub+mul+add). But I'm wondering if that sacrifices
Am 20.02.2013 11:39, schrieb Aras Pranckevicius:
Why did glsl implement this really as x * (1 - a) + y * a?
The usual way for lerp would be (y - x) * a + x, i.e. two ops for most
gpus (sub+mad, or sub+mul+add). But I'm wondering if that sacrifices
precision
Yes.
).
Roland
For UAVs, I think there is ARB_shader_storage_buffer_object and
pipe_context::set_shader_resources.
Yeah, D3D11 UAVs are also supposed to be bound separately in the pipeline.
Jose
Marek
On Wed, Feb 27, 2013 at 3:18 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol
- Original Message -
From: Roland Scheidegger srol...@vmware.com
Unfortunately not usable from OpenGL, and no cap bit.
Pretty similar to a 1d texture, though allows specifying a start element.
The util code for handling clears also needs adjustments (and fix
a bug causing crashes
Yeah the tgsi_aos emit code doesn't really get much testing, as it isn't
actually used anywhere. It might have other unnoticed bugs.
Roland
Am 27.02.2013 21:21, schrieb Jose Fonseca:
Good catch. Thanks!
Jose
- Original Message -
Catched this that morning
From
Hi,
there is some sloppy usage of bind flags in the opengl state tracker
(that is, resources get used for things which they didn't have the bind
flag set).
We'd really like to enforce these flags to be honored but it doesn't
really work (ok llvmpipe so far would only really care about sampler
Am 01.03.2013 08:50, schrieb Andreas Boll:
2013/3/1 srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
texel offsets should have been the last missing feature (not sure
if anything is actually missing for 140). In any case we still
don't do OpenGL 3.0 (missing MSAA which
Am 01.03.2013 19:54, schrieb Brian Paul:
Looks good, just minor things below.
Reviewed-by: Brian Paul bri...@vmware.com
On 03/01/2013 11:41 AM, srol...@vmware.com wrote:
From: Roland Scheideggersrol...@vmware.com
Something I never got around to implement, but this is the tgsi execution
Am 02.03.2013 01:36, schrieb Brian Paul:
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 8e3e3b8..c41b583 100644
---
Am 02.03.2013 04:26, schrieb Dave Airlie:
On Sat, Mar 2, 2013 at 12:02 PM, Roland Scheidegger srol...@vmware.com
wrote:
Am 02.03.2013 01:36, schrieb Brian Paul:
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src
Am 04.03.2013 04:54, schrieb Dave Airlie:
I've been playing with softpipe msaa on and off, but I hit a problem
with the clears and am just wondering if the state tracker should be
doing something like this.
Or maybe only if any bound buffer has nr_samples 1, or fallback to
the non-quad
Am 03.03.2013 21:27, schrieb Dave Airlie:
From: Dave Airlie airl...@redhat.com
This is to be used to implement glGet GL_SAMPLE_POSITION.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/include/pipe/p_context.h | 4
1 file changed, 4 insertions(+)
diff --git
Am 04.03.2013 23:04, schrieb Brian Paul:
Note: This is a candidate for the stable branches.
---
src/gallium/drivers/llvmpipe/lp_scene.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_scene.c
;
}
else {
jit_tex-width = res-width0;
Oops I think I introduced that bug recently when I needed to restructure
the code to handle buffer textures.
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev
Am 08.03.2013 21:03, schrieb Jose Fonseca:
- Original Message -
From: Roland Scheidegger srol...@vmware.com
This is needed for handling the dx10-style sample opcodes.
This also simplifies the logic by getting rid of sampler variants
completely (sampler_views though OTOH have sort
Am 08.03.2013 21:11, schrieb Brian Paul:
On 03/08/2013 12:18 PM, srol...@vmware.com wrote:
From: Roland Scheideggersrol...@vmware.com
Can handle them since the single sampler interface was introduced.
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 18 +-
1 file changed,
Am 12.03.2013 02:23, schrieb Marek Olšák:
On Mon, Mar 11, 2013 at 6:49 PM, Ian Romanick i...@freedesktop.org wrote:
Once upon a time Matt Turner was talking about using pixman to accelerate
operations like this in Mesa. It has a lot of highly optimized paths for
just this sort of thing.
Ok forget about this it still doesn't work correctly. Need to figure out
how all the mask business fits together.
Roland
Am 15.03.2013 19:34, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
If we're in some conditional we must not return, or the code after
Am 18.03.2013 14:36, schrieb Christian König:
From: Christian König christian.koe...@amd.com
To further improve the optimization of source and destination
indirect addressing we need the ability to store a reference
to the declaration of the addressed operands.
Since most of the fields in
Am 20.03.2013 15:41, schrieb Christoph Bumiller:
Sorry, this has become longer than I anticipated ...
I've been toying with adding support for TGSI_FILE_INPUT/OUTPUT arrays
because, since I cannot allocate varyings in the same order that the
register index specifies, I need it:
===
Am 20.03.2013 17:46, schrieb Christoph Bumiller:
On 20.03.2013 17:05, Roland Scheidegger wrote:
Am 20.03.2013 15:41, schrieb Christoph Bumiller:
Sorry, this has become longer than I anticipated ...
I've been toying with adding support for TGSI_FILE_INPUT/OUTPUT arrays
because, since I cannot
Am 20.03.2013 19:09, schrieb Christoph Bumiller:
On 20.03.2013 18:30, Roland Scheidegger wrote:
Am 20.03.2013 17:46, schrieb Christoph Bumiller:
On 20.03.2013 17:05, Roland Scheidegger wrote:
Not sure I fully understand this, but I'm thinking whenever in doubt,
use something close to what
Ok so before someone else notices that, ignore the rgb9e5 part.
The format isn't quite what I thought it was...
Roland
Am 21.03.2013 23:28, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
New conversion code to handle conversion from/to r11g11b10 AoS to/from
SoA
Am 22.03.2013 13:28, schrieb Jose Fonseca:
- Original Message -
From: Roland Scheidegger srol...@vmware.com
New conversion code to handle conversion from/to r11g11b10 AoS to/from
SoA floats, and also add code for conversion from rgb9e5 AoS to float SoA
(which works pretty much
FWIW it looks like we could use that opcode a bit more in glsl to tgsi
translation. There's one use of it in st_glsl_to_tgsi.cpp (though
coupled with a USNE which I'm not sure is even necessary) but another
place states that If TGSI had a UCMP instruction or similar, this extra
instruction would
Well if the condition is just any bit set then it doesn't matter if
the input is a float or int or whatever (of course, for floats, that
definition is different than != zero, as it doesn't hold for negative zero).
That would be the same as for instance the bitwise instructions which
also don't
Am 05.04.2013 00:08, schrieb Zack Rusin:
we break when the mask values are 0 not, 1, plus it's bit comparison
not a floating point comparison. This fixes both.
This sentence doesn't quite parse for me.
Signed-off-by: Zack Rusin za...@vmware.com
---
,
+result, );
}
/* TGSI_OPCODE_USET Helper (CPU Only) */
I think it would be nice if there'd be a comment in the code itself
saying why this is done (e.g. something similar to the commit message).
But either way,
Reviewed-by: Roland Scheidegger
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
,
+ emitted_prims_vec);
} else {
gather_outputs(bld);
}
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Am 10.04.2013 02:22, schrieb Zack Rusin:
both mov and ucmp can be used to move variables of any type.
correctly note that about ucmp in the tgsi_info and make
sure gallivm can handle that by correctly casting the untyped
moves.
Signed-off-by: Zack Rusin za...@vmware.com
---
-
.. _doubleopcodes:
Double ISA
Thanks Zack, looks perfect.
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
-
.. _doubleopcodes:
Double ISA
Thanks Zack, looks perfect.
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Am 11.04.2013 19:09, schrieb Zack Rusin:
- Original Message -
Am 11.04.2013 05:20, schrieb Zack Rusin:
As implemented in tgsi_exec they both test src operands on the bit
level and don't do floating point comperisons as some thought.
This documents them as such to avoid future
Everything emitting those opcodes always assumed this is some sort of
boolean until now, so treating them as floats always was sketchy. Note
that the differences to treating them as uints or floats for comparisons
to zero isn't large, it's the same for everything except -0.0 and NaNs,
and I
Actually our svga driver seems to think that the IF opcode works like
that. Since it will translate it into a SVGA3DOP_IFC (which corresponds
to shader model 2 if_comp which compares to sources and specifies a
comparison function - my guess is this is what the unused
TGSI_OPCODE_IFC was meant for,
Am 11.04.2013 22:52, schrieb Zack Rusin:
- Original Message -
- Original Message -
Ah.. This indeed rings a bell. I don't recall the details but I'm pretty
sure
I was against dual semantics. And the fact that this problem is again
showing its ugly head is the proof of it.
);
}
/* Fix up all emitted labels:
Oh and I think that really should be Disambiguate in the commit title.
Otherwise looks great, let's get rid of that mess.
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev
1 - 100 of 2156 matches
Mail list logo
