[Mesa-dev] [PATCH] intel: Add missing vtable entry for i830
When the is_hiz_depth_format vtable entry was added for i915/i956,
the entry for forgotten in the i830 vtable setup.
Signed-off-by: Carl Simonson simons...@gmail.com
---
src/mesa/drivers/dri/i915/i830_vtbl.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c
b/src/mesa/drivers/dri/i915/i830_vtbl.c
index 6d43726..74aa10c 100644
--- a/src/mesa/drivers/dri/i915/i830_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i830_vtbl.c
@@ -868,6 +868,13 @@ i830_assert_not_dirty( struct intel_context *intel )
(void) i830;
}
+static bool
+i830_is_hiz_depth_format(struct intel_context *intel,
+ gl_format format)
+{
+ return false;
+}
+
static void
i830_invalidate_state(struct intel_context *intel, GLuint new_state)
{
@@ -898,4 +905,5 @@ i830InitVtbl(struct i830_context *i830)
i830-intel.vtbl.finish_batch = intel_finish_vb;
i830-intel.vtbl.invalidate_state = i830_invalidate_state;
i830-intel.vtbl.render_target_supported =
i830_render_target_supported;
+ i830-intel.vtbl.is_hiz_depth_format = i830_is_hiz_depth_format;
}
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Add missing vtable entry for i830
On 08/06/2011 09:43 AM, Carl Simonson wrote: When the is_hiz_depth_format vtable entry was added for i915/i956, the entry for forgotten in the i830 vtable setup. Signed-off-by: Carl Simonson simons...@gmail.com Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39888] [regression] Artifacts in Cogs
https://bugs.freedesktop.org/show_bug.cgi?id=39888 --- Comment #1 from Bryan Cain bryancain3+...@gmail.com 2011-08-06 18:14:39 PDT --- If it is a result of the glsl-to-tgsi merge, then you're in luck, since I just bought the Humble Indie Bundle yesterday. I haven't tried Cogs yet, but I will now to see if I can reproduce your issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
On Sat, Aug 6, 2011 at 5:07 AM, Chad Versace c...@chad-versace.us wrote: On 08/05/2011 05:41 AM, Dan Nicholson wrote: On Thu, Aug 4, 2011 at 7:55 PM, Chad Versace c...@chad-versace.us wrote: On 08/04/2011 04:17 PM, Jose Fonseca wrote: - Original Message - On Thu, Aug 4, 2011 at 2:47 AM, Chad Versace c...@chad-versace.us wrote: This is the first step in porting libGLES* and libEGL to Android. The makefile doesn't build anything yet; it just defines common variables. The values for MESA_COMMON_C_FLAGS and MESA_COMMON_CPP_FLAGS, I obtained by invoking autogen.sh with the options below and then inspecting MESA_TOP/configs/autoconf. My immediate goal is to port i965 to Android, so I used the typical flags for building i965. --disable-gallium --disable-glu --disable-glw --disable-glut --enable-32-bit --enable-egl --enable-gles2 --enable-gles1 --enable-texture-float --with-dri-drivers=i965 --with-gallium-drivers= Note: This is in preparation for porting i965 to Android. CC: Chia-I Wu o...@lunarg.com, CC: Chih-Wei Huang cwhu...@android-x86.org Signed-off-by: Chad Versace c...@chad-versace.us --- Android.mk | 66 android/mesa_local_vars.mk | 32 + 2 files changed, 98 insertions(+), 0 deletions(-) create mode 100644 Android.mk create mode 100644 android/mesa_local_vars.mk There's quite a bit of new build infrastructure here. What would it take to fit this into either the existing autoconf support or add a targeted configs/android? Duplicating a pile of make targets and adding another way to configure/build mesa seems like it might not be the best way to go. What are the current constraints that make building mesa on android difficult? I agree. I'd prefer not have yet another build infrastructure in the mix, unless there's a very good reason. Jose I also agree. I would prefer to not add another build system to Mesa. We have too many as it is. To address Dan's questions, the Android build cannot be fitted into autoconf or configs/android. I explored this option, and discovered that it was impossible. The Android build system is... well... interesting. Allow me to explain. The entirety of the Android project --- libc, webkit, the window manager, *everything* --- exists in a single source tree [1]. And that source tree is built with a single, non-recursive invocation of make. Every time I say that, I find it hard to believe myself, so I'll say it again: The entirety of the Android OS, all core libraries and apps, are built with a single, non-recursive invocation of make. (The kernel is the special exception to this all-encompassing build). The final build artifact is a bootable iso image. [1] http://android.git.kernel.org/ Looking at all those git repos, wouldn't this be more appropriate as an android project? platform/external/mesa or something? Mesa already belongs to the Android x86 tree [1] as platform/external/mesa. (The Android x86 project is a fork that closely mirrors upstream Android). It also exists as such in some private trees. [1] http://git.android-x86.org/ I haven't seen any Android.mk files show up in freetype or expat or anything like that. In the same way, mesa doesn't carry a debian folder even though that's how debian and ubuntu build mesa. Certainly if there are fixes to the existing build infrastructure that help get mesa built on android, that should be done, but I don't see why we should carry the android build bits in upstream mesa. -- Dan Dan, you make a strong point. There's no sense in cluttering Mesa with additional makefiles, at least not now. Other projects do not do that for Android, and Mesa doesn't even do it for beloved Debian. The best approach would be to maintain the Android makefiles in a separate branch, perhaps even in a personal repo. I do not have a strong motivation to upstream Android support because - it requires changes to Android framework - it introduces yet another build system to Mesa I said this a few months back on mesa-user or -dev when asked. But generally, I think the not cluttering Mesa with another build system is debatable. I know I conflict with myself here, but if someone ports Mesa to arguably the most widely used OS and would like to upstream it, should we shut it down because the OS _requires_ its own build system? Incidentally, gstreamer has Android.mk upstream. To fix the existing build infrastructure to support Android, I would like to extract source lists for some targets into a shared makefile, similiar to what has been done with src/mesa/sources.mak. Jose suggested this, and I think this is the best way to continue. Yes, that surely will make the out-of-tree port be more future proof. I think we can make SCons parses the source list too. (Jose, I would rather not take the approach of making one target
Re: [Mesa-dev] [PATCH] glsl: empty declarations should be valid
On Sat, Aug 6, 2011 at 5:35 AM, Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/05/2011 12:41 AM, Chia-I Wu wrote:
On Fri, Aug 5, 2011 at 1:48 PM, Chad Versace c...@chad-versace.us wrote:
On 08/04/2011 06:18 PM, Chad Versace wrote:
On 08/04/2011 01:29 PM, Eric Anholt wrote:
On Thu, 4 Aug 2011 12:59:35 +0900, Chia-I Wu olva...@gmail.com wrote:
From: Chia-I Wu o...@lunarg.com
Unlike C++, empty declarations such as
float;
should be valid. The spec is not explicit about this actually.
Some apps that generate their shader sources may rely on this. This was
noted when porting one of them to Linux from Windows.
Ew. Looking the GLSL 1.20 spec, I see:
statement:
declaration_statement
declaration_statement:
declaration
declaration:
init_declarator_list SEMICOLON
init_declarator_list:
single_declaration
single_declaration:
fully_specified_type
fully_specified_type IDENTIFIER
so it looks like that is actually valid code. That's awful.
I first suspected that this was a spec grammar bug. But it is still
present in
the GLSL 4.10 spec, so it's unlikely to be a bug.
Surprisingly, C also allows empty declarations. Compiling this
float;
int main() { return 0; }
with `gcc --std=c99` succeeds and emits this warning:
warning: useless type name in empty declaration [enabled by default]
I hate to say this, but I believe the spec grammar intentionally allows
empty
declarations. C allows it, and GLSL tries to mimic C.
Even though I don't like empty declarations, this patch is
Reviewed-by: Chad Versace c...@chad-versace.us
Also, please update the commit message to say that `gcc --std=c99` allows
empty
declrations and include the appropriate quotation from the GLSL 1.20 spec's
grammar. Without that extra info, someone may stumble onto this commit and
say WTF.
Oops. I've already committed it...
You have to give a little more time for review. I would like to have
had an opportunity to weigh in, but it's a bit late now.
Yes, I should have given it more time... Sorry about that.
Maybe we can test how the other proprietary drivers work with regard
to this and decide whether to revert it or not? I was told that it is
what the other drivers do on Windows, but I could not verify.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk48VBQACgkQX1gOwKyEAw9ZFACdHy2gnNLdszGp5PbDu84Luay1
tpoAoIcgM2pemUdDINNiAvxc/wWw3J8T
=X0eZ
-END PGP SIGNATURE-
--
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] upstreaming Android support [Was: i965, mesa, glapi: Build libi965_dri on Android]
On Sat, Aug 6, 2011 at 6:01 AM, Chad Versace c...@chad-versace.us wrote: On 08/05/2011 12:24 AM, Chia-I Wu wrote: On Fri, Aug 5, 2011 at 3:42 PM, Chia-I Wu olva...@gmail.com wrote: We will be basically doing everything from scratch, in smaller steps. In that case, I see no reason not to do this based on what is already there. I did plan to upstream my changes. So cleaning it up should not be a nightmare. I've pushed a branch here for discussion http://cgit.freedesktop.org/~olv/mesa/log/?h=android-gingerbread-upstream-wip This is still WIP. It still needs to be cleaned up. The goal of the branch is to provide * a clean tree to be merged to master * integration with Android(-x86) Gingerbread * gallium drivers that work well * i915/i965 drivers that work with simple tests The main focus is the integration with Android. Missing features in i915/i965 should be added later. The commits in this branch can be divided into four groups 1) Fix portability issues (the first 5 commits) Android has its own C library called bionic. There are a few places where it is incompatible with GNU C. These five commits adds compile-time tests to define the compatibility layer for Android. 2) Add support for Android to st/egl (the next 3 commits) These should only be interesting to EGL developers. These commits add _EGL_PLATFORM_ANDROID and Android-specific extensions to EGL core. Support for the new platform and extensions is then added to st/egl. 3) Integration with Android build system (the next 2 commits) This first commit here should be killed. Ignore it for now. The second commit[1] adds a bunch of Android.mk's to the source tree. Android.mk's are read by the Android build system to build Mesa. No changes are made to the existing files. IMHO, this is the better way to upstream Andoird support. We know that things work at this point. We know that nothing can break due to this commit. We can then refactor Makefile's, one by one as follow-up commits, until we are satisfied with the results. 4) Add support for Android to egl_dri2/i915/i965 (the last 3 commits) These commits add Android support to egl_dri2. Build rules for i915 and i965 are also added. The most interesting changes should be 3). I prefer the approach I described in it, but I am also fine with interleaving refactoring Makefile's with adding Android.mk's. That could take a while as we need to have a consensus on how to refactor Makefile's systematically. Thoughts? [1] direct link http://cgit.freedesktop.org/~olv/mesa/commit/?h=android-gingerbread-upstream-wipid=90f8f6dc2fa3e121a9e5921fac106d2b058e08cc The branch looks like a good candidate for merging. I gave it a quick review. [have comment] mesa: fix !FEATURE_GL build [looks good to me] glsl: remove an unnecessary header include [no comment] gallium: add PIPE_OS_ANDROID support [looks good to me] ralloc: SIZE_MAX is missing on Android [have comment] mesa: fix compile issues on Android [have comment] egl: add _EGL_PLATFORM_ANDROID [looks good to me] egl: add Android-specific extensions [needs discussion] android: add Android.mk's [needs discussion] egl_dri2: allow a platform to specify RGBA masks [have comments] egl_dri2: add support for Android I have comments on some patches, and both of the egl_dri2 patches need to be reviewed by the other EGL devs. Could you post the patch series for review? That way, it will be easier for everyone to post comments inline. I'd love to have them reviewed (and thanks for taking a look) even if they are out of tree. But if we decide not to put Android.mk's upstream, which is likely, which of the rest commits do you think should be upstreamed? It seems to me that only the first two commits make sense. Since we (you, me, Jose, and Dan) have not yet decided how to handle the build system issue, when you email the patches please strip the makefiles out. Thanks. -- Chad Versace c...@chad-versace.us -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39891] New: D3D1X can't be compiled: cannot convert ‘pipe_resource*’ to ‘const pipe_resolve_info*’ in argument passing
https://bugs.freedesktop.org/show_bug.cgi?id=39891 Summary: D3D1X can't be compiled: cannot convert ‘pipe_resource*’ to ‘const pipe_resolve_info*’ in argument passing Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: critical Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: alexandre.f.dem...@gmail.com When compiling with d3d1x, I receive the following error: In file included from d3d11.cpp:220:0: d3d11_context.h: In member function ‘HRESULT GalliumD3D11DeviceContextPtrTraits::Map(ID3D11Resource*, unsigned int, D3D11_MAP, unsigned int, D3D11_MAPPED_SUBRESOURCE*) [with PtrTraits = nonatomic_device_child_ptr_traits, HRESULT = int, ID3D11Resource = ID3D11Resource, D3D11_MAP = D3D11_MAP, D3D11_MAPPED_SUBRESOURCE = D3D11_MAPPED_SUBRESOURCE]’: d3d11.cpp:231:1: instantiated from here d3d11_context.h:1461:12: warning: unused variable ‘face’ d3d11_context.h: In member function ‘void GalliumD3D11DeviceContextPtrTraits::CopySubresourceRegion(ID3D11Resource*, unsigned int, unsigned int, unsigned int, unsigned int, ID3D11Resource*, unsigned int, const D3D11_BOX*) [with PtrTraits = nonatomic_device_child_ptr_traits, ID3D11Resource = ID3D11Resource, D3D11_BOX = D3D11_BOX]’: d3d11.cpp:231:1: instantiated from here d3d11_context.h:1522:12: warning: unused variable ‘dst_face’ d3d11_context.h:1524:12: warning: unused variable ‘src_face’ d3d11_context.h: In member function ‘void GalliumD3D11DeviceContextPtrTraits::ResolveSubresource(ID3D11Resource*, unsigned int, ID3D11Resource*, unsigned int, DXGI_FORMAT) [with PtrTraits = nonatomic_device_child_ptr_traits, ID3D11Resource = ID3D11Resource, DXGI_FORMAT = DXGI_FORMAT]’: d3d11.cpp:231:1: instantiated from here d3d11_context.h:1731:3: error: cannot convert ‘pipe_resource*’ to ‘const pipe_resolve_info*’ in argument passing make[5]: *** [d3d11.o] Error 1 If needed, I could bisect. It popped out about 2 days ago and I'm compiling mostly daily. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
