標籤: 網頁設計公司推薦

據美國科技部落格 VentureBeat 報導，德國汽車廠商戴姆勒 （Daimler） 將在 2016 年 10 月份舉行的巴黎國際汽車展上，首次推出超長續航距離電動汽車，希望電動 SUV 的市場與特斯拉 Model X 一較高下。   報導中表示，戴姆勒技術研發部門負責人湯瑪斯‧韋伯 （Thomas Weber） 在出席位於德國斯圖加特舉行的記者會時宣布，該公司將會展示續航里程達 500 公里的賓士電動汽車原型車，與特斯拉 Model X 一較高下。不過， Thomas Weber 並未透露這款電動汽車何時上路行駛，只說會在 2020 年前完成這一目標。   目前，戴姆勒和歐洲其他汽車廠商正加緊對電動汽車的投資，以滿足歐盟新的排放標準，並且追趕上美國電動汽車產業的當紅炸子雞──特斯拉 （Tesla） 。另外，戴姆勒在德國本土的競爭對手，福斯旗下子公司包括奧迪與保時捷均已推出續航里程很長的電動汽車原型車，至於 BMW 也正在開發這種車型。   Thomas Weber 表示，戴姆勒將在 2016 年底推出第四代 Smart 電動汽車，包括兩座和四座兩個車型。戴姆勒目前共有 Smart 和 B 系列兩個全電動車型，還有眾多插電式混合動力車，即同時採用電池和汽油引擎驅動的車型。新款混合動力車也在開發之中。據了解，戴姆勒的目標是在 2020 年以前，每年售出超過 10 萬輛電動車。不過，Thomas Weber 拒絕提供 2015 年的銷售資料。   除了長距離續航力的電動車之外，戴姆勒還在開發燃料電池汽車，這種車型使用由氫發的電。該公司原計劃在 2014 年推出燃料電池汽車，但由於價格問題，不得不延遲發表。消息指出，戴姆勒燃料電池汽車 SUV GLC 預計將在 2017 年投產，屆時可能會與豐田 Mirai 展開競爭。   （首圖來源： CC BY 2.0）   （本文授權轉載自《》─〈〉）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

分享嘉賓：孫宇，百度NLP主任研發架構師、語義計算技術負責人。

本文根據作者在“2019自然語言處理前沿論壇”語義理解主題的特邀報告整理而成。

本報告提綱分為以下3個部分：

·    語義表示

·    語義匹配

·    未來重點工作

語義計算方向在百度NLP成立之初就開始研究，研究如何利用計算機對人類語言的語義進行表示、分析和計算，使機器具備語義理解能力。相關技術包含語義表示、語義匹配、語義分析、多模態計算等。

本文主要介紹百度在語義表示方向的技術發展和最新的研究成果艾尼（ERNIE），同時也會介紹工業應用價值很大、百度積累多年的語義匹配SimNet的相關內容，最後再談談未來的重點工作。

 一、語義表示

 計算機理解語言是一個具有很大挑戰的問題。人類在理解語言的過程中，除了語言符號本身的識別，還包含符號背後的語義和知識。舉個例子，當人看到“計算機”這個符號時，腦子里能迅速浮現出計算機的畫面以及和計算機相關的知識和概念，但是這對於計算機就比較困難。所以如何讓計算機能夠表示語言是研究的重點，讓其既能夠蘊含語義信息又可以計算。

當前主要有兩類方法，一是基於形式化規則的方法，如通過構建語義關係網絡來描述語義的信息；二是基於統計的方法，包括主題模型、Word Embedding等技術。

1、百度早期語義表示技術：基於檢索的表示方法

 

2007年百度便開始語義表示研究，最開始的思路是利用搜索引擎來完成。通過搜索引擎把要表示的句子或者詞語檢索出來，再根據檢索的結果通過Term的分析以及網頁的分析，把相關的詞、信息抽取出來，做成語言符號的表示。但是這個表示實際上停留在原始詞彙空間，表示的空間大小依然是詞表的維度，只是相對於One-Hot的表示來說更精細，這個方法是基於1954年Harris提出來的“上下文相似的詞，其語義也相似”的假設。

2、百度早期語義表示技術：Topic Model

 

此後，百度又研究了Topic Model的語義表示技術，這種方法的核心思路是把文檔詞彙空間降維，將文檔映射到淺層主題的分佈上，而這種主題空間要比詞的分佈空間更小一些。通過降維的方法，可以得到每個詞到主題的映射，通過這種主題的方法做語義的表示。

當時百度主要解決的問題是怎樣做這種新文檔的表示，難點是超大規模語料訓練、Online EM、MPI并行化。此外，百度還將自研的主題模型以及一些主流的主題模型整理為工業應用工具，對外開源了百度NLP主題模型工具包FAMILIA。

3、基於DNN的語義表示技術：Word Embedding

 

深度學習技術興起，基於Word Embedding的表示佔了主流，此類技術在各種NLP任務中也表現出色。從NNLM到現在BERT的技術，取得了很多進展。2013年的Word2vec成為NLP標配性的初始化向量，2018年有了上下文相關的詞向量ELMo等。

 

從2013年到2016年，百度也大力投入到Word Embedding的研究，主要研究工作是在工業界如何用大規模分佈式從海量數據中計算詞向量。比如，怎麼才能高效訓練規模為1T的語料？如何構建大規模分佈式文本計算？此外，算法上我們也有一些研究，比如，如何在一百萬超大規模的詞表裡完成Softmax分類？我們通過一些策略和技術，做成啟髮式Hierarchical Softmax的方法，從而有效地提升分類的效率。2016年，百度把訓練的1T的網頁數據和100萬詞表規模的詞向量對業界進行了開放。

4、多特徵融合的表示模型

 

BERT的核心思路還是大力出奇迹，它利用了大規模的無監督數據，同時藉助Transformer這種高性能的Encoder的能力，在MASK建模任務上做了一些優化，導致這個效果能夠在各個任務上顯著提升。

百度實際在2017年進行了這方面的探索，當時是研究基於對話的口語理解問題，這個問題的核心是做意圖的分類和槽位的標註。難點在於口語理解的問題標註語料非常少。當時想能不能利用海量的搜索語料做Pre-Training，把這個Model作為初始化模型用到下游的SLU任務里。

我們採用20億搜索的Query，通過LSTM模型做單向Language Model的預訓。我們發現在SLU任務上，在各個垂類上樣本數的增加非常顯著，從10個樣本到2000個樣本。但遺憾的是，當時研究的是一個超小規模數據上效果，即2000的數據，在2萬甚至是20萬的數據上的表現並沒有研究，同時在其他應用的通用性上的研究也不夠充分。

5、知識增強的語義表示模型

 BERT提出后，我們發現一個問題，它學習的還是基礎語言單元的Language Model，並沒有充分利用先驗語言知識，這個問題在中文很明顯，它的策略是MASK字，沒有MASK知識或者是短語。在用Transformer預測每個字的時候，很容易根據詞包含字的搭配信息預測出來。比如預測“雪”字，實際上不需要用Global的信息去預測，可以通過“冰”字預測。基於這個假設，我們做了一個簡單的改進，把它做成一個MASK詞和實體的方法，學習這個詞或者實體在句子裏面Global的信號。

 

基於上述思想我們發布了基於知識增強的語義表示ERNIE(1.0)。

 

我們在中文上做了ERNIE（1.0）實驗，找了五個典型的中文公開數據集做對比。不管是詞法分析NER、推理、自動問答、情感分析、相似度計算，ERNIE（1.0）都能夠顯著提升效果。

 

英文上驗證了推廣性，實驗表明ERNIE（1.0）在GLUE和SQuAd1.1上提升也是非常明顯的。為了驗證假設，我們做了一些定性的分析，找了完形填空的數據集，並通過ERNIE和BERT去預測，效果如上圖。

 

我們對比了ERNIE、BERT、CoVe、GPT、ELMo模型，結果如上圖所示。ELMo是早期做上下文相關表示模型的工作，但它沒有用Transformer，用的是LSTM，通過單向語言模型學習。百度的ERNIE與BERT、GPT一樣，都是做網絡上的Transformer，但是ERNIE在建模Task的時候做了一些改進，取得了很不錯的效果。

 

在應用上，ERNIE在百度發布的面向工業應用的中文NLP開源工具集進行了驗證，包括ERNIE與BERT在詞法分析、情感分類這些百度內部的任務上做了對比分析。同時也有一些產品已經落地，在廣告相關性的計算、推薦廣告的觸發、新聞推薦上都有實際應用。目前模型已經開源（

7月31日，百度艾尼（ERNIE） 再升級，發布了持續學習語義理解框架ERNIE 2.0，同時藉助飛槳（PaddlePaddle）多機多卡高效訓練優勢發布了基於此框架的ERNIE 2.0 預訓練模型。該模型在共計16个中英文任務上超越了BERT 和XLNet，取得了SOTA 效果。

二、語義匹配

1、文本語義匹配及挑戰

 

語義匹配在工業界具有非常大的技術價值，它是一個很基礎的問題，很多產品、應用場景都會用到它。很多問題也可以抽象為語義匹配問題，比如，搜索解決的是Query和Document相關性的問題，推薦解決的是User和Item關聯度、興趣匹配度的問題，檢索式問答解決的是問題與答案匹配度，以及檢索對話Query和Response的匹配問題。由於語言比較複雜，匹配靠傳統的方法是比較難的。

 

百度搜索在匹配相似度計算方面做了較多工作，包括挖掘同義詞、詞級別泛化、語義緊密度、對齊資源挖掘、共線關聯計算等。

 

2、神經網絡語義匹配模型：SimNet

2013年百度提出SimNet技術，用於解決語義匹配的問題。這個技術基於DNN框架，沿襲Word Embedding的輸入，基於End-to-End的訓練做表示和匹配，並結合Pairwise訓練。當時，微軟也提出了DSSM，中科院、CMU等研究機構也做了很多語義匹配研究工作。

 

這幾年，百度整體上從語義匹配的框架上做了升級，抽象了三個層次，改進了基礎算法，包括擴展針對不同場景的模型，比如字和語義的匹配模型；在不同的應用場景，針對問題網頁和問題答案的匹配情況分別做了針對性地優化，集成到了匹配框架里。

 

匹配算法主要有兩種範式，一種是基於表示的匹配，首先把自然語言表示成向量，然後再進行相似度計算，這方面也有一些改進，主要是做一些Attention；另一種新匹配範式Interaction-based Model，強調更細的匹配，即一個句子的表示不再是一個向量，而是原來的Term，並把原來的位置信息保留，最後以Attention的方式表示，讓匹配更加充分和精細。

 

關於SimNet技術前瞻性工作，2019年百度在IJCAI上發表了一篇論文“RLTM：An Efficient Neural IR Framework for Long Documents”，其中長文本匹配有一個很大的挑戰，就是讓Document直接做表示，如果文本太長，很多信息會丟失，計算效率也非常低。但如果我們先做一個粗匹配，選擇好相關的句子以後再做精細化的匹配，效果就比較不錯。

3、SimNet的應用

 

SimNet技術在百度應用非常廣泛，包括搜索、資訊推薦、廣告、對話平台都在使用。

 

搜索是百度非常重要的產品，搜索有兩個核心功能，下圖的左側上方是搜索的精準問答，通過問答技術把精準答案直接呈現出來；下方是自然排序，主要採用LTR框架和相關性、權威性、時效性等Features。

SimNet在百度搜索的發展可以分為三個時期。萌芽期，上線了BOW Model，這是業界第一次在搜索引擎上線DNN模型；發展期，做了CNN、RNN，並把知識融合進RNN，在語義相關性計算中，除了標題很多其他文本域在相關性建模中也很重要，所以，我們還做多文本域融合匹配的Model；拓展期，除了相關性，在權威性、點擊模型和搜索問答上都有推廣和使用。

 

在搜索中，SimNet是用超大規模用戶反饋數據訓練。那麼如何依靠海量數據來提升效果？頻次如何選？我們發現模型應用效果並不是靜態的，而是動態變化的，特別是搜索反饋的數據，隨着時間的推移，網民在搜索的時候，Term的分佈、主題的分佈會發生變化，所以數據的時效性影響還是非常大的。

 

除了模型上的融合，我們把Bigram知識也融入了進去。儘管RNN已經很厲害了，但加入知識、模型還是會有很大地提升。

4、新模型：SimNet-QC-MM

 

另外，我們還做了Query和網頁正文的建模，由於Query中每個詞都有一定的用戶意圖，所以在模型建模時，會考慮Query中每個詞被Title和正文覆蓋的情況，並基於Matching Matrix匹配方法計算。此外，搜索架構也做了配合改進，搜索也上線了基於GPU和CPU的異構計算架構。

 

上圖是一個案例，“羋殊出嫁途中遇到危險”，我們後來做了一些分析，發現“危險”和“投毒”有很強的語義關聯，就把這個結果排了上去。

5、語義模型壓縮技術

 

在模型裁減壓縮上，我們也做了很多工作，包括量化的壓縮和哈希技術的壓縮。整個語義的模型基本上已經從依靠一個Embedding 32bits來存，到現在達到Embedding一維僅需4bits，節省線上DNN匹配模型87.5%的內存消耗。這項技術，除了搜索的使用，移動端的使用也有非常大的價值。

 

SimNet技術除了百度搜索，包括Q&A，Query和Answer的匹配等方面都有一些嘗試。

三、未來重點工作

接下來我們會在通用語義表示方面進一步研究與突破，除了如何充分地利用先驗知識，利用一些弱監督信號外，模型方面也會進一步探索創新。技術拓展上，跨語言、多語言表示，面向生成、匹配等任務的表示，面向醫療、法律等領域的表示，多模態表示等都是我們的一些重點方向。

RLTM論文地址：

至此，“2019自然語言處理前沿論壇”語義計算主題《百度語義計算技術及其應用》的分享結束。如果大家想更深入地了解百度持續學習語義理解框架艾尼（ERNIE），歡迎加入ERNIE官方交流群（QQ群號：760439550）。

——————-

划重點！！！

掃碼關注百度NLP官方公眾號，獲取百度NLP技術的第一手資訊！

加入ERNIE官方技術交流群（760439550），百度工程師實時為您答疑解惑！

立即前往GitHub（  ）為ERNIE點亮Star，馬上學習和使用起來吧！ 

 

最強預告！！！

11月23日，艾尼（ERNIE）的巡迴沙龍將在上海加場，乾貨滿滿的現場，行業A級的導師，還有一群志同道合的小夥伴，還在等什麼？感興趣的開發者們趕緊掃描下方“二維碼”或點擊“鏈接”報名參加吧！

 

報名鏈接：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

騰訊開源再次迎來重磅項目，14日，騰訊正式宣布開源高性能圖計算框架Plato，這是在短短一周之內，開源的第五個重大項目。

相對於目前全球範圍內其它的圖計算框架，Plato可滿足十億級節點的超大規模圖計算需求，將算法計算時間從天級縮短到分鐘級，性能全面領先領先於其它主流分佈式圖計算框架，並且打破了原本動輒需要數百台服務器的資源瓶頸，現在，最少只需要十台服務器即可完成計算。

騰訊Plato團隊負責人於東海表示：“Plato已經支持騰訊內部包括微信在內的眾多核心業務，尤其是為騰訊超大規模社交網絡圖數據的各類計算提供支撐，解決了現有其他計算框架無法在有限資源和有限時間內完成計算的難點。Plato不僅為騰訊創造了巨大的業務價值，開源后還將持續推動圖計算技術和行業的協同發展，加速創新。”

實際上，圖計算的“圖”並不是指普通的圖像和照片，而是用於表示對象之間關聯關係的一種抽象數據結構，圖計算就是以圖作為數據模型來表達問題並予以解決的過程。圖計算可以將不同來源、不同類型的數據融合到同一個圖裡進行分析，得到原本獨立分析難以發現的結果，因此成為社交網絡、推薦系統、網絡安全、文本檢索和生物醫療等領域至關重要的數據分析和挖掘工具。

Plato是騰訊內部圖計算TGraph團隊整合內部資源自主研發的一款高性能圖計算框架，取名Plato是為了致敬偉大的數學家柏拉圖，目前騰訊雲大數據團隊正在封裝Plato，即將對所有開發者開放使用。

據了解，Plato的計算性能方面極其強悍，比目前市場上最為領先的圖計算框架Spark GraphX還高出1-2個數量級，它將算法計算時間從天級縮短到分鐘級，性能提升數十倍，也標志著圖計算全面進入分鐘級時代；另外一個巨大優勢是，Plato在內存消耗方面遠小於主流的圖計算框架，比Spark GraphX減少1－2個數量級，僅需10台服務器左右的中小規模集群，即可完成超大規模圖計算，相比此前動輒需要數百台服務器的限制，資源壓力和計算成本都得到了極大降低。
目前，Plato主要提供兩大核心能力：騰訊數據量級下的離線圖計算和騰訊數據量級下的圖表示學習。同時Plato天然適配Kubernetes、YARN等資源調度平台，並提供支持主流文件系統的多種接口，能為開發者提供更友好的運行環境。
架構設計上，Plato框架的核心是自適應圖計算引擎，它能夠根據不同類型的圖算法，提供多種計算模式供開發者靈活選擇，包括自適應計算模式、共享內存計算模式和流水線計算模式等。另外，還設計了良好的接口支持接入新的計算通信模式。

Plato整體架構圖

在計算引擎之上，Plato為算法設計者或具體的業務提供多層次接口：從底層的API，到圖算法庫，再到為具體業務量身打造的“解決方案”——圖工具集。通過這些應用層的接口和工具，Plato還可以把離線計算結果與其他機器學習算法相結合，共同支撐頂層的不同業務。

值得一提的是，目前Plato的算法庫中的圖特徵、節點中心性指標、連通圖和社團識別等多種算法都已經開源，未來還將進一步開源更多的算法。

Plato高性能、可擴展、易插拔的特性在社交網絡、推薦系統、生物醫療等領域應用前景廣闊，例如定期對網頁進行影響力排序以提升用戶的搜索體驗、分析龐大的社交網絡結構以便精準地為用戶推薦服務、通過子圖匹配等方式了解蛋白質間的相互作用從而研製更有效的臨床醫藥等。

自去年930架構調整以來，開源協同成為騰訊技術發展的重要戰略之一，並帶動了重磅項目密集對外開源。就在上周的Techo開發者大會上，騰訊正式宣布TubeMQ、Tencent Kona JDK、TBase、TKEStack四大重點項目開源。隨着Plato的開源，騰訊在開源領域又添大動作。據悉，騰訊已經在Github上已經開源了89個項目，超過1000個貢獻者參与了開源貢獻，擁有超過26萬個Star數，在Github全球公司貢獻榜上居於前列。

Plato開源地址：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※南投搬家前需注意的眉眉角角，別等搬了再說!

目錄

示例代碼託管在：

博客園地址：

華為雲社區地址：

附件PPT來自開發文檔。術語里的cc指的是Chromium Compositor

一直以來都想了解瀏覽器合成層的運作機制，但是相關的中文資料大多比較關注框架和開發技術，這方面的資料實在是太少了，後來在chromium官方網站的文檔里找到了項目組成員malaykeshav在 2019年4月的一份關於瀏覽器合成流水線的演講PPT，個人感覺裏面講的非常清楚了，由於沒有找到視頻，有些部分只能自行理解，本文僅對關鍵信息做一些筆記，對此感興趣的讀者可以在文章開頭的github倉庫或附件中拿到這個PPT自行學習。

摘要

1.合成流水線

合成流水線，就是指瀏覽器處理合成層的工作流程，其基本步驟如下：

大致的流程就是說Paint環節會生成一個列表，列表裡登記了頁面元素的繪製指令，接着這個列表需要經過Raster光柵化處理，並在合成幀中處理紋理，最後的Draw環節才是將這些紋理圖展示在瀏覽器內容區。

2. 預定義UI層

chromium中預定義了一些指定類型的UI層，大致分為：

• Not Drawn – 為了處理透明度或濾鏡效果、transform變形或者clip剪裁的非繪製層
• Solid color layer – 固有顏色層
• Painted texture layer – Texture紋理會在這個層執行paint渲染和後續的rasterized光柵化任務
• Transferable resource layer – 共享資源層，可能是GPU裏面的Texture紋理也可能未來會發給GPU的位圖
• Surface layer – 臨時佔位層，因為自頂向下遍歷layer樹時子樹都還沒處理，需要先佔位最後再填充
• Nine patch layer – 用於實現陰影的層

3. paint是什麼意思

每個層layer是由若干個views組成的，所謂paint，就是每個views將自己對應圖形的繪製指令添加到層的可展示元素列表Display Item List里，這個列表會被添加到一個延遲執行的光柵化任務中，並最終生成當前層的texture紋理（可以理解為當前層的繪製結果），考慮到傳輸性能以及未來增量更新的需求，光柵化的結果會以tiles瓦片形式保存。在chrome中也可以看到頁面瓦片化拆分的結果:

4. 分層的優勢和劣勢

分層的優勢和劣勢也在此進行了說明，和之前我們主動思考的答案基本一致（暗爽一下）。

5. 視圖屬性及其處理方式

views中支持的屬性包含Clip剪裁，transform變換,effect效果（如半透明或濾鏡等）,mask遮罩，通常按照後序遍歷的方式自底向上進行遍歷處理。

clip剪裁的處理方式是在父節點和子節點之間插入一個剪裁層，用來將其子樹的渲染結果剪裁到限定的範圍內，然後再向上與父級進行合併；

transform變換直接作用於父節點，處理到這個節點時其子樹都已經處理完畢，直接將整體應用變形即可；

effect效果一般直接作用於當前處理的節點，有時也會產生交叉依賴的場景；

PPT第40頁中在介紹effect效果處理時描述了兩種不同的透明度處理需求，從而引出了一個Render Surface的概念，它相當於一個臨時的層，它的子樹需要先繪製在這個層上，然後再向上與父節點進行合併，屏幕就是是根級的Render Surface。

6. Quads

Layer遍歷處理輸出的結果被稱為Quads（從意思上理解好像就是指輸出了很多個矩形方塊），每個quad都持有它被繪製到目標緩衝區所需要的資源，根據它持有的資源不同可以分為：

• Solid Color-固定顏色型
• Texture– 紋理型
• Tile– 瓦片型
• Surface– 臨時繪圖表面型
• Video – 視頻幀型
• Render Pass – Render Surface類型的佔位區，Render Surface子樹處理完后填充到關聯的Render Pass

7. Compositor Frame

合成層真正的工作要開始了，主角概念Compositor Frame(合成幀)登場，它負責將quads合併繪製在一起，膠片里59-62頁非常清楚地展示了合成的過程，最終輸出的結果就是根節點的紋理。

chromium是多進程架構，Browser Process瀏覽器進程會對菜單欄等等容器部分的畫面生成合成幀來輸出，每個網頁的Render Process渲染進程會對頁面內容生成合成幀來輸出，最終的結果都被共享給GPU ProcessGPU進程進行聚合併生成最終完整的合成表面，接着在Display Compositor環節將最後的位圖展示在屏幕上。

8. 關於光柵化以及渲染方式

膠片里並沒有描述具體的光柵化的處理過程，但是layer輸出的quads看起來應該是光柵化以後的結果，推測應該是處理Display Item List中的繪圖指令時也和WebGL類似，經過頂點着色器和片元着色器的遍歷式處理機制，並在過程中自動完成像素插值。

9.【重要】軟件渲染和硬件渲染的區別

聲明：本節內容是個人理解，僅用作技術交流，不保證對！

軟件渲染和硬件渲染的區別對筆者而言一直非常抽象，只是知道基本概念。後來在（國內可能無法訪問）中《Compositor Thread Architecture》這篇合成器線程架構的文章中找到了一些相關描述，也解開了筆者心中一直以來的疑惑，相關部分摘抄如下：

Texture Upload

One challenge with all these textures is that we rasterize them on the main thread of the renderer process, but need to actually get them into the GPU memory. This requires handing information about these textures (and their contents) to the impl thread, then to the GPU process, and once there, into the GL/D3D driver. Done naively, this causes us to copy a single texture over and over again, something we definitely don’t want to do.

We have two tricks that we use right now to make this a bit faster. To understand them, an aside on “painting” versus “rasterization.”

• Painting is the word we use for telling webkit to dump a part of its RenderObject tree to a GraphicsContext. We can pass the painting routine a GraphicsContext implementation that executes the commands as it receives them, or we can pass it a recording context that simply writes down the commands as it receives them.
• Rasterization is the word we use for actually executing graphics context commands. We typically execute the rasterization commands with the CPU (software rendering) but could also execute them directly with the GPU using Ganesh.
• Upload: this is us actually taking the contents of a rasterized bitmap in main memory and sending it to the GPU as a texture.With these definitions in mind, we deal with texture upload with the following tricks:
• Per-tile painting: we pass WebKit paint a recording context that simply records the GraphicsContext operations into an SkPicture data structure. We can then rasterize several texture tiles from that one picture.
• SHM upload: instead of rasterizing into a void* from the renderer heap, we allocate a shared memory buffer and upload into that instead. The GPU process then issues its glTex* operations using that shared memory, avoiding one texture copy.The holy grail of texture upload is “zero copy” upload. With such a scheme, we manage to get a raw pointer inside the renderer process’ sandbox to GPU memory, which we software-rasterize directly into. We can’t yet do this anywhere, but it is something we fantasize about.

大概翻譯一下，方便英語水平一般的小夥伴理解，GPU處理圖片的方式是按照Texture進行貼圖的，對此不熟悉的小夥伴可以查看筆者以前發的有關Three.js相關的博文。

紋理上傳:
處理紋理的挑戰之一就是它是在渲染進程（可以理解為單個Tab網頁的進程）的主線程里進行的，但是最終需要將其放入GPU內存。這就需要將紋理數據遞交給合成器線程，然後再交給GPU進程（Chromium架構里有專門的GPU進程用來專門處理和GPU之間的協作任務），最後再傳遞給底層的Direct3D或OpenGL（也就是圖形學的底層技術），如果只是按照常規流程來處理，就會需要一次又一次來複制生成的紋理數據，這顯然不是我們想要的。
我們現在使用了兩個小方法來使這個流程變得快一點。它們分別作用於painting（繪製）和rasterization（光柵化）兩個階段。

• 1號知識點！！！Painting我們用來告訴webkit為RenderObject Tree的來生成對應的GraphicsContext。通過給painting routine（繪製流程）傳遞一個GraphicsContext的具體實現來執行這些已經編排好的繪製命令，也可以傳遞一個record context（記錄上下文）只是簡單地把繪圖命令都記錄下來。
• 2號知識點！！！Rasterization（光柵化）是指Graphics context關聯的繪圖命令實際被執行的過程。通常我們使用CPU（也就是軟件渲染的方式）來執行光柵化任務，也可以直接使用GPU來渲染（也就是硬件渲染的方式）。
• 上傳：指在主線程存儲區獲取到光柵化以後的位圖內容然後將它作為紋理上傳給GPU的過程，考慮到上述已經提及的定義，上傳過程是如下來處理的：
  • 瓦片繪製：我們在webkit中使用recording context來簡單地記錄Graphics Context的操作指令，將它存儲為SkPicture類型（直接使用軟件光柵化時生成的是SkBitmap類型），隨後可以從一張picture裏面光柵化處理得到多個紋理瓦片。
  • 共享內存：在軟件渲染的方式中，光柵化的結果會被存儲在renderer進程的堆內存里，現在不這樣搞了，我們重新分配了一塊共享緩衝區，然後通過它來傳遞相關對象，GPU進程隨後在獲取紋理時直接從共享內存中獲取就行了，這樣就避免了數據的拷貝。
    總的來說，紋理上傳的過程幾乎是零拷貝的。利用這樣的結構，我們在renderer進程（也就是網頁的渲染進程）的沙箱環境內也可以獲取到指向GPU 內存的指針，而在軟件光柵化的過程中，是直接將位圖結果放在這裏的。

• Painting: this is the process of asking Layers for their content. This is where we ask webkit to tell us what is on a layer. We might then rasterize that content into a bitmap using software, or we might do something fancier. Painting is a main thread operation.
• Drawing: this is the process of taking the layer tree and smashing it together with OpenGL onto the screen. Drawing is an impl-thread operation.
• painting:表示的過程是向Layers對象查詢層內容，也就是讓webkit告訴我們每一層上面到底有什麼。接下來我們就可以使用軟件光柵化的方式將這些內容處理為位圖，也可以做一些更牛的事情，painting是一個主線程行為。
• drawing：是指將Layer中的內容用OpenGL繪製在屏幕上的過程，它是另一個線程中的操作。

概念比較多沒有基礎的讀者可能理解起來有難度，我嘗試用自己的話複述一下：

【軟件渲染】的模式下，在paint時會直接利用Graphics Context繪圖上下文將結果繪製出來，在一個SkBitmap實例中保存為位圖信息；【硬件渲染】的模式下，在paint時傳入一個SkPicture實例，將需要執行的繪圖命令保存在裏面先不執行，然後通過共享內存將它傳給GPU進程，藉助GPU來最終去執行繪圖命令，生成多個瓦片化的位圖紋理結果（OpenGL中頂點着色器向片元着色器傳遞數據時可以自動進行數據插值，完成光柵化的任務）。 純軟件渲染里嚴格說是沒有合成層概念的，因為最終輸出的只有一張位圖，按照順序從下往上畫，和畫到一個新層上再把新層貼到已有結果上其實是一樣的。

不管使用哪種途徑，paint動作都是得到位圖數據，而最終的draw這個動作是藉助OpenGL和位圖數據最終把圖形显示在显示器上。

所以【硬件渲染】就是渲染進程把要做的事情和需要的數據都寫好，然後打包遞給GPU讓它去幹活。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

日本松下（Panasonic）、中國北京汽車宣布將共同投資數百億日圓，於中國天津成立合資公司，用於生產純電動車之核心零組件，搶攻中國龐大的電動車市場商機。

《日本經濟新聞》中文版、日本《共同社》等多家媒體報導，松下社長津賀一宏日前曾前往中國，與北汽公司商討成立合資公司一事，並達成協議。北汽旗下兩家汽車零組件廠商將出資54%、松下的中國公司則出資46%，合資公司計畫在2018年左右開始投入量產，主要產品是電動車空調的電動壓縮機，供貨對象則是北汽公司與其他公司。

電動車的空調電力來自蓄電池。為優化電動車的行駛里程，電動車空調壓縮機須能以更好的效率控制冷、暖風，因此性能需求較一般汽油車高。性能佳的空調壓縮機，將有助提高電動車的續航力。

中國市場蓬勃，松下積極搶進

在政府的大力推動下，中國已在2015年成為全球最大電動車市場之一。《日經》指出，日廠豐田決定在2018年起於中國生產插電式混和動力車（PHEV）；而松下與北汽的合作，則象徵松下在中國市場的在地化布局行動。未來預計還會有更多日商在中國展開本土化生產。

松下已宣布退出電視面板製造事業，並轉而提高在住宅、汽車等兩大領域的業務著力。2015財年，松下所生產的車載導航儀與車載電池等零組件銷售額達1.3兆日圓。松下表示，到2018年度時，希望上述零組件銷售額能進一步提高到2兆日圓。

松下在電動車、鋰電池方面的海外投資，包括與美商特斯拉（Tesla）合作在美國內華達州建立的鋰電池工廠Gigafactory，以及中國大連建立的車用鋰電池工廠。大連工廠預計在2017年正式投產。

北汽成立於1953年，為國有企業。在電動車、PHEV領域，北汽是中國僅次於比亞迪（BYD）的第二大業者。北汽計畫到2020年時生產40萬輛電動車。

（照片來源：Wikipedia）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!