1. 24 Oct, 2011 2 commits
  2. 03 Oct, 2011 1 commit
  3. 31 Jul, 2011 1 commit
  4. 20 Jul, 2011 5 commits
    • Paul Berry's avatar
      glsl: Rewrote _mesa_glsl_process_extension to use table-driven logic. · 7b8e7f44
      Paul Berry authored
      Instead of using a chain of manually maintained if/else blocks to
      handle "#extension" directives, we now consult a table that specifies,
      for each extension, the circumstances under which it is available, and
      what flags in _mesa_glsl_parse_state need to be set in order to
      activate it.
      
      This makes it easier to add new GLSL extensions in the future, and
      fixes the following bugs:
      
      - Previously, _mesa_glsl_process_extension would sometimes set the
        "_enable" and "_warn" flags for an extension before checking whether
        the extension was supported by the driver; as a result, specifying
        "enable" behavior for an unsupported extension would sometimes cause
        front-end support for that extension to be switched on in spite of
        the fact that back-end support was not available, leading to strange
        failures, such as those in
        https://bugs.freedesktop.org/show_bug.cgi?id=38015
      
      .
      
      - "#extension all: warn" and "#extension all: disable" had no effect.
      
      Notes:
      
      - All extensions are currently marked as unavailable in geometry
        shaders.  This should not have any adverse effects since geometry
        shaders aren't supported yet.  When we return to working on geometry
        shader support, we'll need to update the table for those extensions
        that are available in geometry shaders.
      
      - Previous to this commit, if a shader mentioned
        ARB_shader_texture_lod, extension ARB_texture_rectangle would be
        automatically turned on in order to ensure that the types
        sampler2DRect and sampler2DRectShadow would be defined.  This was
        unnecessary, because (a) ARB_shader_texture_lod works perfectly well
        without those types provided that the builtin functions that
        reference them are not called, and (b) ARB_texture_rectangle is
        enabled by default in non-ES contexts anyway.  I eliminated this
        unnecessary behavior in order to make the behavior of all extensions
        consistent.
      
      Some changes were made in glsl_parser_extras.h during cherry pick to
      7.10 because 7.11 and master support many extensions that 7.10 does
      not.  The unsupported extensions were removed.
      
      NOTE: This is a candidate for the 7.10 and 7.11 branches.
      Reviewed-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      Signed-off-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      7b8e7f44
    • Paul Berry's avatar
      glsl: Changed extension enable bits to bools. · db3d21d6
      Paul Berry authored
      
      
      These were previously 1-bit-wide bitfields.  Changing them to bools
      has a negligible performance impact, and allows them to be accessed by
      offset as well as by direct structure access.
      
      Some changes were made in glsl_parser_extras.h during cherry pick to
      7.10 because 7.11 and master support many extensions that 7.10 does
      not.  The unsupported extensions were removed.
      
      NOTE: This is a candidate for the 7.10 and 7.11 branches.
      Reviewed-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      Signed-off-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      (cherry picked from commit 9c4445de)
      db3d21d6
    • Paul Berry's avatar
      glsl: Ensure that sampler declarations are always uniform or "in" parameters. · 0a838d1d
      Paul Berry authored
      This brings us into compliance with page 17 (page 22 of the PDF) of
      the GLSL 1.20 spec:
      
          "[Sampler types] can only be declared as function parameters or
          uniform variables (see Section 4.3.5 "Uniform"). ... [Samplers]
          cannot be used as out or inout function parameters."
      
      The spec isn't explicit about whether this rule applies to
      structs/arrays containing shaders, but the intent seems to be to
      ensure that it can always be determined at compile time which sampler
      is being used in each texture lookup.  So to avoid creating a
      loophole, the rule needs to apply to structs/arrays containing shaders
      as well.
      
      Fixes piglit tests spec/glsl-1.10/compiler/samplers/*.frag, and fixes
      bug 38987.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38987
      
      Reviewed-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      (cherry picked from commit f0722105)
      0a838d1d
    • Paul Berry's avatar
      glsl: Move type_contains_sampler() into glsl_type for later reuse. · 94a1fe1f
      Paul Berry authored
      The new location, as a member function of glsl_type, is more
      consistent with queries like is_sampler(), is_boolean(), is_float(),
      etc.  Placing the function inside glsl_type also makes it available to
      any code that uses glsl_types.
      (cherry picked from commit ddc1c963)
      94a1fe1f
    • Ian Romanick's avatar
      linker: Only over-ride built-ins when a prototype has been seen · f2ef6036
      Ian Romanick authored
      The GLSL spec says:
      
          "If a built-in function is redeclared in a shader (i.e., a
          prototype is visible) before a call to it, then the linker will
          only attempt to resolve that call within the set of shaders that
          are linked with it."
      
      This patch enforces this behavior.  When a function call is processed
      a flag is set in the ir_call to indicate whether the previously seen
      prototype is the built-in or not.  At link time a call will only bind
      to an instance of a function that matches the "want built-in" setting
      in the ir_call.
      
      This has the odd side effect that first call to abs() in the shader
      below will call the built-in and the second will not:
      
      float foo(float x) { return abs(x); }
      float abs(float x) { return -x; }
      float bar(float x) { return abs(x); }
      
      This seems insane, but it matches what the spec says.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31744
      (cherry picked from commit 66f4ac98)
      f2ef6036
  5. 19 Jul, 2011 1 commit
  6. 11 Jul, 2011 2 commits
  7. 08 Jul, 2011 1 commit
  8. 07 Jul, 2011 5 commits
  9. 27 Jun, 2011 2 commits
  10. 26 Jun, 2011 1 commit
  11. 25 Jun, 2011 1 commit
  12. 24 Jun, 2011 2 commits
  13. 23 Jun, 2011 1 commit
  14. 22 Jun, 2011 1 commit
  15. 18 Jun, 2011 1 commit
    • Marek Olšák's avatar
      r300g: fix handling PREP_* options · 1ad06c7a
      Marek Olšák authored
      This should fix rendering >65532 vertices using draw_arrays on r300-r400.
      
      NOTE: This is a candidate for the 7.10 branch.
      (cherry picked from commit 7df7eaf8)
      
      Conflicts:
      
      	src/gallium/drivers/r300/r300_render.c
      1ad06c7a
  16. 14 Jun, 2011 4 commits
  17. 13 Jun, 2011 6 commits
  18. 12 Jun, 2011 3 commits
    • Jose Fonseca's avatar
      wgl: Don't hold on to user supplied HDC. · fc23cc06
      Jose Fonseca authored
      Certain applications (e.g., Bernina My Label, and the Windows
      implementation of Processing language) destroy the device context used when
      creating the frame-buffer, causing presents to fail because we were still
      referring to the old device context internally.
      
      This change ensures we always use the same HDC passed to the ICD
      entry-points when available, or our own HDC when not available (necessary
      only when flushing on single buffered visuals).
      fc23cc06
    • Jose Fonseca's avatar
      st/wgl: Remove buggy assertion. · 195e1555
      Jose Fonseca authored
      The assertion is wrong, now that state tracker can cope with a window with
      zero width or height.
      195e1555
    • Jose Fonseca's avatar
      st/wgl: Allow to create pbuffers bigger than the desktop. · 22bf0ec9
      Jose Fonseca authored
      We use a hidden window for pbuffer contexts, but Windows limits window
      sizes to the desktop size by default. This means that creating a big
      pbuffer on a small resolution single monitor would truncate the pbuffer
      size to the desktop.
      
      This change overrides the windows maximum size, allow to create windows
      arbitrarily large.
      22bf0ec9