Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
On Mon, Feb 4, 2019 at 6:43 PM Ilia Mirkin wrote: > On Mon, Feb 4, 2019 at 7:38 PM Jason Ekstrand > wrote: > > > > On Mon, Feb 4, 2019 at 6:25 PM Alyssa Rosenzweig > wrote: > >> > >> > Actually, I just gave you (Alyssa) push access... Also, as you'll (as > >> > far as I understand) basically be owning the panfrost bits in mesa, > >> > you should be able to commit to them. > >> > >> Oh, thank you! :) > >> > >> > 1. Don't break the build > >> > >> Acked-by: Alyssa Rosenzweig > >> > >> > 2. No merge commits > >> > >> Just to be clear, is the idea to just make sure everything applies > >> cleanly / is a straightforward fast-forward, and if not, to > rebase/squash > >> so it does? > > > > > > Roughtly? I really did mean "no merge commits" which really just means > linear history. Ideally, you'd have something that roughly linearly works > but that's a Panfrost quality thing. I'm sure there will be regressions all > over the place as you work given that it's still a bit prototypey. > > An important point here is "bisectable". You shouldn't have commits > like "fix this totally broken earlier commit in the series". Breakage > can happen -- that's a fact of life -- but you should avoid having > "known" breaking commits, since that will mess up bisects down the > line. > Right. I just didn't want to sound too draconian because I know what the crazy prototype world looks like. That said, the more linearly working and bisectable the better. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
Thanks :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
On Mon, Feb 4, 2019 at 7:38 PM Jason Ekstrand wrote: > > On Mon, Feb 4, 2019 at 6:25 PM Alyssa Rosenzweig wrote: >> >> > Actually, I just gave you (Alyssa) push access... Also, as you'll (as >> > far as I understand) basically be owning the panfrost bits in mesa, >> > you should be able to commit to them. >> >> Oh, thank you! :) >> >> > 1. Don't break the build >> >> Acked-by: Alyssa Rosenzweig >> >> > 2. No merge commits >> >> Just to be clear, is the idea to just make sure everything applies >> cleanly / is a straightforward fast-forward, and if not, to rebase/squash >> so it does? > > > Roughtly? I really did mean "no merge commits" which really just means > linear history. Ideally, you'd have something that roughly linearly works > but that's a Panfrost quality thing. I'm sure there will be regressions all > over the place as you work given that it's still a bit prototypey. An important point here is "bisectable". You shouldn't have commits like "fix this totally broken earlier commit in the series". Breakage can happen -- that's a fact of life -- but you should avoid having "known" breaking commits, since that will mess up bisects down the line. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
On Mon, Feb 4, 2019 at 6:25 PM Alyssa Rosenzweig wrote: > > Actually, I just gave you (Alyssa) push access... Also, as you'll (as > > far as I understand) basically be owning the panfrost bits in mesa, > > you should be able to commit to them. > > Oh, thank you! :) > > > 1. Don't break the build > > Acked-by: Alyssa Rosenzweig > > > 2. No merge commits > > Just to be clear, is the idea to just make sure everything applies > cleanly / is a straightforward fast-forward, and if not, to rebase/squash > so it does? > Roughtly? I really did mean "no merge commits" which really just means linear history. Ideally, you'd have something that roughly linearly works but that's a Panfrost quality thing. I'm sure there will be regressions all over the place as you work given that it's still a bit prototypey. > > 4. Don't commit code outside of Panfrost without review from someone who > > has a decent claim to knowing what they're talking about in that area > > Acked-by: Alyssa Rosenzweig > > > 5. Be nice and give stake-holders (who may not be in your time zone) > > enough time to read their e-mail and review (at least 24 hours not > > including week-ends) before pushing anything. > > Acked-by: Alyssa Rosenzweig > > > Inside Panfrost, it's kind-of up to the Panfrost community developers > what > > you want to do about review. If you've got enough people, I highly > > recommend you do good code review. > > Downstream, we've been trying to enforce proper reivew. I review other > people's code; I haggle people to review mine; you know how it is :) > > Thank you again! > > Alyssa > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
> Actually, I just gave you (Alyssa) push access... Also, as you'll (as > far as I understand) basically be owning the panfrost bits in mesa, > you should be able to commit to them. Oh, thank you! :) > 1. Don't break the build Acked-by: Alyssa Rosenzweig > 2. No merge commits Just to be clear, is the idea to just make sure everything applies cleanly / is a straightforward fast-forward, and if not, to rebase/squash so it does? > 4. Don't commit code outside of Panfrost without review from someone who > has a decent claim to knowing what they're talking about in that area Acked-by: Alyssa Rosenzweig > 5. Be nice and give stake-holders (who may not be in your time zone) > enough time to read their e-mail and review (at least 24 hours not > including week-ends) before pushing anything. Acked-by: Alyssa Rosenzweig > Inside Panfrost, it's kind-of up to the Panfrost community developers what > you want to do about review. If you've got enough people, I highly > recommend you do good code review. Downstream, we've been trying to enforce proper reivew. I review other people's code; I haggle people to review mine; you know how it is :) Thank you again! Alyssa ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
On Mon, Feb 4, 2019 at 3:13 PM Rob Herring wrote: > On Sun, Feb 3, 2019 at 9:33 PM Alyssa Rosenzweig > wrote: > > > > > You should just land it and start doing in-tree development! > > > > I don't have push access, you know :P > > I can push it if you don't want to go the MR route. That goes for > subsequent changes too. > Actually, I just gave you (Alyssa) push access. You haven't hit the usual 2-dozen commit threshold in mesa main yet but that's because you've been working (very actively!) out-of-tree. I figure you'll hit that threshold very quickly once you start working in-tree. Also, as you'll (as far as I understand) basically be owning the panfrost bits in mesa, you should be able to commit to them. Please drink responsibly, don't run with scissors (unless they're the GL kind), and remember a few basic merging rules: 1. Don't break the build 2. No merge commits 3. Write good commit messages with reasonable prefixes (such as "panfrost: Implement clip planes for vertex shaders") 4. Don't commit code outside of Panfrost without review from someone who has a decent claim to knowing what they're talking about in that area 5. Be nice and give stake-holders (who may not be in your time zone) enough time to read their e-mail and review (at least 24 hours not including week-ends) before pushing anything. Inside Panfrost, it's kind-of up to the Panfrost community developers what you want to do about review. If you've got enough people, I highly recommend you do good code review. If it's really just you hacking on the compiler, then maybe review isn't practical. Happy hacking and welcome to the mesa tree! --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
On Sun, Feb 3, 2019 at 9:33 PM Alyssa Rosenzweig wrote: > > > You should just land it and start doing in-tree development! > > I don't have push access, you know :P I can push it if you don't want to go the MR route. That goes for subsequent changes too. Rob ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
On February 3, 2019 21:33:39 Alyssa Rosenzweig wrote: You should just land it and start doing in-tree development! I don't have push access, you know :P Make a MR with all the acks on it and I'll click the button. I say MR because the full patch would be huge. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
> You should just land it and start doing in-tree development! I don't have push access, you know :P ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
On Sun, Feb 3, 2019 at 6:18 PM Alyssa Rosenzweig wrote: > > Small comment, you should plan on single build for all supported > > generations.. I'm not entirely sure if this same header is eventually > > planned to be #include'd from different C code w/ different defines > > for gpu gen (afaict you just currently hard-code it at the top of this > > header).. But distro's will be unhappy if it comes to different mesa > > builds for 8xx vs 6xx ;-) > > Yeah, that's a moderately high-prio item, only blocking on other things > being more interesting ;) > > > Also, I guess for your sanity at some point you'll want to autogen > > cmdstream encoding and decoding from a single source. I get the > > impression that envytools isn't the right thing for the bitpacked > > format for mali cmdstream. Maybe the intel thing is better? But I > > didn't get very far w/ a2xx r/e before I realized that keeping hand > > coded decoding and encoding in sync sucked. > > Sure, but.. autogen from.. what? As you note, Mali's "cmdstream" is > wacky and doesn't line up with the model assumed by most of these tools. > > Also, if I have to read/write XML, I might lose my sanity faster ;P > > > Anyways, totally fine w/ those details getting worked out in-tree, > > after merging. > > > > Acked-by: Rob Clark > > Thank you! > > (Is there any particular ack we're waiting for for pushing?) > I don't think so. You've gotten enough buy-in from the community so far that, if your build system and core (if any) changes aren't going to break anything, you should just land it and start doing in-tree development! Right after the 19.0 branch point (which was Wednesday) is a great time to do it too because any small breakages won't cause any release problems. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
> Small comment, you should plan on single build for all supported > generations.. I'm not entirely sure if this same header is eventually > planned to be #include'd from different C code w/ different defines > for gpu gen (afaict you just currently hard-code it at the top of this > header).. But distro's will be unhappy if it comes to different mesa > builds for 8xx vs 6xx ;-) Yeah, that's a moderately high-prio item, only blocking on other things being more interesting ;) > Also, I guess for your sanity at some point you'll want to autogen > cmdstream encoding and decoding from a single source. I get the > impression that envytools isn't the right thing for the bitpacked > format for mali cmdstream. Maybe the intel thing is better? But I > didn't get very far w/ a2xx r/e before I realized that keeping hand > coded decoding and encoding in sync sucked. Sure, but.. autogen from.. what? As you note, Mali's "cmdstream" is wacky and doesn't line up with the model assumed by most of these tools. Also, if I have to read/write XML, I might lose my sanity faster ;P > Anyways, totally fine w/ those details getting worked out in-tree, > after merging. > > Acked-by: Rob Clark Thank you! (Is there any particular ack we're waiting for for pushing?) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
> Doing merge commits for new drivers is not unheard of and preserves > history (if the history is something you want to preserve). The history downstream is a total mess (read: probably not bisectable), and a lot of it was committed sloppily knowing it would get squished. So thank you for offering, but I don't think anything of value is being lost with these mega-patches :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
On Wed, Jan 30, 2019 at 12:43 AM Alyssa Rosenzweig wrote: > > This patch adds an initial stub for the Gallium driver, containing > simple screen functions and the majority of the driver headers but no > actual functionality. It further adds the winsys glue for linking in > this stub driver via kmsro on Rockchip/Amlogic boards. > > Signed-off-by: Alyssa Rosenzweig > --- > meson.build |7 +- > meson_options.txt |2 +- > .../auxiliary/pipe-loader/pipe_loader_drm.c |5 + > .../auxiliary/target-helpers/drm_helper.h | 23 + > .../target-helpers/drm_helper_public.h|3 + > src/gallium/drivers/panfrost/.editorconfig|3 + > .../drivers/panfrost/include/meson.build |0 > .../drivers/panfrost/include/panfrost-job.h | 1481 + > .../drivers/panfrost/include/panfrost-misc.h | 47 + > src/gallium/drivers/panfrost/meson.build | 52 + > src/gallium/drivers/panfrost/pan_allocate.h | 123 ++ > src/gallium/drivers/panfrost/pan_context.h| 362 > src/gallium/drivers/panfrost/pan_public.h | 41 + > src/gallium/drivers/panfrost/pan_resource.h | 85 + > src/gallium/drivers/panfrost/pan_screen.c | 702 > src/gallium/drivers/panfrost/pan_screen.h | 88 + > src/gallium/meson.build |6 + > src/gallium/targets/dri/meson.build |5 +- > src/gallium/targets/dri/target.c | 10 + > .../winsys/kmsro/drm/kmsro_drm_winsys.c | 25 + > src/gallium/winsys/kmsro/drm/meson.build |3 + > src/gallium/winsys/panfrost/drm/Android.mk| 33 + > src/gallium/winsys/panfrost/drm/Makefile.am | 33 + > .../winsys/panfrost/drm/Makefile.sources |3 + > src/gallium/winsys/panfrost/drm/meson.build | 29 + > .../winsys/panfrost/drm/panfrost_drm_public.h | 36 + > .../winsys/panfrost/drm/panfrost_drm_winsys.c | 42 + > 27 files changed, 3244 insertions(+), 5 deletions(-) > create mode 100644 src/gallium/drivers/panfrost/.editorconfig > create mode 100644 src/gallium/drivers/panfrost/include/meson.build > create mode 100644 src/gallium/drivers/panfrost/include/panfrost-job.h > create mode 100644 src/gallium/drivers/panfrost/include/panfrost-misc.h > create mode 100644 src/gallium/drivers/panfrost/meson.build > create mode 100644 src/gallium/drivers/panfrost/pan_allocate.h > create mode 100644 src/gallium/drivers/panfrost/pan_context.h > create mode 100644 src/gallium/drivers/panfrost/pan_public.h > create mode 100644 src/gallium/drivers/panfrost/pan_resource.h > create mode 100644 src/gallium/drivers/panfrost/pan_screen.c > create mode 100644 src/gallium/drivers/panfrost/pan_screen.h > create mode 100644 src/gallium/winsys/panfrost/drm/Android.mk > create mode 100644 src/gallium/winsys/panfrost/drm/Makefile.am > create mode 100644 src/gallium/winsys/panfrost/drm/Makefile.sources > create mode 100644 src/gallium/winsys/panfrost/drm/meson.build > create mode 100644 src/gallium/winsys/panfrost/drm/panfrost_drm_public.h > create mode 100644 src/gallium/winsys/panfrost/drm/panfrost_drm_winsys.c > [snip] > diff --git a/src/gallium/drivers/panfrost/include/panfrost-job.h > b/src/gallium/drivers/panfrost/include/panfrost-job.h > new file mode 100644 > index 00..dbb5486bfa > --- /dev/null > +++ b/src/gallium/drivers/panfrost/include/panfrost-job.h > @@ -0,0 +1,1481 @@ > +/* > + * © Copyright 2017-2018 Alyssa Rosenzweig > + * © Copyright 2017-2018 Connor Abbott > + * © Copyright 2017-2018 Lyude Paul > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice (including the next > + * paragraph) shall be included in all copies or substantial portions of the > + * Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > FROM, > + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN > THE > + * SOFTWARE. > + * > + */ > + > +#ifndef __PANFROST_JOB_H__ > +#define __PANFROST_JOB_H__ > + > +#include > +#include > + > +#define T8XX > + > +#define MALI_SHORT_PTR_BITS (sizeof(uintptr_t)*8) > + > +#define MALI_FBD_HIERARCHY_WEIGHTS
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
On Thu, Jan 31, 2019 at 10:36 AM Eric Anholt wrote: > Alyssa Rosenzweig writes: > > >> There's u_pipe_screen_get_param_defaults() that you really want to be > >> using to avoid regressions when people add new pipe caps. You can get > >> rid of a lot of your switch statement that way, too. > > > > Oh, good to know. Is that newer? I'm pretty sure that whole block was > > copied from vc4 at some point ;) > > > >> We should probably be sticking the kmsro entrypoints in a shared group, > >> since there's nothing specific for the KMS . Looks like we haven't been > >> doing that, though. > > > > Yeah, I had the same thought, but I didn't want to disrupt other drivers > > yet (since that delays merge due to pinging more people). > > > >> These are both things we can change later. I'm mostly excited to see > >> you finally in-tree! > Hear, Hear! Whatever merge/patch you do is Acked-by: Jason Ekstrand It's about time! > > ^_^ > > > > Should either of the above issues be resolved in a v2 now, or just a > > follow-up patch after merging? > > Follow-up, imo. New drivers have a long awkward period where they > wouldn't pass review the way we would for incremental development, but > continuing to work out-of-tree means rebase pain and losing git history. > > (If you have git history out of tree that you'd like to retain when > merging in, I'm happy to try helping with that. I've done fun git > surgery before) > Doing merge commits for new drivers is not unheard of and preserves history (if the history is something you want to preserve). --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
Alyssa Rosenzweig writes: >> There's u_pipe_screen_get_param_defaults() that you really want to be >> using to avoid regressions when people add new pipe caps. You can get >> rid of a lot of your switch statement that way, too. > > Oh, good to know. Is that newer? I'm pretty sure that whole block was > copied from vc4 at some point ;) > >> We should probably be sticking the kmsro entrypoints in a shared group, >> since there's nothing specific for the KMS . Looks like we haven't been >> doing that, though. > > Yeah, I had the same thought, but I didn't want to disrupt other drivers > yet (since that delays merge due to pinging more people). > >> These are both things we can change later. I'm mostly excited to see >> you finally in-tree! > > ^_^ > > Should either of the above issues be resolved in a v2 now, or just a > follow-up patch after merging? Follow-up, imo. New drivers have a long awkward period where they wouldn't pass review the way we would for incremental development, but continuing to work out-of-tree means rebase pain and losing git history. (If you have git history out of tree that you'd like to retain when merging in, I'm happy to try helping with that. I've done fun git surgery before) signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
> There's u_pipe_screen_get_param_defaults() that you really want to be > using to avoid regressions when people add new pipe caps. You can get > rid of a lot of your switch statement that way, too. Oh, good to know. Is that newer? I'm pretty sure that whole block was copied from vc4 at some point ;) > We should probably be sticking the kmsro entrypoints in a shared group, > since there's nothing specific for the KMS . Looks like we haven't been > doing that, though. Yeah, I had the same thought, but I didn't want to disrupt other drivers yet (since that delays merge due to pinging more people). > These are both things we can change later. I'm mostly excited to see > you finally in-tree! ^_^ Should either of the above issues be resolved in a v2 now, or just a follow-up patch after merging? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver
Alyssa Rosenzweig writes:
> This patch adds an initial stub for the Gallium driver, containing
> simple screen functions and the majority of the driver headers but no
> actual functionality. It further adds the winsys glue for linking in
> this stub driver via kmsro on Rockchip/Amlogic boards.
> +static int
> +panfrost_get_param(struct pipe_screen *screen, enum pipe_cap param)
> +{
> +switch (param) {
> +case PIPE_CAP_NPOT_TEXTURES:
> +case PIPE_CAP_MIXED_FRAMEBUFFER_SIZES:
> +case PIPE_CAP_MIXED_COLOR_DEPTH_BITS:
> +return 1;
> +
> +case PIPE_CAP_SM3:
> +return 1;
> +
> +case PIPE_CAP_POINT_SPRITE:
> +return 1;
> +
> +case PIPE_CAP_MAX_RENDER_TARGETS:
> +return PIPE_MAX_COLOR_BUFS;
> +
> +case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
> +return 1;
> +
> +case PIPE_CAP_OCCLUSION_QUERY:
> +case PIPE_CAP_QUERY_TIME_ELAPSED:
> +case PIPE_CAP_QUERY_PIPELINE_STATISTICS:
> +return 1; /* TODO: Queries */
> +
> +case PIPE_CAP_TEXTURE_MIRROR_CLAMP:
> +return 1;
> +
> +case PIPE_CAP_TEXTURE_SWIZZLE:
> +return 1;
> +
> +case PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK:
> +return 0;
> +
> +case PIPE_CAP_MAX_TEXTURE_2D_LEVELS:
> +case PIPE_CAP_MAX_TEXTURE_3D_LEVELS:
> +case PIPE_CAP_MAX_TEXTURE_CUBE_LEVELS:
> +return 13;
> +
> +case PIPE_CAP_BLEND_EQUATION_SEPARATE:
> +return 1;
> +
> +case PIPE_CAP_INDEP_BLEND_ENABLE:
> +return 1;
> +
> +case PIPE_CAP_INDEP_BLEND_FUNC:
> +return 1;
> +
> +case PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT:
> +case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
> +case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER:
> +case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER:
> +return 1;
> +
> +case PIPE_CAP_DEPTH_CLIP_DISABLE:
> +return 1;
> +
> +case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS:
> +return 0; /* no streamout */
> +
> +case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
> +case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
> +return 16 * 4;
> +
> +case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
> +case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
> +return 1024;
> +
> +case PIPE_CAP_MAX_VERTEX_STREAMS:
> +return 1;
> +
> +case PIPE_CAP_PRIMITIVE_RESTART:
> +return 0; /* We don't understand this yet */
> +
> +case PIPE_CAP_SHADER_STENCIL_EXPORT:
> +return 1;
> +
> +case PIPE_CAP_TGSI_INSTANCEID:
> +case PIPE_CAP_VERTEX_ELEMENT_INSTANCE_DIVISOR:
> +case PIPE_CAP_START_INSTANCE:
> +return 0; /* TODO: Instances */
> +
> +case PIPE_CAP_SEAMLESS_CUBE_MAP:
> +case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
> +return 1;
> +
> +case PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS:
> +return 256; /* for GL3 */
> +
> +case PIPE_CAP_MIN_TEXEL_OFFSET:
> +return -8;
> +
> +case PIPE_CAP_MAX_TEXEL_OFFSET:
> +return 7;
> +
> +case PIPE_CAP_CONDITIONAL_RENDER:
> +return 1;
> +
> +case PIPE_CAP_TEXTURE_BARRIER:
> +return 0;
> +
> +case PIPE_CAP_FRAGMENT_COLOR_CLAMPED:
> +case PIPE_CAP_VERTEX_COLOR_UNCLAMPED: /* draw module */
> +case PIPE_CAP_VERTEX_COLOR_CLAMPED: /* draw module */
> +return 1;
> +
> +case PIPE_CAP_MIXED_COLORBUFFER_FORMATS:
> +return 0;
> +
> +case PIPE_CAP_GLSL_FEATURE_LEVEL:
> +return 330;
> +
> +case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
> +case PIPE_CAP_TGSI_TEX_TXF_LZ:
> +return 0;
> +
> +case PIPE_CAP_COMPUTE:
> +return 0;
> +
> +case PIPE_CAP_USER_VERTEX_BUFFERS: /* XXX XXX */
> +case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
> +return 0;
> +
> +case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
> +case PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS:
> +case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
> +case PIPE_CAP_DOUBLES:
> +case PIPE_CAP_INT64:
> +case PIPE_CAP_INT64_DIVMOD:
> +return 1;
> +
> +case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
> +return 16;
> +
> +case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
> +case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
> +case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
> +case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
> +case PIPE_CAP_TEXTURE_MULTISAMPLE:
> +return
