On Tue, Jul 10, 2012 at 03:51:22PM +0200, Marek Ol??ák wrote:
I just wanted to tell you Stephane's change cannot work and it even
has no effect at the moment. The native integer support is global in
core Mesa. It's because integer uniforms are converted to floats based
on the global
On Tue, Jul 10, 2012 at 09:19:05AM -0700, Stéphane Marchesin wrote:
There is also option 3): revert the two patches causing the regression.
And then you'll have this problem again as soon as you want llvmpipe
to reach GL 3.00+/GLSL 1.30+. So why not find a definitive solution
now?
Previous
On Wed, Jul 11, 2012 at 11:04 AM, Olivier Galibert galib...@pobox.com wrote:
On Tue, Jul 10, 2012 at 03:51:22PM +0200, Marek Ol??ák wrote:
I just wanted to tell you Stephane's change cannot work and it even
has no effect at the moment. The native integer support is global in
core Mesa. It's
- Original Message -
- Original Message -
On Tue, Jul 10, 2012 at 3:30 PM, Jose Fonseca jfons...@vmware.com
wrote:
Yep. The interfaces are busted.
Without native integers we get
DCL SV[0], INSTANCEID
...
ARL ADDR[0].x, SV[0].
and
On Wed, Jul 11, 2012 at 12:51:32PM +0200, Marek Ol??ák wrote:
Dude, you should really learn GLSL. The idea to emulate integers is
even older than the GLSL itself. It first appeared in HLSL and NVIDIA
Cg on hardware that wasn't even GL2-capable.
I'm learning 3.30+, which is what I consider
On Wed, Jul 11, 2012 at 1:09 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
- Original Message -
On Tue, Jul 10, 2012 at 3:30 PM, Jose Fonseca jfons...@vmware.com
wrote:
Yep. The interfaces are busted.
Without native integers we get
DCL
On Wed, Jul 11, 2012 at 02:19:02PM +0200, Marek Ol??ák wrote:
On Wed, Jul 11, 2012 at 1:09 PM, Jose Fonseca jfons...@vmware.com wrote:
My current plan is to:
- make it clear that INSTANCEID/VERTEXID always means integer
- require PIPE_SHADER_CAP_INTEGERS to be advertise in the vertex shader
- Original Message -
On Wed, Jul 11, 2012 at 1:09 PM, Jose Fonseca jfons...@vmware.com
wrote:
- Original Message -
- Original Message -
On Tue, Jul 10, 2012 at 3:30 PM, Jose Fonseca
jfons...@vmware.com
wrote:
Yep. The interfaces are busted.
On Wed, Jul 11, 2012 at 4:23 PM, Jose Fonseca jfons...@vmware.com wrote:
When NativeIntegers is FALSE, Mesa generates this VS:
DCL SV[0], INSTANCEID
...
ARL ADDR[0].x, SV[0].
If INSTANCEID is an integer this is wrong, as it is reading a float where
there's an integer. (e.g.,
- Original Message -
On Wed, Jul 11, 2012 at 4:23 PM, Jose Fonseca jfons...@vmware.com
wrote:
When NativeIntegers is FALSE, Mesa generates this VS:
DCL SV[0], INSTANCEID
...
ARL ADDR[0].x, SV[0].
If INSTANCEID is an integer this is wrong, as it is reading a
On Wed, Jul 11, 2012 at 5:26 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
On Wed, Jul 11, 2012 at 4:23 PM, Jose Fonseca jfons...@vmware.com
wrote:
When NativeIntegers is FALSE, Mesa generates this VS:
DCL SV[0], INSTANCEID
...
ARL ADDR[0].x,
Yep. The interfaces are busted.
Without native integers we get
DCL SV[0], INSTANCEID
...
ARL ADDR[0].x, SV[0].
and with integers we get
DCL SV[0], INSTANCEID
...
UARL ADDR[0].x, SV[0].
Olivier's fix is incorrect. It works on the above cases by guessing the type,
but
On Tue, Jul 10, 2012 at 3:30 PM, Jose Fonseca jfons...@vmware.com wrote:
Yep. The interfaces are busted.
Without native integers we get
DCL SV[0], INSTANCEID
...
ARL ADDR[0].x, SV[0].
and with integers we get
DCL SV[0], INSTANCEID
...
UARL ADDR[0].x, SV[0].
- Original Message -
On Tue, Jul 10, 2012 at 3:30 PM, Jose Fonseca jfons...@vmware.com
wrote:
Yep. The interfaces are busted.
Without native integers we get
DCL SV[0], INSTANCEID
...
ARL ADDR[0].x, SV[0].
and with integers we get
DCL SV[0],
On Tue, Jul 10, 2012 at 9:04 AM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
On Tue, Jul 10, 2012 at 3:30 PM, Jose Fonseca jfons...@vmware.com
wrote:
Yep. The interfaces are busted.
Without native integers we get
DCL SV[0], INSTANCEID
...
ARL
- Original Message -
On Mon, Jul 02, 2012 at 06:44:37AM -0700, Jose Fonseca wrote:
But I think that this fix is too ad-hoc, and I suspect it may
introduce other regressions.
If I understood the problem correctly, the issue here is that some
drivers want system values in
On Tue, Jul 03, 2012 at 12:39:47PM -0700, Jose Fonseca wrote:
Note that all registers are stored as floats (for convenience, and
because LLVM has no unions), so integers are bitcasted into floats
while storing/loading. And I'm not sure if your patch would break
that.
I did test the patch
- Original Message -
On Tue, Jul 03, 2012 at 12:39:47PM -0700, Jose Fonseca wrote:
Note that all registers are stored as floats (for convenience, and
because LLVM has no unions), so integers are bitcasted into floats
while storing/loading. And I'm not sure if your patch would
On Fri, Jun 29, 2012 at 3:49 PM, Olivier Galibert galib...@pobox.com wrote:
On Fri, Jun 29, 2012 at 03:09:23PM -0700, Stéphane Marchesin wrote:
I do, but it fixes a regression, so unless you have a fix, it's the way to
go. If you have a fix I'll happily test it :)
Just between us, revert on
FWIW, I think Draw needs to know if a driver does or does not support
integers, so that it can return system values in the correct type (not
sure if that includes gallivm too). The reason for that is that
glsl_to_tgsi generates *different* shaders depending on the native
integer cap. I think this
- Original Message -
On Fri, Jun 29, 2012 at 03:09:23PM -0700, Stéphane Marchesin wrote:
I do, but it fixes a regression, so unless you have a fix, it's the
way to
go. If you have a fix I'll happily test it :)
Just between us, revert on small regressions may not be optimal long
On Mon, Jul 02, 2012 at 06:44:37AM -0700, Jose Fonseca wrote:
But I think that this fix is too ad-hoc, and I suspect it may
introduce other regressions.
If I understood the problem correctly, the issue here is that some
drivers want system values in floats, others want in
integers. Right?
I'll send a revert for those, is there a way to do it without
reverting the rest of the series?
Stéphane
On Mon, Jun 25, 2012 at 11:41 AM, Stéphane Marchesin
stephane.marche...@gmail.com wrote:
The specific commit that seems to break it is:
46931ecf480e1d231bb6c2236d91b5390f2465ac llvmpipe:
On 29-06-12 21:03, Stéphane Marchesin wrote:
I'll send a revert for those, is there a way to do it without
reverting the rest of the series?
yeah, just revert the commit you want and then via 'amend' take out the
parts you don't want to revert (git gui is nice for doing that)
--
Ferry
Yeah, but my question was more high level, whether the vertex id
support required the previous refactor. It looks like it does though,
and I don't want to untangle, so I'll revert both 3/4 and 4/4.
Stéphane
On Fri, Jun 29, 2012 at 12:22 PM, Ferry Huberts maili...@hupie.com wrote:
On 29-06-12
On Fri, Jun 29, 2012 at 12:52:06PM -0700, Stéphane Marchesin wrote:
Yeah, but my question was more high level, whether the vertex id
support required the previous refactor. It looks like it does though,
and I don't want to untangle, so I'll revert both 3/4 and 4/4.
You realize that will
On Fri, Jun 29, 2012 at 3:02 PM, Olivier Galibert galib...@pobox.com wrote:
On Fri, Jun 29, 2012 at 12:52:06PM -0700, Stéphane Marchesin wrote:
Yeah, but my question was more high level, whether the vertex id
support required the previous refactor. It looks like it does though,
and I don't
On Fri, Jun 29, 2012 at 03:09:23PM -0700, Stéphane Marchesin wrote:
I do, but it fixes a regression, so unless you have a fix, it's the way to
go. If you have a fix I'll happily test it :)
Just between us, revert on small regressions may not be optimal long
term on a project like mesa where the
Hi Olivier,
On top of the GL_SELECT regressions reported by Brian, this patch
series is causing regressions on i915g for:
draw-instanced
draw-instanced-divisor
draw-elements-instanced-base-vertex
draw-elements-instanced-base-vertex-user_varrays
draw-non-instanced
instance-array-dereference
The specific commit that seems to break it is:
46931ecf480e1d231bb6c2236d91b5390f2465ac llvmpipe: Simplify and fix
system variables fetch.
On Mon, Jun 25, 2012 at 10:46 AM, Stéphane Marchesin
stephane.marche...@gmail.com wrote:
Hi Olivier,
On top of the GL_SELECT regressions reported by Brian,
Olivier,
This patch series is causing regressions in select/feedback mode. Can you take
a look?
In piglit:
piglit-ci/framework/../bin/select general
Returncode: -11
And in conform:
New LWP 15135]
[Thread debugging using libthread_db enabled]
Using host libthread_db library
On Thu, Jun 21, 2012 at 10:28:22AM -0700, Jose Fonseca wrote:
This patch series is causing regressions in select/feedback mode. Can you
take a look?
Sure. I wouldn't have expected that case to ever happen, but it makes
sense now that I think of it.
commit
32 matches
Mail list logo
