https://bugs.freedesktop.org/show_bug.cgi?id=93648
Pierre Bourdon changed:
What|Removed |Added
Component|Drivers/Gallium/radeonsi|Mesa core
Assignee|dri-devel@
https://bugs.freedesktop.org/show_bug.cgi?id=93648
Pierre Bourdon changed:
What|Removed |Added
Summary|Random lines being rendered |Random lines being rendered
https://bugs.freedesktop.org/show_bug.cgi?id=93648
Ilia Mirkin changed:
What|Removed |Added
Component|Mesa core |Drivers/Gallium/radeonsi
Assigne
Driver loading for imx-drm gallium driver fails, as the current
implementation expects __driDriverGetExtensions_NAME_drm. In order
to get the driver successfully loaded to we need to transform
__driDriverGetExtensions_imx-drm to __driDriverGetExtensions_imx_drm.
Signed-off-by: Christian Gmeiner
-
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #14 from Marek Olšák ---
(In reply to ytrezq from comment #12)
> (In reply to Marek Olšák from comment #11)
> > Yes. If you have a real GPU, any CPU rendering is a bad idea.
>
> I just thought 2 combined ᴄᴘᴜs or 2 combined ɢᴘᴜs were
https://bugs.freedesktop.org/show_bug.cgi?id=93686
ytr...@sdf-eu.org changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #15
https://bugs.freedesktop.org/show_bug.cgi?id=93686
ytr...@sdf-eu.org changed:
What|Removed |Added
CC||mar...@gmail.com
--- Comment #16 from
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #17 from ytr...@sdf-eu.org ---
(In reply to Marek Olšák from comment #14)
> You are completely missing the point. The main concern is that applications
> may try to use all available renderers, including llvmpipe if it's present.
> The
https://bugs.freedesktop.org/show_bug.cgi?id=93686
ytr...@sdf-eu.org changed:
What|Removed |Added
CC|alexdeuc...@gmail.com, |
|mar...@gmail.com
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #18 from Marek Olšák ---
A fast GPU + slow GPU is also a bad idea. There is the risk of improper load
balancing resulting in the performance being the same or slightly above the
slow GPU. Or if it's done badly, it can be well below th
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #19 from ytr...@sdf-eu.org ---
(In reply to Marek Olšák from comment #18)
> A fast GPU + slow GPU is also a bad idea. There is the risk of improper load
> balancing resulting in the performance being the same or slightly above the
> sl
https://bugs.freedesktop.org/show_bug.cgi?id=93686
ytr...@sdf-eu.org changed:
What|Removed |Added
CC||mar...@gmail.com
--- Comment #20 from
https://bugs.freedesktop.org/show_bug.cgi?id=93686
ytr...@sdf-eu.org changed:
What|Removed |Added
CC|mar...@gmail.com|
--
You are receiving this mail beca
hi, Rob Herring:
I have downloaded the AOSP repos finally(spend 36+ hours). and followed your
Instructions try to know your current progress on x86_64.
I finished virglrenderer, qemu, kernel, BUT... (BTW, I have tried AOSP-6,
android-x86 sucessfully in the last)
When I build aosp， I got below e
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #21 from Jose Fonseca ---
I'm one of llvmpipe authors (particularly the initial bring up of the driver).
Enabling llvmpipe to run on top of, or side-by-side with, GPUs or clusters via
OpenCL/whatever is not something we're intereste
https://bugs.freedesktop.org/show_bug.cgi?id=93686
ytr...@sdf-eu.org changed:
What|Removed |Added
CC|jfons...@vmware.com |
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=93686
ytr...@sdf-eu.org changed:
What|Removed |Added
CC||jfons...@vmware.com
--- Comment #22 f
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #23 from Jan Vesely ---
(In reply to ytrezq from comment #16)
> (In reply to Alex Deucher from comment #13)
> > I can't speak for intel, but on AMD APUs, while the GPU appears as a device
> > on the PCIE bus, it actually has a much fa
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #24 from Alex Deucher ---
(In reply to ytrezq from comment #15)
> (In reply to Alex Deucher from comment #13)
> > I can't speak for intel, but on AMD APUs, while the GPU appears as a device
> > on the PCIE bus, it actually has a much
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #25 from ytr...@sdf-eu.org ---
(In reply to Alex Deucher from comment #24)
> The GPU has a direct internal link the system memory similar to what the CPU
> has
Never said the contrary
--
You are receiving this mail because:
You are t
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #26 from ytr...@sdf-eu.org ---
Concerning synchronisation, it don’t removes shared bandwidth with the ᴄᴘᴜ
http://superuser.com/q/789816/282033
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the as
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #27 from ytr...@sdf-eu.org ---
At least for intel ᴀᴘᴜs there’s ᴘᴄɪe bus :
http://i.stack.imgur.com/Gcwi4.png
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #28 from Jason Ekstrand ---
(In reply to ytrezq from comment #15)
> (In reply to Alex Deucher from comment #13)
> > I can't speak for intel, but on AMD APUs, while the GPU appears as a device
> > on the PCIE bus, it actually has a muc
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #29 from Jason Ekstrand ---
(In reply to ytrezq from comment #27)
> At least for intel ᴀᴘᴜs there’s ᴘᴄɪe bus :
> http://i.stack.imgur.com/Gcwi4.png
That picture is a lie. It shows up on the bus, yes, but only because that
makes it e
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #30 from Marek Olšák ---
(In reply to ytrezq from comment #19)
> llvmpipe is essentially an opersource driver itself (the difference is only
> not requiring in‑kernel part). So generally when a modern Linux distro ship
> llvmpipe, it
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #31 from ytr...@sdf-eu.org ---
(In reply to Marek Olšák from comment #30)
>
> You can't be more wrong. I wish you said something that is correct, but
> sadly that's probably not gonna happen.
>
> llvmpipe doesn't need any hardware-sp
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #32 from Marek Olšák ---
(In reply to ytrezq from comment #31)
> I already told that for kernel. I recognize I used the wrong word : llvmpipe
> is definitely partially dependent (ꜱɪᴍᴅ instructions)
Yes, dependent on the CPU. :)
--
https://bugs.freedesktop.org/show_bug.cgi?id=93686
--- Comment #33 from ytr...@sdf-eu.org ---
(In reply to Marek Olšák from comment #32)
> Yes, dependent on the CPU. :)
Hardware dependent, like the user mode libraries for controlling ɢᴘᴜ kernel
ᴅʀᴍ.
--
You are receiving this mail because:
You a
On Fri, Jan 15, 2016 at 9:40 PM, Tapani Pälli wrote:
> Patch moves uniform calculation to happen during link_uniforms, this
> is possible with help of UniformRemapTable that has all the reserved
> locations.
>
> Location assignment for implicit locations is changed so that we
> utilize also the 'h
On Thu, Jan 14, 2016 at 12:27 PM, Matt Turner wrote:
> On Thu, Jan 14, 2016 at 12:08 PM, Jason Ekstrand wrote:
>> BDW adds the following restriction: "When multiplying DW x DW, the dst
>> cannot be accumulator."
>> ---
>> src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 6 +-
>> 1 file changed,
On Sat, 2016-01-16 at 07:40 +0200, Tapani Pälli wrote:
> Patch moves uniform calculation to happen during link_uniforms,
Hi Tapani,
I like that you are moving the check here as it allows arrays without
an explicit location to be resized before the max check is done.
However I'm not too excited ab
On Jan 16, 2016 5:56 PM, "Matt Turner" wrote:
>
> On Thu, Jan 14, 2016 at 12:27 PM, Matt Turner wrote:
> > On Thu, Jan 14, 2016 at 12:08 PM, Jason Ekstrand
wrote:
> >> BDW adds the following restriction: "When multiplying DW x DW, the dst
> >> cannot be accumulator."
> >> ---
> >> src/mesa/driv
From: Dave Airlie
One of the oglconform tests was crashing here, and it was
due to not cloning the actual parameters before creating the
new call. This makes a call clone function that does the right
things to make sure we clone all the needed info, and points
the callee at it. (It differs from -
On Fri, Jan 15, 2016 at 11:45 PM, 陈渝 wrote:
> hi, Rob Herring:
> I have downloaded the AOSP repos finally(spend 36+ hours). and followed your
> Instructions try to know your current progress on x86_64.
>
> I finished virglrenderer, qemu, kernel, BUT... (BTW, I have tried AOSP-6,
> android-x86 s
On 01/17/2016 12:32 AM, Matt Turner wrote:
On Fri, Jan 15, 2016 at 9:40 PM, Tapani Pälli wrote:
Patch moves uniform calculation to happen during link_uniforms, this
is possible with help of UniformRemapTable that has all the reserved
locations.
Location assignment for implicit locations is cha
On 01/17/2016 04:56 AM, Timothy Arceri wrote:
On Sat, 2016-01-16 at 07:40 +0200, Tapani Pälli wrote:
Patch moves uniform calculation to happen during link_uniforms,
Hi Tapani,
I like that you are moving the check here as it allows arrays without
an explicit location to be resized before the ma
From Section 7.9 (SUBROUTINE UNIFORM VARIABLES) of the OpenGL
4.5 Core spec:
"The command
void UniformSubroutinesuiv(enum shadertype, sizei count,
const uint *indices);
will load all active subroutine uniforms for shader stage
shadertype with sub
https://bugs.freedesktop.org/show_bug.cgi?id=93731
--- Comment #2 from Timothy Arceri ---
Thanks for the bug report.
Mesa fix:
http://patchwork.freedesktop.org/patch/70667/
Piglit test:
http://patchwork.freedesktop.org/patch/70666/
--
You are receiving this mail because:
You are the QA Contac
The efficiency should be approximately the same. We do a little more work
per phi node because we have to sort the predecessors. However, we no
longer have to walk the blocks a second time to pop things off the stack.
The bigger advantage, however, is that we can now re-use the phi placement
and
Right now, we have phi placement code in two places and there are other
places where it would be nice to be able to do this analysis. Instead of
repeating it all over the place, this commit adds a helper for placing all
of the needed phi nodes for a value.
Cc: Connor Abbott
---
src/glsl/Makefil
Previously, nir_dominance.c didn't properly handle unreachable blocks.
This can happen if, for instance, you have something like this:
loop {
if (...) {
break;
} else {
break;
}
}
In this case, the block right after the if statement will be unreachable.
This commit makes two
---
src/util/bitset.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/bitset.h b/src/util/bitset.h
index c452819..2404ce7 100644
--- a/src/util/bitset.h
+++ b/src/util/bitset.h
@@ -98,7 +98,7 @@ __bitset_ffs(const BITSET_WORD *x, int n)
static inline unsigned
__bit
On Sun, 2016-01-17 at 07:09 +0200, Tapani Pälli wrote:
> On 01/17/2016 04:56 AM, Timothy Arceri wrote:
> > On Sat, 2016-01-16 at 07:40 +0200, Tapani Pälli wrote:
> > > Patch moves uniform calculation to happen during link_uniforms,
> > Hi Tapani,
> >
> > I like that you are moving the check here a
43 matches
Mail list logo
