On Sun, Nov 16, 2014 at 01:37:52AM +, Emil Velikov wrote:
On 13/11/14 18:05, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
The DRM_IOCTL_MODE_CREATE_DUMB (and others) IOCTL isn't very rigorously
specified, which has the effect that some kernel drivers do not consider
Hi Marek,
First of all, sorry for breaking Draw yesterday.
No problem. draw_llvm.c was really obfuscating the fact that it relied on the
layout of the pipe_viewport_state.
There's also the OpenGL extension AMD_vertex_shader_layer which is
supported by all GS-capable Mesa drivers except for
I take that despite that it's still a good idea to keep around if/when one
needs it.
Yep. I don't oppose moving it elsewhere (e.g, src/gallium/tools/) if its
presence in src/gallium/auxiliary/gallivm is confusing.
Apologies for the breakage, it was definitely not intended to get someone to
Thanks Emil, makes sense. I totally missed the stable tag.
Jose
From: Emil Velikov emil.l.veli...@gmail.com
Sent: 16 November 2014 21:12
To: Jose Fonseca; Tom Stellard
Cc: emil.l.veli...@gmail.com; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev]
Well, nvidia hw (pre-GM204; it seems like it's supported there now)
doesn't support setting gl_Layer from VS, so it's just not an option
there. However I do believe that the HW has enough support to handle
color masking as well as scissors, so I might try to add a PIPE_CAP
which indicates that
When using the stand alone compiler, if we try to
link a shader with vertex attributes it will
segfault on linking as the binding hash tables are
not included in the shader program. Obviously, we
cannot make the linking stage succeed without the
bound attributes but we can prevent the crash and
On Mon, Nov 17, 2014 at 1:45 AM, Michel Dänzer mic...@daenzer.net wrote:
On 14.11.2014 19:37, Marek Olšák wrote:
surface_destroy should never be called directly, because surfaces have
a reference counter. For unreferencing resources, use
pipe_surface_reference(pointer, NULL). It will call
On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner matts...@gmail.com wrote:
On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
So when checking/building sse code we have three possibilities:
1
On Mon, 2014-11-17 at 02:51 +0100, Thomas Helland wrote:
The spec states that pow is undefined for x 0.
Just set the range to correspond to a constant 0
if this is the case.
---
src/glsl/opt_minmax.cpp | 11 +++
1 file changed, 11 insertions(+)
diff --git
On Mon, Nov 17, 2014 at 9:44 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner matts...@gmail.com wrote:
On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov emil.l.veli...@gmail.com
On Mon, Nov 17, 2014 at 3:50 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Mon, Nov 17, 2014 at 9:44 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner matts...@gmail.com wrote:
On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On 17/11/14 14:44, Erik Faye-Lund wrote:
On Sat, Nov 15, 2014 at 7:18 PM, Matt Turner matts...@gmail.com wrote:
On Sat, Nov 15, 2014 at 10:13 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Sat, Nov 15, 2014 at 12:04 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
So when checking/building
On 17/11/14 13:32, Ilia Mirkin wrote:
Well, nvidia hw (pre-GM204; it seems like it's supported there now)
doesn't support setting gl_Layer from VS, so it's just not an option
there. However I do believe that the HW has enough support to handle
color masking as well as scissors, so I might try
Hi Sedat,
On 15/11/14 12:50, Sedat Dilek wrote:
Cosmetics? Intended?
$ LC_ALL=C git status
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
nothing to commit, working directory clean
$ LC_ALL=C git checkout -b 10.4 origin/10.4
Branch 10.4 set up to track remote
On Mon, Nov 17, 2014 at 10:30 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
Hi Sedat,
On 15/11/14 12:50, Sedat Dilek wrote:
Cosmetics? Intended?
$ LC_ALL=C git status
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
nothing to commit, working directory clean
$
From: Michael Varga michael.va...@amd.com
Signed-off-by: Michael Varga michael.va...@amd.com
---
src/gallium/state_trackers/va/surface.c | 120
1 file changed, 120 insertions(+)
diff --git a/src/gallium/state_trackers/va/surface.c
From: Michael Varga michael.va...@amd.com
added BGRA format
create/destroy
set image
associate/deassociate
Signed-off-by: Michael Varga michael.va...@amd.com
---
src/gallium/state_trackers/va/subpicture.c | 160 ++---
src/gallium/state_trackers/va/va_private.h | 12 +++
On 15/11/14 17:44, Ilia Mirkin wrote:
On Sat, Nov 15, 2014 at 6:52 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 14 November 2014 19:50, Ilia Mirkin imir...@alum.mit.edu wrote:
On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Hello all,
This is an old
On 15/11/14 17:50, Marek Olšák wrote:
I've always found the X.Org versioning scheme unintuitive. This is
actually for the first time after ~5 years of contributing to open
source graphics that I finally understand how the X versioning works.
Granted, I had never been interested in it anyway.
DRI_PRIME setups have different issues due the lack of dma-buf fences
support in the drivers. For DRI3 DRI_PRIME, a race can appear, making
tearings visible, or worse showing older content than expected. Until
dma-buf fences are well supported (and by all drivers), an alternative
is to send the
From: Christoph Bumiller christoph.bumil...@speed.at
v3: thanks to Brian, improved coding style, also glennk helped spot few
things (unsigned - int, two constify)
v4: thanks Ilia improved function, dropped u_box_clip_3d
v5: incorporated rest of Gregor proposed changes,clean ups
v6: u_box_clip_2d
Implements vblank_mode and throttling, which allows us change default ratio
between framerate and input lag.
Signed-off-by: David Heidelberg da...@ixit.cz
Signed-off-by: Axel Davy axel.d...@ens.fr
---
src/gallium/state_trackers/nine/adapter9.h | 1 +
Hi,
Here is last (4th) iteration of Gallium Nine patches.
We have integrated the new feedback we have got and hope
the status of the serie is good enough now for merge.
Thanks,
Axel Davy
Axel Davy (2):
nine: Add drirc options (v2)
nine: Implement threadpool
Christoph Bumiller (5):
From: Christoph Bumiller christoph.bumil...@speed.at
At this moment we use only zero or positive values.
v2: Implement it for also for Solaris, MSVC assembly
and enable for other combinations.
Signed-off-by: David Heidelberg da...@ixit.cz
---
src/gallium/auxiliary/util/u_atomic.h | 78
From: Christoph Bumiller christoph.bumil...@speed.at
v2: moved in in same order as in p_shader_tokens (thanks Brian)
Reviewed-by: Marek Olšák marek.olsak at amd.com
Signed-off-by: David Heidelberg da...@ixit.cz
---
src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h | 1 +
1 file changed, 1
From: Christoph Bumiller christoph.bumil...@speed.at
Implement pipe_loader_sw_probe_wrapped which allows to use the wrapped
software renderer backend when using the pipe loader.
v2: - remove unneeded ifdef
- use GALLIUM_PIPE_LOADER_WINSYS_LIBS
- check for CALLOC_STRUCT
thanks to Emil
From: Christoph Bumiller christoph.bumil...@speed.at
Signed-off-by: David Heidelberg da...@ixit.cz
---
src/gallium/winsys/sw/wrapper/wrapper_sw_winsys.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/gallium/winsys/sw/wrapper/wrapper_sw_winsys.c
On 17/11/14 15:34, Ilia Mirkin wrote:
On Mon, Nov 17, 2014 at 10:30 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Hi Sedat,
On 15/11/14 12:50, Sedat Dilek wrote:
Cosmetics? Intended?
$ LC_ALL=C git status
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
From: Michael Varga michael.va...@amd.com
When calling vaCreateImage() an internal copy of VAImage is maintained
since the allocation of image may not be guaranteed to live long enough.
Signed-off-by: Michael Varga michael.va...@amd.com
---
src/gallium/state_trackers/va/image.c | 70
On Mon, Nov 17, 2014 at 11:01 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 17/11/14 15:34, Ilia Mirkin wrote:
On Mon, Nov 17, 2014 at 10:30 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Hi Sedat,
On 15/11/14 12:50, Sedat Dilek wrote:
Cosmetics? Intended?
$ LC_ALL=C git status
Sorry, patch 4 is too big the mailing list.
The entire serie can be found here:
https://github.com/iXit/Mesa-3D/commits/for-upstream-5
On 17/11/2014 16:58, Axel Davy wrote :
Hi,
Here is last (4th) iteration of Gallium Nine patches.
We have integrated the new feedback we have got and hope
the
From: Michael Varga michael.va...@amd.com
In a few locations handles were being added but not removed.
Signed-off-by: Michael Varga michael.va...@amd.com
---
src/gallium/state_trackers/va/buffer.c | 1 +
src/gallium/state_trackers/va/context.c | 1 +
src/gallium/state_trackers/va/image.c | 1
Hi,
I am having difficulty in understanding why you implemented pipe_surface in
st_atom_atomicbuf.c.
On Mon, Nov 17, 2014 at 2:24 AM, Aditya Avinash adityaavina...@gmail.com
wrote:
Hi,
On Sunday, November 16, 2014, Ilia Mirkin imir...@alum.mit.edu wrote:
The direction I went in was by
Please split up this patch into:
1. gallium comment fixes
2. linker string fixes
3. hash table code changes
-Brian
On 11/17/2014 07:27 AM, Andres Gomez wrote:
When using the stand alone compiler, if we try to
link a shader with vertex attributes it will
segfault on linking as the binding
Because shader resources were already specified as pipe_surfaces (in
the existing, albeit presently unused API). A pipe_surface is a
wrapper around a resource that specifies what view of the resource
should be writable, and attaches an optional format to that resource.
Normally pipe_surfaces are
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
On Mon, Nov 17, 2014 at 10:58 AM, Axel Davy axel.d...@ens.fr wrote:
From: Christoph Bumiller christoph.bumil...@speed.at
v2: moved in in same order as in p_shader_tokens (thanks Brian)
Reviewed-by: Marek Olšák marek.olsak at amd.com
On Mon, Nov 17, 2014 at 10:58 AM, Axel Davy axel.d...@ens.fr wrote:
From: Christoph Bumiller christoph.bumil...@speed.at
At this moment we use only zero or positive values.
v2: Implement it for also for Solaris, MSVC assembly
and enable for other combinations.
Signed-off-by: David
Am 17.11.2014 um 16:21 schrieb Jose Fonseca:
On 17/11/14 13:32, Ilia Mirkin wrote:
Well, nvidia hw (pre-GM204; it seems like it's supported there now)
doesn't support setting gl_Layer from VS, so it's just not an option
there. However I do believe that the HW has enough support to handle
On Mon, 2014-11-17 at 16:01 +, Emil Velikov wrote:
On 17/11/14 15:34, Ilia Mirkin wrote:
On Mon, Nov 17, 2014 at 10:30 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Hi Sedat,
On 15/11/14 12:50, Sedat Dilek wrote:
Cosmetics? Intended?
$ LC_ALL=C git status
# On branch
Fix oversights from the add a window_space option to the passthrough
vertex shader patch.
---
src/gallium/tests/trivial/quad-tex.c |2 +-
src/gallium/tests/trivial/tri.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/tests/trivial/quad-tex.c
Reviewed-by: Jakob Bornecrantz ja...@vmware.com
On 17 Nov 2014 18:11, Brian Paul bri...@vmware.com wrote:
Fix oversights from the add a window_space option to the passthrough
vertex shader patch.
---
src/gallium/tests/trivial/quad-tex.c |2 +-
src/gallium/tests/trivial/tri.c |2
I'm not, in principle, opposed to merging st/nine into the tree. I've
reviewed all the patches that I'm qualified to review (which is the
vast minority of them -- 3 total), and I have outstanding feedback on
one of them (the atomic stuff).
I've asked Axel to provide a sample program which could
2014-11-17 18:28 GMT+01:00 Thomas Helland thomashellan...@gmail.com:
2014-11-17 15:48 GMT+01:00 Bruno Jimenez brunoji...@gmail.com:
On Mon, 2014-11-17 at 02:51 +0100, Thomas Helland wrote:
The spec states that pow is undefined for x 0.
Just set the range to correspond to a constant 0
if this
Not sure if that's the right place, but this framebuffer state is set
by the driver and not a state tracker. Compute shader read-write
resources (buffers, images) are implemented by the CB block on r600
and are referred to as RAT (random access target) in the register
docs. The first 0-7 binding
From: Christoph Bumiller christoph.bumil...@speed.at
At this moment we use only zero or positive values.
v2: Implement it for also for Solaris, MSVC assembly
and enable for other combinations.
v3: Replace MSVC assembly by assert + warning during compilation
Signed-off-by: David Heidelberg
On Mon, Nov 17, 2014 at 1:20 PM, Axel Davy axel.d...@ens.fr wrote:
From: Christoph Bumiller christoph.bumil...@speed.at
At this moment we use only zero or positive values.
v2: Implement it for also for Solaris, MSVC assembly
and enable for other combinations.
v3: Replace MSVC assembly
From: Christoph Bumiller christoph.bumil...@speed.at
At this moment we use only zero or positive values.
v2: Implement it for also for Solaris, MSVC assembly
and enable for other combinations.
v3: Replace MSVC assembly by assert + warning during compilation
v4: remove inc and dec with
On Mon, Nov 17, 2014 at 2:05 PM, Axel Davy axel.d...@ens.fr wrote:
From: Christoph Bumiller christoph.bumil...@speed.at
At this moment we use only zero or positive values.
v2: Implement it for also for Solaris, MSVC assembly
and enable for other combinations.
v3: Replace MSVC assembly
On Mon, Nov 17, 2014 at 12:20 PM, Axel Davy axel.d...@ens.fr wrote:
From: Christoph Bumiller christoph.bumil...@speed.at
At this moment we use only zero or positive values.
v2: Implement it for also for Solaris, MSVC assembly
and enable for other combinations.
v3: Replace MSVC
On Mon, Nov 17, 2014 at 2:15 PM, Patrick Baggett
baggett.patr...@gmail.com wrote:
On Mon, Nov 17, 2014 at 12:20 PM, Axel Davy axel.d...@ens.fr wrote:
From: Christoph Bumiller christoph.bumil...@speed.at
At this moment we use only zero or positive values.
v2: Implement it for also for
Looking at u_atomic.h there is a section that uses
PIPE_ATOMIC_ASM_MSVC_X86 and has explicit assembly, and there's a
section that uses PIPE_ATOMIC_MSVC_INTRINSIC and has intrinsics. No
clue whatsoever what the difference between them is, but presumably it
doesn't exist solely for the
Hi,
I agree with the solution. Considering images as buffers or buffers
as images (as they are operated inside shaders but not texture units)
makes sense. I think we can make atomic buffers as a part of
ARB_shader_image_load_store. Because, images are 2D array of buffers with
atomic operations run
The issue with STORE isn't whether it's necessary (it is!), but the
exact semantics of the TGSI opcode. The way I have it in my patch
right now is that it doesn't have a destination, which upsets the dead
code removal logic in st_glsl_to_tgsi greatly. For now I've just
commented it out, but that's
On 14/11/14 14:14, Emil Velikov wrote:
On 02/11/14 18:27, David Heidelberg wrote:
Hello everyone!
First I'd like thank you for great feedback.
Sending third Gallium Nine merge request. We reduced number of commits
to necessary minimum. I hope all proposed changes are incorporated in v3.
Hello all,
As you may have noticed there are only three commits since 10.3.3, which
imho are quite serious of people hitting those issues.
Thus I do plan on releasing 10.3.4 this Friday.
The usual summary with testing stats will be out on Wednesday, as I
would like to see if we'll have any
The sampler_array_size field was added by mesa/st: add support for
dynamic sampler offsets. But the field wasn't getting copied in
the get_pixel_transfer_visitor() or get_bitmap_visitor() functions.
The count_resources() function then didn't properly compute the
From: Marek Olšák marek.ol...@amd.com
No known benefit for OpenGL, but it doesn't hurt.
---
src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
src/gallium/drivers/radeonsi/si_state_draw.c | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git
From: Marek Olšák marek.ol...@amd.com
Cc: 10.4 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeonsi/si_state_draw.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
From: Marek Olšák marek.ol...@amd.com
Required by Nine. Tested with util_run_tests.
It's added to softpipe, llvmpipe, and r300g/swtcl.
---
src/gallium/auxiliary/draw/draw_context.c | 40 ++
src/gallium/auxiliary/draw/draw_llvm.c | 2 +-
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
Ooops, I thought I had caught all of that :(
On Mon, Nov 17, 2014 at 4:42 PM, Brian Paul bri...@vmware.com wrote:
The sampler_array_size field was added by mesa/st: add support for
dynamic sampler offsets. But the field wasn't getting copied in
I plan on checking in the multi-layer clear in the presence of
scissor/color mask fix today or tomorrow, which should fix things for
llvmpipe and nouveau. IMHO it'd be worth pulling that one in as well.
It's not in yet, but just a heads-up. [Or were you planning on
re-pulling on Wed?]
On Mon, Nov
On 17/11/14 20:05, Emil Velikov wrote:
Henri,
Considering the interface note able, would you say that any new
implementation towards handling D3D9 in wine is acceptable ? Please note
that I'm not talking about improving the existing one be that via GL
extensions or otherwise.
How about
+Laura. This thread is about you.
On Sun 16 Nov 2014, Gustaw Smolarczyk wrote:
Ok. It would be helpful to note the progress in the docs/GL3.txt file.
The overview of ARB_dsa summarizes the difference between it and the
EXT variant, so I understand the undesirability of implementing
EXT_dsa.
From: Dave Airlie airl...@redhat.com
This fixes
tests/spec/glsl-1.10/execution/fs-op-assign-mult-ivec2-ivec2-overwrite.shader_test.
Reported-by: ghallberg on irc
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/drivers/r600/r600_shader.c | 23 ++-
1 file
From: Dave Airlie airl...@redhat.com
This fixes
tests/spec/glsl-1.10/execution/fs-op-assign-mult-ivec2-ivec2-overwrite.shader_test.
Reported-by: ghallberg on irc
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/drivers/r600/r600_shader.c | 26 +++---
1 file
I will check for patches tomorrow and Wed morning. Then I'll throw
piglit in the mix and let it do it's thing :)
On 17/11/14 22:00, Ilia Mirkin wrote:
I plan on checking in the multi-layer clear in the presence of
scissor/color mask fix today or tomorrow, which should fix things for
llvmpipe
On Tue, 18 Nov 2014 00:56:38 +0100, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
This fixes
tests/spec/glsl-1.10/execution/fs-op-assign-mult-ivec2-ivec2-overwrite.shader_test.
Reported-by: ghallberg on irc
Signed-off-by: Dave Airlie airl...@redhat.com
---
On 14/11/14 14:39, Emil Velikov wrote:
Hello all,
This is an old question that I had laying around - why doesn't mesa use
a more conventional numbering for the development/rc releases ?
Eg.
mesa 10.4.0-rc1 - 10.3.99.901
mesa 10.4.0-rc2 - 10.3.99.902
...
mesa 10.4.0 - 10.4.0
mesa
From: Dave Airlie airl...@redhat.com
It appears on cayman the TG4 outputs were reordered.
This fixes a lot of piglit tests.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/drivers/r600/r600_shader.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff
From: Dave Airlie airl...@redhat.com
Some of the geom shader tests produce an empty vertex shader,
on cayman we'd crash in the finaliser because last_cf was NULL.
cayman doesn't need the NOP workaround, so if the code arrives
here with no last_cf, just emit an END.
fixes crashes in a bunch of
On Tue, 18 Nov 2014 01:57:13 +0100, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
It appears on cayman the TG4 outputs were reordered.
This fixes a lot of piglit tests.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/drivers/r600/r600_shader.c | 15
On Tue, 18 Nov 2014 02:23:51 +0100, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
Some of the geom shader tests produce an empty vertex shader,
on cayman we'd crash in the finaliser because last_cf was NULL.
cayman doesn't need the NOP workaround, so if the code
On 17/11/14 15:58, Axel Davy wrote:
Hi,
Here is last (4th) iteration of Gallium Nine patches.
We have integrated the new feedback we have got and hope
the status of the serie is good enough now for merge.
Just added the remaining r-b/acked-by tags and pushed it to master.
Guys take care
On 17.11.2014 23:30, Aaron Watry wrote:
On Mon, Nov 17, 2014 at 1:45 AM, Michel Dänzer mic...@daenzer.net wrote:
On 14.11.2014 19:37, Marek Olšák wrote:
surface_destroy should never be called directly, because surfaces have
a reference counter. For unreferencing resources, use
On 18.11.2014 00:58, Axel Davy wrote:
Implements vblank_mode and throttling, which allows us change default ratio
between framerate and input lag.
Signed-off-by: David Heidelberg da...@ixit.cz
Signed-off-by: Axel Davy axel.d...@ens.fr
Reviewed-by: Michel Dänzer michel.daen...@amd.com
--
Mesa 10.4.0 release candidate 1 is now available for testing. The
current plan is to have an additional release candidate each Friday
until the eventual 10.4.0 release on Friday, Dec 5th.
The tag in the git repository for Mesa 10.4.0-rc1 is 'mesa-10.4.0-rc1'.
As a reminder, with the 10.4 branch
On 18.11.2014 06:42, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
Cc: 10.4 mesa-sta...@lists.freedesktop.org
Both patches are
Reviewed-by: Michel Dänzer michel.daen...@amd.com
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
For values above integer accuracy in floats, val - floor(val) might
actually produce a value greater than 1. For such large floats, it's
reasonable to be imprecise, but it's unreasonable for FRC to return a
value that is not between 0 and 1.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
From: Dave Airlie airl...@redhat.com
Otherwise we seem to lose the split_gs_inputs and try and
pull from an uninitialised register.
fixes 9 texelFetch geom shader tests.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/drivers/r600/r600_shader.c | 3 ++-
1 file changed, 2
From: Dave Airlie airl...@redhat.com
For 1D and 2D arrays we don't want the other coordinates being
offset and affecting where we sample. I wrote this patch 6 months
ago but lost it.
This fixes at least
./bin/tex-miplevel-selection textureOffset 1DArray
./bin/tex-miplevel-selection textureOffset
From: Dave Airlie airl...@redhat.com
For 1D and 2D arrays we don't want the other coordinates being
offset and affecting where we sample. I wrote this patch 6 months
ago but lost it.
Fixes:
./bin/tex-miplevel-selection textureLodOffset 1DArray
./bin/tex-miplevel-selection textureLodOffset
On 18.11.2014 05:43, Emil Velikov wrote:
Hello all,
As you may have noticed there are only three commits since 10.3.3, which
imho are quite serious of people hitting those issues.
Thus I do plan on releasing 10.3.4 this Friday.
The usual summary with testing stats will be out on Wednesday, as
82 matches
Mail list logo
