Hi. I'd like to introduce the Mesa3D community to a software project
that we hope to upstream. We're a small team at Intel working on
software defined visualization (http://sdvis.org/), and have
opensource projects in both the raytracing (Embree, OSPRay) and
rasterization (OpenSWR) realms.
We're
> On Oct 20, 2015, at 12:44 PM, Ilia Mirkin wrote:
>
> On Tue, Oct 20, 2015 at 1:43 PM, Ilia Mirkin wrote:
>> On Tue, Oct 20, 2015 at 1:11 PM, Rowley, Timothy O
>> wrote:
>>> Does one build work on both AVX and AVX2?
>>> ---
> On Oct 20, 2015, at 4:23 PM, Jose Fonseca wrote:
>
> I tried it on my i7-5500U, but I run into two issues:
>
> - OpenSWR seems to only use 2 threads (even though my system support 4
> threads)
>
> - and even when I compensate llvmpipe to only use 2 rasterizer threads, I
> still only get ha
> On Oct 20, 2015, at 2:03 PM, Roland Scheidegger wrote:
>
> Certainly looks interesting...
> From a high level point of view, seems quite similar to llvmpipe (both
> tile based, using llvm for jitting shaders, ...). Of course llvmpipe
> isn't well suited for these kind of workloads (the most im
> On Oct 20, 2015, at 5:58 PM, Jose Fonseca wrote:
>
> Thanks for the explanations. It's closer now, but still a bit of gap:
>
> $ KNOB_MAX_THREADS_PER_CORE=0 ./gloss
> SWR create screen!
> This processor supports AVX2.
> --> numThreads = 3
> 1102 frames in 5.002 seconds = 220.312 FPS
> 1133 f
> On Oct 22, 2015, at 4:17 PM, Jose Fonseca wrote:
>
> They do share a lot already, Mesa, gallium statetracker, and gallivm. If
> further development in openswr is planned, it might require to jump through a
> few hoops, but I think it's worth to figure out what would take to get this
> merge
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Feb 4, 2017, at 5:55 PM, Vinson Lee
mailto:v...@freedesktop.org>> wrote:
Tested-by: Vinson Lee mailto:v...@freedesktop.org>>
On Thu, Feb 2, 2017 at 12:42 PM, Cherniak, Bruce
mailto:bruce.chern...@intel.com>> wrote:
I followed up wi
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Feb 3, 2017, at 11:35 AM, Bruce Cherniak
mailto:bruce.chern...@intel.com>> wrote:
Removed unused Clip() and FRUSTUM_CLIP_MASK define.
---
src/gallium/drivers/swr/rasterizer/core/clip.cpp | 22 --
src/gallium/drive
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Oct 12, 2016, at 4:13 PM, Eric Engestrom
mailto:e...@engestrom.ch>> wrote:
Fixes: b3bd8bb611bb465d2e5e ("swr: [rasterizer core] add support
for "RAW" surface format")
CovID: 1373647
Signed-off-by: Eric Engestrom mailto:e...@en
Don’t think it’ll help Minecraft. Looking at an apitrace of running around in
the demo world for a little bit, it only created 66 display lists all of which
were quite small (less than 100 api entries).
-Tim
> On Aug 18, 2016, at 3:10 AM, Gustaw Smolarczyk wrote:
>
> Hi,
>
> Will this help
Review ping.
Missed this in my original jitevents patch because I had built llvm as one lib.
> On Aug 2, 2016, at 12:54 PM, Rowley, Timothy O
> wrote:
>
> Needed to successfully link llvmpipe or swr when using shared llvm libs.
> ---
> configure.ac | 5 +
> 1 file
> On Aug 26, 2016, at 8:30 AM, Emil Velikov wrote:
>
> On 2 August 2016 at 18:54, Tim Rowley wrote:
>> Needed to successfully link llvmpipe or swr when using shared llvm libs.
>> ---
>> configure.ac | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/configure.ac b/configure.ac
>>
I’ve seen the bucket hang on stop in the past, but thought this was now a thing
of the past. Is there a particular workload that was making this easy to
trigger?
What workload of glmark2 were you looking at? Watching it run, most of the
scenes appear very light in geometry, which would cause
> On Nov 3, 2016, at 7:09 PM, Roland Scheidegger wrote:
>
> I'm a bit worried by this.
> We've had some (a lot actually) unpleasant surprises in the past with
> llvm choosing to use instruction sets not appropriate for a given cpu...
> Hence only setting flags we checked ourselves being availabl
We suspect the remaining failure might be due to not quantizing the depth
bounds min/max values. That can be addressed in a future patch.
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 1, 2016, at 3:45 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Il
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 1, 2016, at 3:45 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/rasterizer/core/api.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 delet
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 7, 2016, at 6:18 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/swr_state.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
Looking at the spec, that seems like that should also check for sRGB and also
disable in that case (“GetFormatInfo(compileState.format).isSRGB”).
> On Nov 7, 2016, at 6:18 PM, Ilia Mirkin wrote:
>
> Signed-off-by: Ilia Mirkin
> ---
> src/gallium/drivers/swr/swr_state.cpp | 5 +
> 1 file cha
I’d prefer parenthesis to clarify the logic "(foo && ((bar == bla) || footer)”.
With those added, Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 8, 2016, at 4:30 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
--
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 7, 2016, at 6:18 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Most logic op usage is probably going to end up with normalized
textures. Scale the floating point values and convert to integer before
performing the logic o
Yes, that was about to be my suggestion too - remove the drivertype use in the
clipper and use the “clipHalfZ” flag instead.
driverType is still used in the SwrSetViewports setup, so can’t be completely
removed right now.
-Tim
> On Nov 9, 2016, at 10:04 AM, Ilia Mirkin wrote:
>
> On Wed, Nov
> On Nov 9, 2016, at 10:16 AM, Ilia Mirkin wrote:
>
> On Wed, Nov 9, 2016 at 11:12 AM, Rowley, Timothy O
> wrote:
>> Yes, that was about to be my suggestion too - remove the drivertype use in
>> the clipper and use the “clipHalfZ” flag instead.
>>
>
SwrSetRastState shouldn’t be overriding what the caller passed in. clip.h
changes look good.
> On Nov 9, 2016, at 10:56 AM, Ilia Mirkin wrote:
>
> With ARB_clip_control, GL may also do 0..1 depth clipping, not just
> -1..1. This removes clip's reliance on driver type. Instead we force
> halfz
> On Nov 9, 2016, at 11:03 AM, Ilia Mirkin wrote:
>
> On Wed, Nov 9, 2016 at 12:03 PM, Rowley, Timothy O
> wrote:
>> SwrSetRastState shouldn’t be overriding what the caller passed in. clip.h
>> changes look good.
>
> Then how should I force halfZ to 1 for DX?
A couple good additions would be “(indent-tabs-mode . nil)” and a
"(show-trailing-whitespace . t)”.
With that, Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 9, 2016, at 11:08 AM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@a
> On Nov 9, 2016, at 11:09 AM, Ilia Mirkin wrote:
>
> On Wed, Nov 9, 2016 at 12:06 PM, Rowley, Timothy O
> wrote:
>>
>>> On Nov 9, 2016, at 11:03 AM, Ilia Mirkin wrote:
>>>
>>> On Wed, Nov 9, 2016 at 12:03 PM, Rowley, Timothy O
>>> wr
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 9, 2016, at 11:50 AM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
With ARB_clip_control, GL may also do 0..1 depth clipping, not just
-1..1. This removes clip's reliance on driver type. DX users will need
to be updated to s
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 8, 2016, at 11:03 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
This improves bin/arb_clip_control-clip-control results, but still not
quite there yet.
src/ga
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 9, 2016, at 1:38 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
This setting is for whether color and alpha have different blend
settings, not for whether blending is enabled on a per-RT basis.
Signed-off-by: Ilia Mirkin
While more verbose and a little slower, I think using the
util_is_intensity/luminance* functions would make it clearer to someone reading
the code what’s being excluded.
> On Nov 9, 2016, at 2:15 PM, Ilia Mirkin wrote:
>
> The rasterizer does not have StoreTile support for these, so just mark
Oh, good spotting. I had incorporated the earlier version of your patch which
had the other bracing “if () {“ bracing stye. I’ll remove this change from the
push.
> On Nov 9, 2016, at 9:38 PM, Ilia Mirkin wrote:
>
> What's the preferred style? It seems like every other if () in this
> file h
Ah, yes, this patch missed the 8x2 tile path - I’ve fixed that now. I don’t
see another path to using the blend jit functions.
Thanks.
On Nov 9, 2016, at 10:44 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
I think a second instance of the blend func being called was missed in
backend
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 14, 2016, at 7:03 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Fixes glsl-arb-fragment-coord-conventions.
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/swr_shader.cpp | 10
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 14, 2016, at 7:03 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Fixes gl-3.2-basevertex-vertexid
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/swr_state.cpp | 1 +
1 file changed, 1
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 14, 2016, at 7:03 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
There is no functionality in swr to clamp either vertex or frag colors.
This could be added in swr_shader, at which point these could be
re-enabled.
Fixes a
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 17, 2016, at 6:51 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
The non-fast-clear path was never updated after clear colors were passed
in as floats. Remove the now-harmful conversion from unorm8.
Signed-off-by: Ilia Mi
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 17, 2016, at 10:56 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
The minification should happen before alignment, not after. See similar
logic on ComputeLODOffsetY. The current logic requires unnecessarily
large textures
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 17, 2016, at 10:56 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
There's no guarantee that mip width/height will be a multiple of the
compressed block size. Doing a divide by the block size first yields
different results
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 19, 2016, at 10:11 AM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
This is the same value that llvmpipe uses. Since swr uses the same
sampler logic, makes sense for this value to also be the same. Most
applications don't ca
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 20, 2016, at 10:32 AM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
The former calculations were for min/max y. The width/height don't take
translate into account.
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
--
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 20, 2016, at 12:20 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
This may ultimately be possible to support, but for now it's not hooked
up and the swr core only supports this output from GS.
This normally wouldn't matte
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 21, 2016, at 11:52 AM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
The way that dual-source blending is described for GLES2 is very odd,
and we end up with a shader that both has this property set *and* has a
color1 value t
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 21, 2016, at 11:52 AM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
We were previously not marking the "regular" flat outputs as flat when
flatshading was enabled.
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
--
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 21, 2016, at 11:52 AM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Fixes a few things:
- sprite coords only apply to generic varyings, and are a bitmask
- back color only applies in 2-sided lighting mode
- handle some odd s
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 21, 2016, at 11:52 AM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
This fixes gl-coord-replace-doesnt-eliminate-frag-tex-coords
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/swr_shade
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 21, 2016, at 11:52 AM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/swr_shader.cpp | 6 --
1 file changed, 4 insertions(+), 2 deletions(
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 17, 2016, at 6:51 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Currently clears only operate on the 0th array index (ignoring surface
layout parameters). Instead normalize to take a RTAI like all the
load/store tile logi
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 17, 2016, at 6:51 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
When switching render target array indexes (as might happen in a GS, or
in a future change, with layered clears), if the previous state is
HOTTILE_CLEAR, we
This code seems to assume that all attached buffers have the same start layer,
and that start will be zero. Maybe it should construct the clearMask inside
the layer loop, which would also be a bit clearer than the code you added to
drop bits out of the mask?
-Tim
> On Nov 17, 2016, at 6:51 PM
Mirkin
mailto:imir...@alum.mit.edu>> wrote:
On Wed, Nov 23, 2016 at 3:02 PM, Rowley, Timothy O
mailto:timothy.o.row...@intel.com>> wrote:
This code seems to assume that all attached buffers have the same start layer,
and that start will be zero. Maybe it should construct the clearMask insi
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 25, 2016, at 7:35 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/rasterizer/core/api.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletio
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 19, 2016, at 9:48 AM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp | 2 ++
1 file changed, 2 insertions(+)
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 19, 2016, at 9:48 AM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp | 13 -
1 file changed, 8 ins
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 19, 2016, at 9:48 AM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp | 10 --
1 file changed, 8 insert
This patch is showing some regressions on internal testing. As we talked about
on irc, it appears to be a combination of crashes (probably missing table
entries) and possibly wrong clear values. Will need to back to you later about
the errors, but for now we need to hold off on this patch.
-T
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 22, 2016, at 7:37 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/swr_draw.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
di
Ouch, that must have been a pain to reorganize - thanks. Visual inspection
says the caps are the same before and after, and testing shows it still passing
the same tests.
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 22, 2016, at 7:37 PM, Ilia Mirkin
mailto:imir...@alum.
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 22, 2016, at 7:37 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/swr_state.cpp | 13 +
1 file changed, 1 insertion(+), 12 dele
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 22, 2016, at 7:37 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Everything is in place for these.
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/swr_screen.cpp | 2 +-
1 file changed,
I’ve verified the same entries are in the list before/after.
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 22, 2016, at 7:37 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/swr_screen
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 22, 2016, at 7:37 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/swr_screen.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/ga
On Nov 27, 2016, at 11:13 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
On Thu, Nov 24, 2016 at 6:11 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Instead of (incorrectly) biasing the snorm value to make it look like a
unorm, just use signed integer math.
This fixes arb_color_buf
Not seeing this assert fire on our tests either.
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 29, 2016, at 8:04 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
I've been running this for a little while and
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 16, 2016, at 9:04 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Since we don't pass a renderTargetArrayIndex in, and the current hot
tile may be for a different index, we may end up loading the RTAI=0 into
the hot tile fo
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 29, 2016, at 8:05 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
We now support clearing these, and actually rendering to multiple layers
would require GS support, which will fail in much more spectacular ways
for now. Onc
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 29, 2016, at 8:23 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
There is no support for resuming streamout. Furthermore, this also
controls glDrawTransformFeedback functionality which requires the same
ability to query ho
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 29, 2016, at 8:23 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
The components count the number of individual values, not the number of
slots.
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/driv
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 29, 2016, at 8:23 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
The number has to be less than or equal to the max, not just less than.
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 29, 2016, at 8:23 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>
---
src/gallium/drivers/swr/swr_context.cpp | 10 +-
1 file changed, 9 insertions(+), 1 delet
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Nov 29, 2016, at 8:23 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
The buffer_size does not take the offset into account. Just add the
offset into the pointer which lines up the structures much better.
Signed-off-by: Ilia M
Should have parens on the zsbuf test line to match your corresponding change
for cbuf attachments.
With that change, Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Dec 2, 2016, at 1:18 PM, George Kyriazis
mailto:george.kyria...@intel.com>> wrote:
Include propagation of compari
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Dec 1, 2016, at 7:08 PM, Bruce Cherniak
mailto:bruce.chern...@intel.com>> wrote:
The active_query count was incorrect for query types that don't require
a begin_query. Removed the unnecessary assert.
---
src/gallium/drivers/swr/swr
Interesting. My testing was done using piglit on an avx512 capable processor,
where I didn’t see any regressions.
llvmpipe’s “make check” also passes for me with this change on avx2 and avx512
machines.
Was this the only regression you saw?
-Tim
> On Dec 6, 2016, at 12:27 AM, Michel Dänzer
> On Nov 24, 2016, at 2:29 PM, Ilia Mirkin wrote:
>
> Clip distances need to be perspective-divided. This fixes all the
> interpolation-*-{distance,vertex} piglits.
>
> Also take this opportunity to fix clip distances for points rasterized
> as triangles - the clip distance is not subject to sp
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Dec 8, 2016, at 8:21 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Large points become pairs of triangles when rasterized, so we must feed
it three clip distances, one for each vertex.
The clip distance is not subject to spr
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Dec 8, 2016, at 8:21 PM, Ilia Mirkin
mailto:imir...@alum.mit.edu>> wrote:
Clip distances need to be perspective-divided. This fixes all the
interpolation-*-{distance,vertex} piglits.
Signed-off-by: Ilia Mirkin mailto:imir...@alum.m
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99119
Reviewed-by: Tim Rowley
mailto:timothy.o.row...@intel.com>>
On Dec 22, 2016, at 6:06 PM, Bruce Cherniak
mailto:bruce.chern...@intel.com>> wrote:
ICC doesn't like the use of nullptr (std::nullptr_t) argument in
p_atomic_set. GCC and c
Tested on gcc-5.3.1, clang-3.8, icc-16.0.3
Reviewed-by: Tim Rowley
Tested-by: Tim Rowley
> On Jun 28, 2016, at 2:50 PM, Chuck Atkins wrote:
>
> Encapsulate the test for which flags are needed to get a compiler to
> support certain features. Along with this, give various options to try
> for
> On Jul 6, 2016, at 7:32 PM, Roland Scheidegger wrote:
>
> Am 06.07.2016 um 23:51 schrieb Tim Rowley:
>> ---
>> .../drivers/swr/rasterizer/jitter/builder_misc.cpp | 38
>> --
>> .../jitter/scripts/gen_llvm_ir_macros.py | 5 ---
>> 2 files changed, 28 insertions(+),
> On Aug 2, 2016, at 1:00 PM, Matt Turner wrote:
>
> On Tue, Aug 2, 2016 at 10:53 AM, Tim Rowley
> wrote:
>> swr rasterizer contains numerous data transfers between vectors
>> and ordinary C types. Fixing for strict aliasing will take time.
>
> Oh, sorry! I forgot about swr.
>
>> ---
>> con
Thanks for looking at this. I didn’t realize that automake was smart enough to
generate separate targets for the overlapping object files; had figured that
would be a collision.
I notice you removed the install-gallium-links portion of the makefile, which
you had pointed out before as being a
Testing this, I needed to make the following change to install-gallium-links.mk
to avoid a segfault while building. If that’s the right approach, the
egl_LTLIBRARIES line probably needs the same treatment for future proofing.
diff --git a/install-gallium-links.mk b/install-gallium-links.mk
inde
> On Apr 13, 2016, at 2:21 PM, Emil Velikov wrote:
>
> On 13 April 2016 at 19:13, Rowley, Timothy O
> wrote:
>> Testing this, I needed to make the following change to
>> install-gallium-links.mk to avoid a segfault while building. If that’s the
>> right appr
> On Apr 15, 2016, at 10:33 AM, Jose Fonseca wrote:
>
> On 15/04/16 00:30, Tim Rowley wrote:
>> On the philosophy that a driver shouldn't change the compile flags
>> for the entire tree, take the clove approach of moving the c++11 flag
>> to the swr driver directory.
>> ---
>> configure.ac
> On Apr 15, 2016, at 1:30 PM, Ilia Mirkin wrote:
>
> Signed-off-by: Ilia Mirkin
> ---
> src/gallium/drivers/swr/.gitignore | 7 +++
> 1 file changed, 7 insertions(+)
> create mode 100644 src/gallium/drivers/swr/.gitignore
>
> diff --git a/src/gallium/drivers/swr/.gitignore
> b/src/gallium
> On Apr 14, 2016, at 4:42 PM, Roland Scheidegger wrote:
>
> Am 14.04.2016 um 21:53 schrieb Tim Rowley:
>>
>> diff --git a/src/gallium/drivers/swr/rasterizer/core/frontend.h
>> b/src/gallium/drivers/swr/rasterizer/core/frontend.h
>> index 8307c0b..12e7ae4 100644
>> --- a/src/gallium/drivers/sw
> On Nov 18, 2015, at 12:34 PM, Emil Velikov wrote:
> I have no objections against getting this merged, although here are a
> couple of things that should be sorted. Some of these are just
> reiteration from others:
Sorry about the delay responding to this; we’ve been working on a number of the
Switching the default renderer to swr was part of our development so that we
could get users to test our driver without accidentally forgetting to change
the driver and ending up with llvmpipe. I was thinking we might be able to
leave that change in since swr isn’t in the default automake galli
Thanks for taking the time to dig into this patch. Figured I’d address a few
of the comments now, and work on all your points for the next revision.
> On Feb 22, 2016, at 12:53 PM, Emil Velikov wrote:
>
> On 18 February 2016 at 01:53, Tim Rowley wrote:
>
> Don't be shy to mention something i
> On Feb 17, 2016, at 7:07 PM, Roland Scheidegger wrote:
>
> You could use different functions for avx and avx2 code, and plug the
> right ones in at runtime, as you can link them both just fine. It just
> requires that your code containing avx2 code is in a different compile
> unit to the one c
Modest ping: haven’t had any comments on these patches for a few days.
I don’t have freedesktop git write privileges, so once the patches are cleared
it would be great if someone could push them.
Thanks.
-Tim
> On Feb 24, 2016, at 9:20 PM, Rowley, Timothy O
> wrote:
>
> Upda
On Feb 29, 2016, at 3:47 PM, Roland Scheidegger
mailto:srol...@vmware.com>> wrote:
Am 29.02.2016 um 22:07 schrieb Rowley, Timothy O:
Modest ping: haven’t had any comments on these patches for a few
days.
Patches look ok to me (for the parts I looked at and commented on).
I don’
> On Mar 3, 2016, at 11:54 AM, Kai Wasserbäch
> wrote:
>
> Tim Rowley wrote on 03.03.2016 18:20:
>> swr uses the legacy FunctionPassManager for llvm-3.6 compatibility,
>> but a change to llvm headers in 3.9 includes the new version as well.
>> Explicity use the legacy version to prevent ambigui
> On Mar 4, 2016, at 3:26 PM, Emil Velikov wrote:
>
> On 4 March 2016 at 19:28, Tim Rowley wrote:
>>
>> diff --git a/src/gallium/drivers/swr/rasterizer/common/os.h
>> b/src/gallium/drivers/swr/rasterizer/common/os.h
>> index 736d298..522ae0d 100644
>> --- a/src/gallium/drivers/swr/rasterizer/
> On Mar 22, 2016, at 3:51 PM, Justen, Jordan L
> wrote:
>
> What does 532172 in the subject refer to?
swr rasterizer development happens in another source control system. 532172 is
a revision id to checkpoint where we’ve pushed the changes publicly.
> From this commit message, it seems cle
> On Mar 23, 2016, at 12:52 AM, Justen, Jordan L
> wrote:
>
> On 2016-03-22 20:55:10, Rowley, Timothy O wrote:
>>
>> Yes, there’s a lot in this patch. I froze the public version of the
>> rasterizer when I began the upstreaming process mid February, so
>
> On Mar 23, 2016, at 12:52 AM, Kenneth Graunke wrote:
>
> That's an awkward situation we've not run into before.
>
> If the code is going to live in the upstream Mesa git repository, then
> it seems like the best long term plan is to reverse the workflow: make
> upstream Mesa the canonical rep
> On Mar 23, 2016, at 2:19 PM, Tom Stellard wrote:
>
> On Wed, Mar 23, 2016 at 04:53:29PM +0000, Rowley, Timothy O wrote:
>>
>> While that situation would be nice, the swr rasterizer is a subset of an
>> internal project, and what is upstreamed publicly is not just
Reviewed-by: Tim Rowley
> On May 24, 2016, at 3:00 PM, Bruce Cherniak wrote:
>
> Indexed primitives were always using cut-aware primitive assembly,
> whether primitive_restart was enabled or not. Correctly pass down
> primitive_restart and select optimized PA when possible.
> ---
> src/gallium
> On May 25, 2016, at 9:16 PM, Ilia Mirkin wrote:
>
> On Wed, May 25, 2016 at 10:03 PM, Tim Rowley
> wrote:
>> v2: only load the clip vertex once
>>
>> v3: fix clip enable logic, add cullDistance
>> ---
>> docs/GL3.txt | 2 +-
>> src/gallium/drivers/swr/swr_context.h
1 - 100 of 189 matches
Mail list logo
