The latter is a constructor for file objects, but when actually opening
a file, using the former is more idiomatic.
In addition, file() is not a builtin any more in Python 3, so this makes
the script compatible with both Python 2 and Python 3.
Signed-off-by: Mathieu Bridon <bochecha@daitauha.fr>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
The XML parser wants byte strings, not unicode strings.
In both Python 2 and 3, opening a file without specifying the mode will
open it for reading in text mode ('r').
On Python 2, the read() method of the file object will return byte
strings, while on Python 3 it will return unicode strings.
Explicitly specifying the binary mode ('rb') makes the behaviour
identical in both Python 2 and 3, returning what the XML parser
expects.
Signed-off-by: Mathieu Bridon <bochecha@daitauha.fr>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
The hex() builtin returns a string containing the hexa-decimal
representation of an integer.
When the argument is not an integer, then the function calls that
object's __hex__() method, if one is defined. That method is supposed to
return a string.
While that's not explicitly documented, that string is supposed to be a
valid hexa-decimal representation for a number. Python 2 doesn't enforce
this though, which is why we got away with returning things like
'NIR_TRUE' which are not numbers.
In Python 3, the hex() builtin instead calls an object's __index__()
method, which itself must return an integer. That integer is then
automatically converted to a string with its hexa-decimal representation
by the rest of the hex() function.
As a result, we really can't make this compatible with Python 3 as it
is.
The solution is to stop using the hex() builtin, and instead use a hex()
object method, which can return whatever we want, in Python 2 and 3.
Signed-off-by: Mathieu Bridon <bochecha@daitauha.fr>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
In Python 2, iterating over a byte-string yields single-byte strings,
and we can pass them to ord() to get the corresponding integer.
In Python 3, iterating over a byte-string directly yields those
integers.
Transforming the byte string into a bytearray gives us a list of the
integers corresponding to each byte in the string, removing the need to
call ord().
This makes the script compatible with both Python 2 and 3.
Signed-off-by: Mathieu Bridon <bochecha@daitauha.fr>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Detect if the display (X-Server) gpu and Prime renderoffload gpu prefer
different channel ordering for color depth 30 formats ([X/A]BGR2101010
vs. [X/A]RGB2101010) and perform format conversion during the blitImage()
detiling op from tiled backbuffer -> linear buffer.
For this we need to find the visual (= red channel mask) for the
X-Drawable used to display on the server gpu. We use the same proven
logic for finding that visual as in commit "egl/x11: Handle both depth
30 formats for eglCreateImage()".
This is mostly to allow "NVidia Optimus" at depth 30, as Intel/AMD
gpu's prefer xRGB2101010 ordering, whereas NVidia gpu's prefer
xBGR2101010 ordering, so we can offload to nouveau without getting
funky colors.
Tested on Intel single gpu, NVidia single gpu, Intel + NVidia prime
offload with DRI3/Present.
Note: An unintended but pleasant surprise of this patch is that it also
seems to make the modesetting-ddx of server 1.20.0 work at depth 30
on nouveau, at least with unredirected "classic" X rendering, and
with redirected desktop compositing under XRender accel, and with OpenGL
compositing under GLX. Only X11 compositing via OpenGL + EGL still gives
funky colors. modesetting-ddx + glamor are not yet ready to deal with
nouveau's ABGR2101010 format, and treat it as ARGB2101010, also exposing
X-visuals with ARGB2101010 style channel masks. Seems somehow this triggers
the logic in this patch on modesetting-ddx + depth 30 + DRI3 buffer sharing
and does the "wrong" channel swizzling that then cancels out the "wrong"
swizzling of glamor and we end up with the proper pixel formatting in
the scanout buffer :). This so far tested on a NVA5 Tesla card under KDE5
Plasma as shipping with Ubuntu 16.04.4 LTS.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
We need to distinguish if the backing storage of a pixmap
is XRGB2101010 or XBGR2101010, as different gpu hw supports
different formats. NVidia hw prefers XBGR, whereas AMD and
Intel are happy with XRGB.
Use the red channel mask of the first depth 30 visual of
the x-screen to distinguish which hw format to choose.
This fixes desktop composition of color depth 30 windows
when the X11 compositor uses EGL.
v2: Switch from using the visual of the root window to simply
using the first depth 30 visual for the x-screen, as testing
shows that each driver only exports either xrgb ordering or
xbgr ordering for the channel masks of its depth 30 visuals,
so this should be unambiguous and avoid trouble if X ever
supports depth 30 pixmaps on screens with a non-depth 30 root
window visual. This per Michels suggestion.
v3: No change to v2, but spent some time testing this more on
AMD hw, with my software hacked up to intentionally choose
pixel formats/visual with the non-preferred xBGR2101010
ordering on the ati-ddx, also with a standard non-OpenGL
X-Window with depth 30 visual, to make sure that things show
up properly with the right colors on the screen when going
through EGL+OpenGL based compositing on KDE-5. Iow. to confirm
that my explanation to the v2 patch on the mailing list of why
it should work and the actual practice agree (or possibly that
i am good at fooling myself during testing ;).
v4: Drop the local `red_mask` and just `return visual->red_mask`/
`return 0`, as suggested by Eric Engestrom.
Rebased onto current master, to take the cleanup via the new
function dri2_format_for_depth() into account.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Add support for XBGR2101010 and ABGR2101010 formats.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Add support for XBGR2101010 and ABGR2101010.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Ilia Mirkin <imirkin@alum.mit.edu>
The hardware doesn't support byte immediates, so similar to setup_imm_df()
for doubles, these helpers work by loading the constant value into a
VGRF.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This commit does not add support for the opcodes in gallivm or tgsi_to_nir.c
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
This fixes the following dEQP-GLES31 cases from NotSupported to
Pass for me:
- dEQP-GLES31.functional.blend_equation_advanced.state_query.*
- dEQP-GLES31.functional.blend_equation_advanced.basic.*
- dEQP-GLES31.functional.blend_equation_advanced.srgb.*
- dEQP-GLES31.functional.blend_equation_advanced.msaa.*
- dEQP-GLES31.functional.blend_equation_advanced.barrier.*
- dEQP-GLES31.functional.draw_buffers_indexed.overwrite_*advanced_blend_eq*
- dEQP-GLES31.functional.state_query.indexed.blend_equation_advanced_*
- dEQP-GLES31.functional.debug.negative_coverage.*.advanced_blend.*
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In gallium, supporting FBFETCH means supporting non-coherent fetches, but
in virglrenderer, due to technical reasons this is backed by coherent
fetches instead. This means we don't need to do anything for the barriers.
However, if we don't have a texture_barrier implementation, we get crashes
because the non-coherent extensions is exposed.
So, let's leave this as a NOP for now.
[airlied: I've got a more complete impl of this somewhere, once we
land the host side].
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
This instruction is used to ensure that TMU stores have been processed
before moving on. In particular, you need any TMU ops to be done by the
time the shader ends.
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Tested-By: Gert Wollny<gert.wollny@collabora.com>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Reviewed-By: Gert Wollny <gw.fossdev@gmail.com>
Not sure if GL/GLES can hit this path, but it's just decompression.
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Tested-By: Gert Wollny<gert.wollny@collabora.com>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Reviewed-By: Gert Wollny <gw.fossdev@gmail.com>
in order to support ASTC
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Tested-By: Gert Wollny<gert.wollny@collabora.com>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Reviewed-By: Gert Wollny <gw.fossdev@gmail.com>
in order to support ASTC
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Tested-By: Gert Wollny<gert.wollny@collabora.com>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Reviewed-By: Gert Wollny <gw.fossdev@gmail.com>
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Tested-By: Gert Wollny<gert.wollny@collabora.com>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Reviewed-By: Gert Wollny <gw.fossdev@gmail.com>
for ASTC support later
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Tested-By: Gert Wollny<gert.wollny@collabora.com>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Reviewed-By: Gert Wollny <gw.fossdev@gmail.com>
When texture buffers are used as images in compute shaders, the guest
never sees the modified data since the TBO is always marked as clean.
Fixes most dEQP-GLES31.functional.image_load_store.buffer.* tests.
Example test cases:
dEQP-GLES31.functional.image_load_store.buffer.load_store.r32ui
dEQP-GLES31.functional.image_load_store.buffer.qualifiers.coherent_r32f
dEQP-GLES31.functional.image_load_store.buffer.format_reinterpret.rgba8_rgba8ui
Note: virglrenderer side patch also needed to bind TBOs correctly
Reviewed-by: Dave Airlie <airlied@redhat.com>
Make glXChooseFBConfig properly handle the case where the only matching
configs have the sRGB flag set, but no sRGB attribute is specified.
Since 6e06e281, the sRGBcapable flag is now actually compared, using
MATCH_DONT_CARE.
7b0f912e added defaulting of sRGBcapable to GL_FALSE in
__glXInitializeVisualConfigFromTags(), to handle servers which don't report
it, but this function is also used by glXChooseFBConfig(), so sRGBcapable is
implicitly false when not explicitly specified.
(This can cause e.g. glxinfo to fail to find anything matching the simple
config it looks for if all the candidates have the sRGB flag set to true.
I'm assuming this doesn't happen 'normally' as candidate configs with and
without sRGB true are available)
Move this defaulting to createConfigsFromProperties(), and set the default
for glXChooseFBConfig() in init_fbconfig_for_chooser() to GLX_DONT_CARE.
Reviewed-by: Eric Anholt <eric@anholt.net>
get_supported_modifiers() and pixmap_from_buffers() requests both
expect a window as drawable, passing a pixmap will fail as the Xserver
will fail to match the given drawable to a window.
That leads to dri3_alloc_render_buffer() to return NULL and breaks
rendering when using GLX_DOUBLEBUFFER on pixmaps.
Query the root window of the pixmap on first init, and use the root
window instead of the pixmap drawable for get_supported_modifiers()
and pixmap_from_buffers().
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107117
Fixes: 069fdd5 ("egl/x11: Support DRI3 v1.1")
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
v2: ignore names on purpose, for consistency with other places where
we are doing the same (Alejandro)
v3: changes proposed by Timothy Arceri, implemented by Alejandro Piñeiro:
* Remove redundant 'struct active_xfb_varying'
* Update several comments, including spec quotes if needed
* Rename struct 'active_xfb_varying_array' to 'active_xfb_varyings'
* Rename variable 'array' to 'active_varyings'
* Replace one if condition for an assert (<MAX_FEEDBACK_BUFFERS)
* Remove BufferMode initialization (was already done)
v4: simplify output pointer handling (Timothy)
Signed-off-by: Neil Roberts <nroberts@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
