Recent Posts

Pages: 1 ... 7 8 [9] 10
Well, before you spend big bucks, you can try Google Cardboard

You better don't wear that in public  :P
Google cardboard (without rainbow) is good.:) But smartphone for VR?! lol xD

EDIT: If we use Google cardboard for a long time then the electromagnetic radiation can harm the brain.
English forum / Re: Quad Tessellation
« Last post by JeGX on March 16, 2016, 06:02:34 PM »
I added a new function in the gh_renderer lib to set the number of vertices per patch (GL_PATCH_VERTICES):
Code: [Select]

Every group of 4 vertices of the input mesh is used as patch. All built-in meshes in GeeXLab are triangular meshes, so they won't be rendered properly. You have to build your own meshes using gh_mesh.create_v2() and gh_mesh.alloc_mesh_data(). I added a code sample in the host_api/gl-400-arb-tessellation-shader/ that shows how to build these kind of meshes and how to to quad tess.

Everything will be available in the next (beta) update asap!

Well, before you spend big bucks, you can try Google Cardboard

You better don't wear that in public  :P
3D-Tech News Around The Web / NVIDIA legacy driver 341.95 WHQL
« Last post by Stefan on March 16, 2016, 05:34:18 PM »
This driver adds security updates for driver components of Tesla architecture class GPUs (not to be confused with Tesla product line).

 Driver version = 01/29/2016,
 Branch r340_00-595
3D-Tech News Around The Web / HWiNFO32 & HWiNFO64 v5.22 released
« Last post by Stefan on March 16, 2016, 05:26:06 PM »
Changes in HWiNFO32 & HWiNFO64 v5.22 - Released on:  Mar-16-2016: 
  • Fixed a possible hang in sensors when system is using multiple page files.
  • Added hotkeys to disable/hide sensors.
  • Improved handling of invalid sensor values.
  • Disabled GPU I2C access on Fiji again due to stability issues.
  • Enhanced GPU temperature monitoring on Fiji (VR VDDC, VR VDD, Liquid).
  • Fixed CPU Power measurement on Haswell systems with overclocked BCLK.
  • Added monitoring of GPU VDDC for AMD Fiji.
  • Added monitoring of GPU Current and Power for AMD Hawaii/Bonaire and later generations.
  • Fixed SMBus issues on some Fujitsu machines.
English forum / Re: Quad Tessellation
« Last post by JeGX on March 16, 2016, 04:38:53 PM »
Let me look at the problem...
English forum / Quad Tessellation
« Last post by Bludo on March 15, 2016, 11:43:58 PM »

I was hoping someone might be able to help me with an issue I've run into while trying to modify one of the existing tessellation samples.  I was attempting to use quad tessellation rather than triangles.  After making adjustments to the tessellation eval and control shaders, I was still running into an issue where the resulting geometry was skewed.

My suspicion is that I am unable to modify the GL_PATCH_VERTICES parameter inside of initialization to tell GL the proper number of vertices to use.  So before I put up the shader code (which is basic quad tessellation sample shader code), I thought I'd see if this seems like the source of the problem.  If so, is it possible to set the GL_PATCH_VERTICES parameter inside of GeeXLab, and if it is possible, how would it be done?  Thanks in advance for any help that anyone can provide.
3D-Tech News Around The Web / NVIDIA GP104 (GTX 1080?) would not have HBM2 memory
« Last post by JeGX on March 15, 2016, 04:52:34 PM »
Most importantly though the new flagship would not have HBM2 memory. Card is allegedly equipped with 8GB GDDR5X memory, which basically means HBM2 will have to wait for Pascal GP100. Now does it make sense? Technically yes, because mass production of HBM2 modules is not expected to begin sooner than third quarter. FinFET GPU production is probably doing much better than HBM production, so NVIDIA could have taken a safe route that would protect them from any possible issues with HBM production. So rather than wait for new memory chips, NVIDIA is going to use known technology and focus exclusively on new power efficient 16nm FF node.

Ok but **NOTICE** I don't want Oculus because rainbow may cause eyestrain.
3D-Tech News Around The Web / Vulkan API specifications 1.0.6 released
« Last post by JeGX on March 13, 2016, 03:32:17 PM »
* Bump API patch number and header version number to 6 for this

Github Issues:
  * Define 'invocation group' for compute and graphics shaders. Cleanup
    definition and use of 'workgroup', and add glossary entries (public
    issue 1).
  * Various minor editorial fixes (public issue 33).
  * Clarify locations for block members in the
    <<interfaces-iointerfaces-locations,Location Assignment>>
    section (public issue 45).
  * Editorial fixes for <<commandbuffer-allocation,Command Buffer
    Allocation>> section (public issues 54, 59).
  * Clarify behavior of depth test in the <<fragops-depth,Depth
    Test>> section (public issues 80, 81).
  * Remove discussion of return codes from
    flink:vkGetPhysicalDeviceSparseImageFormatProperties and
    flink:vkGetImageSparseMemoryRequirements, which don't return values
    (public issue 82).
  * Allow flink:vkCmdDrawIndirect and flink:vkCmdDrawIndexedIndirect
    pname:drawCount of 0, as well as 1, when the multiDrawIndirect
    feature is not supported (public issue 88).
  * Remove confusing wording in the <<features-limits,Limits>>
    section describing the slink:VkPhysicalDeviceLimits
    pname:minUniformBufferOffsetAlignment, and
    pname:minStorageBufferOffsetAlignment members as both minimums and
    maximums (public issue 91).
  * Clarified that only the RGB components should be affected in places
    where sRGB is referred to in the spec, such as ASTC formats. Minor
    re-wording to avoid "color space" when actively incorrect, now that
    we refer to the Data Format Spec which actually makes a distinction
    between color space and transfer function (public issue 94).
  * Treat pname:pPropertyCount == 0 consistently in
    flink:vkEnumerateInstanceLayerProperties and
    flink:vkEnumerateDeviceLayerProperties (public issue 99)
  * Cleanup minor editorial issues in chapters 14-17 (public issue 100).
  * Clarify definition of flink:vkEnumerateInstanceExtensionProperties
    and flink:vkEnumerateDeviceExtensionProperties (public issue 101).
  * Define the flink:vkEnumerateInstanceExtensionProperties and
    flink:vkEnumerateDeviceExtensionProperties pname:pLayerName
    parameter to be a pointer to a null-terminated UTF-8 string (public
    issue 101).
  * Rearrange "Missing information" references in mandatory format
    tables (public issue 101).
  * Clarify that the enumerated extensions returned by
    flink:vkEnumerateInstanceExtensionProperties and
    flink:vkEnumerateDeviceExtensionProperties will only include
    extensions provided by the platform or extensions implemented in
    implicitly enabled layers (public issue 101).
  * Miscellaneous editorial fixes. Include the Vulkan spec patch number
    in the PDF title. Fix label on <<fig-non-strict-lines,Non
    strict lines>> diagram. Use more easily distinguished symbols in
    tables in the <<features-required-format-support,Required
    Format Support>> section. Don't require FQDNs used as layer names be
    encoded in lower case if not possible, in the
    <<extensions-naming-conventions, Extension and Layer Naming
    Conventions>> section (public issues 101, 119, 121).

Internal Issues:
  * Fixed excessive spacing in tables in XHTML (internal issue 18).
    applies to secondary command buffers. Previously spec only referred
    to the members of pname:pCommandBuffers being affected by this bit.
    Added a separate slink:VkSubmitInfo Valid Usage restriction
    also applies to any secondary command buffers that are recorded into
    the primary command buffers in pname:pCommandBuffers (internal issue
  * Clarify that slink:VkDeviceCreateInfo::pname:pEnabledFeatures can be
    NULL (internal issue 117).
  * Remove "the value of" where it is redundant (e.g. speaking of an API
    parameter, struct member, or SPIR-V variable, but not when speaking
    of color components) (internal issue 175).
  * Forced patch version to always be 0 in the header. Add a
    "VK_API_VERSION_<major>_<minor>" macro for people to use to do the
    right thing. Add a VK_HEADER_VERSION which captures the header
    release number independent of the spec patch number (internal issue
  * Correct description of
    slink:VkPipelineShaderStageCreateInfo::pname:pName to "a pointer to
    a null-terminated UTF-8 string" (internal issue #197).

Other Commits:
  * Updated DataFormat spec reference to the new date for revision 5 of
    that spec.
  * Fixed KEEP option (to retain LaTeX intermediate files) in the
    Makefile to be included when edited there, as well as set on the
    command line.
  * Reserve and add "VK_IMG_filter_cubic" to the registry, and implement
    script functionality to add and remove validity from existing
    functions. Includes schema and readme changes.
  * Update GL_KHR_vulkan_glsl so push_constants do not have descriptor


Vulkan resource list:
Pages: 1 ... 7 8 [9] 10