This is not to say that there aren't vulnerabilities in the drivers, that said the only 3 PE/CE vulnerabilities in the NVIDIA driver in the past 4+ years were not exploitable through any vectors you are suggesting since they involved NVAPI, AMD doesn't discloses vulnerabilities openly IIRC.
To exploit a vulnerability in the manner you suggest you need to break through the sandboxing and security model of the browser, break the sandboxing and security model of the web API you are using e.g. WebGL break through the security model and sandboxing of the actual API e.g. DirectX on Windows, break through the sandboxing and security model of the user mode driver, and then exploit a vulnerability in a kernel mode driver that might have actual access to something you might care about.
And even then it's not that simple in WDDM for example even in pure kernel mode you'll have issues accessing memory out of the bounds of your application due to how GPU resource are managed, pinned and translated.
To put it simply every process accesses a "virtual GPU" through it's own endpoint, there is a zero-out process which is invoked on both the GPU and system memory when any buffer is allocated or accessed, and there is an out-of-bounds behaviour control running on the GPU independent of the driver, basically once you access (read or write) out of bound memory the GPU would terminate the loaded kernel which would crash your application and the driver would be cycled (restarted).
The out of bound memory is a real annoyance anyone who's worked with GPGPU especially CUDA is pretty familiar with, it's the #1 app killer (as far as code errors go) and for good reasons, even a privileged kernel running natively on the GPU is protected from abusing it's own rights.
There is a reason why the graphics driver is in user mode, and why the memory is virtualized.
The application doesn't have traditional DMA unless you load a privileged kernel which you can't do via a browser.
An application can't access the memory of another application via the display driver this is a solved issue.
Open web people can not endorse DRM, once a open web persons endorses DRM they cease to be a Open Web Person.
Claiming to be a Open Web supported while also endorsing closed items like DRM, is an objective violation of the Philosophy of the open web
People over use and misappropriate the charge of No True Scots Man
In the end, there'll be a standard DRM multimedia format whether it's "endorsed" by Open Web people or not; if browsers don't build in support for it, then it'll just build support for itself, via the APIs that do exist: WebGL, WebRTC, ASM.js, etc. Consumers will get their media; they'll just be running an opaque blob of Javascript in the browser to get it, instead of the browser doing the job—cleanly—itself.