Reviewed-by: Erik Faye-Lund
And just for the record, I think this is the right "compromise" between
checking all possible formats and facilitating fallbacks.
On Tue, 2019-02-12 at 22:40 -0500, Ilia Mirkin wrote:
> If the driver supports PIPE_BIND_BLENABLE on RGBA32F, flip
> EX
On Thu, 2019-02-14 at 08:53 +1000, Dave Airlie wrote:
> On Thu, 14 Feb 2019 at 06:04, Stéphane Marchesin
> wrote:
> > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier <
> > tournier.e...@gmail.com> wrote:
> > >
> > >
> > > On Wednesday, 13 February 2019, Stéphane Marchesin <
> > > stephane.marche.
On Wed, 2019-02-13 at 11:53 -0800, Ian Romanick wrote:
> On 2/13/19 9:59 AM, Juan A. Suarez Romero wrote:
> > On Wed, 2019-02-13 at 09:16 -0800, Ian Romanick wrote:
> > > On 2/13/19 7:53 AM, Juan A. Suarez Romero wrote:
> > > > On Tue, 2019-02-12 at 16:22 -0800, Ian Romanick wrote:
> > > > > On 2/1
On Thu, 2019-02-14 at 16:25 +0100, Gert Wollny wrote:
> > > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier <
> > > > tournier.e...@gmail.com> wrote:
> [...]
> > > > > A solution would be to inline the
> > > > > function in GLSL but I'm scared than the following shader
> > > > > will
> > > > > be
Yeah, good move!
Reivewed-by: Erik Faye-Lund
On Mon, 2019-02-25 at 11:57 +, Emil Velikov wrote:
> From: Emil Velikov
>
> Mention the tick-box otherwise only the MR author can rebase the
> series.
>
> Cc: Jordan Justen
> Cc: Dylan Baker
> Cc: Erik Faye-Lu
When we try to do a vrend transfer from a renderable texture, we end up
using glReadPixels to read the data. However, OpenGL ES has
restrictions on what formats are allowed to be used for glReadPixels.
In partcular, only GL_UNSIGNED_BYTE + GL_RGBA are guaranteed to be
supported (for OpenGL ES 2.0;
On Wed, 2019-03-06 at 13:39 +1000, Dave Airlie wrote:
> On Wed, 6 Mar 2019 at 01:01, Erik Faye-Lund
> wrote:
> > When we try to do a vrend transfer from a renderable texture, we
> > end up
> > using glReadPixels to read the data. However, OpenGL ES has
> > restrictio
On Mon, 2019-03-18 at 14:44 -0700, Lepton Wu wrote:
> virgl render complains about "Illegal resource" when running
> dEQP-EGL.functional.color_clears.single_context.gles2.rgb888_window,
> the reason is that a zero bind value was given for temp resource.
>
> Signed-off-by: Lepton Wu
> ---
> src/g
On Mon, 2019-04-01 at 12:43 -0700, Lepton Wu wrote:
>
>
> On Tue, Mar 19, 2019 at 4:29 AM Erik Faye-Lund <
> erik.faye-l...@collabora.com> wrote:
> > On Mon, 2019-03-18 at 14:44 -0700, Lepton Wu wrote:
> > > virgl render complains about "Ill
On Mon, 2019-04-08 at 11:39 +0200, Samuel Pitoiset wrote:
> This fixes the following LLVM error when using RADV_DEBUG=checkir:
> Intrinsic name not mangled correctly for type arguments! Should be:
> llvm.amdgcn.buffer.atomic.add.i32
> i32 (i32, <4 x i32>, i32, i32, i1)* @llvm.amdgcn.buffer.atomic.a
On Mon, 2019-04-08 at 12:39 +0200, Samuel Pitoiset wrote:
> On 4/8/19 12:32 PM, Erik Faye-Lund wrote:
> > On Mon, 2019-04-08 at 11:39 +0200, Samuel Pitoiset wrote:
> > > This fixes the following LLVM error when using
> > > RADV_DEBUG=checkir:
> > > Intrinsic
Nice move to put the logic in its own function!
Reviewed-by: Erik Faye-Lund
On Mon, 2019-04-08 at 09:39 -0700, Lepton Wu wrote:
> virgl render complains about "Illegal resource" when running
> dEQP-EGL.functional.color_clears.single_context.gles2.rgb888_window,
> the reason
Yeah, moving this to the mesa group in gitlab would be great for
visibility.
On Sat, 2019-04-13 at 12:22 +, Jean Hertel wrote:
> Any other mesa developer interested in seeing this move forward?
>
> Kind Regards,
> Jean Hertel
>
> ___
> mesa-dev mai
On Tue, 2019-04-16 at 01:49 +, Alyssa Rosenzweig wrote:
> This (fairly large) patch continues work surrounding the panfrost_job
> abstraction to improve job lifetime management. In particular, we add
> infrastructure to track which BOs are used by a particular job
> (currently limited to the ve
On Tue, Aug 14, 2018 at 5:47 AM, Gurchetan Singh
wrote:
This is virgl analogue to cf6dad.
Fixes:
dEQP-GLES31.functional.image_load_store.3d.atomic.*
Example test cases:
dEQP-GLES31.functional.image_load_store.3d.atomic.add_r32ui_return_value
dEQP-GLES31.functional.image_load_store.3
Instead of doing conservative guesses, we should report the max levels
based on the max sizes we get from GL on the host.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_hw.h | 3 +++
src/gallium/drivers/virgl/virgl_screen.c | 7 +++
2 files changed, 10 insertions
tracts computes max-size by doing by 2^(n-1), which means this
should be 256 cubed, not 512 cubed. The other comments are correct.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_screen.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/src/galliu
I forgot to mention, this patch depends on a virglrenderer MR that
hasn't been merged yet. So it shouldn't be merged before the MR has
landed.
https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/25
On Tue, Aug 14, 2018 at 3:02 PM, Erik Faye-Lund
wrote:
Instea
What are you referring to, exactly? In OpenGL, texture size-limits are
per axis, not in total...
On Tue, Aug 14, 2018 at 5:43 PM, Marek Olšák wrote:
You could have a 3d or cube texture where 1 or 2 dimensions are 16k.
Marek
On Tue, Aug 14, 2018, 9:02 AM Erik Faye-Lund
wrote:
These macro
ue, Aug 14, 2018, 11:57 AM Erik Faye-Lund
wrote:
What are you referring to, exactly? In OpenGL, texture size-limits
are per axis, not in total...
On Tue, Aug 14, 2018 at 5:43 PM, Marek Olšák
wrote:
You could have a 3d or cube texture where 1 or 2 dimensions are 16k.
Marek
On Tue, Aug 14,
12:11 AM, Lionel Landwerlin
wrote:
Hey Erik,
Out of curiosity, what app/test managed to run into this assert?
We could have some test added :)
Thanks,
-
Lionel
On 08/08/18 09:34, Lionel Landwerlin wrote:
On 07/08/18 20:31, Erik Faye-Lund wrote:
If called with an empty size, brw_emit_buffer_surface_s
This adds an environment-varaible that can be used for driver-specific
flags, as well as a flag for it to enable verbose output.
While we're at it, quiet some overly chatty debug-output by default.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_context.c | 6 --
This is just debug-cruft left over. Let's just get rid of it.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_encode.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/drivers/virgl/virgl_encode.h
b/src/gallium/drivers/virgl/virgl_encode.h
index 749cd
This is the only direct call-site for fprintf in virgl; all other
call-sites call debug_printf instead. So let's follow in style here.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_encode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/ga
Sorry, made a mistake when sending this series out. I'll resend
properly soon.
On Mon, Aug 20, 2018 at 2:03 PM, Erik Faye-Lund
wrote:
This adds an environment-varaible that can be used for driver-specific
flags, as well as a flag for it to enable verbose output.
While we're at
This is the only direct call-site for fprintf in virgl; all other
call-sites call debug_printf instead. So let's follow in style here.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_encode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/ga
t variable.
Erik Faye-Lund (4):
virgl: delete commented out fprintf-call
virgl: replace fprintf-call with debug_printf
virgl: introduce $VIRGL_DEBUG=verbose
virgl: add debug-switch to output TGSI
src/gallium/drivers/virgl/virgl_context.c | 6 --
src/gallium/drivers/virgl/virgl_enco
This is just debug-cruft left over. Let's just get rid of it.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_encode.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/drivers/virgl/virgl_encode.h
b/src/gallium/drivers/virgl/virgl_encode.h
index 749cd
This adds an environment-varaible that can be used for driver-specific
flags, as well as a flag for it to enable verbose output.
While we're at it, quiet some overly chatty debug-output by default.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_context.c | 6 --
This is quite useful for debugging shader-transpiling issues in
virglrenderer.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_encode.c | 3 +++
src/gallium/drivers/virgl/virgl_screen.c | 1 +
src/gallium/drivers/virgl/virgl_screen.h | 1 +
3 files changed, 5 insertions
has an
exhaustive list of qualifiers here, and it does not include an option
with both.
So let's factor out the precise/invariant handling from the
type_qualifier rule so we can reuse it, as there's some intricate
subtleties here.
For reference: glslangValidator already allows this.
Sig
On ma., aug. 27, 2018 at 9:49 AM, Gert Wollny
wrote:
Am Montag, den 20.08.2018, 14:10 +0200 schrieb Erik Faye-Lund:
This is quite useful for debugging shader-transpiling issues in
virglrenderer.
Isn't this coverted by ST_DEBUG=tgsi?
Ah, I wasn't even aware of this.
There&#
x->cbuf->cdw,
hdr_len);
...instead.
Otherwise we'll get spewing on stderr, which has been known to cause
issues for some test-suite runners.
With that fixed:
Reviewed-by: Erik Faye-Lund
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Ping?
On on., aug. 22, 2018 at 7:34 PM, Erik Faye-Lund
wrote:
There's seems to be nothing in the GLSL (ES) specifications that
diallow
redeclaring a variable as both 'precise' and 'invariant' in the same
statement. But the way the parse-rules are structured this fai
MaxAtomicCounters has already been assigned in the loop above in the
ssbo_atomic = true case, so this will calculate the same value as the
default.
While we're at it, fixup indentation on the MaxAtomicBufferBindings
assign.
Signed-off-by: Erik Faye-Lund
---
src/mesa/state_tr
final step currently needed to pass dEQP GLES-3.1 (as well as
GLES-3.2) using virgl/virglrenderer on i965 hardware.
Erik Faye-Lund (6):
st/mesa: use real bool for can_ubo
st/mesa: clean up atomic vs ssbo code
st/mesa: simplify MaxAtomicBufferSize-logic
gallium: add PIPE_CAP_MAX_COMBINED_SHAD
This gets rid of a r600 specific hack in the state-tracker, and prepares
for other drivers to be able to use hw-atomics.
While we're at it, clean up some indentation in the various drivers.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/etnaviv/etnaviv_screen.c | 3 +++
src/ga
SSBOs without incorrectly
dropping the last SSBO.
This has the nice result that the SSBOs and atomic buffers are dealt
with almost completely orthogonally, easing some upcoming patches.
Signed-off-by: Erik Faye-Lund
---
src/mesa/state_tracker/st_extensions.c | 27 --
1
This moves the evergreen-specific max-sizes out as a driver-cap, so
other drivers with less strict requirements also can use hw-atomics.
Remove ssbo_atomic as it's no longer needed.
We should now be able to use hw-atomics for some stages and not for
other, if needed.
Signed-off-by: Erik
We're doing full c99 now, so there's no point in using the old boolean
type.
Signed-off-by: Erik Faye-Lund
---
This is not technically nessecary for the series, but IMO a nice cleanup
nevertheless.
src/mesa/state_tracker/st_extensions.c | 6 +++---
1 file changed, 3 insertions(+), 3
virgl_protocol.h is considered to have it's upstream in the
virglrenderer repository, and somehow these minor differences has
crept in.
Let's sync with the upstream to avoid this.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_protocol.h | 2 +-
1 file changed, 1
From: Tomeu Vizoso
Emulating atomics on top of ssbos can lead to too small max SSBO count,
so let's use the hw-atomics mechanism to expose atomic buffers instead.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_context.c | 37 ++
src/gallium/dr
On fr., aug. 31, 2018 at 7:35 PM, Gurchetan Singh
wrote:
On Thu, Aug 30, 2018 at 6:41 AM Erik Faye-Lund
wrote:
From: Tomeu Vizoso
Emulating atomics on top of ssbos can lead to too small max SSBO
count,
so let's use the hw-atomics mechanism to expose atomic buffers
in
On fr., aug. 31, 2018 at 7:44 PM, Gurchetan Singh
wrote:
On Thu, Aug 30, 2018 at 6:41 AM Erik Faye-Lund
wrote:
This moves the evergreen-specific max-sizes out as a driver-cap, so
other drivers with less strict requirements also can use hw-atomics.
Remove ssbo_atomic as it's no l
PM Gurchetan Singh
wrote:
On Thu, Aug 30, 2018 at 6:41 AM Erik Faye-Lund
wrote:
>
> From: Tomeu Vizoso
>
> Emulating atomics on top of ssbos can lead to too small max SSBO
count,
> so let's use the hw-atomics mechanism to expose atomic buffers
instead.
>
> S
MaxAtomicCounters has already been assigned in the loop above in the
ssbo_atomic = true case, so this will calculate the same value as the
default.
While we're at it, fixup indentation on the MaxAtomicBufferBindings
assign.
Signed-off-by: Erik Faye-Lund
Reviewed-by: Marek Olšák
---
src
SSBOs without incorrectly
dropping the last SSBO.
This has the nice result that the SSBOs and atomic buffers are dealt
with almost completely orthogonally, easing some upcoming patches.
Signed-off-by: Erik Faye-Lund
Reviewed-by: Marek Olšák
---
src/mesa/state_tracker/st_extensions.c
This moves the evergreen-specific max-sizes out as a driver-cap, so
other drivers with less strict requirements also can use hw-atomics.
Remove ssbo_atomic as it's no longer needed.
We should now be able to use hw-atomics for some stages and not for
other, if needed.
Signed-off-by: Erik
state-tracker requirement.
- [Marek] Added documentation of the new caps
Erik Faye-Lund (6):
st/mesa: use real bool for can_ubo
st/mesa: clean up atomic vs ssbo code
st/mesa: simplify MaxAtomicBufferSize-logic
gallium: add PIPE_CAP_MAX_COMBINED_SHADER_BUFFERS
gallium
This gets rid of a r600 specific hack in the state-tracker, and prepares
for other drivers to be able to use hw-atomics.
While we're at it, clean up some indentation in the various drivers.
Signed-off-by: Erik Faye-Lund
Reviewed-by: Marek Olšák
Reviewed-by: Wladimir J. van der Laan
---
We're doing full c99 now, so there's no point in using the old boolean
type.
Signed-off-by: Erik Faye-Lund
Reviewed-by: Marek Olšák
---
src/mesa/state_tracker/st_extensions.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_extension
virgl_protocol.h is considered to have it's upstream in the
virglrenderer repository, and somehow these minor differences has
crept in.
Let's sync with the upstream to avoid this.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_protocol.h | 2 +-
1 file changed, 1
From: Tomeu Vizoso
Emulating atomics on top of ssbos can lead to too small max SSBO count,
so let's use the hw-atomics mechanism to expose atomic buffers instead.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_context.c | 37 ++
src/gallium/dr
no longer crash (although it still
fails):
bin/copyteximage 2D -samples=2 -auto
Signed-off-by: Erik Faye-Lund
---
This is the patch that I'm a bit unsure about. More details in the
cover letter.
src/gallium/drivers/virgl/virgl_texture.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(
When we fail to map memory, we should also free trans to avoid
leaking memory.
Noticed while reading code.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_texture.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/virgl/virgl_texture.c
b/src/gallium
ughts here? It seems you introduced this
inconsistency in the very first commit to virgl. Was there some
expectation of some third, non-depth handling case here that just didn't
get noticed until now?
Erik Faye-Lund (4):
virgl: free trans on map-error
virgl: drop needless return-code
vir
We don't use the size we calculate in this function, so let's just
drop the calculation
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_texture.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/gallium/drivers/virgl/virgl_texture.c
b/s
We always return TRUE, and we never check the return-value. Let's
just drop the return value instead.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/virgl/virgl_texture.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/gallium/drivers/virgl/virgl_texture
0xBBB30CA: st_api_create_context (st_manager.c:896)
by 0xB981E76: dri_create_context (dri_context.c:155)
by 0xB97BDCE: driCreateContextAttribs (dri_util.c:473)
by 0x5288331: dri3_create_context_attribs (dri3_glx.c:309)
by 0x5264D64: glXCreateContextAttribsARB (create_context.c:78)
Signed-off-by: Erik
On to., sep. 6, 2018 at 3:00 PM, Emil Velikov
wrote:
Hi Erik,
On 6 September 2018 at 11:48, Erik Faye-Lund
wrote:
If we end up never taking the loop that writes ret, we can end up
with
an uninitialized value, and if we're *really* unlucky, that value
can
be -1, causing us to go
"},
+ { "glsl", debug_shader_glsl, "Print GLSL shaders created from
TGSI"},
+ { "glsl", debug_shader_streamout, "Print GLSL shaders created
from TGSI"},
Typo? Shouldn't the string be "streamout", and the description be
somet
On to., sep. 6, 2018 at 3:25 PM, Emil Velikov
wrote:
On 5 September 2018 at 16:34, Gert Wollny
wrote:
+
+enum virgl_debug_flags {
+ debug_shader_tgsi = 1 << 0,
+ debug_shader_glsl = 1 << 1,
+ debug_shader_streamout = 1 << 2,
+ debug_shader = debug_shader_tgsi | debug_shader_
88d24s8ms4
Signed-off-by: Erik Faye-Lund
Fixes: a8987b88ff1 "virgl: add driver for virtio-gpu 3D (v2)"
---
I noticed this crash while testing this patch:
https://patchwork.freedesktop.org/patch/248805/
src/gallium/drivers/virgl/virgl_texture.c | 2 ++
1 file changed, 2 insertions(
If we update the program-state etc, we risk compiling needless shaders,
which can cost quite a bit of performance.
Signed-off-by: Erik Faye-Lund
---
This was motivated by seeing an unexpected shader-compile with
nonsensical state on start-up in glxgears.
src/mesa/main/clear.c | 34
ed, Sep 12, 2018 at 12:05 PM Erik Faye-Lund
wrote:
If we update the program-state etc, we risk compiling needless
shaders,
which can cost quite a bit of performance.
Signed-off-by: Erik Faye-Lund
---
This was motivated by seeing an unexpected shader-compile with
nonsensical state on s
ids a crash while running Piglit's glx/glx-visuals-stencil
test, both on virgl and r600g.
Signed-off-by: Erik Faye-Lund
---
src/mesa/state_tracker/st_atom_framebuffer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_atom_framebuffer.c
On Wed, Apr 11, 2018 at 8:48 PM, Thomas Helland
wrote:
> This series came about when I saw a talk online, while simultaneously
> being annoyd about the needless waste of memory in our set as reported
> by pahole. I have previously made some patches that changed our hash
> table from a reprobing on
On Fri, Apr 27, 2018 at 11:17 AM, samiuddi
wrote:
> Test: CtsDisplayTestCases pass
>
> Signed-off-by: samiuddi
> ---
> src/egl/drivers/dri2/platform_android.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/egl/drivers/dri2/platform_android.c
> b/src/egl/drivers/dri2/platform_an
On Thu, Nov 16, 2017 at 6:26 PM, Ilia Mirkin wrote:
> On Thu, Nov 16, 2017 at 7:15 AM, Wladimir wrote:
>>> I think it would be reasonable to re-emit the shader state (or maybe
>>> just the varyings) when the primitive type changes from points to
>>> non-points. It virtually never happens that the
On Thu, Dec 14, 2017 at 6:02 AM, Timothy Arceri wrote:
> Fixes 56 crashes in radeonsi.
56 crashes with what? Piglit?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Feb 1, 2018 04:35, "Dave Airlie" wrote:
From: Dave Airlie
In order to deal with conversions properly we need to extract
non-64bit sources from vectors instead of expanding them as
the 64-bit code does.
We need non-64bit sources for the 32->64 conversion functions.
Signed-off-by: Dave Airli
On Thu, Feb 22, 2018 at 2:23 PM, Thierry Reding
wrote:
> On Wed, Feb 21, 2018 at 05:01:02PM +, Emil Velikov wrote:
>> Hi Thierry,
>>
>> On 21 February 2018 at 15:30, Thierry Reding
>> wrote:
>> > +static const char *
>> > +tegra_screen_get_name(struct pipe_screen *pscreen)
>> > +{
>> > + r
Just as a fun toy, I decided to give an animated SVG "variation" of
this a go myself:
https://codepen.io/kusma/pen/vrXppL
The actual SVG can be found here:
https://gitlab.freedesktop.org/snippets/492
The gears were generated by this python script, based on the glxgears
source code:
https://git
; Cheers
>
> Mike
>
> On Thu, 7 Jun 2018 at 10:02 Erik Faye-Lund wrote:
>>
>> Just as a fun toy, I decided to give an animated SVG "variation" of
>> this a go myself:
>>
>> https://codepen.io/kusma/pen/vrXppL
>>
>> The actual SVG can
On Thu, Jun 7, 2018 at 9:25 AM, Daniel Stone wrote:
> Hi,
>
> On 2 June 2018 at 16:45, Jason Ekstrand wrote:
>> When the migration happens, there will be a very brief (less than 30
>> minutes?) period during which no one will be able to push to either repo.
>> I'll fire off an e-mail as well as m
On Fri, Jun 8, 2018 at 2:06 PM, Rob Clark wrote:
> On Fri, Jun 8, 2018 at 3:02 AM, Jordan Justen wrote:
>> On Thu, Jun 7, 2018 at 2:56 AM Eero Tamminen
>> wrote:
>>> On 07.06.2018 12:01, Erik Faye-Lund wrote:
>>> > Just as a fun toy, I decided to give an an
On Fri, Jun 8, 2018 at 4:09 PM Rhys Perry wrote:
>
> Might be good to do something like this: https://codepen.io/anon/pen/ERNdYJ
> So that those with NoScript or something won't have gears constantly
> rotating on their screen.
>
Yeah, good point.
___
m
I've updated my attempt here, to now have the original colors, and
centered the M-corners on the text a bit more properly:
https://codepen.io/kusma/pen/vrXppL
On Tue, Jun 12, 2018 at 2:51 AM Rob Clark wrote:
>
> On Mon, Jun 11, 2018 at 6:24 PM, Laura Ekstrand wrote:
> > I really like the rotate
On Tue, Jun 12, 2018 at 1:59 PM Ilia Mirkin wrote:
>
> On Tue, Jun 12, 2018 at 7:04 AM, Erik Faye-Lund wrote:
> > I've updated my attempt here, to now have the original colors, and
> > centered the M-corners on the text a bit more properly:
> >
> > https://cod
On Tue, Jun 12, 2018 at 2:12 PM Erik Faye-Lund wrote:
>
> On Tue, Jun 12, 2018 at 1:59 PM Ilia Mirkin wrote:
> >
> > On Tue, Jun 12, 2018 at 7:04 AM, Erik Faye-Lund wrote:
> > > I've updated my attempt here, to now have the original colors, and
> > >
On Tue, Jun 12, 2018 at 1:03 AM Dylan Baker wrote:
>
> ---
> docs/meson.html | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/docs/meson.html b/docs/meson.html
> index 6697dbb34ef..7541e7a71b0 100644
> --- a/docs/meson.html
> +++ b/docs/meson.html
> @@ -1,9 +1,9 @@
>
Typo in the subject, should be "meson", not "meosn".
On Tue, Jun 12, 2018 at 1:03 AM Dylan Baker wrote:
>
> They require the pipe-loaders, which require xmlconfig, which doesn't
> build with msvc.
> ---
> src/gallium/tests/meson.build | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
On Wed, Jun 20, 2018 at 3:03 AM Jonathan Marek wrote:
>
> Signed-off-by: Jonathan Marek
> ---
> src/gallium/drivers/freedreno/a2xx/fd2_program.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_program.c
> b/src/gallium/drivers/freedreno/a2xx/fd2
On Tue, Jun 26, 2018, 14:00 Rob Clark wrote:
> On Tue, Jun 26, 2018 at 3:32 AM, Erik Faye-Lund
> wrote:
> > On Wed, Jun 20, 2018 at 3:03 AM Jonathan Marek
> wrote:
> >>
> >> Signed-off-by: Jonathan Marek
> >> ---
> >> src/gallium/drive
Unless I'm misunderstanding, this seems to indicate that the hardware
has a fixed set of sample positions, which I don't think is true for
most hardware. Instead, the sample locations is a function of the
multisampling mode for a given surface...
On Thu, Jun 28, 2018 at 3:45 PM Gert Wollny wrote:
On Thu, Jun 28, 2018 at 5:31 PM Gert Wollny wrote:
>
> Am Donnerstag, den 28.06.2018, 17:09 +0200 schrieb Erik Faye-Lund:
> > Unless I'm misunderstanding, this seems to indicate that the hardware
> > has a fixed set of sample positions, which I don't think is true fo
On Thu, Jun 28, 2018 at 5:54 PM Gert Wollny wrote:
>
> Am Donnerstag, den 28.06.2018, 17:40 +0200 schrieb Erik Faye-Lund:
> > On Thu, Jun 28, 2018 at 5:31 PM Gert Wollny > m> wrote:
> > >
> > > There are two aspects:
> > >
> > > For each n
a crash in dEQP-GLES31.functional.draw_indirect.random.0
on VirGL for me.
Signed-off-by: Erik Faye-Lund
---
This is a resend of a mail that didn't reach the mailing-list yet.
Sorry if it appears twice for someone!
src/gallium/auxiliary/util/u_vbuf.c | 3 +++
1 file changed, 3 insertions(
a crash in dEQP-GLES31.functional.draw_indirect.random.0
on VirGL for me.
Signed-off-by: Erik Faye-Lund
---
I noticed this while debugging something else, so I thought I'd send
a patch upstream, as the problem doesn't seem unique to my usecase.
src/gallium/auxiliary/util/u_vbuf.c |
On Thu, Jun 28, 2018 at 7:49 PM Gert Wollny wrote:
>
> Am Donnerstag, den 28.06.2018, 18:09 +0200 schrieb Erik Faye-Lund:
> > It still seems kinda strange (and fragile) to me to try to enumerate
> > all possible sample locations up-front instead of querying a given
> >
On Thu, Jun 28, 2018 at 11:12 PM Fritz Koenig wrote:
>
> Adds an extension to glFramebufferParameteri
> that will specify if the framebuffer is vertically
> flipped. Historically system framebuffers are
> vertically flipped and user framebuffers are not.
> Checking to see the state was done by loo
itions for intermediate sample counts
> - fix unused varible warning
> - update description
> v4: explain better what this patch assumes and how it handles sample numbers
> that are not directly advertised (thanks go to Erik Faye-Lund for making
> me aware that this s
On Fri, Jun 29, 2018 at 12:52 PM Erik Faye-Lund wrote:
>
> On Fri, Jun 29, 2018 at 12:39 PM Gert Wollny
> wrote:
> >
> > Use caps to obtain the multisample sample positions for up to 16
> > positions and implement the according Gallium interface.
> >
> > T
The OpenGL 4.4 specification, table Table 23.55 ("Implementation
Dependent Values"), defines the minimum-maximum value for
MAX_VERTEX_ATTRIB_STRIDE to be 2048.
So we shouldn't enable OpenGL 4.4 on implementations where this isn't
the case. Let's add a check for this.
The OpenGL 3.1 specification, table Table 20.41 ("Implementation
Dependent Values"), defines the minimum-maximum value for
MAX_VERTEX_ATTRIB_STRIDE to be 2048.
So we shouldn't enable OpenGL ES 3.1 on implementations where this
isn't the case. Let's add a check for this
2048. Any
applications using 2048 are already broken anyway.
Signed-off-by: Erik Faye-Lund
---
src/gallium/drivers/r600/r600_pipe.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index bc5660d6d1..2518032
avoid
exposing a too high spec version in virgl and then get
dEQP failures when running on old hardware. The virgl
specific bits are being sent separately, because they
depend on some other not-yet-upstream things ATM.
Thoughts?
Erik Faye-Lund (3):
r600: report incorrect max-vertex-attrib
On 06. juli 2018 18:43, Roland Scheidegger wrote:
Am 06.07.2018 um 12:03 schrieb Erik Faye-Lund:
OpenGL 4.4 and OpenGL ES 3.1 both require the maximum
vertex attrib stride to be at least 2048. If this isn't
the case, we shouldn't expose these API versions.
Unfortunately, the r600 d
On Thu, Jul 5, 2018 at 7:02 PM Emil Velikov wrote:
>
> On 5 July 2018 at 17:17, Eric Engestrom wrote:
> > On Thursday, 2018-07-05 14:43:02 +0100, Emil Velikov wrote:
> >> On 5 July 2018 at 10:53, Eric Engestrom wrote:
> >> > On Monday, 2018-07-02 14:12:44 +0530, samiuddi wrote:
> >> >> This fixe
On 10. juli 2018 15:42, Gert Wollny wrote:
For three component textures virgl faces the problem that the host driver
may report that these can not be used as a render target, and when the
client requests such a texture a four-componet texture will be choosen
even if only a sampler view was reques
501 - 600 of 762 matches
Mail list logo
