I have a hobby project that could use some gpu compute, I figured it would also be a great time to test out the new WebGPU API. So far I tried looking at various WebGPU demos on latest versions of both chrome canary and firefox dev edition, both having webgpu flag enabled beforehand but nothing works. In console I get various errors about some vertex buffer or some context not existing, big piles of red.
So.. I was under the impression that I could actually check it out? Does this work for anyone? Is it broken rn?
Possibly relevant system information: Windows 10, Nvidia M3000M
Can you show me the error message?
If it's your own example, I guess you may not have configured how to introduce it .wgsl file.
webpack4: rules: [{ test: /\.wgsl$/, use: "raw-loader" }]
webpack5: rules: [{ test: /\.wgsl$/, type: "asset/source" }]
vite: import xxx from './xx.wgsl?raw
I've been toying with WebGPU in Chrome and it seems to be possible to test without major issues.
It does seem that a number of demos out there are outdated, using an older API or syntax for WSGL, but most of the time I'm just getting warnings and not errors. Those warnings are quite informative and have been straightforward to fix too (eg: replacing [[location(0)]] with #location(0)).
As a tip, I've been using it with TypeScript and combining it with #webgpu/types makes the development way easier.
Here an answer to the main question, if webgpu can be tested yet:
As #Rob mentioned as well, caniuse.com/webgpu shows that
no browser has it activated by default yet
but you CAN TEST IT by activating it as experimental feature, there just won't be many users able to see your work if you were to publish the site.
(august 2022)
As of January 2023 you can enable WebGPU in Canary builds of Chrome if you enable the feature through about://flags.
It's also possible to view some examples (e.g. the ones here) in shipping versions of Chrome. You can request a site token for the origin trial, which will make the feature available for your site--however the site says "The origin trial is expected to end in Chrome 109 (Feb 1, 2023)."
Beta and Nightly builds of Firefox have an implementation of WebGPU that's not as fully featured.
As other answers suggest though, at time of writing it's still pretty experimental and there are very few good demos beyond spinning cubes and some basic particle systems.
Related
I've recently released a new version of my extension as V3.
Since the day I released the extension, I see that older versions of my extension are gaining more users. This is super weird. I haven't done anything with older versions, and I can clearly see in the Chrome Web Store statistics of weekly users, that there is a rise in the number of users, right when my extension was released with MV3. This can't be a coincidence.
Did anyone else see this? Any idea why this is happening? I want all of my users to be on the latest version of my extension, especially on the MV3 one.
I tried looking around the web for answers, but couldn't fin d anyone with this issue.
I know it sounds funny, because who would complain about having more users, but I really want to understand why this is happening.
Thanks
Originally posted here.
I was under the impression that WebGL should work on Chrome on pretty much any desktop device, but that it may fall back to software rendering in some cases (assuming you don't pass failIfMajorPerformanceCaveat=true when getting the context). However in practice this seems not to be true for a substantial number of users on both Macs and Windows (especially, but not limited to, those within some kind of managed corporate IT system).
As far as I can tell, on all hardware/setups where WebGL is disabled in Chrome, it is possible to run it using a different browser (FF, and even IE11). I believe that IE11 only uses software and FF may be less strict with its blacklisting of GPUs, but that doesn't explain why Chrome can't switch to software when hardware is unavailable. Indeed, in some cases, overriding the GPU blacklist in Chrome does seem to work (but presumably is not a good idea).
So firstly, could I check that my assessment of the situation is correct? And secondly, could anyone suggest how to force software rendering (i.e. flags etc.) and/or point me at an issue discussing this?
Any advice would be very much appreciated - even if the process is rather involved it is still worth knowing about as it may be workable for our clients.
update:
#gman points out that there is no software emulation on Macs in Chrome, but that still leaves the question of what's going on in windows.
update 2:
(to partly answer my own question): it seems that (at least on 32bit Chrome on windows) if you go to chrome://components and see SwiftShader is at version 0.0.0, then simply hitting the update button should download the latest veriso,n and hey presto..it works. Not sure about 64bit Chrome though.
update 3:
As #Nicloas says, M59 in Chrome (to be released in May/June 2017) should fix this issue in Chrome on Windows and Linux, with Mac following later.
Quoting my own answer from swiftshader#googlegroups.com:
I'm happy to let you know that with the upcoming M59 release of Chrome, we have integrated SwiftShader to provide seamless fallback support for WebGL in case the GPU is blacklisted.
We were previously only using SwiftShader as a separately downloaded component, which indeed does not work on managed corporate systems, and required a browser restart. Integrating SwiftShader was only possible after open-sourcing it and substantially reducing its binary size.
You can test it today on Windows using Chrome Canary or the Beta channel, and specifying the --disable-gpu launch flag. Linux is also supposed to work but the libraries were mistakenly not shipped as part of the beta package, which we hope will be rectified in the next update and before it reaches the Stable channel. We haven't started integrating Mac OS X support yet, because Chrome works significantly differently there, but it's on our radar.
As my application only support Chrome browser and try to test it using IBM RFT.
Issues:
Browser enablement test is fail while testing Chrome from Enable Environment in RFT
Due to that not able to capture any objects in Chrome using RFT
Tried the below steps as well but not able to resolve :
https://www.ibm.com/developerworks/community/forums/html/topic?id=1e5ec381-03c3-4ab6-a9b8-4ce98f592b3b
If anyone face the same issue previously please do reply.
If you are using Chrome 45(Where NPAPI is disabled ) or above , you need to install RFT 8.6.0.5 on top of which a test fix is available that will allow you to execute/playback your existing scripts. To get the testfix you will need to contact the product technical support.
Rational Functional Tester old versions doesn't work with Chrome anymore. In their last release notes (fix pack 4) the greatest "feature" is to make it work with newer versions of Chrome. I have the version just before this one and I guarantee that it doesn't work with Chrome. The update process is really error prone. Reserve at least day to do it.
this morning I noticed my Chrome updated to Chrome 22 and that the search in the top right has been removed and can now be accessed with ctrl-f.
I also noticed that ctrl-shift-f is no longer working as expected... (but this is inconsistent)
The global search has been a huge time saver for me, and now sometimes it doesn't work until I've viewed a script at least once.
For example, I have 5 scripts that I know all contain "fn_init"
I search for fn_init and nothing comes up.
I open one of those scripts and then ctrl-shift-f again, and finally get a matching result for just the one file...
Is this working as intended? Am I missing an option or something? My dev tools config options are:
General
Disabled cached
Sources
Show folders checked
Search in content scripts checked
Also: how can I install an older version of Chrome and stop it from updating automatically?
To get an older version of Chrome your best bet is to find a build of Chromium from https://chromium-build.appspot.com/p/chromium/console however if this if for devtools stability you are missing out on a lot of new features and bug fixes.
As for Search across all files it is still there and CTRL-SHIFT-F on Windows and CMD-OPT-F on Mac. See Addy Osmani's post https://plus.google.com/115133653231679625609/posts/e4W2kdrFJY9
If you find issues as bugs, it is better to raise the issue on http://crbug.com/new as it will get direct attention from the engineering team there.
We have used HTML5s navigator.geolocation and found it to be very good on iOS and Android smartphones. Now the users want the same HTML5 web app to run on a laptop with external GPS. Using Windows 7 on the laptop I just can't figure a way to share the location to a HTML5 browser (tried Safari, FF, IE, Chrome). For testing I am using a GlobalStat BU-353 USB GPS which works standalone and I have found GPSDirect (cool freeware) to feed that signal to Win7 Sensor Location Services but still the HTML5 browsers do not see the GPS.
Anyone had any luck with this please ?
I was looking for similar solution and found this: GpsGate.
It is standalone application which connects to almost any GPS device and publishes it's data in several forms including browsers (through Javascript API which in turn makes jsonp call to http://localhost:12175/gps/[getVersion|getGpsInfo]?jsonp=padding). It's not compatible with Geolocation API, but I think writing simple adapter shouldn't take much time. Another good thing is that it's Express edition is free for both private and commercial use (link).
EDIT: After some digging I found this patch which adds geolocation compatible adapter for GpsGate to some other geolocation library.
Issue 45535 is beginning to address this in the Chromium feature requests. As of Jan 5 2012, the feature has been marked as "started".
Feature request: http://code.google.com/p/chromium/issues/detail?id=45535
As long as you only need a single browser for your client solution (and not a universal solution) this will solve your problem.
A great method to start testing and keeping an eye out for this issue is to download Chrome Canary, which is usually 2 versions ahead of the Chrome release. I'm right now using v18 on Canary and it's great since I've been keeping an eye on the websocket schema changes.
You can find Canary here: http://tools.google.com/dlpage/chromesxs